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: feedme(_at_)yamta(_dot_)org
Phone: +44 20 88008915
Mobile: +44 7986 053399
http://sabahattin-gucukoglu.com/