(running unhacked complete courier 0.44.2 on rh9)

can someone help me with the flow involved with the calling of maildrop filters.

in my particular setup i have two methods of calling a maildrop filter, one local and one global.

in ~/.mailfilter/smtpfilter I use a maildrop "include" statement to reference a script that in turn calls either spamc or spamassassin (see * later why I mention both spamc AND spamassassin )

also, I have a file /usr/lib/courier/etc/maildroprc defined that does something similar in that it contains a maildrop "include" statement that calls a maildrop script that also calls spamc or spamassassin.

these two SA calling scripts are only different in that they make a note in the maildrop filter log to specify who the caller was for tracing and debugging purposes. in the remainder of this email i refer to them as either an smtpfilter call or a maildroprc call. (note that each script dumps the maildrop var $MAILFILTER to the maildrop log file. in the case of the smptfilter the $MAILFILTER var contains the string "smtpfilter" - seems reasonable - but following the call from maildroprc the $MAILFILTER var contains a null string.)

there is one other significant difference in the two scripts - i'd love an explanation of this too - i find that for the maildroprc to work correctly (not deliver email upon detection of spam) the EXITCODE must be set to 0 upon detection of spam:

if ( /^X-Spam-Flag: YES/ ) { echo "SpamAssassin (maildroprc) declares this email to be spam" EXITCODE=0 exit }

whereas in the smtpfilter script the EXITCODE must be set to 1 for the email not to be delivered: if ( /^X-Spam-Flag: YES/ ) { echo "SpamAssassin (smtp) declares this email to be spam" EXITCODE=1 exit }

go figure....

now, here is the embarrassing part. I cannot determine why in some cases the smptfilter gets called alone, in other cases the maildroprc filter gets called alone and in some other cases, they both get called and applied to a single piece of email. i clearly do not understand something significant about the flow here. yes - i have read the documentation, searched the internet, checked the mail list archives.

i would have thought that global filtering would have been done first, maildroprc, then the user's local filter, smtpfilter, would follow (if the global filter hand't punted the email as spam) but now i'm not sure...

(*) it seems that sometimes when spamc is specified that the calls cannot be completed as I get a high frequency of msgs in the /var/log/maillog:

Apr 25 15:18:15 aasen courieresmtpd: error,relay=::ffff:205.219.84.13,from=<zmqo...@everymail.net>: 558 450 maildrop: Unable to filter message.

this problem disappears when spamassassin is called explicitly, rather than the daemon, spamd. is there way to debug explicitly why maildrop is unable to filter the msg - clearly we aren't talking about a maildrop language syntax error as sometimes the scripts work. the entries in the /var/log/maillog aren't very helpful. redirecting the spamd log info to a file (spamd -s file) doesn't increase the verbosity or help in any other way.

so, wouldn't you think that putting the call in maildroprc alone would be enough - all i really want is a global filter to call spamassassin and detect spam - i did, and apparently i was wrong. the only way i could get all mail calling SA and subsequently filtered was to add the call from .mailfilter/smtpfilter - but the downside now is that sometimes, just sometimes, both scripts are called (but not always!) what was that about programs behaving deterministically?

and then there is the issue of the maillog msg originators - can someone tell me why sometimes the msg doesn't originate from couriersmtpd but instead courierlocal as in:

Apr 25 18:41:26 aasen courierlocal: id=000045FB.408C68BE.00004AA1,from=<038...@cse.nagoya-u.ac.jp>,addr=<pet...@davies.com>:
SpamAssassin (maildroprc) declares this email to be spam

Apr 25 05:49:46 aasen courieresmtpd: error,relay=::ffff:66.54.93.250,from=<CfDr...@srcbprs.com>: 558 450 SpamAssassin (smtp) declares this email to be spam

i guess the question here is why does some "external" email get handled by courierlocal where as other external email gets handled by couriersmtpd? its seems that an error detected by the global filter, maildroprc, would be reported by a module named courierlocal. i'm missing something significant here.

hopefully there is enough stupidity in here to provoke mr.sam into making a terse, yet meaningful comment bu yet not too much that there will be no response - the ultimate courier list insult...

thanks for any and all help

peter