Hi all, This question is bothering me. It's stalled my reading of 2821bis, and the discussion around the issue (having diverged from IPv6) seems worthwhile fodder for continued debate.
I've got a message in my queue here destined for natwest.co.uk. Natwest.co.uk exists, but it isn't running an SMTP service; it's intended as a web server. There's no MX, and I don't check SPF. (Both natural conditions for typical hosts.) The message is a DSN generated by this host. The original message was intended for a primary host for which I am an acting secondary. I will only accept mail for primaries when I can't connect to them myself, with a few exceptions to help routing difficulties of some hosts reaching the primary directly. Which is the problem? 1. I am naive enough to receive mail from non-verifiable senders. I have not gone even to the extent of checking that the domain exists; a surefire but, as you can see here, pointless check. I will never be happy until every conceivable check is done to verify that, should an error occur, I wil *always* be able to send mail back to the sending site at the sending mailbox. There will never be mail for which I cannot succeed in delivery a status report. That will be true even during my transition to IPv6: without, dual, exclusive. Many hosts on the net are already finding it hard both to avoid misusing the null sender and yet to provide a safe, nondeliverable address that isn't rejected at the SMTP level for those common (but inadvisable) instances where bounces aren't actually wanted without creating blackholes. (Perhaps you could argue that, for sites which send double bounces to local postmasters, sending to noreply-style addresses which *are* rejected during the SMTP conversation at least gives the sending site a chance to review why bounces are being generated for recipients there post-accept.) 2. I am not doing enough to ensure that I will not have to generate a DSN. The problem is not the semantics of nonexistent senders so much as that the result is backscatter and full mail queues. My endeavours are better served by protecting the recipient mailboxes; by guaranteeing that they are either deliverable or not at the SMTP level (usually RCPT command). I find that this strategy is easiest to implement, and that the only time it is a problem to deliver unreturnable mail for mailboxes at the local host is the rare case when the recipient (who is, more often than not, a human being) needs to return some status report about mail sent to it. Careful configuration reduces actual blowback, such as by configuring autoreply throttles or denying acknowledgement to untrusted or unknown senders (I have a mailing list which accepts posts from the world but doesn't acknowledge moderated outside posts unless I, the moderator, actually accept or reject the post explicitly). In that event, as we've been saying, the Return-Path is not necessarily appropriate (mailing list software, autoresponders, etc) in which case an unreturnable sender is not an issue where sender fields are return mailbox are different. For the backup MX case, of course, there exists the possibility as shown that mail may be accepted when it is later impossible to propagate to the primary. The envelope sender must then be used, and this results in possibly dead jobs if a verification step wasn't done at the time, but the problem is easily possible to diminish in severity by doing call-forward-style checks or, more surely, by simply maintaining a list of all known recipients at every MX (there is a serious administrative cost if the backup is not maintained by the same people who maintain the primary, in spite of many other reasons why doing that is a bad idea unrelated to recipient mailbox addresses - like spam blocklist or greylisting circumvention). My vote is for 2 on general grounds of practicality, ease of implementation and least harm done. Perhaps elements of 1 can be added, but I'm not certain it's at all useful unless it's done thoroughly enough. While policy-wise 1 makes sense, yet there is little doubt it could never become standardised. It would do too much harm, and the actual benefit is questionable when 2 is an option that has for a long time been advocated as a best practice (many small sites stopped using backup MXs just to avoid the administration and many other sites are less willing to act as backups for complete strangers). Discuss. :-) Cheers, Sabahattin -- Sabahattin Gucukoglu <mail<at>sabahattin<dash>gucukoglu<dot>com> Address harvesters, snag this: [EMAIL PROTECTED] Phone: +44 20 88008915 Mobile: +44 7986 053399 http://sabahattin-gucukoglu.com/
