ok - wow - that's a lot to digest... So do the dated thing though I'd have to have a lot more complicated config than I do now (I'm an ISP, with remote users... have to start simple and well documented and expand as possible...)
For that I'd need to configure the smtp proxy, and accept mail there (and retag it) for all those outlook users - right? My webmail uses esmtp, so that would work the same... But to allow SOME users to use this and not others, I'd have to use a separate port, and include that in some sort of advanced setup directions (or could this process be configured to just pass the message through if an environtment var / flag indicated the user did not want preprocessing... Setting BOUNCE_ENV_SENDER could be done globally based on the domain of the sending user - or does this have to be done in the smtp proxy? If it's done when called from maildroprc (for incoming mail - not outgoing) then I have the env vars existing containing the user domain, and an alias could be built ([EMAIL PROTECTED]) to use for each virtual server. Would I be supposed to reject any mail to that address, eat it with maildrop? or does tmda eat it for me (cleaning up it's pending at the same time?) Does tmda-ofmipd proxy the authentication when it sends to the local smtp server? We don't allow ANY unauthenticated smtp (we have special patches to our local scripting languages to handle authenticated smtp automatically so all mail returns to sender properly, and no spammers can use the nobody account). I could write a stub to tie into our auth database (mysql) and then bob's your uncle - right? One other question about this - I bet I know the answer cause you HATE programs that lose mail... the ofmipd doesn't return ok until the local smtp does - right? ;-) Thanks - enjoying my progress immensely. m/ > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Tim Legant > Sent: Thursday, January 15, 2004 10:45 AM > To: [EMAIL PROTECTED] > Subject: Re: One more question - bounce processing... > > > "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 > _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
