On 07Jun2019 21:08, Frank Watt <youngoldbl...@gmail.com> wrote:
First of all, apologies for munging the thread: Gmail didn't deliver
Cameron's response. I had to get the text from the archives.
That seems to happen to me quite a bit. I harbour some suspicions to do
with years of maintaining the adzapper project (which is filled with
spamlike domain strings). Please see if I'm in your spam folder; marking
my messages as not spam might improve future delivery.
Cameron Simpson wrote:
| Procmail generally relies on being installed in the user's ~/.forward
| file to cause sendmail (the mail system) to deliver email to the
| procmail programme instead of the default.
I don't have a ~/.forward: I have a ~/.fetchmailrc and a ~/.procmail
file, the former having this statement in its first line:
# Configuration created Fri Dec 13 22:30:42 2002 by fetchmailconf
I don't recall doing that, but I edited that file a number of times
since 2002.
Ok, so fetchmail collects your email and hands it to procmail? I'd have
thought that should continue to work regardless of what you've done with
the system MTA (sendmail/nullmailer/whatever).
How's fetchmail run by your system? Cron? Something else?
| fetchmail collects email and delivered it to the local email system.
| Which means it delivers to sendmail. And sendmail hands it to
| procmail...
|
| However, fetchmail has a -m option, which can probably deliver directly
| to procmail, bypassing the local mail system entirely.
Looks like that's not as simple as I'd hoped. From the fetchmail man
page:
-m <command> | --mda <command>
This option lets fetchmail use a Message or Local
Delivery Agent (MDA or LDA) directly, rather than
forward via SMTP or LMTP.
To avoid losing mail, use this option only with MDAs
like maildrop or MTAs like sendmail that exit with a
nonzero status on disk-full and other delivery errors;
[...]
The well-known procmail(1) package is very hard to
configure properly, it has a very nasty "fall through to
the next rule" behavior on delivery errors (even
temporary ones, such as out of disk space if another
user's mail daemon copies the mailbox around to purge
old messages), so your mail will end up in the wrong
mailbox sooner or later. The proper procmail
configuration is outside the scope of this
document. Using maildrop(1) is usually much easier, and
many users find the filter syntax used by mail‐ drop
easier to understand.
That seems to be a big incentive not to use procmail.
It does look that way. I left procmail because I disliked its rule
syntax, its totally regexp based matching system (ok for subject lines,
ghastly for email addresses) and the performance cost incurred by it
rereading the filter files from scratch on every message processed. I've
got about 2000 filing rules myself - procmail starts to scale badly for
that.
Is your procmailrc extensive? Would it be hard to switch filers?
That said, many people use procmail with little apparent pain.
Meanwhile, in
the man pages for maildrop:
DESCRIPTION
[...]
maildrop does not accept an mbox-style From_ line before the
first header line. maildrop does not accept leading empty
lines before the first non-blank header line. If the message
can possibly start with empty lines, and a From_ line, use
reformail -f0 to remove any initial empty lines, and replace a
From_ line with a proper “Return-Path:” header; then pipe it to
maildrop.
When I look at the headers of most mail, I see an mbox-style From
line. Where do we make use of the 'reformat -f0' and "Return-Path"
advice?
Are you looking in mbox files or in other places. [...] Hmm, my maildir
message files also have From_ lines.
If fetchmail's delivering to a programme, nothing prevents that being an
arbitrary script to premangle a leading From_ line. Hmm. I've got a
script in my bin directory called "unfrom_" for exactly this purpose,
which reads:
#!/usr/bin/env sed -f
#
# Transmute leading "From " line on email message, if any.
# - Cameron Simpson <c...@cskk.id.au> 13jul2002
#
1{s/^From /From_: /}
You can just include that script in a pipeline ahead of maildrop.
Cheers,
Cameron Simpson <c...@cskk.id.au>
