Re: [ietf-smtp] DSNs

Dave Crocker <> Sun, 26 April 2020 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED2603A08E5 for <>; Sun, 26 Apr 2020 08:24:19 -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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TVeRDYN8vFLJ for <>; Sun, 26 Apr 2020 08:24:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DB993A08E7 for <>; Sun, 26 Apr 2020 08:24:17 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 03QFQ2j2026284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 26 Apr 2020 08:26:03 -0700
To: John C Klensin <>, Ned Freed <>
Cc:, Viktor Dukhovni <>
References: <20200409230011.F039B17637D0@ary.qy> <alpine.OSX.2.22.407.2004091945050.80689@ary.qy> <> <> <r7fq4k$1nm5$> <C1A5FAAA942E0F363CA177C0@PSB> <> <> <> <> <> <CCD9771E28F1C5438052BB1A@PSB>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Sun, 26 Apr 2020 08:24:07 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <CCD9771E28F1C5438052BB1A@PSB>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Sun, 26 Apr 2020 15:24:20 -0000

On 4/25/2020 3:41 PM, John C Klensin wrote:
> --On Saturday, April 25, 2020 14:46 -0700 Dave Crocker
> <> wrote:
>> ...
>> First, I meant whether the feature worked, for whatever
>> reason.  If operational policy prohibits its use, then it
>> doesn't work.
> Dave, I think this is where either your comments are still not
> clear (at least to me) or we disagree.
> Suppose there were correspondents, or even domains, for which I
> have found read receipts useful and something I'm willing to let
> them use.  So, because of them, I advertise the availability of
> that feature in the EHLO response. 

You think that advertising something through an EHLO response produces a 
communication of that support back to one or another author?

For that matter, you think that advertising anything, downstream and as 
part of a real-time infrastructure transaction, affects later 
origination behavior?

Also, MDN isn't an SMTP option.(*)  It's a user-level feature, unlike 
DSN.  It's independence of the transport service is why it's usable; the 
requirement for protocol support of DSN requests at every SMTP hop is 
why it has such poor -- in my experience, non-existence -- utility.

 > When the MAIL command comes
> along and doesn't contain that domain or mailbox, I reject the
> request. 

Sorry, I'm not parsing this sentence meaningfully. I don't understand 
what specific actions or references you are making in this sentence, nor 
why a rejection by the receiving server is produced.

>    Now, which mailboxes or domains to accept is an

You seem to be saying that advertising DSN support affects which domains 
mail is accepted from, by the receiving server. (You also don't indicate 
which identifier field is to be used for this accept/reject evaluation.)


> Your statement above (at least as I interpreted it) would
> clearly be true (and the feature not workable for policy
> reasons) if operational policies were consistent all across the
> Internet, probably including uses of SMTP over VPNs or SDNs, and
> those policies never allowed the feature to be used, but
> counterexamples  have already been given to any possible
> assertion about the policy condition is globally true.

Let's try a different approach...

Success for any bit of end-to-end functionality requires:

   Specification + Software + Deployment + Operations + Use

If any one of these do not happen, the functionality fails.  If there is 
a long-term demonstration of failure, the functionality is deprecated as 
a matter of pragmatics.  Broadly any effort/expense to support it is 
therefore wasted.  (Obviously, if there are pockets of end-to-end 
support and those pockets matter to the Internet community, then it 
hasn't failed; my comments concern 'general' failure.)

My comment was meant to note that, in general terms, such a long-term 
demonstration of failure for a feature warrants removing it from the 
specification. This a) makes the spec cleaner, b) clarifies to the 
community that the feature isn't supported, c) saves time/money.



Dave Crocker
Brandenburg InternetWorking