From: Don Hammond
Sent: Thursday, April 15, 2004 12:10 AM
On 14 Apr, Dallman Ross wrote:
| what happens if procmail says the EXITCODE is 0 but TRAP says it's
| not zero. Who wins? Does the TRAP value get sent to the MTA,
| or just to the shell?
I haven't been able to follow the entire thread, but I don't
think this got any answers. Excuse me if it did.
You were correct; it hadn't.
After running a handful of tests, all sending a message designed to
trip a recipe from outside tradersdata.com to an address at
tradersdata.com, these are the results.
Setting EXITCODE = 1, generated a bounce (permanent failure)
indicating "unknown mailer error 1", but the message was
delivered successfully.
Leaving EXITCODE alone and setting TRAP = 'false', resulted in the
message being delivered. No bounce.
Very, very interesting. Thank you for bothering to work it
out!
Setting EXITCODE="" and TRAP = 'false' was the same result as
the first.
In summary, all three were delivered appropriately and the first and
third generated a bounce that reflected the EXITCODE = 1.
I had tried one experiment with EXITCODE = 1, then 2, then 3, on
our postfix system under NetBSD. In each case the message was
delivered, followed by a pipeful of "nothingness" to the MDA
in a second (empty, no headers, no body) message. I've actually
been seeing those occasionally for a year or so (and have quaintly
named them "nonmail" and trapped them as such in my .procmailrc --
my invocation of procmail in my .forward runs the -t- switch, so
they do end up with a From_ header). No one seemed to know what
was causing them, except it was happening when the server's load
was way high. So now I think some process sometimes an undefined
return-error code to postfix. Glad to have confirmed that it's
not causing mail to be lost, in any case.
The reason for the third test was a re-read of the man page which
indicated if EXITCODE is set but empty, procmail will set it
to whatever
the TRAP returns. If EXITCODE has not been set, procmail will set it
to zero shortly before executing TRAP. This is all confirmed in the
logs.
Second run (procmail sets EXITCODE=0, because it was
previously unset):
procmail: [25267] Wed Apr 14 17:07:45 2004
procmail: Assigning "TRAP=false"
procmail: Locking "/var/spool/mail/deh.lock"
procmail: Assigning "LASTFOLDER=/var/spool/mail/deh"
procmail: Opening "/var/spool/mail/deh"
procmail: Acquiring kernel-lock
procmail: Unlocking "/var/spool/mail/deh.lock"
From ***(_at_)[redacted] Wed Apr 14 17:07:44 2004
Subject: B-B-B-o-o-o-i-i-i-n-n-n-g-g-g
Folder: /var/spool/mail/deh
1457
procmail: Notified comsat: "deh(_at_)4610903:/var/spool/mail/deh"
procmail: Assigning "EXITCODE=0"
procmail: Executing "false"
Third run (EXITCODE="" before TRAP):
Caught B-B-B-o-o-o-i-i-i-n-n-n-g-g-g
procmail: [25449] Wed Apr 14 17:25:24 2004
procmail: Assigning "EXITCODE="
procmail: Assigning "TRAP=false"
procmail: Locking "/var/spool/mail/deh.lock"
procmail: Assigning "LASTFOLDER=/var/spool/mail/deh"
procmail: Opening "/var/spool/mail/deh"
procmail: Acquiring kernel-lock
procmail: Unlocking "/var/spool/mail/deh.lock"
From ***(_at_)[redacted] Wed Apr 14 17:25:23 2004
Subject: B-B-B-o-o-o-i-i-i-n-n-n-g-g-g
Folder: /var/spool/mail/deh
1469
procmail: Notified comsat: "deh(_at_)4195383:/var/spool/mail/deh"
procmail: Executing "false"
I'm not sure what good this is since there's nothing in the log that
indicates TRAP did, in fact, effectively change the EXITCODE (although
the bounce proves it did). I can't think of anyway to trap that
EXITCODE that wouldn't, at the same time, change it back to zero.
Okay. It's still interesting, at least to me, and I appreciate
your sleuthwork.
Whether you can do anything with it is beyond me, but I think this
answers your question by showing that the TRAP exitcode is being sent
to the MTA.
Dallman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail