[Top] [All Lists]

Re: Queued Mail or Unreturnable Mail?

2008-05-05 10:27:43

On May 5, 2008, at 6:20 AM, Sabahattin Gucukoglu wrote:

On Mon, 05 May 2008 11:51:30 +0200, Alessandro Vesely 
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?

That question seems ill-conditioned to me. It is semantically correct to reject mail because the *recipient* is undeliverable.

The question is written as intended, but we appear to be in agreement.

I still want to know why sender verification is a good idea, though. If the recipient validation is sufficient to reduce backscatter and queue cloggage, why *are* we insisting upon a semantic disapproval of invalid sender addresses? What kind of high horse are we on, to insist that even under normal mail delivery circumstances, sender addresses of less-than-perfect form may not be used?

Messages are often carried over multiple MTAs where the majority of messages exchanged are undesired. Checks performed at each differ, where for example, a full mailbox will still likely result in non- delivery notifications. To avoid delays and high losses occurring with NDNs, validation of the return path _prior_ to message acceptance best ensures delivery integrity. Return-path validation should become just a check for an associated MX record.

Certainly, to me, this looks like an anti-spam tool which, while tempting to the eye of the postmaster wishing to reduce tempfailing blowback, is already seeing diminished usefullness and which is known to break legitimate mail.

Legitimate mail must be made easy to recognize. In effect, this means any domain transmitting SMTP messages should publish MX records. Otherwise this will expose any domain being spoofed as originating a spam campaign to what may be significant amounts of highly distributed undesired traffic. This traffic is associated with attempts to deliver NDNs and to confirm of the return-path by establishing a connection. After all, an address record says nothing about whether the SMTP service is supported.