"Mitch (WebCob)" <[EMAIL PROTECTED]> writes: > Someone on the courier list suggested that processing empty senders didn't > make sense
First, some background. Mail from an empty SENDER is not special to TMDA except that TMDA won't send a challenge for that message. This is pretty logical, since TMDA sends challenges to the SENDER and there isn't one. In practical terms that means that the message will be stored in pending/ and at some point in the future (default 2 weeks) the message will be automatically deleted. If the SENDER variable isn't set, TMDA can do one of two things: it can raise an error and defer the message temporarily, so that delivery will be attempted again, or it can assume that the SENDER was <>. A misconfiguration can cause SENDER to be empty, even if an envelope sender was provided during the SMTP transaction. So TMDA can't tell whether a non-existent SENDER means that the user has a configuration problem or that the envelope sender really was <>. What this means is that legitimate mail could end up in pending/ with no challenge issued and, two weeks later, it will be deleted with the recipient none the wiser. Both Jason and I despise programs that happily lose legitimate mail. So, TMDA takes the first approach given above when it encounters an unset SENDER variable; it hollers and postpones delivery in order to give the user a chance to fix the configuration. > I realize it does (that's how TMDA knows about the bounces to > it's confirmation messages - right?) BUT on the other hand, will TMDA eat > the bounces that my users generate themselves? TMDA may or may not see bounces to its challenges. If BOUNCE_ENV_SENDER is left at its default setting (the empty sender, <>), then it will never see bounces to those messages. The reason is that MTAs send bounce messages to the envelope sender, but who, exactly, is <>? A bounce of a bounce is called a double bounce and is usually sent to 'postmaster', although most MTAs allow this to be configured. (Note: TMDA recognizes these [SENDER is "[EMAIL PROTECTED]"] and will not challenge them). Some people configure BOUNCE_ENV_SENDER to a special throwaway address so that bounces to TMDA challenges get tossed rather than filling up their postmaster's mailbox. As far as real bounces to legitimate messages sent by TMDA users (SENDER really is <> in these cases), TMDA does nothing special, as I've noted above. The user won't see these bounce messages and they'll eventually be deleted. Since many of us like to see when a message doesn't go through, we configure TMDA to use a dated envelope sender address for outgoing mail generated by us (BOUNCE_ENV_SENDER is used for outgoing mail generated by TMDA). See the FAQ: http://tmda.net/faq.cgi?req=show&file=faq05.004.htp A catch-all rule at the end of your outgoing filter to do the same thing for all addresses not matched by previous outgoing rules would look like this: to * tag envelope dated=10d from bare Tim _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
