Lloyd Zusman <[EMAIL PROTECTED]> writes:

> I am using TMDA within a larger system of spam control that consists of
> SpamAssassin and some of my own, home-grown filters.  I run this all
> under the Courier MTA (I'm using version 0.43.2 of that software, a
> fairly recent release).  Because of all this, one of the paths that
> email travels through does not result in SENDER being set before TMDA
> gets invoked (this occurs when the MTA returns a non-delivery message).
> This is the cause of the problem I mention above.

You are running TMDA from maildrop, correct?  Do these messages come
through maildrop?  Is there any way to detect a missing $SENDER and
set it yourself (to the empty string, since these are bounces)?

> Non-delivery responses to confirmation requests should never require any
> further response.  Therefore, I believe that TMDA doesn't really need to
> know the sender in this case.

TMDA has no way to determine whether a message is a bounce or not,
except through the RFC-defined empty sender, <>.  TMDA doesn't really
care if it's a bounce, of course, but it does have special provisions
for empty senders.

> Can any of you think of a way to make TMDA recognize these kinds of
> responses, and to thereby handle the message in such a way that the
> code on line 236 of tmda-rfilter is completely bypassed?

If TMDA were to ignore the absence of a $SENDER variable (it would
have to assume the sender was empty), it couldn't distinguish between
real empty senders and misconfigurations, which in turn could lead to
lost mail, if the pending queue wasn't carefully examined on a regular
basis.  My gut says ignoring a missing $SENDER variable isn't a good
idea.

Assuming you can't create a fake one (in maildrop) if you detect it's
missing, is it possible to patch Courier to always create $SENDER?
All the other MTAs we support behave consistently for all types of
messages (with the exception of Sendmail, of course, which almost
never behaves correctly... sigh).


Tim

_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users

Reply via email to