Subject: [ietf-smtp] SMTP, DSNs, and enhanced replies (was: Re: SMTP server reply extensions)

From: John C Klensin <[email-masked]>
Date: Wed, 08 Apr 2020 13:34:35 -0400

Hi.

This note is just for information and documentation -- no action
required or requested until we have a WG.

Thinking about my recent response to Jeremy and Timo raised
another question about 5321bis: 

Given that the DSN extensions, the DSN model, and the Enhanced
Status Codes are widely implemented and used, should 5321bis
incorporate them or at least reference them normatively?   If
the latter and maybe even if 5321bis ignores them, they are
another candidate for inclusion in the Applicability Statement.

The working copy of 5321bis Appendix G has been modified to add
the above to the list.

best,
  john

---

From: Hector Santos <[email-masked]>
Date: Thu, 09 Apr 2020 10:17:08 -0400

Hello John. I hope all is well during this crisis.

I support a technical summary of OPTIONAL Extended Reply Codes (ERC), 
include some examples but definitely provide references related to ERC.

While ERC is widely supported, not every SMTP system needs them and do 
not implement them. The key consideration is that ERC is not a SMTP 
technical protocol requirement for SMTP communications.  It is a MAY 
and not a SHOULD, and most certainly, not a MUST.

That said, I would support the development of a formal response 
"language" to help automate the system, similar to the "SMTP Service 
Extension for Greylisting Operations" where is has been shown to have 
major benefit for timely mail delivery and DSNs for systems who have 
implemented this protocol.

[1] 
https://tools.ietf.org/id/draft-santos-smtpgrey-00.html#rfc.section.2.3

Related to this, I would "mention" additional SMTP extended add-on 
protocols that have shown and have  some level of SMTP benefits.

Have a good and safe day.

-- 
HLS

On 4/8/2020 1:34 PM, John C Klensin wrote:
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Apr 2020 07:18:47 -0700

On 4/8/2020 10:34 AM, John C Klensin wrote:
> iven that the DSN extensions, the DSN model, and the Enhanced
> Status Codes are widely implemented and used,

DSNs are widely used?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Brandon Long <[email-masked]>
Date: Thu, 9 Apr 2020 12:35:29 -0700

> > Status Codes are widely implemented and used,

Not positive ones, but negative ones?  I haven't done a survey of whether
bounces are typically formatted as DSNs or not, but I thought
they were more common now.

Brandon

---

From: "John Levine" <[email-masked]>
Date: 9 Apr 2020 19:00:11 -0400

>they were more common now.

My impression is that these days if you get a bounce it's usually a DSN.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Apr 2020 16:11:33 -0700

> My impression is that these days if you get a bounce it's usually a DSN.

Right.  I thinking of the SMTP mechanism for a client's /requesting/ its 
use, which as far as I has not gained widespread use.

d/

---

From: "John R Levine" <[email-masked]>
Date: 9 Apr 2020 19:45:40 -0400

> Right.  I thinking of the SMTP mechanism for a client's /requesting/ its use, 
> which as far as I has not gained widespread use.

Oh, RFC 3461.  Agreed, it's basically an SMTP level web bug.  Nobody 
implements that.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Ned Freed <[email-masked]>
Date: Thu, 09 Apr 2020 19:20:19 -0700 (PDT)

> My impression is that these days if you get a bounce it's usually a DSN.

My impression - and (admiteeded limited) data - say so too. That said, I'd
amend that to be "something close to a DSN".
Multipart/report;report-type=delivery-status  yes, but beyond that there can be
a fair bit of noncompliance.

The good news is that there's usually just enough there that an automatic
processor can sort it out.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 09 Apr 2020 19:26:36 -0700 (PDT)

> use, which as far as I has not gained widespread use.

Widely supported, not widely enabled. THe main issue IME is success DSNs. The
way the standard reads you have to support them or be noncompliant. i tell
people security needs override that and to simply reject messages that request
them for security reasons.

Including the SUCCESS machenism was a mistake, but we were quite concerned
about feature parity with X,400 at the time - yes, this is that old - and
blowback wasn't on the radar.

But perhaps the real reason is that none of the mechanism the extension
provides have proven to be essential. Most applications for envelope ids and
original recipient addresses have been implement with more reliable VERP schems
instead, the ability to turn off DSNs completely has always been present, and
control over return of content is (a) Less useful because message sizes aren't
as relevant, (b) Something you don't want th sender to have control over
because of phishing/viral content, and (c) Something you don't want people to
be able to do for really large messages.

				Ned

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 10 Apr 2020 09:58:40 +0100

> Oh, RFC 3461.  Agreed, it's basically an SMTP level web bug.  Nobody

Exim implements that.  Whether it's used is up to the writer of
the config file.
-- 
Cheers,
  Jeremy

---

From: Claus Assmann <[email-masked]>
Date: Fri, 10 Apr 2020 11:04:30 +0200

> Oh, RFC 3461.  Agreed, it's basically an SMTP level web bug.  Nobody

sendmail implemented it too (more than 20 years ago?). I guess it
should read "nobody enables/uses it"?

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Apr 2020 15:41:59 -0400

> On Apr 10, 2020, at 5:04 AM, Claus Assmann <[email-masked]> wrote:
> 

And likewise Postfix also implements RFC3461.  It is on by default.
I turn it off on inbound edge systems, and ignore remote "DSN" on
outbound edge systems.  That way, any DSNs are sent within either my
or the remote ADMD, but not across ADMD boundaries.

Bounces are of course delivered in DSN (RFC3462) form regardless of
whether the DSN ESMTP extension is enabled or disabled.  That is,
when DSN is disabled messages sensibly default to "NOTIFY=FAILURE".

A side-effect of entirely disabling DSN inbound is that NOTIFY=NEVER
is no longer honoured, even if supported earlier along the forward
path, when any message I accept from outside ultimately bounces inside
my system.  This is rare enough to not be an issue.  Arguably it should
be possible to advertise just "NOTIFY=NEVER", but there's no mechanism
for that.  Simpler to just use an empty return path.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2020 21:06:28 -0000

In article <[email-masked]>,
Viktor Dukhovni  <[email-masked]> wrote:
>or the remote ADMD, but not across ADMD boundaries. ...

I meant that nobody sends positive DSNs.  You're right, we get lots of DSN bounces.

R's,
John

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Sat, 18 Apr 2020 19:10:21 -0400

--On Saturday, April 18, 2020 21:06 +0000 John Levine
<[email-masked]> wrote:

>>>> Oh, RFC 3461.  Agreed, it's basically an SMTP level web
>>>> bug.  Nobody implements that.
>>> 
>>> sendmail implemented it too (more than 20 years ago?). I
>>> guess it should read "nobody enables/uses it"?
>> 
>> And likewise Postfix also implements RFC3461.  It is on by
>> default. I turn it off on inbound edge systems, and ignore
>> remote "DSN" on outbound edge systems.  That way, any DSNs
>> are sent within either my or the remote ADMD, but not across
>> ADMD boundaries. ...
> 

But, fwiw, I occasionally (very rarely) request delivery and/or
read receipts and sometimes (especially for the former) get
responses and get them in DNS form.  It may not be common, but
terms like "nobody" are a little strong.

And that brings me back to what I think are the key questions as
far as some potential WG that looks at 5321/5322 updates and
maybe their relationship to other email specs:

(1) Are DSNs implemented broadly enough that it is reasonable to
claim that the spec is good enough to allow interoperability?
Because RFC 3461 met the interoperability criteria for Draft
Standard 17 years ago, I think the only basis for claiming the
answer to that question is not "yes" would be the discovery of
some horrible problem in the specification that, if known, would
have produced a "no" answer when 3461 was reviewed and approved.

(2) Have they been deployed sufficiently to demonstrate that
they are perceived of as useful by at least some of the people
some of the time.  Noting that the requirements for full
standard do not distinguish between good and evil users, the
number of DNS requests --especially for read acknowledgments-- I
see in a month seems to make the case even if I don't choose to
have those acknowledgements sent back out.

(3) Have the specification or the feature proven sufficiently
problematic that we should be moving to deprecate RFC 3461
and/or the specifications that depend on it and/or update it?  I
haven't heard that argument yet.

And that leads to a question that I think is quite separate from
the above:

(4) Are DNSs sufficiently problematic under various conditions
that have been observed in the current world that we would
recommend that at least some of them not be used -- and requests
for them either rejected or ignored -- unless they are
accompanied by some mechanism that allows verification of the
legitimacy of the requestor and request and/or that the reply is
actually a response to a request and requestor.  Unless the
answers to some of those questions require changes to the DSN
spec(s) themselves, it seems to me they are matters for an
applicability statement about when and how DSNs should be used
(or not used) and not about the DNS specs.

Anyway, that is my analysis after reflecting on the recent
thread.  YMMD, of course.

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 18 Apr 2020 22:54:31 -0400

>some of the time. ...

It seems quite clear that the parts of RFC 3461 that describe a DSN to
be sent back on non-delivery are widely implemented.  The SMTP
extensions aren't, but this is hardly the only RFC where people
implement some parts and not others.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 21 Apr 2020 11:00:48 +0200

> And likewise Postfix also implements RFC3461.  It is on by default.

Ditto for Courier-MTA.

> or the remote ADMD, but not across ADMD boundaries.

May I ask why?  I may be dumb, but I don't see the risk of letting positive
DSNs be returned when (rarely) requested.  Yes, it may betray forwarding, but
so do negative DSNs, e.g. in case of mailbox full.  Is that the concern?

Best
Ale
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 24 Apr 2020 21:36:24 -0400

> terms like "nobody" are a little strong.

Indeed much too strong, because IIRC support NOTIFY=SUCCESS is on by
default in Postfix, and while I may make a point of turning it off
"at the edge", that's likely not a common practice, and so success
notifications likely work for a large fraction of internet-connected
MTAs.

> claim that the spec is good enough to allow interoperability?

I don't recall seeing any reports of substantive DNS-interop issues on
the Postfix-users list in the almost ~20 years that I've been an active
participant.

> some of the time.

I also believe that DSNs are useful at least between a sending
application to the edge MTA to acknowledge handoff from the sender's
edge MTA toto the remote organization's edge MTA.  Though similar data
can be collected by providing log excerpts to applications, sometimes
DSNs are easier to orchestrate.  That said, NOTIFY=SUCCESS is not
common.

> haven't heard that argument yet.

I am not aware of any substantive defects.

> actually a response to a request and requestor.

Here, I would personally recommend to others not advertising DSN on
receiving edge systems, and perhaps also ignoring its advertisement
by remote edge systems.

    * Inbound, I do not want to offer SUCCESS notices, they leak data
      I'd prefer to not leak.  Let the remote MTA send SUCCESS once
      I accept the message.  The rest is none of their business.

    * Outbound, I can give a timely notification to internal senders
      that the message was delivered to the responsible organisation.
      I prefer to not delegate them to them a duty I'm unwilling to
      fulfil inbound, or to trust that they'll carry it out.

-- 
    Viktor.

---

From: Ned Freed <[email-masked]>
Date: Sat, 25 Apr 2020 06:01:59 -0700 (PDT)

> the Postfix-users list in the almost ~20 years that I've been an active

Getting something that meets the basic criteria for a DSN - correct MIME
structure - is not a problem. It's only when you actually go to parse the
things that problems can show up, Usually missing fields, but sometimes you'll
see bogus field values.

All of this appears to be shoddy implementation work, althopugh the one that
leaves the second part blank while including all the secord part information in
the first part goes a bit beyond "shoddy".

But such cases are rare, and in any case, none of this seems to have anything
to do with specification quality.

> DSNs are easier to orchestrate.  That said, NOTIFY=SUCCESS is not

Log processing is actually a poor substitute for a bunch of reasons, not just
the obvious one that DSNs do come back from remote sites while logs, not so
much. Logs are problematic even within an ADMD because every implementation has
its own format. There are also potential security issues with transferring
entire logs around.

Dealing with a single, consistent format, even when there are some
implementation issues, is easier.

> I am not aware of any substantive defects.

Aside from implementation errors, I've seen no operational problems with DSNs,
only with the DSN extension. The problem there is that some people have
claimed that since NOTIFY=SUCCESS is a part of the base and they don't want to
do it the only alternative is to disable the entire extension. I disagree; I
think that since security concerns are paramount it's perfectly OK to simply
reject NOTIFY=SUCCESS on security grounds. Regardless, there needs to be
language added saying that implementations MAY reject/ignore NOTIFY=SUCCESS,
and perhaps there needs to be a way for the extension to incidate that this is
going to happen.

> receiving edge systems, and perhaps also ignoring its advertisement

The problem with this approach is that it breaks end-to-end features of
the extension like ENVID and ORCPT. ORCPT in particular is very useful.

>       I accept the message.  The rest is none of their business.

They also provide another means of creating blowback.

>       fulfil inbound, or to trust that they'll carry it out.

Interesting idea to ignore the advertisement and return relayed. Nobody
has ever asked us for it, but legitimate use of NOTIFY=SUCCESS is rare.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Apr 2020 07:56:56 -0700

On 4/25/2020 6:01 AM, Ned Freed wrote:
> reject NOTIFY=SUCCESS on security grounds.

Perhaps this goes to the challenge of a specification's distinguishing 
its essential core, versus desired-but-not-required enhancements.

Fail to support all of the core and it's not valid to claim to support 
the specification.

The danger of a pick-and-choose free-for-all is that a claim to support 
a specification provides little useful information.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 25 Apr 2020 14:47:57 -0400

> a specification provides little useful information.

I'm very much with Dave on this one.  If you're not offering
NOTIFY=SUCCESS, then you're not offering DSN.  Pretending to support it,
but then not offering it is breakage.  On the other hand, since I ignore
"DSN" on the outbound leg, I avoid running into any problems should the
remote side misrepresent its behaviour.

There is no mechanism to offer a fine-grained subset of the DSN ESMTP
extension, so I turn it off entirely.  The only one I'd be comfortable
in offering to outsiders would be "NEVER", but the ability to avoid
some rare bounces is not that compelling.

Thus, for example, I also only send delay notices for outbound mail from
inside, but not for inbound mail from outside.

-- 
    Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Apr 2020 11:57:00 -0700

> remote side misrepresent its behaviour.

To be clear, I wasn't commenting on the details of what should be in the 
core, in this particular case.

But since you've raised it, I'll note that a core which has 
well-established failures to gain widespread adoption and use is a 
pretty poor core.

A specifications is not an exercisesin dictating ideals but in 
facilitating practice.  When there is established practice, it needs to 
return the favor by dictating the specification.

d/

---

From: Ned Freed <[email-masked]>
Date: Sat, 25 Apr 2020 14:15:23 -0700 (PDT)

> its essential core, versus desired-but-not-required enhancements.

Completely inapplicable in this case, I'm afraid. One of the primary goals of
the NOTARY effort, if not the primary goal, was feature parity with X.400.
And the operational model for X.400 was success receipts as the default.

So the feature had to be part of the core. 

But thinkgs change. X.400 collapsed - a casualty of even more serious
design errors than success DSNs. Spam became email's biggest problem,
which made NOTIFY=SUCCESS less desirable. Privacy concerns also arose that
weren't even on the radar at the time this work was done.

> Fail to support all of the core and it's not valid to claim to support

It's not a question of support, it's a question of operational policy. Every
implementation of the DSN extension I've seen has no problem supporting
NOTIFY=SUCCESS. THe debate has been over whether or not it's legitimate to have
an operational policy of bouncing messages that ask for it.

Of course there's also the issue of whether or not the extension, eith
or without NOTIFY=SUCESS, is of sufficient value to enable. Some people
see little value here, and the NOTIFY=SUCCESS situation is sufficiently
bothersome to tip the scale to dropping the extension.

> a specification provides little useful information.

Dave, we're talking about having an operational policy of restricing the use of
exactly one feature which made sense when the standard was defined but has
issues today. This is hardly a pick-and-choose free-for-all.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sat, 25 Apr 2020 14:46:20 -0700

> issues today. This is hardly a pick-and-choose free-for-all.

Apparently I was too terse and also too loose with terminology.  Being 
casual about the word 'support', given the nature of this thread, was 
particularly unfortunate.

First, I meant whether the feature worked, for whatever reason.  If 
operational policy prohibits its use, then it doesn't work.

And my comment, quoted above, was meant to imply that the spec needs to 
change.  There is widespread and intentional non-use of the feature, so 
it has become obsolete.  It's presence in the specification now creates 
a misunderstanding about what is needed in the working Internet.

d/

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 25 Apr 2020 22:52:36 +0100

On 25/04/2020 22:46, Dave Crocker wrote:
>   It's presence in the specification now creates

Can the specification not support uses that are not Internet-wide,
such as within an ADMD?

I think there's a useful distinction to be made between protocol
and profiles.
-- 
Cheers,
  Jeremy

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Apr 2020 18:15:04 -0400

--On Saturday, April 25, 2020 14:15 -0700 Ned Freed
<[email-masked]> wrote:

[...]

>> Perhaps this goes to the challenge of a specification's
>> distinguishing its essential core, versus
>> desired-but-not-required enhancements.
> 
>> Fail to support all of the core and it's not valid to claim
>> to support the specification.
> 
>> The danger of a pick-and-choose free-for-all is that a claim
>> to support a specification provides little useful information.
> 

Agreed.   And FWIW, it seems to me that much, if not most, of
this discussion is not about whether a feature can be
implemented, has been implemented, or interoperates but about a
potentially useful (but so far non-existent, at least in the
IETF) document that says "it would be a good idea to enable
feature A if circumstances and considerations X apply and to not
do so if circumstances and conditions Y apply".  Even if either
X or Y exist all the time or are null, that sort of statement
would likely be useful.  And that is a suggestion for an
Applicability Statement, one that I hope someone who cares will
start writing, not a fundamental flaw or error in the Technical
Specifications.

Just my opinion, of course.

    john

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 25 Apr 2020 22:38:48 +0000

>I think there's a useful distinction to be made between protocol

Is this something an applicability statement would be appropriate for?

Scott K

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Apr 2020 18:41:09 -0400

--On Saturday, April 25, 2020 14:46 -0700 Dave Crocker
<[email-masked]> 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.  When the MAIL command comes
along and doesn't contain that domain or mailbox, I reject the
request.  Now, which mailboxes or domains to accept is an
operational decision, but the behavior, AFAICT, is fully
conforming and it certainly don't mean that the features doesn't
work, just that I have an operational policy prohibiting its use
in most circumstances.  The security vunerability of that
particular policy are obvious but, if I were to tighten them up
to require the the identity of the sender be proven to my
satisfaction, it wouldn't change the analysis.

That exactly becomes particularly striking in the case of read
receipt--type MDNs because, even if the delivery MTA advertises
the feature and accepts the request, all it can do then is to
pass the request on to the receiving MUA because only it knows
whether the message was read (maybe a message body retrieval
request to an IMAP server would be an adequate approximation,
maybe not).   Now there is an end user operational policy issue:
"do I allow a read receipt to be sent to to particular sender?".
That user may have any operational policy he or she fancies,
including ones ranging sending receipts only to messages whose
bodies have verifiable signatures to sending receipts only for
messages that arrive between 10AM and 4PM on alternate Tuesdays
and ignoring all others.  Again, that doesn't have anything to
do with the feature not working.

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.

best,  
  john

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 26 Apr 2020 12:04:12 +0200

On 26/04/2020 00:41, John C Klensin wrote:
> 
> 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.
> When the MAIL command comes along and doesn't contain that domain or
> mailbox, I reject the request.  Now, which mailboxes or domains to accept is
> an operational decision, but the behavior, AFAICT, is fully conforming and
> it certainly don't mean that the features doesn't work, just that I have an
> operational policy prohibiting its use in most circumstances.

Wow, I never tried that at home!

A decade ago we fantasized about a Verified Hello, whereby:

   Non-empty arguments of the MAIL FROM commands are restricted to
   addresses whose domain part consists of the authenticated Domain.
      https://tools.ietf.org/html/draft-vesely-vhlo-06#section-3.4.1

Otherwise, the reply code is ambiguous.  For example:

  4xx HELO name/MAIL FROM inconsistency, try another session.

AFAIK, the HELO name is practically constant for most mailouts, so the above
reply will make the relevant message bounce for days, until timeout.

Best
Ale
--

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 26 Apr 2020 12:31:04 +0200

> weren't even on the radar at the time this work was done.

X.400 collapsed, other things appeared. Delivery and display receipts 
appear to be popular features of some human-to-human instant messaging 
systems nowadays — I've heard that Signal added that precisely because it 
was popular with Telegram users. That's a rumour, but that both have 
delivery receipts is a fact.

I've no idea what the problems with notify=success are considered to be, so 
I don't know whether Signal/Telegram/Threema/… have equivalent problems, or 
whehter the problems relate to some aspect of the implementation that is 
not shared by those IM implementations. I'd love to know.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Sun, 26 Apr 2020 07:20:52 -0700 (PDT)

> > operational policy prohibiting its use in most circumstances.

There are lots of ways to offer NOTIFY=SUCCESS selectively depending on what
you're trying to accomplish. Keeping in mind that it's a RCPT TO parameter,
another possibiity is to only allow it on domains within the ADMD.

Given all the possible uses and ways of authorizing them, it is perhaps better
to focus on the one problematic case: Relay between ADMDs where the server
doesn't trust the client.

> reply will make the relevant message bounce for days, until timeout.

The EHLO name is necessarily consistent with the DNS entries for the client IP.
It most certainly is not reliably the same as the MAIL FROM domain, especially
when operating at scale. And foccing a disconnect/reconnect in such cases is
highly problematic given that we have no means of indicating that's what's
needed, and even if we added one, no existing client would understand it.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Apr 2020 11:07:18 -0400

--On Sunday, April 26, 2020 07:20 -0700 Ned Freed
<[email-masked]> wrote:

>...
> There are lots of ways to offer NOTIFY=SUCCESS selectively
> depending on what you're trying to accomplish. Keeping in mind
> that it's a RCPT TO parameter, another possibiity is to only
> allow it on domains within the ADMD.
> 
> Given all the possible uses and ways of authorizing them, it
> is perhaps better to focus on the one problematic case: Relay
> between ADMDs where the server doesn't trust the client.
>...

Exactly.  I was just focusing on what I took to be an argument
that the functionality didn't work because (presumably everyone)
had operational policies against using it.

  john

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Apr 2020 11:13:11 -0400

--On Sunday, April 26, 2020 12:31 +0200 Arnt Gulbrandsen
<[email-masked]> wrote:

>> the NOTARY effort, if not the primary goal, was feature
>> parity with X.400. And the operational model for X.400 was
>> success receipts as the default.
>> 
>> But thinkgs change. X.400 collapsed - a casualty of even more
>> serious design errors than success DSNs. Spam became email's
>> biggest problem, which made NOTIFY=SUCCESS less desirable.
>> Privacy concerns also arose that weren't even on the radar at
>> the time this work was done.
> 
> X.400 collapsed, other things appeared. Delivery and display
> receipts appear to be popular features of some human-to-human
> instant messaging systems nowadays — I've heard that Signal
> added that precisely because it was popular with Telegram
> users. That's a rumour, but that both have delivery receipts
> is a fact.
> 
> I've no idea what the problems with notify=success are
> considered to be, so I don't know whether
> Signal/Telegram/Threema/… have equivalent problems, or
> whehter the problems relate to some aspect of the
> implementation that is not shared by those IM implementations.
> I'd love to know.

On the differences (not an aspect of the implementation but of
the design) between email and most IM systems (I'm not familiar
with the details of those three) is that SMTP is designed to
work reliably through relays and with systems at the endpoints
that are independent of each other.  Most of the IM systems I've
seen either assume a direct connection between the originating
and destination hosts or require that the entire path between
sender and receiver be under the control of a single provider
entity.   That makes a lot of things easier including that
provider's being able to authenticate and validate the sender
and receiver to the extent it considers necessary.

   john

---

From: Dave Crocker <[email-masked]>
Date: Sun, 26 Apr 2020 08:24:07 -0700

On 4/25/2020 3:41 PM, John C Klensin wrote:
> 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
> 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.)

...

> 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.

d/

(*) 
https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-2

---

From: Ned Freed <[email-masked]>
Date: Sun, 26 Apr 2020 11:26:09 -0700 (PDT)

> why it has such poor -- in my experience, non-existence -- utility.

And IME almost never work. NOTIFY=SUCCESS, on the other hand...

>    Specification + Software + Deployment + Operations + Use

Depending on how you define the ends, both DSN in general and NOTIFY=SUCCESS 
in particular meet handily.

> hasn't failed; my comments concern 'general' failure.)

All this 10,000 feet stuff is starting to make my head spin. Let's please
focus on the specific issue that's been identified here, which is that
sites are turning off the DSN extension entirely on ingress systems because
they believe they have to in order to comply with the specification.

So how do we address this issue? Well, we can:

(0) Move the entire DSN specification to historic.

(1) Revise DSN saying it should only be used within an ADMD.

(2) Same as (1), but only the NOTIFY=SUCCESS part.

(3) Revise the DSN specification and eliminate NOTIFY=SUCCESS.

(4) Change the specification to make it clear you can reject NOTIFY=SUCCESS,
    and specify a status code for that purpose. (This could be done in a
    follow-on document.)

(5) In addition to (4), deprecate NOTIFY=SUCCESS.

(6) In addition to (4), add some sort of indicator to EHLO that NOTIFY=SUCCESS
    will be rejected.

(7) Do nothing.

> community that the feature isn't supported, c) saves time/money.

Even if we believe that removal is warranted or even necessary, the devil is
always in the details. Those details are what concern me, not whether or not
making changes is justified by an overarching standards development philosophy.

				Ned

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 26 Apr 2020 15:43:14 -0400

> (0) Move the entire DSN specification to historic.

I don't believe that's warranted.

> (1) Revise DSN saying it should only be used within an ADMD.

Though I usually give that advice informally, SHOULD would IMHO be too
strong, I think this is closer to MAY, i.e. something along the lines of
(non-normative lower case):

    operators should consider whether limiting the use of DSN to just
    inside their ADMD is appropriate for them.

> (3) Revise the DSN specification and eliminate NOTIFY=SUCCESS.

There is no interoperable way to do that without introducing a new ESMTP
extension keyword, along the lines of:

    250-DSNNG NEVER FAILURE DELAY

with the old "DSN" retaining its original meaning:

    DSN == DSNNG NEVER SUCCESS DELAY FAILURE

>     and specify a status code for that purpose. (This could be done in a

No, that's broken.  Existing MTAs won't know about the shiny new DSN
semantics and will bounce the message, 

> (5) In addition to (4), deprecate NOTIFY=SUCCESS.

Though "DSNNG" could be defined without SUCCESS, while the utility of
SUCCESS is limited, and we should recommend that it not be turned on
"DSNNG" by default, I think that SUCCESS should be retained, for cases
(say within an ADMD) where it can be useful.

> (6) In addition to (4), add some sort of indicator to EHLO that NOTIFY=SUCCESS

This too is broken, but would be addressed with a "DSNNG".

> (7) Do nothing.

This is also an option, with the only downside being that when chooses
to neither offer nor consume DSN SUCCESS across ADMD boundarie, one also
loses the other options.

-- 
    Viktor.

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2020 16:33:06 -0400

In article <[email-masked]> you write:
>I don't know whether Signal/Telegram/Threema/… have equivalent problems, ...

Those are each single systems under single management.  They also
don't make it easy for a user to send a whole lot of messages to
strangers.

With SMTP you have no way to tell who is sending a message that
arrives from outside, and experience tells us that the majority of
incoming mail is hostile.  We don't do success notifications or web
bugs because we don't want to leak info about our users to malicious
strangers.

NDNs don't have that problem sort of by definition since they're
generally saying that the address isn't one of your users.  (I realize
there's "mailbox full" and such, it's not a perfect correlation.)

R's,
John

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 26 Apr 2020 17:02:04 -0400

> bugs because we don't want to leak info about our users to malicious

Can someone explain something, slowly, to me:

Incoming mail is addressed to a non-existent recipient. Your MTA rejects the  
recipient.

Incoming mail is addressed to a valid mailbox. Your MTA accepts it. As such,  
the sender already knows it is a valid recipient.

I don't follow what information is getting leaked, if a second later a  
success DSN gets sent to the sender. The sender already knows it's a valid  
mailbox, by the virtue of the fact that the mail was accepted.

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Sun, 26 Apr 2020 17:53:36 -0400

> they believe they have to in order to comply with the specification.

The other big problem is that even if we chunk out an RFC that clarifies
that they *can* pick-and-choose which DSN events to react to on a case by
case basis, it's still going to take a decade before people actually do something
about it.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Apr 2020 17:59:18 -0400

On Sunday, April 26, 2020 5:53:36 PM EDT Valdis Klētnieks wrote:
> case basis, it's still going to take a decade before people actually do
> something about it.

I think that's backwards.  People already have done something about it and do 
pick and choose.  The question is if and how we should align standards to that 
reality.

We could pick the not unusual for the IETF path of defining a third path which 
makes everyone wrong (the new reply code suggestion comes to mind), but I 
think that for this topic if we are going to make a change, it should be to 
align standards to reality rather than attempt the reverse.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2020 18:22:36 -0400

>mailbox, by the virtue of the fact that the mail was accepted.

Not necessarily.  It might be forwarded, it might bounce later.

We can bikeshed forever about whether you send a success DSN if it's
delivered to a spam folder.

R's,
John

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 26 Apr 2020 19:56:13 -0400

> Not necessarily.  It might be forwarded, it might bounce later.

It's already known that if you are going to forward your mailbox, you want  
to get your bounces go somewhere else. The bouncing on forwarded mail are  
mostly useless to the original sender. The original sender can't do anything  
about them.

In this situation I would considering forwarding to be a secondary act that  
has no bearing on the original mail. The message was delivered to the  
recipient. The fact that it was forwarded by the recipient's mailbox is a  
out of scope for DSNs.

> delivered to a spam folder.

If it's succesfully delivered to a spam folder, that seems like a smashing  
success to me.

But that's not important. I thought there were some security implications to  
successful DSNs, that I didn't know about; but looks like that's not the  
case; all are things that have been known for decades…

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Sun, 26 Apr 2020 21:04:20 -0400

> pick and choose.  The question is if and how we should align standards to that

I was unclear.. I meant specifically the "We turned it off because we thought that's
what we had to do to comply" crowd.   Once it gets in config files, it's there *forever*.

(Not SMTP, but demonstrating the problem - I had an IP address for an AIX
workstation on my desk that was running a stratum-2 NTP server. That IP address
was removed from the clocks.txt file in late 1998, and went permanently offline
in June 1999 when we moved from "workstations on desks doing servers" to proper
rack-mounted boxes with all the bells and whistles.

In July 2018, a test over 6 hours found 501 machines that *still* thought that IP
address was a good place to send NTP requests...   Gaak.)

---

From: Laura Atkins <[email-masked]>
Date: Mon, 27 Apr 2020 09:23:02 +0100

> On 27 Apr 2020, at 00:56, Sam Varshavchik <[email-masked]> wrote:
> 
> John Levine writes:
>> 
> It's already known that if you are going to forward your mailbox, you want to get your bounces go somewhere else. The bouncing on forwarded mail are mostly useless to the original sender. The original sender can't do anything about them.
> 
> In this situation I would considering forwarding to be a secondary act that has no bearing on the original mail. The message was delivered to the recipient. The fact that it was forwarded by the recipient's mailbox is a out of scope for DSNs.

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. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: Sam Varshavchik <[email-masked]>
Date: Mon, 27 Apr 2020 18:08:48 -0400

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.

---

From: "John Levine" <[email-masked]>
Date: 28 Apr 2020 03:12:40 -0000

In article <[email-masked]>,
Sam Varshavchik  <[email-masked]> wrote:
>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.

---

From: Sam Varshavchik <[email-masked]>
Date: Tue, 28 Apr 2020 08:19:09 -0400

> and then the forward fails.  Either send a DSN or drop it on the floor

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.

---

From: "John Levine" <[email-masked]>
Date: 28 Apr 2020 18:13:57 -0400

>address to <>, or to some other address where you want the bounces to go.

Huh?  If I send a DSN it includes the original delivery address but it
doesn't have to include the forwarded-to address.

R's,
John

---

From: Sam Varshavchik <[email-masked]>
Date: Tue, 28 Apr 2020 18:50:45 -0400

> doesn't have to include the forwarded-to address.

I'm talking about the forwarding system. Whatever's forwarding the message,  
it can easily reset the return address to <>, or to some bit bucket.

>From that point on, any DSN can be sent normally. It won't go anywhere, and  
the sender will never see it.

For all practical matters, the forwarding system is the end recipient, and  
would report any success DSN. Hooray, your message was received by  
[email-masked].

The fact that it gets forwarded to [email-masked] by my  
forwarding script (it's not, this is just as an example) is something that  
you have any knowledge of. The return address on the forwarded message is  
not [email-masked] any more, it's [email-masked]. Or maybe it's  
even <>. You have no knowledge of that, either. Since I received the mail,  
and I decided to forward it, I can change the return address. There is no  
law that says that I must keep it the same.

Either way, since I set up the forwarding: if it breaks and I lose my mail,  
I only have myself to blame and noone else. Noone else is responsible for my  
forwarded mail other than myself.

But, as far as you're concerned, you sent mail to [email-masked] with  
NOTIFY=SUCCESS, and you got a DSN stating that fact. That's all you know.  
Did I get it at this address, or the other one? You'll never know.

---

From: Ned Freed <[email-masked]>
Date: Tue, 28 Apr 2020 16:36:25 -0700 (PDT)

> > doesn't have to include the forwarded-to address.

That depends on the type of forwwarding. Forwarding that doesn't change
envelope return address is reflected in the change of the final recipient
address only; the DSN request semantics generally do not change.

> it can easily reset the return address to <>, or to some bit bucket.

Yes, and if this happens as far as the DSN status of the message is 
concerned you have essentially delivered one message and things are
now proceeding with a new one.

All of this is covered in detail in RFC 3461 section 5.2.7. The terminology
may be a bit archaic but the required semantics are pretty clear.

				Ned