gmane.mail.nmh.devel

nmh dependence on metamail

Dale Alspach — 2013-05-18T16:20:00

Ubuntu 12.04 includes a package for nmh but none for metamail. Someone
noted this in a bug report. Debian seems to have abandoned metamail.
In Ubuntu 10.xx I was able to make it work from source.
The source that I have for metamail 2.7 will not compile on my upgraded
system and I am not knowledgeable enough to try to fix it.

Are there any replacements for metamail  or an updated source?

exmh seems to work fine.

Dale Alspach

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Date syntax

2013-05-17T15:40:09

Would somebody please point me to a specification of the date syntax used by pick and sortm.

    Norman Shapiro

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

reason: 554 5.7.0 Message Size Violation

2013-05-04T17:41:28

This is the first I've ever heard of this rejection reason. The message consisted, almost entirely, of an attachment, Spec_05_04_10:04.zip,  a 471,282 byte zip file.

Is there anything I can do, short of breaking the attachment into several pieces, and sending separately?

Is there some way, other than trial and error, to determine the size limit?
--------

------- Forwarded Message

Return-Path: <MAILER-DAEMON< at >rawbw.com>
X-Original-To: norm< at >localhost
Delivered-To: norm< at >localhost.dad.org
Received: from lad.dad.org (localhost [IPv6:::1])
by lad.dad.org (Postfix) with ESMTP id 9973360E78
for <norm< at >localhost>; Sat,  4 May 2013 10:08:25 -0700 (PDT)
Received: from imap.rawbw.com [198.144.192.43]
by lad.dad.org with IMAP (fetchmail-6.3.17)
for <norm< at >localhost> (single-drop); Sat, 04 May 2013 10:08:25 -0700 (PDT)
Received: from ns2.adzone.com (ns2.adzone.com [96.247.50.174])
by mail1.rawbw.com (8.14.2/8.14.2) with ESMTP id r44H73eX067605
for <soft< at >rawbw.com>; Sat, 4 May 2013 10:07:08 -0700 (PDT)
Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45])
by ns2.adzone.com (8.14.5/8.14.5) with ESMTP id r44H2LGu118336
for <norm< at >dad.org>; Sat, 4 May 2013 10:02:21 -0700
Received: from localhost (localhost)
by shell0.rawbw.com (8.14.4/8.14.4) id r44H72Kw096661;
Sat, 4 May 2013 10:07:02 -0700 (PDT)
(envelope-from MAILER-DAEMON)
Date: Sat, 4 May 2013 10:07:02 -0700 (PDT)
From: Mail Delivery Subsystem <MAILER-DAEMON< at >rawbw.com>
Message-Id: <201305041707.r44H72Kw096661< at >shell0.rawbw.com>
To: <norm< at >dad.org>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="r44H72Kw096661.1367687222/shell0.rawbw.com"
Subject: Returned mail: see transcript for details
Auto-Submitted: auto-generated (failure)

This is a MIME-encapsulated message

- --r44H72Kw096661.1367687222/shell0.rawbw.com

The original message was received at Sat, 4 May 2013 10:06:36 -0700 (PDT)
from [198.144.207.170]

   ----- The following addresses had permanent fatal errors -----
<rha90272< at >mac.com>
    (reason: 554 5.7.0 Message Size Violation)

   ----- Transcript of session follows -----
... while talking to mx4.mac.com.akadns.net.:
<<< 554 5.7.0 Message Size Violation
554 5.0.0 Service unavailable

- --r44H72Kw096661.1367687222/shell0.rawbw.com
Content-Type: message/delivery-status

Reporting-MTA: dns; shell0.rawbw.com
Received-From-MTA: DNS; [198.144.207.170]
Arrival-Date: Sat, 4 May 2013 10:06:36 -0700 (PDT)

Final-Recipient: RFC822; rha90272< at >mac.com
Action: failed
Status: 5.7.0
Remote-MTA: DNS; mx4.mac.com.akadns.net
Diagnostic-Code: SMTP; 554 5.7.0 Message Size Violation
Last-Attempt-Date: Sat, 4 May 2013 10:07:02 -0700 (PDT)

- --r44H72Kw096661.1367687222/shell0.rawbw.com
Content-Type: message/rfc822

Return-Path: <norm< at >dad.org>
Received: from lad.dad.org ([198.144.207.170])
by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r44H6aKw096597;
Sat, 4 May 2013 10:06:36 -0700 (PDT)
(envelope-from norm< at >dad.org)
Message-Id: <201305041706.r44H6aKw096597< at >shell0.rawbw.com>
To: rha90272< at >mac.com, Jeff_Rothenberg< at >acm.org, "David Yost" <Dave< at >Yost.com>
cc: norm< at >dad.org
From: norm< at >dad.org
Subject: Spec_05_04_10:0405_04_10:04
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <15572.1367687195.0< at >lad.dad.org>
Date: Sat, 04 May 2013 10:06:35 -0700

...

Norman Shapiro

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

files created by Fcc header always have mode 0600

Irwin Tillman — 2013-05-02T21:39:52

Platform: nmh-1.5 on Solaris 10 SPARC

Is the intended behavior of an Fcc header that
the files it writes always have mode 0600,
regardless of other settings?

--

When I use comp with an Fcc header, the file written
to the Fcc folder always have mode 0600.

My umask is 022, and in .mh_profile I have:
Msg-Protect: 0644
Folder-Protect: 0755

I expected the file written to the Fcc folder to 
have mode 0644 rather the 0600 I I actually see.

It looks like post gets called, creates a temp file (MAILDIR/postXXXXXX)
with permission 0600, then performs chmod(0600) on that file,
then later calls refile to link that temp file into the Fcc folder.

I see that post(1) says that post doesn't read mh_profile,
so it's no surprise that Msg-Protect isn't used.

Irwin Tillman

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

files created by Fcc header always have mode 0600

Irwin Tillman — 2013-05-03T12:59:39

Platform: nmh-1.5 on Solaris 10 SPARC

Is the intended behavior of an Fcc header that
the files it writes always have mode 0600,
regardless of other settings?

--

When I use comp with an Fcc header, the file written
to the Fcc folder always have mode 0600.

My umask is 022, and in .mh_profile I have:
Msg-Protect: 0644
Folder-Protect: 0755

I expected the file written to the Fcc folder to 
have mode 0644 rather the 0600 I I actually see.

It looks like post gets called, creates a temp file (MAILDIR/postXXXXXX)
with permission 0600, then performs chmod(0600) on that file,
then later calls refile to link that temp file into the Fcc folder.

I see that post(1) says that post doesn't read mh_profile,
so it's no surprise that Msg-Protect isn't used.

Irwin Tillman


_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

mhshow(1) Suggests moreproc can be used.

Ralph Corderoy — 2013-05-03T10:47:27

Hi,

mhshow(1):

    If a display string is not found, mhshow has several default values:

        mhshow-show-text/plain: %pmoreproc '%F'
        mhshow-show-message/rfc822: %pshow -file '%F'

That suggests to this reader that one can use `moreproc' in one's own
entries, perhaps anywhere in the command but certainly at the beginning.
It doesn't seem to be the case.  Does the man page need clarifying?

Cheers, Ralph.

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

send/post busted...

Valdis Kletnieks — 2013-05-02T16:56:30

Some commit recently broke my 'post' command's ability to find the
SASL password needed to authenticate to our mail server.  I'd do a git bisect
to track it down further, but 'git log' hints there's intermediate broken
states.

After 'git checkout a431fb0f788cf93c9d93c3ad268fa0813e1bf2ef' (the last commit
before 'credential' support was added, I get this trying to post mail. PW redacted.

(tls-encrypted) => EHLO turing-police.cc.vt.edu
(tls-decrypted) <= 250-auth3.smtp.vt.edu Hello turing-police.cc.vt.edu [128.173.14.107], pleased to meet you
(tls-decrypted) <= 250-ENHANCEDSTATUSCODES
(tls-decrypted) <= 250-PIPELINING
(tls-decrypted) <= 250-8BITMIME
(tls-decrypted) <= 250-SIZE 26210000
(tls-decrypted) <= 250-DSN
(tls-decrypted) <= 250-AUTH LOGIN PLAIN
(tls-decrypted) <= 250-DELIVERBY
(tls-decrypted) <= 250 HELP
(tls-encrypted) => AUTH LOGIN
(tls-decrypted) <= 334 VXNlcm5hbWU6
(tls-encrypted) => dmFsZGlzQHZ0LmVkdQ==
(tls-decrypted) <= 334 UGFzc3dvcmQ6
(tls-encrypted) => redacted-base64-pass-here
(tls-decrypted) <= 235 2.0.0 OK Authenticated
(tls-encrypted) => MAIL FROM:<Valdis.Kletnieks< at >vt.edu>
(tls-decrypted) <= 250 2.1.0 <Valdis.Kletnieks< at >vt.edu>... Sender ok
(tls-encrypted) => RCPT TO:<valdis< at >vt.edu>
(tls-decrypted) <= 250 2.1.5 <valdis< at >vt.edu>... Recipient ok
(tls-encrypted) => DATA
(tls-decrypted) <= 354 Enter mail, end with "." on a line by itself
(tls-encrypted) => .
(tls-decrypted) <= 250 2.0.0 r42GTajg021042 Message accepted for delivery
(tls-encrypted) => QUIT
(tls-decrypted) <= 221 2.0.0 auth3.smtp.vt.edu closing connection

At current HEAD, I get this.  Apparently something is still not backwards-combatable
in the 'credentials' code.

SSL negotiation successful: DHE-RSA-AES256-SHA(256) TLSv1/SSLv3
(tls-encrypted) => EHLO turing-police.cc.vt.edu
(tls-decrypted) <= 250-auth3.smtp.vt.edu Hello turing-police.cc.vt.edu [128.173.14.107], pleased to meet you
(tls-decrypted) <= 250-ENHANCEDSTATUSCODES
(tls-decrypted) <= 250-PIPELINING
(tls-decrypted) <= 250-8BITMIME
(tls-decrypted) <= 250-SIZE 26210000
(tls-decrypted) <= 250-DSN
(tls-decrypted) <= 250-AUTH LOGIN PLAIN
(tls-decrypted) <= 250-DELIVERBY
(tls-decrypted) <= 250 HELP
(tls-encrypted) => AUTH LOGIN
(tls-decrypted) <= 334 VXNlcm5hbWU6
(tls-encrypted) => *
(tls-decrypted) <= 501 5.0.0 AUTH aborted
(tls-encrypted) => RSET
(tls-decrypted) <= 250 2.0.0 Reset state
(tls-encrypted) => QUIT
(tls-decrypted) <= 221 2.0.0 auth3.smtp.vt.edu closing connection
post: problem initializing server; [BHST] SASL client negotiation failed: invalid parameter supplied
send: message not delivered to anyone

The relevant line out of my .netrc (slightly redacted):

machine auth.smtp.vt.edu login valdis< at >vt.edu password redacted-password-here

and 'send -version' reports:

Profile: -nomime -msgid -server auth.smtp.vt.edu -port 587 -tls -sasl -user valdis< at >vt.edu

I get the same results with and without the 'login valdis< at >vt.edu' phrase in .netrc, and
whether or not I put a 'credentials: legacy' in .mh_profile.
It doesn't seem to find the entry.

Hope this
_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Setup help???

Bob Carragher — 2013-05-02T03:00:13

Can someone please point me to resources or provide a simple How-To
for configuring NMH (and related systems, like sendmail)?  My setup:

*  Laptop running (Ubuntu 10.04) Linux.
*  My "public" address is "dnc2dnc< at >gmail.com."
   --  I want all my email to appear to come from this address.  I have
       set "From:" and "Reply-To:" fields in my "components" and other
       configuration files.  However, I have problems with the generated
       "Sender:" field (see below).
   --  I use fetchmail to POP email from this address.  (I mention this
       only in case it changes the setup.)
*  I send mail when connected to my ISP, but fetch/POP mail whenever
   I'm connected to the Internet.  It would be nice to be able to use NMH
   to send mail whenever I'm connected to the Internet, but I will settle
   for continuing to use the Google web interface for that.
*  I added to /etc/hosts a FQDN that I don't normally send email
   to ("mit.edu") because some mailers reject email that comes
   from "foo< at >localhost" or "foo< at >localhost.localdomain."  I didn't
   add "<ISP>" because then any email I send to "foo< at ><ISP>"
   appears to be for a "local user;" also "<laptop-userID>< at ><ISP>"
   is taken.

This has generally worked, although (because I use sendmail) this adds
the line

     Sender: <laptop-userID>< at ><ISP>

to all my message headers.  In the last few years, more and more mail
providers are keying off this as an indication of spam, and in recent
weeks my email doesn't even reach some recipients at all (not even
deposited in their "spam" folder).

This *should* be a relatively common use case amongst NMH users,
so I have to believe that the setup for it should be straightforward.

I am the only user of this laptop, so if it is necessary to hard-code
the sender's ID and/or hostname, then I would be willing to do that.

Can anyone help, or point to help?

Thank you!

Bob

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

another message corruption bug

Paul Fox — 2013-05-01T15:32:19

hi --

sorry to have to report another corruption issue.  inc corrupts the
DKIM-Signature header in the attached message from:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:sender:content-type:mime-version:subject:from
:in-reply-to:date:cc:message-id:references:to:x-mailer;
bh=9RvGuD7z0t+zYV3baoa1XJT3sSAnFive2ajfw7XzoAI=;
b=oegx7thD9cv2dxX30/3vHXKritCxhrTIMIsAX0cBnt1C6JXWgq7sKD5M+w/+CrkJp1
JqUHyVQnwSqMu03WfNBYdzAVrNc7Ask11AVp+GrwniRFfW6yGXzUh/okC/fAwS4U46sh
tAeflp3+SiSKLuo6U+00jjH8ekhtYxmWSrXBvYHQgvsyqHd5CHvPThO4qxDUJ0Zx/4mj
sU1fI9N5mBm27WkHFgFJbBgeMZViP9LDw3wapxHK0ABucKdEM6cqOrNn+cZVuVfysNXl
53IWIWcIOMBwL5zlG6k7pdNm3OtCnn59RML9EIPfDv+Vuk8VfHfiP7Siz7kqPQVf+8ol
/6QQ==

to: 

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:sender:content-type:mime-version:subject:from
:in-reply-to:date:cc:message-id:references:to:x-mailer;
bh=9RvGuD7z0t+zYV3baoa1XJT3sSAnFive2ajfw7XzoAI=;
b=oegx7thD9cv2dxX30/3vHXKritCxhrTIMIsAX0cBnt1C6JXWgq7sKD5M+w/+CrkJp1
JqUHyVQnwSqMu03WfNBYdzAVrNc7Ask11AVp+GrwniRFfW6yGXzUh/okC/fAwS4U46sh
tAeflp3+SiSKLuo6U+00jjH8ekhtYxmWSrXBvYHQgvsyqHd5CHvPThO4qxDUJ0Zx/4mj
sU1fI9N5mBm27WkHFgFJbBgeMZViP9LDw3wapxHK0ABucKdEM6cqOrNn+cZVuVfysNXl
53IWIWcIOMBwL5zlG6k7pdNm3OtCnn59RML9EIPfDv+Vuk8VfHfiP7Siz7kqPQVf+8ol
/6QQ==

(i don't know whether the issue is this header, or something previous.)

i went back to the commit before f6e6ec96c9e179f7817fca4c8c22bc2bd4e417e8,
which introduced the corruption previous issue i found, but rather
than fix the problem, the inc built that commit simply dumps core. ;-)

so:

somewhere between
    commit f6e6ec96c9e179f7817fca4c8c22bc2bd4e417e8 (master~193^2~6^2~31)
    Author: David Levine <levinedl< at >acm.org>
    Date:   Sun Jan 13 11:08:28 2013 -0600

      Added bytes_read to m_getfld() buffer state.  This is the
      next step in supporting ftell()/fseek().
and
    commit 55f65ae2d3baf60396d3359db952460939de03ca
    Author: David Levine <levinedl< at >acm.org>
    Date:   Sun Apr 14 10:47:31 2013 -0500

Moved #include of signal.h to h/signals.h.  And it was already
in h/nmh.h.

the behavior changed from dumping core to losing a tab character.  i
didn't bisect further -- it's not clear that bisecting between two failures
would be all that productive.  ;-)

paul
----------------------
 paul fox, pgf< at >foxharp.boston.ma.us (arlington, ma, where it's 61.7 degrees)
From twine-bounces< at >lists.example.com  Wed May  1 11:12:38 2013
Return-Path: <twine-bounces< at >lists.example.com>
X-Original-To: pgf< at >foxharp.boston.ma.us
Delivered-To: pgf< at >foxharp.boston.ma.us
Received: from colo.foxharp.net (grass [127.0.0.1])
by grass.foxharp.boston.ma.us (Postfix) with ESMTP id CCF212E8020
for <pgf< at >foxharp.boston.ma.us>; Wed,  1 May 2013 10:45:24 -0400 (EDT)
Received: from swan.example.com (swan.example.com [18.85.2.166])
by colo.foxharp.net (Postfix) with ESMTPS id 5812E540DB
for <pgf< at >foxharp.boston.ma.us>; Wed,  1 May 2013 10:37:59 -0400 (EDT)
Received: by swan.example.com (Postfix)
id E733A316790; Wed,  1 May 2013 10:45:16 -0400 (EDT)
Delivered-To: pgf< at >example.com
Received: from swan.example.com (localhost [127.0.0.1])
by swan.example.com (Postfix) with ESMTP id C682931665B;
Wed,  1 May 2013 10:45:16 -0400 (EDT)
Received: by swan.example.com (Postfix)
id 0F4DD316644; Wed,  1 May 2013 10:45:15 -0400 (EDT)
Delivered-To: twine< at >example.com
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com
[209.85.216.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
(No client certificate requested)
by swan.example.com (Postfix) with ESMTPS id E17B63163D8;
Wed,  1 May 2013 10:45:14 -0400 (EDT)
Received: by mail-qa0-f47.google.com with SMTP id bn16so2122913qab.13
for <multiple recipients>; Wed, 01 May 2013 07:45:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=x-received:sender:content-type:mime-version:subject:from
:in-reply-to:date:cc:message-id:references:to:x-mailer;
bh=9RvGuD7z0t+zYV3baoa1XJT3sSAnFive2ajfw7XzoAI=;
b=oegx7thD9cv2dxX30/3vHXKritCxhrTIMIsAX0cBnt1C6JXWgq7sKD5M+w/+CrkJp1
JqUHyVQnwSqMu03WfNBYdzAVrNc7Ask11AVp+GrwniRFfW6yGXzUh/okC/fAwS4U46sh
tAeflp3+SiSKLuo6U+00jjH8ekhtYxmWSrXBvYHQgvsyqHd5CHvPThO4qxDUJ0Zx/4mj
sU1fI9N5mBm27WkHFgFJbBgeMZViP9LDw3wapxHK0ABucKdEM6cqOrNn+cZVuVfysNXl
53IWIWcIOMBwL5zlG6k7pdNm3OtCnn59RML9EIPfDv+Vuk8VfHfiP7Siz7kqPQVf+8ol
/6QQ==
X-Received: by 10.229.6.1 with SMTP id 1mr1114959qcx.17.1367419521930;
Wed, 01 May 2013 07:45:21 -0700 (PDT)
Received: from [192.168.1.104] (pool-173-76-238-235.bstnma.fios.verizon.net.
[173.76.238.235])
by mx.google.com with ESMTPSA id c7sm2467085qel.2.2013.05.01.07.45.20
for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 01 May 2013 07:45:21 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Ed McNierney <ed< at >example.com>
In-Reply-To: <ED675598-CEC8-4FBA-B91F-53ABC6BD4E76< at >gmail.com>
Date: Wed, 1 May 2013 10:45:20 -0400
Message-Id: <FA6021C5-9C09-49ED-A9B3-7D75BC85DEB7< at >example.com> (sfid-20130501_104524_976278_A4BCFCC7)
References: <CAFZjaHU0_ZqUKpKGnCGp3PEvB0xZbxo-uNnO7t=3TjLWyKm4uA< at >mail.gmail.com>
<ED675598-CEC8-4FBA-B91F-53ABC6BD4E76< at >gmail.com>
To: Reuben Caron <reuben< at >example.com>
X-Mailer: Apple Mail (2.1503)
Cc: "twine< at >example.com" <twine< at >example.com>
Subject: Re: [Twine] working at home today
X-BeenThere: twine< at >lists.example.com
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: <twine.lists.example.com>
List-Unsubscribe: <http://lists.example.com/options/twine>,
<mailto:twine-request< at >lists.example.com?subject=unsubscribe>
List-Archive: <http://lists.example.com/pipermail/twine>
List-Post: <mailto:twine< at >lists.example.com>
List-Help: <mailto:twine-request< at >lists.example.com?subject=help>
List-Subscribe: <http://lists.example.com/listinfo/twine>,
<mailto:twine-request< at >lists.example.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6004824184846411424=="
Sender: twine-bounces< at >lists.example.com
Errors-To: twine-bounces< at >lists.example.com
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
X-CRM114-CacheID: sfid-20130501_104524_976278_A4BCFCC7 
X-CRM114-Status: GOOD ( 999.99 )

test

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Does maildrop work correctly with nmh?

Martin McCormick — 2013-04-28T11:41:39

I am probably just setting up .mailfilter wrong, but so
far, it doesn't seem to understand that it should behave in an
mh way. It wants to put mail in a .mbox format in just about any
directory except $HOME/Mail/folder/message# in the normal mh
style.

Right now, I use procmail but maildrop reportedly makes
filtering and sorting easier since it does better mime
expansions.

Thanks for any good ideas.

Martin McCormick

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Inability to cat a Message Part.

Ralph Corderoy — 2013-04-28T11:38:35

Hi,

Take

    $ mhlist
     msg part  type/subtype              size description                         
    7800       multipart/mixed           1842
         1     text/plain                  62
         2     application/x-gzip         971
    $ 

The headers for part 2 are

    Content-Type: application/x-gzip
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename="foo.log.1.gz"

It seems odd I can't do something like

    mhcat -part 2 | gunzip | less

and instead have to mhstore first.  Or can I?  I know mhstore formatting
strings in ~/.mh_profile can start with a `|' to give the command to
pipe to but they're switched on type or type/subtype and I don't want to
do this for all application/x-gzip, just part 2 of this message.

If I create

    mhshow-show-application/x-gzip: zcat

then I can

    mhshow -form mhl.null -part 2 | less

but again that needs ~/.mh_profile editing and affects all
application/x-gzip;  I know this part is gzip'd text but not all are for
all mhshows.

Is some means of specifying type/subtype handling needed for the command
line instead of always being ~/.mh_profile?  Really, I don't want nmh
doing the zcat;  just give me the raw part, like mhcat above.  mhcat is
easy enough to script for one's own purpose, using mhshore, but it would
seem more the Unix way to fit better in a pipeline.

Cheers, Ralph.

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Does maildrop work correctly with nmh?

Martin McCormick — 2013-04-25T16:06:20

The subject is the message. I am thinking of switching
from procmail to maildrop in hopes of better filtering. The
question could also be asked, "Is there any reason not to do
this?"

Thank you very much.

Martin McCormick

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Semi-annual cat -v mailout

Lyndon Nerenberg — 2013-04-25T02:26:09

I'm going to set up a cron job to send this twice a year ...




_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

extra and missing blank lines with replyfilter

Joel Uckelman — 2013-04-24T17:51:58

I finally got fed up with all the garbage in replies to quoted-printable
messages, so decided to try out replyfilter just now. I have this in my
mhl.reply:

from:nocomponent,formatfield="Thus spake %(decode(friendly{text})):"
body:nocomponent,format,nowrap,formatarg="%(trim{content-type})%(putstr)",formatarg="%(trim{content-transfer-encoding})%(putstr)",formatarg="> "

What I'm seeing when I reply to a quoted printable message from a friend
of mine is the "Thus spake" line, followed by six blank >-quoted lines,
followed by the (un-q-p'd) text of the original message, but with all of
the blank lines (e.g., the lines between paragraphs!) removed.

So, it looks something like this:

Thus spake Joel's Friend:

and so on.

There are definitely not six blank lines in the original message before
the text starts, and there are definitely blank lines between paragraphs.

Am I misusing replyfilter? Is this a bug?

Responding to calendar requests

Ken Hornstein — 2013-04-24T14:42:48

At $REALJOB today, I got a calendar request via email for some training
I have to do, and I was requested to respond to the calendar request so
they could easily track who was coming.

I guess my shame had reached a point where I felt that simply replying
saying my MUA couldn't handle that wasn't quite reasonable, so I looked
at how hard it would be to actually handle that.  It turns out that
stuff is reasonably documented in RFCs (see RFC 5545 and RFC 5546 for
starters), and I was able to hand-construct a text/calendar reply message
that I think did the right thing (I haven't actually heard back yet
to see if it worked).  nmh helped here in that I was able to create a
mhbuild directive that had the right magic in it.

But this got me thinking ... how hard would this be to handle natively?
It turns out that it's not hard to handle the right bits; seems like
a Perl program could handle that (there is iCal::Parser).  But that brings
up a related question: how exactly would that work?

It seems to me that putting "native" text/calendar handling in the core
of nmh is wrong; that seems like something that should be handled by
an external script/program.  I think most everyone would agree with that.
But exactly what would that look like?  If we get a text/calendar object,
do we convert that to "plain text" to display to the user?  Okay, that's
not so hard; I think we can do that today without any changes to nmh.
But to me the interesting part is when you want to reply to that message
saying "accept" or "decline".  How does the user do that?  Do they have
some wrapper to repl?  I've always viewed wrappers to programs like
repl as working around deficiencies.  Maybe an alternate replyfilter
that knows how parse a text/calendar and output a response?  Okay, but
how does a user pass down arguments to say "accept" or "decline"?
That gets into larger meta-questions about how much nmh should do out
of the box versus requiring user configuration.

I don't know the right answers here, but I'm interested in hearing
what people think.

--Ken

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Ordering of Parts by mhlist.

Ralph Corderoy — 2013-04-19T10:45:47

Hi,

    $ mhlist
     msg part  type/subtype              size description
    19696       multipart/alternative     4785
         1     text/html                 2787
         2     text/plain                1680
    $

The email has subtype plain first, then html.  I know this from show(1)
so it's then a bit odd to then see them flipped by mhlist.  Does mhlist
deliberately rank html above text?  Is it alphabetical?

mhlist(1) doesn't mention order AFAICS.  Personally, I'd prefer the
email's order rather than add a layer of change for what seems little
gain.

BTW, the header line has many spaces after `description'.

Cheers, Ralph.

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

test-slocal

David Levine — 2013-04-18T14:25:25


That looks right.  /usr/bin/tee will only be used if it
exists.

How about adding "-verbose -debug" here and then see if the test output
has any clues:

--- a/test/slocal/test-slocal
+++ b/test/slocal/test-slocal
< at >< at > -80 +80 < at >< at > EOF
-$slocal -maildelivery $md $mbox <"$MH_TEST_DIR"/Mail/inbox/1
+$slocal -verbose -debug -maildelivery $md $mbox <"$MH_TEST_DIR"/Mail/inbox/1

Maybe I'll add that to the test if that first non-trivial slocal fails.

David

______________________________________________________________________
The information contained in this e-mail message and its attachments are intended only for the personal and confidential use of the named recipient(s).  If you are neither the intended recipient nor the person responsible for delivering to the intended recipient, you are not authorized to and must not disclose, copy, distribute or retain this e-mail or its attachments.  If you have received this communication in error, please notify us immediately by e-mail and delete the original message.  E-mail is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses.  We are not liable for data corruption, interception, tampering, amendment or viruses or any consequences thereof.

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

message corruption with inc

Paul Fox — 2013-04-15T15:11:43

i'm sometimes seeing a minor corruption of incoming mail after running
inc.  it's happened since i switched recently to running latest git
HEAD.

i've bisected, and the first failing commit is:

    commit f6e6ec96c9e179f7817fca4c8c22bc2bd4e417e8 (master~193^2~6^2~31)
    Author: David Levine <levinedl< at >acm.org>
    Date:   Sun Jan 13 11:08:28 2013 -0600

Added bytes_read to m_getfld() buffer state.  This is the
next step in supporting ftell()/fseek().


to reproduce:  save the attached message to /tmp/foo.mbox, and run:

    $ inc -file /tmp/foo.mbox
    $ diff -u /tmp/foo.mbox $(mhpath cur)
    --- /tmp/foo.mbox       2013-04-15 11:05:14.000000000 -0400
    +++ /home/pgf/Mail/foo/10       2013-04-15 11:06:24.000000000 -0400
    < at >< at > -1,4 +1,3 < at >< at >
    -From notification+xxxxpjwi< at >facebookmail.com  Mon Apr 15 00:24:09 2013
     Return-Path: <notification+xxxxpjwi< at >facebookmail.com>
     X-Original-To: pgf-facebook< at >foxharp.boston.ma.us
     Delivered-To: pgf-facebook< at >foxharp.boston.ma.us
    < at >< at > -37,6 +36,8 < at >< at >
     Content-Type: multipart/alternative;
    boundary="b1_b24c20bb119a0a0f754067dd12b0d2c3"
     
    +2c3"
    +
     
     --b1_b24c20bb119a0a0f754067dd12b0d2c3
     Content-Type: text/plain; charset="UTF-8"
    < at >< at > -53,4 +54,3 < at >< at >
     
     
     --b1_b24c20bb119a0a0f754067dd12b0d2c3--
    -


you can see that the last several characters of the message header
have been prepended to the message body.  this is the typical behavior
i've been seeing.  never more than 4 or 5 extra characters.

i'll debug if no one else can get to it near-term, but i'm sure david
will be quicker at it than i will be, if he has time.

paul
----------------------
 paul fox, pgf< at >foxharp.boston.ma.us (arlington, ma, where it's 47.5 degrees)

From notification+xxxxpjwi< at >facebookmail.com  Mon Apr 15 00:24:09 2013
Return-Path: <notification+xxxxpjwi< at >facebookmail.com>
X-Original-To: pgf-facebook< at >foxharp.boston.ma.us
Delivered-To: pgf-facebook< at >foxharp.boston.ma.us
Received: from colo.foxharp.net (grass [127.0.0.1])
by grass.foxharp.boston.ma.us (Postfix) with ESMTP id 7ABAB2E8017
for <pgf-facebook< at >foxharp.boston.ma.us>; Mon, 15 Apr 2013 00:24:09 -0400 (EDT)
Received: from mx-out.facebook.com (outmail018.snc7.facebook.com [69.171.232.152])
by colo.foxharp.net (Postfix) with ESMTP id 649D254103
for <pgf-facebook< at >foxharp.boston.ma.us>; Mon, 15 Apr 2013 00:17:17 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=facebookmail.com;
s=s1024-2011-q2; t=1365999848;
bh=E4JnVGi6ZBizni9cA1lkDgiVmRBIzwfhrt/Fdl3ZgSg=;
h=Date:To:From:Subject:MIME-Version:Content-Type;
b=WIbBRu9Clz4KVFnblllkxl8UmkdwdT8LKc4hyIJ1L7+1jCTbFNZUjhS1eFD6qb8/m
 xL7hvRjVGubQ177ZumKOwd5UQ/PhvCdv3cTuxYjebNouSxmvSY8SFmCjuBGooTbGkS
 PKNjKJQKaGI6NOyp661Bx7Rq5XmwQJyMyuUguof0=
Received: from [10.74.228.23] ([10.74.228.23:38708])
by smout030.snc7.facebook.com (envelope-from <notification+kuuupjwi< at >facebookmail.com>)
(ecelerity 3.5.1.37927 r(/root/Momo-dev:tip)) with ECSTREAM
id 1D/AC-06532-8E08B615; Sun, 14 Apr 2013 21:24:08 -0700
X-Facebook: from zuckmail ([MTI3LjAuMC4x]) 
by www.facebook.com with HTTP (ZuckMail);
Date: Sun, 14 Apr 2013 21:24:08 -0700
To: Paul Fox <pgf-facebook< at >foxharp.boston.ma.us>
From: "Facebook" <notification+xxxxpjwi< at >facebookmail.com>
Reply-to: Reply to Comment <e+xxxxxxxxx0000l1pn3j002wrw0ebtg80000000000000000000000002bn53< at >reply.facebook.com>
Subject: Some Friend mentioned you on Facebook
Message-ID: <b24c20bb119a0a0f754067dd12b0d2c3< at >www.facebook.com>
X-Priority: 3
X-Mailer: ZuckMail [version 1.00]
Errors-To: notification+kuuupjwi< at >facebookmail.com
X-Facebook-Notify: comment_mention; mailid=xxxxxxxxxxxxx62fG5766f48Gb7
X-FACEBOOK-PRIORITY: 0
X-Auto-Response-Suppress: All
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_b24c20bb119a0a0f754067dd12b0d2c3"


--b1_b24c20bb119a0a0f754067dd12b0d2c3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

.....


--b1_b24c20bb119a0a0f754067dd12b0d2c3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




--b1_b24c20bb119a0a0f754067dd12b0d2c3--

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Specify port for inc.

2013-04-07T07:13:16

The -port argument to inc coredumps. Here is a patch. As far as I
can tell, that argument is undocumented as well.

- Martin

diff -aur a/uip/inc.c b/uip/inc.c
--- a/uip/inc.cMon Jun 11 04:06:19 2012
+++ b/uip/inc.cSun Apr  7 07:02:30 2013
< at >< at > -338,7 +338,7 < at >< at >
 continue;
 
     case PORTSW:
-if (!(host = *argp++) || *port == '-')
+if (!(port = *argp++) || *port == '-')
     adios (NULL, "missing argument to %s", argp[-2]);
 continue;
 

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

bug #23168: post -sasl doesn't honour username in.netrc

David Levine — 2013-04-06T14:35:06

This old bug is about post ignoring a login name in .netrc:

  http://savannah.nongnu.org/bugs/index.php?23168

I had closed it, but I really think that it should be fixed.
The current behavior is to determine the user using the
first of:

  1) -user switch
  2) local login name

I'd like to change the behavior to:

  1) -user switch
  2) matching host entry with "login" in a .netrc
  3) interactively request name from user

That would affect those who rely on the local login name.  I
don't expect that's very useful these days, especially with
-sasl.  If someone needs that and we go with the fix, they'd
have to add -user switch(es) or add a "login" to their .netrc.

One unfortunate result of this change would be that a "default"
entry in the .netrc would kick in before 3).  But I don't see
that as being worse than using the local login name.

Also, with inc and msgchk -sasl, the password is set to the
login name.  Does anyone use that?

David

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

Limit of 27 messages sequences per folder

2013-03-26T12:44:46

Apparently, nmh limits the number of message sequences per folder to 5 less than the number of bits in a C int -- which, these days is usually 32. I guess 27 was once a large number, but perhaps, now, not so much. What would happen, to performance, on 64 bit machines if line 86 of h/mh.h which now reads:

typedef unsigned int seqset_t;

were changed to:

typedef unsigned long seqset_t;

If there is no significant effect, then maybe int, vs long, for seqset_t, should be a made a configuration parameter ???

Of course, there might well be some more fundamental reason why my naive suggestion wouldn't work  ???

    Norman Shapiro

_______________________________________________
Nmh-workers mailing list
Nmh-workers< at >nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers