"Jason R. Mastaler" <[EMAIL PROTECTED]> writes:
> Lloyd Zusman <[EMAIL PROTECTED]> writes:
>
>> Perhaps it's a "feature" of maildrop to treat the setting of a
>> variable to an empty string as unsetting it.
>
> An unset variable is != to a set variable whose value is null. All
> the other mail delivery agents TMDA supports distinguish these two
> cases. This is clearly a maildrop bug IMO.
>
> Someone has already reported this to the maildrop list, but it has
> been ignored thus far. This issue needs to be pursued there, or
> directly with the maildrop maintainer. See
> http://mla.libertine.org/tmda-users/2003-09/msg00324.html
>
>> In an earlier message here, Jason recommended that I do not do this:
>>
>> SENDER="<>"
>
> I don't think so. Please recheck our correspondence.
Unfortunately, it has expired in my email archive. But I thought you
recommended against this in favor of setting that variable to an empty
string, for reasons of forward compatibility with possible future
changes that might some day get made to this code (in tmda-rfilter):
if envelope_sender == '':
envelope_sender = '<>'
But if I misunderstood you, then so much the better, because I'd prefer
to set SENDER to <> prior to invoking tmda-filter, if that environment
variable isn't already set.
>> 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.
>
> The check for $SENDER is done well before the incoming filter file is
> read.
Aside from the complications involved in refactoring working code, are
there any other reasons why a future version of TMDA couldn't have this
test performed right before a message is going to be sent to the
original sender?
--
Lloyd Zusman
[EMAIL PROTECTED]
_____________________________________________
tmda-users mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-users
