[moving this to tmda-workers where it's more appropriately discussed. See http://mla.libertine.org/tmda-users/200212/msg00129.html for Roy's original message]
Roy Badami <[EMAIL PROTECTED]> writes: > Jason, have you had a chance to think about this any more? You ask tough (aka, good) questions. I deferred this one because I didn't have an immediate answer. Thanks for the reminder. > (I'm not subscribed to the list; I just scan the archives now and > then). A much better method is to point your newsreader to the corresponding Gmane newsgroups which allow you to both read messages and post: tmda-cvs <--> news://news.gmane.org/gmane.mail.spam.tmda.cvs tmda-users <--> news://news.gmane.org/gmane.mail.spam.tmda.user tmda-workers <--> news://news.gmane.org/gmane.mail.spam.tmda.devel tmda-announce <--> news://news.gmane.org/gmane.mail.spam.tmda.announce > As I understand it TMDA by default sends its mail by opening an SMTP > connection to the local mail daemon. So if you're not seeing this > problem with qmail, it sounds like qmail's SMTP listener will accept > a RCPT TO command for a non-existent user in the local domain, and > queue the mail anyway (and then subsequently bounce it). I do believe that's correct. > In general, you should *expect* an SMTP listener to reject the > transaction if it can immediately verify that the address is > undeliverable. Sendmail, postfix and exim all seem to behave this > way. It seems so. > So I think far from sendmail doing something unusual, I rather > suspect that TMDA is relying on qmail (or perhaps just your qmail > installation) doing something unusual... All qmail installations act this way. This omission wasn't intentional, it's just that I only use qmail at the moment, as do most (all?) of the current TMDA developers, so this wasn't caught. > Think about what qmail will do once it's accepted your message: it's > got a message to a non-existent local user, that is clearly > undeliverable. The message has a null envelope sender so it can't > bounce it to anyone. Whilst I'm not familiar with qmail, the only > things an MTA can do under these circumstances are to notify the > postmaster, or to silently drop the message. It causes a qmail ``double-bounce'' which indeed ends up going to the postmaster. Many TMDA users set BOUNCE_ENV_SENDER to some /dev/null-ish address though, so in that case no one would see the bounce. > I would suggest that if a confirmation mail (or any mail with a null > sender) causes a hard (5xx) error, then TMDA should (configurably) > either silently give up on the message, or notify postmaster (or > another specified user). I'm not comfortable trying to notify the postmaster or another e-mail address as that's a misconfiguration waiting to happen. I'm on the fence with regards to silently failing on a 5xx SMTP reply code. RFC 2821, section 4.2.1 says about 5xx reply codes: 5xy Permanent Negative Completion reply The command was not accepted and the requested action did not occur. The SMTP client is discouraged from repeating the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct the SMTP client to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered the account status). So, I don't think we can assume that a 5xx code definitively means that the message should not and can not be retried. Dropping the auto-response on the floor won't allow the TMDA user to ``reinitiate the command sequence by direct action at some point in the future'' which may result in the user not seeing the orignal message (as the sender won't be able to confirm it). Indeed, some 5xx replies do indicate only transient failures, or SMTP server misconfigurations, and so dropping the message in these cases would be harmful. For example, A temporary DNS lookup failure resulting in an a 553 reply: http://mla.libertine.org/tmda-users/200206/msg00325.html The very common case where the qmail server is not configured for mail relay produces a 553 reply: http://tmda.net/faq.cgi?req=show&file=faq03.003.htp I'm considering a couple of options here. (1) Document that non-qmail users who experience these problems can set OUTGOINGMAIL = 'sendmail' in the .tmda/config which will cause TMDA to send mail using the /usr/sbin/sendmail interface rather than direct SMTP, thus avoiding the problem. (2) Provide a configuration option (default is false) which silently fails when the SMTP server returns a 5xx reply code. This is useful for users who don't run qmail, are unable to use the /usr/sbin/sendmail interface, are unable or unwilling to configure their MTA around this issue, and are willing to accept the possible risks and ramifications of this decision. Thoughts anyone? I start to get conservative when mail loss is possible, so I'm leaning toward option #1. FWIW, I consider this yet another example of where qmail "does the right thing" even though the other MTAs do not. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
