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

"Chris Lewis" <> Thu, 02 July 2009 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C6713A6DA1 for <>; Thu, 2 Jul 2009 08:05:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vvjE4CxNXmmL for <>; Thu, 2 Jul 2009 08:05:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2E1B43A6DAB for <>; Thu, 2 Jul 2009 08:05:43 -0700 (PDT)
Received: from ( []) by (Switch-2.2.6/Switch-2.2.0) with ESMTP id n62F5wd15216 for <>; Thu, 2 Jul 2009 15:05:58 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 11:05:43 -0400
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Jul 2009 11:05:42 -0400
Message-ID: <>
Date: Thu, 2 Jul 2009 11:05:42 -0400
From: "Chris Lewis" <>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090605 Lightning/0.9 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Jul 2009 15:05:43.0170 (UTC) FILETIME=[91E36E20:01C9FB26]
Subject: Re: [Asrg] reject and DSN, was What are the IPs
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Jul 2009 15:05:44 -0000

Ian Eiloart wrote:
> --On 2 July 2009 13:54:09 +0000 John Levine <> 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.