"Jason R. Mastaler" <[EMAIL PROTECTED]> writes: > Lloyd Zusman <[EMAIL PROTECTED]> writes: > >> The reason I manually set SENDER in cases such as these is because >> TMDA throws an exception if there is no sender set. > > Right, because $SENDER is how TMDA gleans the envelope sender address > of the message. > >> there are cases where my MTA doesn't get a chance to force the >> SENDER variable to be set. > > You are using Courier and/or maildrop no?
I am. >> Is there any way that a future version of TMDA might handle the >> no-SENDER case gracefully? ... > > How then would TMDA be able to distinguish between a misconfiguration > ($SENDER is not set), and an empty envelope sender address ($SENDER is > set, but has a null value)? Well, how about this: allow us to put an optional directive in our configuration file that tells TMDA to treat SENDER as if it has this user-configured value if SENDER doesn't appear? This way, I can make my own user-specific assumptions about how to handle a missing sender, without TMDA having to try to figure out why this variable isn't set. Hmmm ... even better yet would be if this configuration directive could contain executable Python code, so I can implement some kind of user-specific run-time heuristic about this. > Another user discovered[1] that maildrop removes variables from the > environment if they have an empty value. He reported[2] the problem on > the maildrop list, but AFAIK nothing was done about it. I believe this > is a bug in maildrop and would like to see it fixed there. OK. I'll check over there. As for variables having an empty value being removed ... what if I just set "SENDER" to an empty value if it doesn't appear in my environment before my call to "tmda-filter -p"? Will TMDA handle this case? -- Lloyd Zusman [EMAIL PROTECTED] _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
