Re: [ietf-smtp] DSNs

Sam Varshavchik <> Mon, 27 April 2020 22:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24ED03A0C22 for <>; Mon, 27 Apr 2020 15:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fn-glAfbp6Dj for <>; Mon, 27 Apr 2020 15:08:51 -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 0E24D3A0C1F for <>; Mon, 27 Apr 2020 15:08:50 -0700 (PDT)
Received: from ( [::ffff:]) (TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by with UTF8ESMTPS id 00000000002C0011.000000005EA757F1.00007F8A; Mon, 27 Apr 2020 18:08:49 -0400
Received: from (localhost []) (IDENT: uid 1004) by with UTF8ESMTP id 000000000005E9C1.000000005EA757F0.0000F600; Mon, 27 Apr 2020 18:08:48 -0400
References: <20200426222237.7E1351864BA8@ary.qy> <> <>
Message-ID: <>
From: Sam Varshavchik <>
Date: Mon, 27 Apr 2020 18:08:48 -0400
Mime-Version: 1.0
X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg
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: Mon, 27 Apr 2020 22:08:52 -0000

Laura Atkins writes:

> Forwarding can happen before the message hits the recipient’s mailbox (sieve,  
> procmail). Also, recipients may have per-user filters to /dev/null mail,  
> before the MUA gets it or afterwards - most MUAs allow for blocking. Often,  
> these are solutions implemented to avoid harassment or abuse and there is a  
> significant security / escalation risk for the people implementing the blocks  
> if the blocks are discovered. 

I only dimly recall, a very, very long time ago, seeing precursors to modern  
DSNs that included the exact details of what procmail did with a given  
message. This was long before DSNs were standardized.

I have not seen any modern DSN that spills the guts to such a detail. All  
the ones that I've seen, that follow the current spec (to varying degrees)  
say nothing more than the mail was delivered (or not) to such and such E- 
mail address without going into the details as to where exactly the mail  
wound up, in the actual INBOX, or trash.

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. So, neither success nor failure DSNs really  
have any value to the receiving party. But I do not see any security issue  
with DSNs themselves, as specified.