Re: [Asrg] reject and DSN, was What are the IPs

Ian Eiloart wrote:
> --On 2 July 2009 13:54:09 +0000 John Levine <johnl(_at_)taugh(_dot_)com> wrote:
>
> > You appear to be under the impression that a sender would obtain and
> > use valuable information from a DSN that can't be sent in a rejection,
> > which is completely contrary to my experience.  I don't spend an
> > enormous amount of time reading DSNs, but my mailing list software
> > does and all it really wants to know is the address that bounced,
> > which rejections reliably provide.  DSNs often give no hint what
> > address the bouncing message was sent to.  That's why we have to use
> > kludges like VERP.
> I guess rejections are more useful for automated processes, but they're 
> often converted to DSNs anyway. Certainly, our mailing list software only 
> sees DSNs. VERP may be a kludge, but it is a solution.
> DSNs have the potential to be more useful to humans if they're constructed 
> by the MTA that has more information.
You seem to be missing the distinction here.

Users (and most automated processes that defer to a MTA to initiate 
sending) _only_ see DSNs [+].
The question is _who_ constructs the DSN?

If it's the MX (or later) of the recipient, (IOW: _recipient_ generated 
DSNs) you get backscatter.  This is bad.  It's so bad that it's 
generally better to blackhole (possibly providing quarantine on the 
recipient side to find misfires) once the perimeter has accepted the 
email than to DSN later.
If its the sending MTA (the one that does the MX lookup and connect and 
is reacting to an inline-reject), this is good.  Good MTAs can generate 
quite readable messages if they care to.  Even if only to generate a 
reasonably well-formatted message that explains what the MX MTA actually 
said in its rejection.
I've seen a number of MTAs that do a good job (eg, postfix I think) on 
formatting DSNs, and others that do an abysmal job (eg, gag, Exchange).
> DSNs are often hard to understand, especially when the sending MTA is 
> trying to wrap an error message. All too often, they discard the error 
> message and insert completely misleading diagnostics.
Eg: Exchange.

The work, if any, is to to encourage that sending MTAs generate 
reasonably readable DSNs from a reject and NOT to discard the text of 
the rejection.  Encouraging DSNs once you're past the MX's acceptance is 
a very bad idea.
[+] The only time a user will directly see an SMTP reject is during the 
SMTP SUBMIT phase with their own MTA.  The only time an application will 
see a reject "properly" is if it's the application's own SMTP client.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg