[svlug] procmail (was: Some pretty serious parsing)

Akkana Peck akkana at shallowsky.com
Mon Nov 16 08:44:41 PST 2015

Rick Moen writes:
> What I said about procmail is that some argue that instead of calling it
> orphaned / unmaintained, it's fairer to say it works and doesn't need
> anything new (despite a couple of theoretical security flaws that always
> struck me as far-fetched).

I've been using procmail for years and until recently would have
agreed that "it works and doesn't need anything". But I had a fairly
serious problem with procmail's local delivery just a few weeks ago.

The problem is messages silently not getting delivered. The verbose
procmail log says, after all the logging of rules and so forth:

procmail: Opening in/foldername
procmail: Acquiring kernel-lock
procmail: Unlocking "in/foldername.lock"
>From [sender] [date]
 Subject: [subject]
  Folder: in/foldername

and there are no errors, or any further lines related to that
message; but I never see the message. It's hard to debug because I
don't even know how often it's happening: I only find out it's
happened when somebody replies, I say "Hey! I never saw the message
this is a reply to" and check the procmail log.

It's either a problem with procmail or with mutt: procmail is
running on my local machine after fetchmailing the inbox, and
nothing else touches the inbound mailboxes between when procmail
(supposedly) delivers it and when I open the local folder with mutt.
When I discover it, I immediately suspend mutt and examine the
folder with vim; but that doesn't exonerate mutt since by this time
I've probably visited and updated that folder several times since
the original message.

Filesystem is ext4, system is debian sid, mailboxes are mbox.
Procmail is called from fetchmail like this:
  mda "/usr/bin/procmail -f %F -m /home/akkana/.procmailrc"
so there should be only one running at a time -- hmm, unless it takes
so long that it's still running 120 seconds later when fetchmail
next fires off. But even that shouldn't matter since procmail says
it's doing file locking.

After missing two messages in the same week in the same mailing
list, I wondered if it might have something to do with the target
mail folder being relatively large (though I don't know of any
reason that a 2.8M file should be any harder to append to than a
small file). I renamed all my inbound mail folders and started a new
in/ folder directory, and I haven't seen any definite missed mail
since. But that doesn't mean it hasn't happened, and I no longer
have confidence that any given message will actually arrive. I can't
even think of a way to detect when it's happened, let alone fix it.

Rick, thanks for posting your list of LDAs -- I'll look through
those and see if there's anything else I could use. I have a huge
set of procmail rules and *really* don't want to switch ... but if
it can't be trusted to deliver mail ...


More information about the svlug mailing list