Tim Legant <[EMAIL PROTECTED]> writes:
> Lloyd Zusman <[EMAIL PROTECTED]> writes:
>
>> [ ... ]
>
> 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)?
These messages are coming through maildrop, but for some reason, despite
the following code in that file, SENDER is still being treated by
TMDA as being unset:
EXITCODE=0
if ( "X$SENDER" eq "X" )
{
SENDER=""
}
exception {
xfilter "/usr/local/tmda/bin/tmda-filter -p"
}
if ( $RETURNCODE != 0 )
{
EXITCODE=$RETURNCODE
exit
}
Perhaps it's a "feature" of maildrop to treat the setting of a variable
to an empty string as unsetting it.
In an earlier message here, Jason recommended that I do not do this:
SENDER="<>"
Therefore, the next thing I will try is to replace the xfilter line
as follows:
xfilter "/usr/bin/env SENDER='$SENDER' /usr/local/tmda/bin/tmda-filter -p"
Maybe this will work. I'll give it a try a little later.
> 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.
Well, I can supply rules to TMDA which will match these bounce messages.
If I say "drop" or "reject", or even "ok" in these rules, will that
force line 236 of tmda-rfilter to be bypassed? I don't see how the
sender could possibly be needed if a message is rejected or marked "ok".
> 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.
I understand. However, I still don't see why a message flagged with
"drop" or "reject" or "ok" would need to be tested for a valid SENDER.
> 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).
Well, the /usr/bin/env workaround I mentioned above might do the job for
me. I'll give it a try and report back a little later.
But I still think that $SENDER should only be tested in the cases where
TMDA knows for sure that it needs to send something back to the
message's originator.
> Tim
--
Lloyd Zusman
[EMAIL PROTECTED]
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
