Re: [ietf-smtp] DSNs

Sam Varshavchik <> Tue, 28 April 2020 12:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67B813A08B7 for <>; Tue, 28 Apr 2020 05:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YwaK0jawhQxQ for <>; Tue, 28 Apr 2020 05:19:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 604803A0868 for <>; Tue, 28 Apr 2020 05:19:13 -0700 (PDT)
Received: from ( [::ffff:]) (TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by with UTF8ESMTPS id 00000000002C0012.000000005EA81F3E.000098E9; Tue, 28 Apr 2020 08:19:10 -0400
Received: from (localhost []) (IDENT: uid 1004) by with UTF8ESMTP id 000000000005E9BC.000000005EA81F3E.00012D2B; Tue, 28 Apr 2020 08:19:10 -0400
References: <20200426222237.7E1351864BA8@ary.qy> <> <> <> <r886v8$kl3$>
Message-ID: <>
From: Sam Varshavchik <>
Date: Tue, 28 Apr 2020 08:19:09 -0400
Mime-Version: 1.0
Content-Type: multipart/signed; boundary=""; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [ietf-smtp] DSNs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Apr 2020 12:19:16 -0000

John Levine writes:

> In article <>om>,
> Sam Varshavchik  <> wrote:
> >I do agree that I don't /quite/ see the value-added to the recipient of
> >implementing success DSNs. Or any DSNs, for that matter. If the receiving
> >mail server does not want the email it should reject it instead of accepting
> >it and generate a failure DSN.
> In general I agree but there are still situations where an MTA (mine
> for example) accepts a message intending to forward it somewhere else
> and then the forward fails.  Either send a DSN or drop it on the floor
> at that point.

Well, yes. You take ownership of that message by the act of forwarding, you  
now own it, from the point of forwarding. If you don't want to disclose the  
forwarded-to address, that's your responsibility, so either set the sender's  
address to <>, or to some other address where you want the bounces to go.

Presuming that you decide to keep the original MAIL FROM, you obviously made  
the decision to forward your mail knowing, fully well, that in the event of  
a problem your forwarded-to address is going to be visible. This is not an  
inherit problem with DSNs. That's how they work.