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

Rick Moen rick at linuxmafia.com
Mon Nov 16 10:40:51 PST 2015


Quoting Akkana Peck (akkana at shallowsky.com):

> 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.

I'm guessing you mean it's _some_ messages not getting delivered, not
all of them, right?  (If it were all of them, you'd be in emergency
debugging mode, not corresponding with mailing lists -- unless perhaps
you get mail on multiple systems.)

I've sometimes managed to put procmail in a state where no mail
whatsoever is delivered, at times I've made a severe error in a new or
revised procmail recipe.  In those cases, I backtrack by reverting or
commenting out whatever was the last recipe I altered or added, mail
delivery resumes, and I then figure out how to do that correctly.

Often, it turns out I've made an error on the first line of the recipe,
the cryptic one that includes what's to be done with locking.

(BTW, you probably already know about 'man 5 procmailex', showing you
examples of useful recipes, but I'll mention it for those looking for 
it.)

Anyway, one way to attempt debugging is to comment out whatever recipes
you touched after the last time you're sure messages started silently
not getting delivered.  Another, more painful way, is to temporarily set
aside your existing .procmailrc and substitute a from-scratch, radically
simplified one long enough to see if the symptom goes away.  If it does
go away, then reintroduce your standard recipes a few at a time, until
you find the one causing trouble.  If it doesn't, then you've at least
isolated the problem to something other than a recipe.

The only other diagnostic approach that comes immediately to mind is
running suspect processes under strace, and seeing if that helps you 
spot where something goes wrong.  (I mean, who knows?  It could even be
something like a filesystem error.  Not likely, but it could be.)


One problem with my list of LDAs so far is that it's just a bestiary;
it doesn't state which are the most-popular alternatives to procmail,
let alone review the entries from actual usage.  (The latter would be
more work than I'm willing to undertake.)  FWIW, almost certainly 
the most often suggested alternative are Courier Maildrop and Dovecot's
deliver (aka 'lda'), as Nathan Willis said in the 2010 LWN.net story.

-- 
Cheers,                                        <BombScare> i beat the internet
Rick Moen                                      <BombScare> the end guy is hard
rick at linuxmafia.com                                           -- seen on IRC
McQ! (4x80)



More information about the svlug mailing list