Subject: Re: [Asrg] where the message originated (was: DKIM role?) (SM)

From: Paul Russell <[email-masked]>
Date: Thu, 05 Feb 2009 19:22:48 -0500

On 1/26/2009 3:54 PM, Graeme Fowler wrote:
> On Sun, 2009-01-25 at 22:12 -0500, Paul Russell wrote:
>> Exchange parses an inbound DSN to identify every address for which delivery
>> status information is provided, then pre-pends the entire DSN with boilerplate
>> text for every address in the DSN, regardless of the specific status code and
>> text for that address.
> 
> In my current experience, it's *Outlook* which does the
> mangling/prepending/call-it-what-you-will.

I access my Exchange mailbox using Thunderbird; Outlook is not in the picture.

Appended below is the DSN I received when I sent a test message to a known bogus
address in a domain I control.  Everything above the original message headers
was added by Exchange.  We see the same boilerplate in every DSN handled by the
Exchange servers, regardless of the actual delivery status information returned
by the MTA that generated the DSN.  This is particularly problematic when the
a message is sent by an Outlook, Entourage, or OWA user to multiple recipients,
and at least one recipient address is invalid, because the resulting DSN will
include delivery status information for every recipient, including those for
whom delivery was successful.  Unfortunately, the first thing the recipient of
the DSN sees is the boilerplate stating that delivery failed for every
recipient.

==== begin =====
 > Delivery has failed to these recipients or distribution lists:
 >
 > [email-masked]<mailto:[email-masked]>
 > The recipient's e-mail address was not found in the recipient's e-mail
 > system. Microsoft Exchange will not try to redeliver this message for you.
 > Please check the e-mail address and try resending this message, or provide
 > the following diagnostic text to your system administrator.
 >
 > The following organization rejected your message: smtp.easydns.com.
 >
 > Diagnostic information for administrators:
 >
 > Generating server: mx-p1.cc.nd.edu
 >
 > [email-masked]
 > smtp.easydns.com #<smtp.easydns.com #5.1.1 SMTP; 550 5.1.1
 > <[email-masked]>: Recipient address rejected: User unknown in local
 > recipient table> #SMTP#
 >
 > Original message headers:
 >
 > Return-Path: <[email-masked]>
 > Received: from osgood.cc.nd.edu (osgood.cc.nd.edu [129.74.250.227])
 >         by mx-p1.cc.nd.edu (Switch-3.3.0/Switch-3.3.0) with ESMTP id
 > 	n15NlrkU014403
 >         (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
 >         for <[email-masked]>; Thu, 5 Feb 2009 18:47:53 -0500
 > Received: from [172.19.226.30] (nat20.cc.nd.edu [129.74.4.120])
 >         (authenticated bits=0)
 >         by osgood.cc.nd.edu (Switch-3.2.2/Switch-3.2.2) with ESMTP id
 > 	n15Nls7M008205
 >         (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
 >         for <[email-masked]>; Thu, 5 Feb 2009 18:48:06 -0500 (EST)
 > Message-ID: <[email-masked]>
 > Date: Thu, 5 Feb 2009 18:47:53 -0500
 > From: Paul Russell <[email-masked]>
 > User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
 > MIME-Version: 1.0
 > To: [email-masked]
 > Subject: test msg to known invalid address
 > Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
 > Content-Transfer-Encoding: 7bit
 > X-Source-IP: 129.74.250.227
 > X-ND-MTA-Date: Thu, 05 Feb 2009 18:47:54 EST
 >
 > ------------------------------------------------------------------------
 >
 > Reporting-MTA: dns; mx-p1.cc.nd.edu
 >
 > Final-recipient: RFC822; [email-masked]
 > Action: failed
 > Status: 5.1.1
 > Remote-MTA: dns; smtp.easydns.com
 > X-Supplementary-Info: <smtp.easydns.com #5.1.1 SMTP; 550 5.1.1
 >  <[email-masked]>: Recipient address rejected: User unknown in local
 >  recipient table>
 >
===== end =====

---

From: David Nicol <[email-masked]>
Date: Tue, 10 Feb 2009 16:25:02 -0600

On Mon, Jan 12, 2009 at 6:51 AM, Ian Eiloart <[email-masked]> wrote:
>
> In a world where you *can* prevent abuse of your domain, what's wrong with
> bouncing email?
>
> --
> Ian Eiloart
> IT Services, University of Sussex
> x3148

Nothing, provided that by "bounce" you really mean "reject"