[Top] [All Lists]

Re: Queued Mail or Unreturnable Mail?

2008-05-05 03:14:39

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.