Re: Queued Mail or Unreturnable Mail?

Sabahattin Gucukoglu wrote:
> To be sure, it sounds like the right thing to do.  As yet, though, there's 
> no justification in doing it other than that queue clogging will often 
> result if you don't.  Is it *semantically* correct to reject mail just 
> because bounces for the sender are undeliverable?  If it isn't, fine -
That question seems ill-conditioned to me. It is semantically correct 
to reject mail because the *recipient* is undeliverable. In addition, 
the semantics of the MX record, or lack thereof, should hint that 
verifying a recipient address is much easier for a receiving server 
than investigating about the sender address. Established such basic 
point, there are a number of standard situations, ranging from 
secondary MXes to remote MDAs, where recipient verification can be 
difficult. Those are instances of forwarding within the mail receiving 
network.
Let me spend a paragraph to clarify that the global semantics of MX 
records allow to univocally determine a boundary between mail 
originating network and mail receiving network. The boundary point 
lies after the server that looks up the global MX record of the 
destination address for the first time. (That obviously depends on the 
particular forward path that a given message gets through.) 
Successively, the recipient address itself can even be changed, e.g. 
according to alias or list expansions. This considerations suggest 
that the extent to which a server accepts responsibility for 
delivering a given message, and therefore the semantics of a possible 
rejection, are entangled with the whys and wherefores of the relevant 
SMTP transaction.
Forwarding has been broken since rfc 1123 deprecated building the 
return path. In particular, the semantically widely different possible 
reasons for forwarding have never been extensively worked out: List 
expansion is currently well described, but mailing lists are not 
differentiated from newsletters. Alias expansion, as standardized, 
only suits mail delivery within the same server/domain. Privacy 
mandated final address non-disclosure is mentioned, but not thoroughly 
analyzed. Perhaps those concerns don't belong to the SMTP 
specification, but the semantic of accepting a message varies 
accordingly. For example, a company might decide to forward all 
incoming mail to an internal "big brother" mailbox for statistical 
purposes; however, a sender does not deserve a DSN in case that 
mailbox gets clogged.
I would argue that if a server is unable to verify a given recipient 
address before accepting a message, there must have been something in 
its forwarding reasons that altered the transaction's semantic 
dramatically. Except for backup MXes. The current trend to strengthen 
mail acceptance in order to avoid backscatter, leaves something to be 
desired for classically conceived backup MXes, which is probably why 
they are not much in vogue nowadays.
HTH
Ale