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