Re: New install omits mbox "From <addr> <date> <time>" separator
On 31.03.21 09:17, Ruud H.G. van Tol wrote:
On 2021-03-31 05:41, dvalin@internode.on.net wrote:
Situation: procmail v3.23pre 2001/09/13 running on a new devuan beowulf install, using an unaltered .procmailrc which has served flawlessly for decades on the old host.
The .procmailrc guides distribution of incoming emails to a dozen mailboxes, but on the new host is heading each email with a line like:
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=150.101.137.105;
omitting the mbox format email separator: "From ...". That, naturally stuffs mutt up mightily until I edit in some separators by hand
Neither the procmail nor procmailrc manpages seem to offer any control for this, so I haven't yet been able to find where to stick the screwdriver in and twist. Any pointers would help save what hair I have left.
What is the mail stack, Postfix + Dovecot?
Whoops, I omitted to mention that procmail is invoked directly by fetchmail, through the mda option in .fetchmailrc: # Configuration created Sat Mar 27 22:14:20 2021 by fetchmailconf 1.58 set logfile "/tmp/fetchmail_log" set postmaster "erik" set bouncemail set no spambounce set softbounce set properties "" set daemon 600 poll mail.internode.on.net with proto POP3 user 'dvalin' there is 'erik' here options ssl fetchall mda /usr/bin/procmail That delivers fine to procmail, which distributes to a dozen mailboxes, but omits the mbox separator. Why skip port 25 and an MTA? Yesterday I had it doing that, with devuan beowulf's default MTA, exim, and that stack omitted the mbox separator. That does narrow the problem down to procmail, as it fails to prefix the mbox separator however invoked, whatever the mail stack.
An extensive guide: https://workaround.org/ispmail/buster/
I have no problems setting up an MTA, having used sendmail on mail servers and my own machine for decades, then switching to postfix more than a decade ago. Trying with exim and without shows that it is not an MTA issue, but entirely in the MDA, as it essentially must be, as that is the only entity writing to the mailbox. OK, it ought to be possible to bodge an mbox separator with a "formail -I", I figure, but that does not seem to be the canonical method for coaxing procmail to conform with its traditional default mailbox format. That hasbeen intrinsic for decades. Apologies if this doesn't thread; I'm stuck on webmail until I have mailworking on the new beowulf host. Erik
On Wed, 31 Mar 2021, at 20:48, dvalin@internode.on.net wrote:
Whoops, I omitted to mention that procmail is invoked directly by fetchmail, through the mda option in .fetchmailrc: (...) mda /usr/bin/procmail
That delivers fine to procmail, which distributes to a dozen mailboxes, but omits the mbox separator.
I reproduced what you described using at the commandline `procmail < msg` where `msg` included no leading "From " and procmailrc delivered to Maildir. Already the LOGABSTRACT in Procmail's logfile showed no "From ". And neither did the resulting Maildir file. I did the same as root using mbox, same result. It does work, though, with `procmail -f - < msg`. -- -- Andreas :-)
On 2021-03-31 12:18, dvalin@internode.on.net wrote:
On 31.03.21 09:17, Ruud H.G. van Tol wrote:
On 2021-03-31 05:41, dvalin@internode.on.net wrote:
Situation: procmail v3.23pre 2001/09/13 running on a new devuan beowulf install, using an unaltered .procmailrc which has served flawlessly for decades on the old host.
The .procmailrc guides distribution of incoming emails to a dozen mailboxes, but on the new host is heading each email with a line like:
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=150.101.137.105;
omitting the mbox format email separator: "From ...". That, naturally stuffs mutt up mightily until I edit in some separators by hand.
Neither the procmail nor procmailrc manpages seem to offer any control for this, so I haven't yet been able to find where to stick the screwdriver in and twist. Any pointers would help save what hair I have left.
What is the mail stack, Postfix + Dovecot?
Whoops, I omitted to mention that procmail is invoked directly by fetchmail, through the mda option in .fetchmailrc:
# Configuration created Sat Mar 27 22:14:20 2021 by fetchmailconf 1.58 set logfile "/tmp/fetchmail_log" set postmaster "erik" set bouncemail set no spambounce set softbounce set properties "" set daemon 600 poll mail.internode.on.net with proto POP3 user 'dvalin' there is 'erik' here options ssl fetchall mda /usr/bin/procmail
That delivers fine to procmail, which distributes to a dozen mailboxes, but omits the mbox separator.
Why skip port 25 and an MTA? Yesterday I had it doing that, with devuan beowulf's default MTA, exim, and that stack omitted the mbox separator. That does narrow the problem down to procmail, as it fails to prefix the mbox separator however invoked, whatever the mail stack.
An extensive guide: https://workaround.org/ispmail/buster/
I have no problems setting up an MTA, having used sendmail on mail servers and my own machine for decades, then switching to postfix more than a decade ago. Trying with exim and without shows that it is not an MTA issue, but entirely in the MDA, as it essentially must be, as that is the only entity writing to the mailbox.
OK, it ought to be possible to bodge an mbox separator with a "formail -I", I figure, but that does not seem to be the canonical method for coaxing procmail to conform with its traditional default mailbox format. That has been intrinsic for decades.
Apologies if this doesn't thread; I'm stuck on webmail until I have mail working on the new beowulf host.
The '^From[ ]' line contents come out of the conversation (AKA "envelope information") between the MTA and the remote, which is not necessarily relatable to the contents of the mail message. So now you want to fake the '^From[ ]' from the contents of the mail message? Then first check the fetchmail man-page again: multidrop, --envelope. Also look for a custom header that contains envelope details, to re-build the envelope-'^From[ ]' from. -- Ruud
participants (3)
-
Andreas Schamanek -
dvalin＠internode.on.net -
Ruud H.G. van Tol