[Top] [All Lists]

Queued Mail or Unreturnable Mail?

2008-04-30 10:33:07

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 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. :-)


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

<Prev in Thread] Current Thread [Next in Thread>