Subject: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP

From: John C Klensin <[email-masked]>
Date: Thu, 26 Dec 2019 14:09:01 -0500

Hi.

My impression is that discussions are now either going around in
circles or have deteriorated into a couple of people repeating
themselves in attempts to convince, or at least explain to,
others.  I wouldn't presume to try to stop those discussions,
but want to see if we can move forward.

That impression may be wholly incorrect but I think it is, or
should be, clear to everyone that we've significantly departed
from the fairly narrow questions of whether it is appropriate
for IETF servers to reject any mail session opening attempt that
uses an IP address literal in the EHLO command and what 5421
actually says (and was intended to say) about acceptance or
rejection of address literals.

In the hope that it will help us make progress, at least toward
getting some focus on getting a WG put together and/or clarity
from the ADs about how (or if) they would like to move forward,
I've worked up a new draft of rfc5321bis that adds a appendix
(G) about outstanding issues identified in the last several
weeks to the appendix about issue identified in errata (H.1 in
the -02 version, formerly G.1 in the -01 one).  It does _not_
propose solutions, only identifies topics that need discussion
about whether or not we should deal with them and, if so, where.
I will probably post that version tomorrow or over the weekend.
If anyone has more or less broad issues that should be
identified in that section that have not come up either in
errata or recent discussions, mentioning them RSN so I can add
them to the list would be helpful.  The list so far is:

   Appendix G.  Other Outstanding Issues
     G.1.  IP address literals
     G.2.  Meaning of "MTA" and Related Terminology
     G.3.  Originator, or Originating System, Authentication

thanks,
   john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 26 Dec 2019 11:16:49 -0800

>       G.3.  Originator, or Originating System, Authentication

So, the goal is to have multiple places that provide text for these, to 
increase ambiguity and confusion?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Dec 2019 14:23:39 -0500

John,

Just to clarify my point-of-view, I don't see the recent spam 
discussions as resulting in significant new text in RFC5231bis. What I 
imagine for RFC5321bis is at most some very slight tweaking of the 
wording.    As far as I can tell it was just a coincidence that the 
issue with the IETF MTA cropped up at about the same time you started to 
ask about 5321bis.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 Dec 2019 16:25:01 -0500

--On Thursday, December 26, 2019 11:16 -0800 Dave Crocker
<[email-masked]> wrote:

> So, the goal is to have multiple places that provide text for
> these, to increase ambiguity and confusion?

No, Dave.  It is to discuss whether the terminology and
definitions of 5321bis are in harmony with your Informational
document and with contemporary practice, and, if not, to make a
decision as to whether one or the other is worth fixing.

  john

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 Dec 2019 16:30:25 -0500

--On Thursday, December 26, 2019 14:23 -0500 Keith Moore
<[email-masked]> wrote:

> discussions as resulting in significant new text in
> RFC5231bis. What I imagine for RFC5321bis is at most some very
> slight tweaking of the wording.    As far as I can tell it
> was just a coincidence that the issue with the IETF MTA
> cropped up at about the same time you started to ask about
> 5321bis.

Keith,

I don't either.  But I don't see it as useful to revise 5321
without some consensus, however rough, about whether or not
something should be said about those issues.  I note in that
regard that there are advantages and uses for originator
authentication that have little or nothing to do with anti-spam
activities.   I also interpret some recent work and statements
within the IETF as leading toward prohibiting email that is not
encrypted hop-by-hop on the grounds of privacy protection not
anti-spam efforts.  If a WG comes together and treats those
issues as out of scope, it would be fine with me.  I just don't
think we should either be ignoring the issue or assuming that
everyone agrees with those who have spoken up most loudly in
recent weeks.

   john

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Dec 2019 17:03:34 -0500

On 12/26/19 4:30 PM, John C Klensin wrote:

> I also interpret some recent work and statements
> anti-spam efforts.

As sympathetic as I am to the privacy issue, I'd have a difficult time 
supporting a general requirement to encrypt all mail relaying because of 
backward compatibility issues with hosts that don't have TLS support yet 
(including IIoT-related concerns).

I also think that any SMTP upgrade will quite naturally have a long 
tail, so imposing any global requirement (even if it earned broad 
support) without breaking mail that people need to continue to have 
delivered, would be quite a technical challenge.

To me it seems that all of this should be out-of-scope for 5321bis, or 
that the only mention of this in 5321bis should be to declare such 
things out-of-scope.   Requiring hop-by-hop encryption would be the most 
disruptive change in the history of SMTP, I think, far more so than EHLO.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Dec 2019 17:37:24 -0500

> On Dec 26, 2019, at 5:03 PM, Keith Moore <[email-masked]> wrote:
> 
> To me it seems that all of this should be out-of-scope for 5321bis, or that the only mention of this in 5321bis should be to declare such things out-of-scope.   Requiring hop-by-hop encryption would be the most disruptive change in the history of SMTP, I think, far more so than EHLO.

It may well be too soon to *mandate* TLS, but we could perhaps MUST a
RECOMMENDED or a SHOULD for inter-domain relay of email.

Also SUBMIT on 587 is widely encrypted, and, for exampl, last 6 months of
Gmail's stats show north of 90% use of TLS, with a slightly more support
for TLS from client to server (inbound to Gmail) than at the server
(outbound from Gmail):

  https://transparencyreport.google.com/safer-email/overview?encrypt_out=start:1560988800000;end:1577318400000;series:outbound&lu=encrypt_out&encrypt_in=start:1560988800000;end:1577318400000;series:inbound

What's sometimes left unencrypted is:

  1. Submission and relay on "internal" networks, and

  2. A diminishing, but not yet negligible fraction of
     inter-domain relay traffic.

I don't think it would be unreasonable at this point to consider
at least "RECOMMENDED", and perhaps a "SHOULD" for use of STARTTLS
for case "2".

We could perhaps even "RECOMMEND" DANE and/or MTA-STS, but adoption
is much thinner for both[1].

-- 
-- 
	Viktor.
[1]

I see 1.73 million DANE domains, and O(500) domains with MTA-STS DNS records.

DANE presently covers 2-3 orders of magnitude more domains, while MTA-STS
likely covers 1-2 orders of magnitude more users, given the user count of
Gmail vs. comcast.net, web.de, gmx.de, ...).

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Dec 2019 17:59:04 -0500

> On Dec 26, 2019, at 5:37 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

I botched that sentence, the "MUST" was not supposed to be there.

	... we could perhaps agree on ...

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Dec 2019 19:29:53 -0500

On 12/26/19 5:37 PM, Viktor Dukhovni wrote:

> It may well be too soon to*mandate*  TLS, but we could perhaps MUST a RECOMMENDED or a SHOULD for inter-domain relay of email.

I'd support a carefully-worded recommendation to use TLS when relaying, 
as long as it didn't (yet) recommend blocking mail based on absence of 
TLS and (probably) cautioned against doing so outside of some narrow 
corner cases.

I suspect that there are a lot of devices out there sending cleartext 
mail, that probably can't be upgraded for the useful lifetime of the 
device.  And using TLS to send mail from a device, actually makes the 
device more fragile because it implies a need to upgrade the CAs that 
the device trusts.

(I do also wonder how many existing SMTP servers can handle TLS with 
client certificates, because that seems like that would also be a 
recommendation worth considering.)

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 26 Dec 2019 20:00:06 -0500

--On Thursday, December 26, 2019 17:59 -0500 Viktor Dukhovni
<[email-masked]> wrote:

>> It may well be too soon to *mandate* TLS, but we could
>> perhaps MUST a RECOMMENDED or a SHOULD for inter-domain relay
>> of email.
> 

Since I've recently been chewed out again for writing long
messages, if there is an attempt to form a WG, argue that this
should be in scope.  And, if a WG is created with it in scope,
propose text and see where it leads.

   john

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 26 Dec 2019 20:17:55 -0500

> On Dec 26, 2019, at 7:29 PM, Keith Moore <[email-masked]> wrote:
> 
> I'd support a carefully-worded recommendation to use TLS when relaying, as long as it didn't (yet) recommend blocking mail based on absence of TLS and (probably) cautioned against doing so outside of some narrow corner cases.

+1.  As much as spend cycles promoting appropriate use of TLS, I also
caution against overzealous enforcement.  For example, RFC7435.

> I suspect that there are a lot of devices out there sending cleartext mail, that probably can't be upgraded for the useful lifetime of the device.  And using TLS to send mail from a device, actually makes the device more fragile because it implies a need to upgrade the CAs that the device trusts.

For SMTP relay that's less of an issue, because unlike SUBMIT and IMAP,
SMTP (relay) STARTTLS is by default unauthenticated.

For authentication of inter-domain relay, we have DANE and MTA-STS, which
enable authentication opportunistically, when advertised by the peer.

DANE provides always on downgrade resistance, while MTA-STS is not downgrade
resistant on first contact (or when cached policies expire due to sufficiently
infrequent traffic).

> (I do also wonder how many existing SMTP servers can handle TLS with client
> certificates, because that seems like that would also be a recommendation
> worth considering.)

Most don't request client certs, and the client can't unilaterally include
these in the TLS handshake when not requested by the server.  Even when the
server does request client certs, it is presently not a good idea to send
client certs to strangers, because failure to validate these may cause
connection abort in some stacks.

Therefore, for now client certs should be enabled only for use with peers
that are known to need them (typically to authenticate outbound relaying),
and not otherwise.

Before we could encourage use of client-certs in inter-domain relaying, we'd
need to first encourage asking for them, while treating failure to validate
them as equivalent to absence of certificates, rather than reason to abort
the TLS handshake.

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 27 Dec 2019 09:47:01 +0000

On 27/12/2019 00:29, Keith Moore wrote:
[ the IOT-sourced mail case ]
> device.

Another case:  LKML sends in-clear.  I'd ague that this is reasonable
since a) the information is supposed to be public anyway, plus
b) the sending system is handling a high load, and adding that for
encryption will significantly increase costs.
The argument in favour of encryption here would be: anything that
can be done to make the spooks lives harder in doing pervasive
data-gathering will dissuade that policy.
-- 
Cheers,
  Jeremy

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 27 Dec 2019 13:34:47 +0100

>      G.3.  Originator, or Originating System, Authentication

I have a couple of topics that I think it's worth discussing:

    G.4.  Reshape Section 3.9 so that ancillary specs can define:
          G.4.1 Mailing lists, including newsletters, and,
          G.4.2 Email address portability, by forwarding.

    G.5.  Clarify where the protocol stands with respect to
          * submission on port 587
          * submission on port 465
          * TLS relay on a port different from 25 (whenever)

I take the occasion to recall that I have copied some annotations from YAM to:
https://hyp.is/QQqD1iW3Eeq0pQfOL0z_1Q/tools.ietf.org/html/draft-klensin-rfc5321bis-00
(See https://web.hypothes.is/start/)

Further annotating rfc5321bis-00 can help staying focused, IMHO.

Best
Ale
--

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Dec 2019 12:07:07 -0500

Ok, I have revised the working draft to include additional
issues suggested by on and off-list notes.  Several of those
identified issues already called out in -02 either by the errata
or by the inline CREF notes.   As a result of the latter, I'd
added an additional subsection to the new appendix that is
essentially an index to the inline CREF notes that I consider
substantive (it doesn't list all of them and YMMD about what is
or is not substantive).   While I hope it will be useful, it
turned out to be a lot of work, leading to:

_Grumpy editor's note_  
	(those who find it amusing can parse that either way -
	the ambiguity is intentional)

As most of you have probably deduced by now, I'm very busy and
have little time for IETF work.  I'm willing to do this editing
job because I think it is important and overdue, but it isn't
going to happen unless it is a group effort.  This means that,
while I'm willing to add items to a list of topics to be
discussed, nothing that I believe has any substantive impact is
going into the body text of the document unless there is either
consensus that is rather clear to me (and I never count silence
as support for a position) or some WG Chair or AD tells me that
they see consensus and I should make the change.  That, in turn,
implies that I'm going to get increasingly impatient with
suggestions for additions or changes the document has already
listed or covered, strongly implying that those making those
suggestions have not read the draft (or at least the current
version).  My expectation is that people will actually read
before commenting.  I also expect that, if I prepare a message
explaining changes that people will read that.  For those people
who don't like my long messages, I'm happy to have a volunteer
to prepare a summary short enough to avoid TL;DR comments, but
that still won't save people reading the drafts themselves.  I
promise in return that I won't make non-trivial changes without
documenting them so that a diff from a prior, carefully-read,
version plus my notes should be sufficient to keep track of what
is happening without reading all 100+ pages every time.

Another warning about my likely reactions both personally and as
editor.   It is generally believed that a small number of
providers (certainly under a dozen) are carrying or handling a
very large fraction of Internet mail traffic as measured by
either message count or total byte count.  I have no reason to
doubt that belief although, especially given all of the
spam-originating systems and bots and the mail service providers
in places like China and India who rarely show up on those lists
but carry a lot of traffic, I'm occasionally suspicious about
the numbers quoted.  However, there are also many thousands of
systems out there that are able to act as SMTP senders and/or
receivers, even after excluding spam generators and academic and
enterprise servers that have been outsourced to those big
providers.  When one adds in IoT and IIoT systems that generate
or process email, that is probably tens or hundreds of systems,
at least before we start quibbling about what is an SMTP system
and what is a Submission one.  When someone says "NN% of mail
does X or uses Y", with NN large, we should pay attention to
that but it should not be sufficient for making changes in what
the standard requires.  It might, instead, be a good reason to
better explain why the standard says what it does even if those
providers choose to not conform.  And whether that explanation
should make it into 5321bis or some supplemental A/S or BCP is
another, separate, question. If, instead, we conclude that
whatever that handful (or two) of providers do is really the
standard, then there is little point in revising 5321 and,
perhaps instead, we should take the IETF out of the business of
specifying some or all email standards and encourage those
providers to form a consortium to publish a specification of
what they are doing so that everyone else can get in line.

Grump!
   john

In addition, I hope everyone is aware that experience predicts
that every topic-level issue that is added to the "perhaps
should be covered in 5321bis" list lowers the odds that we will
actually converge before enough people run out of energy to have
the remainder represent additional consensus.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Dec 2019 13:13:04 -0500

> On Dec 27, 2019, at 12:07 PM, John C Klensin <[email-masked]> wrote:
> 
> or by the inline CREF notes.

It seems that the -02 has not yet been uploaded, did you mean for it
to be already available?

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Dec 2019 13:42:33 -0500

--On Friday, December 27, 2019 13:13 -0500 Viktor Dukhovni
<[email-masked]> wrote:

>> identified issues already called out in -02 either by the
>> errata or by the inline CREF notes.
> 
> It seems that the -02 has not yet been uploaded, did you mean
> for it to be already available?

Sorry... meant -01.  Been thinking about and working on -02 too
much.   It should be up in the next couple of hours.

  john

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Dec 2019 16:08:29 -0500

> On Dec 27, 2019, at 1:42 PM, John C Klensin <[email-masked]> wrote:
> 

Thanks, I see it now.  Thanks for including the "552 -> 442" issue,
much appreciated.

I'd also like to see a similar placeholder for clarifying the semantics
of a "554" greeting.  Is the client expected to immediately bounce the
message, or look for a better MX host?  The spec is not clear and
implementations vary.

Past behaviour by some MTAs (returning a 554 banner under load) made
the second choice more appropriate, but I've not seen recent reports
of whether that's ongoing.

More recently some users are running into policy-based 554 greeting
rejects, and don't want to keep retrying message that will be
consistently rejected.

I'd like to know which is the expected client behaviour, and which
is a work-around for particular unexpected circumstances a client
may encounter.

-- 
	Viktor.

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Dec 2019 18:25:50 -0500

--On Friday, December 27, 2019 16:08 -0500 Viktor Dukhovni
<[email-masked]> wrote:

>> Sorry... meant -01.  Been thinking about and working on -02
>> too much.   It should be up in the next couple of hours.
> 
> Thanks, I see it now.  Thanks for including the "552 -> 442"
> issue, much appreciated.
> 
> I'd also like to see a similar placeholder for clarifying the
> semantics of a "554" greeting.  Is the client expected to
> immediately bounce the message, or look for a better MX host?
> The spec is not clear and implementations vary.

The text says (Section 4.2.4.2) 

	"... including 554 and the temporary 450, are used for
	more transient situations and situations in which an
	SMTP server cannot or will not deliver to (or accept
	mail for) a particular system or mailbox for policy
	reasons rather than ones directly related to SMTP
	processing."

I'd construe "more transient situations" especially if the code
is used instead of 220 when the client attempts to open a
connection, as implying that working down the MX chain is
entirely appropriate.  But YMMD here.  A different statement of
the problem is that better statements needed about when a server
should reply to a connection opening attempt with a 521 code and
when it should use 554 (or 556).   Section 4.2.4.2 is probably
where that should go, but my notes indicate it is new to 5321bis
and was introduced after discussions associated with RFC 7504.
So it should be considered a preliminary proposal, open for
suggestions about rewriting or there modifications once we
actually start working on the document (as distinct from getting
a foundation and issues list in place for doing that).

> Past behaviour by some MTAs (returning a 554 banner under
> load) made the second choice more appropriate, but I've not
> seen recent reports of whether that's ongoing.

Probably worth reviewing RFC 1846 to see what it says about
these issues.  I have not done that yet and it isn't at the top
of my queue.

> More recently some users are running into policy-based 554
> greeting rejects, and don't want to keep retrying message that
> will be consistently rejected.

Well, if the policy is that the server isn't accepting mail from
anyone, ever, as a matter of policy, then it probably ought to
be returning a 521 in response to the connection attempt and be
done with it.  If the policy reason is "we like some would-be
senders but not you and you should either go to hell or find
some out-of-band way to appeal our decision", then maybe neither
code is right and we should be thinking about a new code.  

As has been pointed out about some other issues, anything we
change (or even clarify) here is going to have a long
implementation tail, so clients had best be prepared to use the
"first digit" rule and/or to aggressively apply the robustness
principle.

> I'd like to know which is the expected client behaviour, and
> which is a work-around for particular unexpected circumstances
> a client may encounter.

See above, with the understanding that is not intended to be an
answer but the beginning of a discussion when we are ready to
have such discussions.  I've provided additional text in what
will become rfc5321bis-03, but don't hold your breath waiting
for it to appear: unless important new issues turn up or I get
instructions to the contrary from the ADs, -03 is likely to be
delayed until after we have a WG charter in place or at least
under active consideration.

best,
   john

---

From: S Moonesamy <[email-masked]>
Date: Sat, 28 Dec 2019 11:03:56 -0800

Hi John,
>these issues.  I have not done that yet and it isn't at the top

RFC 1846 sets a requirement with two possible paths:

   1. Retry another (MX) host.

   2. Give up and return a NDR.

Was there some past discussion to use 421 for (1) instead of a 521?

RFC 1846 proposed a minimal smtp server.  The minimal implementation 
defined in RFC 5321 would not be compliant [1] with RFC 1846 and RFC 
7504 if that implementation does not support the postmaster address.

Regards,
S. Moonesamy

1. Section 4.5.1 of RFC 5321 states that the postmaster address is 
strictly not necessary if the server always returns a 554.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 29 Dec 2019 17:08:50 -0500

As I'm nominally on vacation for this past and the upcoming week
(where "vacation" is a relative term), I'm not keeping up with this
discussion as I might have done.

But I'd like to throw in my opinion about how we should handle the
IP-literals question:

I'd like to see us keep to a plan of folding in errata, doing some
sensible reorganization, otherwise minimizing changes, and
republishing 5321 with a target of "Internet Standard", which it
clearly is.

I'd like to see us then address some of these other issues in a
separate document, which can go out as BCP or Proposed Standard
(applicability statement) -- and there are other options as well --
that would aim to give normative advice about these sorts of things
but that is not part of the Internet-Standard level spec at this
point.

Is there substantial objection to taking that approach?

Barry, doing AD-like things...

---

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Dec 2019 14:29:29 -0800

> Is there substantial objection to taking that approach?

It's difficult to assess the utility of some other document without 
having a clear idea of what it would be expected to cover and how it 
would be expected to get used.  (It also has never been clear to me how 
useful IETF applicability statements are; my general impression is: not 
very.)

That is, there seems to be an effort to do point-based work here without 
attending to any larger integrated system/architecture level issues.

If there were an urgent need for that point work, this might make sense 
but I haven't noticed that case being made.

d/

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2019 17:30:46 -0500

>Is there substantial objection to taking that approach?

Sounds good to me, keeping in mind that the putative goal of a
standard is to tell people how to interoperate with everyone else.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Dec 2019 18:57:25 -0500

> but that is not part of the Internet-Standard level spec at this

I find myself wanting something fairly similar to that.   Whether the 
difference is significant I can't quite tell.

IMO 5321bis should be viewed as the long-term stable document, and as 
such should refrain from making recommendations about how to deal with 
short-term, local, or ephemeral considerations.   It should define the 
SMTP protocol and clean up any remaining ambiguities in that protocol.  
To the extent that 5321bis can be simplified while still fulfilling the 
task of accurately documenting the SMTP protocol, that might be a Good 
Thing.  It should be mostly about protocol, with policy considerations 
kept to a minimum.

IMO most of the spam-filtering criteria I've seen are countermeasures 
for short-term, local, and/or ephemeral conditions.   Either the 
filtering is just exploiting some coincidence that can be expected to 
change over time, or the countermeasure is something that spammers will 
discover and be able to work around.   I could make a case for spam 
filtering being entirely out-of-scope for 5321bis, except perhaps for 
some slight tweaks for about servers being able to impose their own 
policies for rejecting messages, and some recommendations for whether 
and how to report failed delivery due to spam filtering.

IMO to the extent that there's spam filtering advice that's broadly 
applicable across all sites,  that advice still doesn't have the 
maturity of 5321[bis] and its predecessors, and should not go in an 
Internet Standard document.

IMO there's lots of valuable work that could be done to improve 
reliability of Internet mail in the face of spam and spam filtering, but 
none of that work should creep into 5321[bis] or pace it.

Keith

---

From: "John Levine" <[email-masked]>
Date: 29 Dec 2019 20:30:33 -0500

In article <[email-masked]> you write:
>for short-term, local, and/or ephemeral conditions. ...

I'm guessing that the spam filtering criteria you're describing bear
little resemblance to the stuff we talk about at places like M3AAWG
with people who run systems that filter billions messages a day every
day.  One of the reasons we can talk about them at M3AAWG is of course
that the discussions there are not public.

I do agree that we should leave out advice on spam filtering other
than perhaps the obvious observation that without some kind of
filtering, recipient mailboxes are too full of spam to be usable.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Dec 2019 21:25:53 -0500

> that the discussions there are not public.

So they're not subject to outside scrutiny.  No wonder email delivery is 
so unreliable.

Keith

---

From: "John R Levine" <[email-masked]>
Date: 29 Dec 2019 21:31:01 -0500

> So they're not subject to outside scrutiny.  No wonder email delivery is so 
> unreliable.

Aw, come on.  They have a billion users who vote with their feet if 
they're unhappy.

Nothing personal but I cannot imagine why someone running a large mail 
system would care what you or I thought of their filtering scheme.  They 
have way more data than we will ever have.

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

---

From: Keith Moore <[email-masked]>
Date: Sun, 29 Dec 2019 21:44:15 -0500

On 12/29/19 9:31 PM, John R Levine wrote:

>> So they're not subject to outside scrutiny.  No wonder email delivery 
>> is so unreliable.
>

Sure, because changing email addresses (or services, for those who have 
their own domain names) is easy for everyone.

But yes, my response was a bit flippant. I do acknowledge that there's a 
kind of expertise that people who deal with large volumes of traffic on 
a daily basis, have, that others generally do not have.

> system would care what you or I thought of their filtering scheme.  
> They have way more data than we will ever have.

I'd be curious as to their measurement methods, but I suppose those are 
also kept secret.

Keith

---

From: Laura Atkins <[email-masked]>
Date: Mon, 30 Dec 2019 13:31:30 +0000

> On 30 Dec 2019, at 02:44, Keith Moore <[email-masked]> wrote:
> 
>>> So they're not subject to outside scrutiny.  No wonder email delivery is so unreliable.
>> 
>> Aw, come on.  They have a billion users who vote with their feet if they're unhappy.
> 
> Sure, because changing email addresses (or services, for those who have their own domain names) is easy for everyone.

30% of email addresses on a marketing list go bad every year. It doesn’t seem that changing email addresses is that problematic. 

> But yes, my response was a bit flippant. I do acknowledge that there's a kind of expertise that people who deal with large volumes of traffic on a daily basis, have, that others generally do not have.

>> Nothing personal but I cannot imagine why someone running a large mail system would care what you or I thought of their filtering scheme.  They have way more data than we will ever have.
> 
> I'd be curious as to their measurement methods, but I suppose those are also kept secret.

There is an entire sub-section of computer science publications (many of them peer reviewed documents, others whitepapers, still others theory document) that address these issues. Perhaps a few hours with google or at your local library will give you some insight into the research being done and published. 

Both Google and Microsoft also publish information about what they’ve learned about filtering and how they address issues. A recent google post: https://cloud.google.com/blog/products/g-suite/ridding-gmail-of-100-million-more-spam-messages-with-tensorflow <https://cloud.google.com/blog/products/g-suite/ridding-gmail-of-100-million-more-spam-messages-with-tensorflow> 

And an older post, but one that I think addresses a lot of the issues addressed here: https://elie.net/blog/security/in-depth-analysis-of-the-lessons-we-learned-while-protecting-gmail-users/ <https://elie.net/blog/security/in-depth-analysis-of-the-lessons-we-learned-while-protecting-gmail-users/>

Happy researching. 
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: Keith Moore <[email-masked]>
Date: Mon, 30 Dec 2019 10:24:15 -0500

On 12/30/19 8:31 AM, Laura Atkins wrote:

> 30% of email addresses on a marketing list go bad every year. It 
> doesn’t seem that changing email addresses is that problematic.

Of course it is problematic, because any email address that is changed 
for that reason cannot be used as stable contact info for use between 
friends and colleagues.    And this degrades the utility of email.

Of those 30%, I wonder how many of those addresses were addresses that 
people intended to use as stable addresses in the first place.   I 
wonder how many people obtain "throwaway" addresses specifically for the 
purpose of disclosing in contexts where they seem likely to be exploited 
by marketers, while reserving other addresses for use for mail that they 
want to get.

I also wonder how many people routinely get a "throwaway" email address 
on any rare occasion that they need to correspond with anyone over 
email, with the expectation that such correspondence will inherently be 
short term, because many people seem to treat email as a communications 
medium of last resort.

So I wouldn't assume that those 30% were addresses that people wanted to 
keep anyway.

But yes, I'm aware that one of the ways that people deal with spam is by 
changing email addresses.     If spam as experienced by ordinary people 
were not so bad, causing them to change email addresses as a way of 
dealing with it, email would be more useful.

Keith

---

From: Laura Atkins <[email-masked]>
Date: Mon, 30 Dec 2019 15:58:12 +0000

> On 30 Dec 2019, at 15:24, Keith Moore <[email-masked]> wrote:
> 
> Of course it is problematic, because any email address that is changed for that reason cannot be used as stable contact info for use between friends and colleagues.    And this degrades the utility of email.

This has been the case since 1999. 

> Of those 30%, I wonder how many of those addresses were addresses that people intended to use as stable addresses in the first place.   I wonder how many people obtain "throwaway" addresses specifically for the purpose of disclosing in contexts where they seem likely to be exploited by marketers, while reserving other addresses for use for mail that they want to get.

There has been published research on this. Which goes back to what Dave was saying - you really need to understand what has been done before you start proposing solutions. I have a copy of the .pdf, but you can search google to find it, too. The title is  "ISPs and Spam: The Impact of Spam on Customer Retention and Acquisition," Gartner Inc., Stamford, Conn. June 14, 1999. 

> I also wonder how many people routinely get a "throwaway" email address on any rare occasion that they need to correspond with anyone over email, with the expectation that such correspondence will inherently be short term, because many people seem to treat email as a communications medium of last resort.
> 
> So I wouldn't assume that those 30% were addresses that people wanted to keep anyway.

The initial research was done on behalf of ISPs, not senders. 

> But yes, I'm aware that one of the ways that people deal with spam is by changing email addresses.     If spam as experienced by ordinary people were not so bad, causing them to change email addresses as a way of dealing with it, email would be more useful.

In 1999, the volume of spam was a tiny fraction of what it is today. And, yet, it was bad enough to cause 30% of people to abandon their email addresses. 

laura 

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Dec 2019 11:06:26 -0500

On 12/30/19 10:58 AM, Laura Atkins wrote:

>
>> On 30 Dec 2019, at 15:24, Keith Moore <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Of course it is problematic, because any email address that is 
>> changed for that reason cannot be used as stable contact info for use 
>> between friends and colleagues. And this degrades the utility of email.
>
So addressing the issue is clearly long overdue.

>> Of those 30%, I wonder how many of those addresses were addresses 
>> that people intended to use as stable addresses in the first place.   
>> I wonder how many people obtain "throwaway" addresses specifically 
>> for the purpose of disclosing in contexts where they seem likely to 
>> be exploited by marketers, while reserving other addresses for use 
>> for mail that they want to get.
>
> There has been published research on this. Which goes back to what 
> Dave was saying - you really need to understand what has been done 
> before you start proposing solutions. I have a copy of the ..pdf, but 
> you can search google to find it, too. The title is  "ISPs and Spam: 
> The Impact of Spam on Customer Retention and Acquisition," 
> Gartner Inc., Stamford, Conn. June 14, 1999.

Thanks for this and other references.   I certainly agree that I need to 
survey the literature.   But it's not necessary to survey the literature 
to understand that spam is a huge problem and that existing solutions 
are inadequate.

(I assume this is your reference for the 30% figure also?)

>> But yes, I'm aware that one of the ways that people deal with spam is 
>> by changing email addresses. If spam as experienced by ordinary 
>> people were not so bad, causing them to change email addresses as a 
>> way of dealing with it, email would be more useful.
>
> In 1999, the volume of spam was a tiny fraction of what it is today. 
> And, yet, it was bad enough to cause 30% of people to abandon their 
> email addresses.

And yet, a lot has changed since 1999, so the conditions that caused 30% 
of the people to abandon email addresses then may not be the same 
conditions that exist now, even if that 30% figure were about the same 
today as then.   (but do we even know that?)

Keith

---

From: Laura Atkins <[email-masked]>
Date: Mon, 30 Dec 2019 16:34:25 +0000

> On 30 Dec 2019, at 16:06, Keith Moore <[email-masked]> wrote:
> 
>>> On 30 Dec 2019, at 15:24, Keith Moore <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

Why are you assuming no one has attempted to address the issue in 20 years?

>> There has been published research on this. Which goes back to what Dave was saying - you really need to understand what           has been done before you start proposing solutions. I have a copy of the ..pdf, but you can search google to find it, too. The title is  "ISPs and Spam: The Impact of Spam on Customer Retention and Acquisition," Gartner Inc., Stamford, Conn. June 14, 1999. 
> Thanks for this and other references.   I certainly agree that I need to survey the literature.   But it's not necessary to survey the literature to understand that spam is a huge problem and that existing solutions are inadequate.
> 
It is necessary to understand why the existing solutions are what they are. You’ve made a host of assumptions that are, quite honestly, disrespectful of the people who’ve been working on this for their entire careers. 
> (I assume this is your reference for the 30% figure also?)
This is, to the best of my research, the original iteration of the 30% figure. There is more recent data as well. 
> And yet, a lot has changed since 1999, so the conditions that caused 30% of the people to abandon email addresses then may not be the same conditions that exist now, even if that 30% figure were about the same today as then.   (but do we even know that?)
> 

This is the type of question you can answer yourself with research. 

laura 

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Dec 2019 14:17:39 -0500

On 12/30/19 11:34 AM, Laura Atkins wrote:

>> On 30 Dec 2019, at 16:06, Keith Moore <[email-masked] 
>>>> changed for that reason cannot be used as stable contact info for 
>>>> use between friends and colleagues.    And this degrades the 
>>>> utility of email.
>>>

I don't assume that at all, and the myriad efforts to address the issue 
are quite evident.  But I also observe that email delivery, as 
experienced by casual email users, is still unreliable - to the point 
that for many people, email is the messaging system of last resort.   
But it's also essential enough to have that system of last resort that 
casual email users have developed lots of ways of attempting to cope 
with the unreliability.

And yet, I still find Internet standard email fundamentally more 
functional than every other messaging system out there.  And I think 
Internet email is fixable, whereas most of the other interpersonal 
messaging systems appear to me to have fundamental and largely 
insurmountable limitations that will likely keep them from ever being as 
functional.

>> But it's not necessary to survey the literature to understand that 
>> spam is a huge problem and that existing solutions are inadequate.
>>
> It is necessary to understand why the existing solutions are what they 
> are. You’ve made a host of assumptions that are, quite honestly, 
> disrespectful of the people who’ve been working on this for their 
> entire careers.

I mean no disrespect, and my very purpose in this conversation is to 
understand the landscape.   But I suspect the political and/or economic 
landscape is more of an impediment to solving the problem than the 
technical challenges are.   And that's why, to me, it makes sense to try 
to understand the political and/or economic landscape before doing a 
technical deep dive on any particular proposal.

I also observe that the landscape is different now than it was in the 
late 1990s and wonder if the changing landscape creates new 
opportunities that did not exist 20 years ago.

Or to explain this a different way - I  have identified roughly a dozen 
significantly different technical approaches that appear to have not 
been tried (at least at scale), because most of them are things that 
would involve changes to the email protocols and/or widespread practice 
- if they had been tried, it would be evident.

I also know better than to float concrete proposals without doing a lot 
of technical research first.   But in my experience the political 
research is even more important.   If a bad idea gets shot down for 
technical reasons, that's overall a good thing even if it meant some 
energy was wasted.    But if a good idea gets shot down for political 
reasons, that's a very bad result, because the good idea can be 
discredited for decades after the political issues have been forgotten.

So before trying to pitch or defend or even develop technical proposals 
in detail, I want to understand which of those proposals might land on 
potentially-fertile ground, and maybe also where the fertile ground is 
if it exists.

Keith

p.s. I also understand that if any new ideas were found to be helpful, 
they would be more likely to be complimentary approaches to what exists, 
than competing ones.

---

From: Hector Santos <[email-masked]>
Date: Tue, 31 Dec 2019 12:33:12 -0500

On 12/29/2019 9:44 PM, Keith Moore wrote:
> Sure, because changing email addresses (or services, for those who
> have their own domain names) is easy for everyone.

+1 and never mind among the "billions" represent a huge chunk of junk, 
expired addresses and sources of spam who put pressure of the rest of 
the community who are the majority of systems.

I don't buy the "BIG GUY" dictates so "shut up" arguments.  They can 
help lead the way, but they also need to also compete cooperatively 
with the rest of the mail community, and foremost, the must not raise 
barriers that forces unnecessary change on others.  Just because they 
may be looking at allowing bias in their big data directed decisions, 
they must be aware that fundamentally, their biased decisions does not 
applies across the board to everyone else.

>> Nothing personal but I cannot imagine why someone running a large
>> mail system would care what you or I thought of their filtering
>> scheme. They have way more data than we will ever have.
>

I don't believe bigger volume sites have anything different than 
anyone else except larger amounts of it.  Dimensional analysis tells 
us we are all the same and at end of the day, SMTP wise, we are all 
expected to work the same at a minimum requirement level. I hope what 
we are trying to here is to fine tune the system with modern 
considerations.

What I have been trying to separate in all these years is to use 
deterministic filtering based on SMTP compliancy, separating it from 
the more administrative, sysop-defined heuristics, subjective, 
nondeterministic filters.

I have two SMTP compliancy-based deterministic filters:

- Machine name ip-literal matching connecting ip because SMTP tells us 
it is defined as the IP address of the connecting client, and

- Dynamic validation of the Reverse Path because SMTP tells us it MUST 
be valid for NDN purposes.

(Technically, I have a 3rd with greylisting which test the "Good 
client" retry expected SMTP behavior.)

I have two POLICY-based deterministic filters:

- SPF
- DKIM Policy (ADSP, DMARC and ATPS)

Everything else I consider as local policy subjective filters.

Thanks

-- 
HLS

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Dec 2019 13:23:30 -0500

> it is defined as the IP address of the connecting client, and

This is something that should be clarified in 5321bis, IMO.   The IP 
address literal is the address as seen by the client, which in an IPv4 
world with increasing numbers of NATs can't be guaranteed to be the 
address as seen by the server.  And as long as people keep using IPv4, 
there will be NATs in the middle of the network.

So if an IP address literal is used in HELO/EHLO, it MUST (or at least 
SHOULD) be the source IP address of the current TCP connection as seen 
by the client.   The HELO/EHLO tag will then get copied to a Received 
header field.   But because of NATs, servers therefore SHOULD NOT (maybe 
MUST NOT) refuse mail based on whether the EHLO/HELO address matches the 
peer address.   (The only case I can think of that makes sense for 
rejecting such mail is if the server somehow has reliable out-of-band 
information that the client is lying about its address.   It's not 
impossible, but it's difficult to imagine how this could happen.)

And while clients SHOULD use a DNS name in HELO/EHLO if they have one, 
not all SMTP clients can be expected to have a DNS name.   So servers 
SHOULD NOT (maybe MUST NOT) reject mail based on the mere presence or 
absence of an IP address literal in HELO/EHLO.   It would be insane for 
a standard to make a recommendation that degrades the reliability of the 
service it provides.

Having said that, if a server operator /reliably/ knows that use of an 
IP address literal in HELO/EHLO is /currently/ a /reliable//indication/ 
of spam, it might make sense to filter based on that use.   The keys are 
in /reliably/ knowing that, knowing that it is a /reliable indication/, 
and knowing that the indication is /currently/ reliable. The operator 
might also have other information of use - such as knowing the community 
of people who can legitimately send mail to the server, and how they 
configure their servers [*].   If an operator knows those things, then 
the rejection is not based on the "mere" presence or absence of an IP 
address literal - it's based on other information also.

But reliably knowing these things requires work and tools, and keeping 
that information current also requires work and tools.   I wonder how 
much spare time operators have to do the necessary work to make sure 
that the indicators are reliable, and I wonder if the tools that they 
need to do this are readily available to them.   I don't know how much 
of this should be in scope for 5321bis - probably none of it - but this 
does seem like part of what's required to improve the reliability of 
email delivery.

Keith

[*] But is using an SMTP forwarder that has a DNS name really part of 
the price of admission to IETF discussions?   And if so, shouldn't that 
be explicit policy rather than just the ad hoc decision of a server 
administrator?

---

From: "John Levine" <[email-masked]>
Date: 31 Dec 2019 13:57:22 -0500

>a standard to make a recommendation that degrades the reliability of the 

I am reasonably sure that if we compare the number of MTAs sending
legit mail with numeric HELO to the number of spambots doing so, mail
reliability would be greatly improved by completely forbidding them.

With respect to all of the low performance IoT devices mailing out
status reports, that's submission, not SMTP.  You point them at a
submission server that knows what network(s) the clients are on,
cleans up the messages, perhaps does some sanity checking so a rogue
lightbulb can't mailbomb people at qq.com, and forwards on the
messages as an MTA.  A Raspberry Pi is overkill for this.

We definitely need to make it clear in 5321bis that submission and
SMTP are different, and devices that can't do everything that a modern
SMTP client needs to do have to use a submission relay.  It's store and
forward.  The mail gets through anyway.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 31 Dec 2019 13:08:46 -0800

> status reports, that's submission, not SMTP.  
...
> SMTP are different

+1

Hence, Item 2 of the items list that I posted.

d/

---

From: Hector Santos <[email-masked]>
Date: Tue, 31 Dec 2019 17:43:45 -0500

> reliability would be greatly improved by completely forbidding them.

This bias will also suggests the premise can be reasonably off as well.

We need to separate the SMTP protocol engine from the administrative 
decisions with has inherent bias it in.  Too much of this has been 
going on for too long with the IETF Mail Cogs that quite frankly has 
been predictably off now compared to current empirical observations.

> SMTP are different.

That is a good point. Unless the user is compromised, authenticated 
input has never been an issue.  The issue is SMTP compliancy as a 
public port service.  SMTP Compliancy should be a primary focus for 
RFC5321bis.  Everyone, enterprise including the "billion users" 
systems to Mom & Pop shop is expected to have a minimum requirement to 
adhere to.

-- 
HLS

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 Dec 2019 18:23:36 -0500

--On Tuesday, 31 December, 2019 13:57 -0500 John Levine
<[email-masked]> wrote:

>...
> I am reasonably sure that if we compare the number of MTAs
> sending legit mail with numeric HELO to the number of spambots
> doing so, mail reliability would be greatly improved by
> completely forbidding them.
>...

I am reasonably sure that if we compare the number of MTAs
sending legit mail with HELO, rather than EHLO, to the number of
spambots doing so, mail reliability would be greatly improved by
completely forbidding them.

Noting that the logic above is the same, anyone want to make a
case that people have had circa 27 years to adapt to EHLO (i.e.,
since RFC 1425 was published), that a number of important and
heavily-used features (such a the 8BITMIME extension) are
dependent on it as are other options that people in many part of
the world consider important (e.g., SMTPUTF8), and it is
therefore time to just deprecate HELO.  

Or course, it one makes the argument that any embedded (IoT
included, but not limited to that) or other non-upgraded client
should be using a submission server with responsibility for
cleaning things up rather than an SMTP client, it further
strengthens that argument.  FWIW, IMO advocating that change
also strengthens the case for making the terminology
change/reversion mentioned in Appendix G.3 of rfc5321bis-02.

Again, not taking a position on any of this, just pointing out
questions that probably need asking, especially if we are going
to start deprecating previously-valid (or, especially,
previously-required) features.

   john

---

From: "John R Levine" <[email-masked]>
Date: 31 Dec 2019 20:28:55 -0500

> therefore time to just deprecate HELO.

With a clearer split between SMTP and submission, that seems sensible. 
Submission can excuse all sorts of antique stuff that SMTP wouldn't.

Regards,

---

From: Keith Moore <[email-masked]>
Date: Tue, 31 Dec 2019 20:37:00 -0500

> reliability would be greatly improved by completely forbidding them.

I am starting to think that it's important to distinguish between

(a) SMTP the protocol, and

(b) The "globally-relevant Internet public email" service (GRIPE?  [*]) 
that exchanges mail between otherwise-uncooperating [**] DNS-named 
domains, routing mail by default using DNS MX, A, and/or AAAA records as 
determined by lookup from the ICANN-specified roots, and exchanging mail 
using SMTP-over-TCP over the public IPv4 or IPv6 Internet.

IMO the two have always been separate, even though the landscape has 
changed over time and continues to change.   And there are many 
private-use networks (which might or might not be using private or local 
address space) which use SMTP to exchange mail not only within 
themselves but also with domains on the GRIPE service, and via the GRIPE 
service to other private-use networks.

I believe the proper scope of 5321bis is the SMTP protocol, or at least, 
that while the protocol and rules for transmission of mail within GRIPES 
both need to be specified, they should be clearly separated.   Offhand, 
I suspect it's better if they're addressed in separate documents, but 
that's just a guess at this point.

I think it makes sense to define rules for GRIPE that do not apply to 
the use of SMTP in general.   For example:

  * all header and envelope addresses MUST be expressed in terms of DNS
    names rather than IP literals;
  * all participating nodes MUST have DNS names, which MUST be used in
    EHLO ;
  * there MUST be PTR records linking clients' IP source addresses to
    the DNS names that they use in EHLO;
  * ESMTP MUST be supported by servers;
  * HELO MUST NOT be used by clients and MAY be rejected by servers;
  * all mail relayed via GRIPES MUST be subjected to certain sanity
    checks and cleanup before such relaying,
  * etc., etc.

I'm not necessarily arguing for any of these rules; I am not sure that I 
agree with all of them.   The point is that if you define a separate 
service, you can make up rules for that service and also give GRIPE 
servers advice about how to deal with mail that doesn't (yet) follow 
those rules, independently of SMTP.   And I think it makes sense to 
raise the bar for GRIPE mail over time, and reduce the amount of 
acceptable variation in email traffic, without having to revisit the 
SMTP protocol specification, and without having to impose general 
requirements on all SMTP servers. [***]

However, there will still be a need for private-use networks to be able 
to relay mail through GRIPE, including to recipients on other 
private-use networks.

> status reports, that's submission, not SMTP.

(It might be better to not speak of these as IoT devices, because IoT 
seems to come with vastly different assumptions for different people.   
But for now...)

To me this is at least a separate question.   I don't think it makes 
sense to insist that IoT devices submit mail directly to a submission 
server that follows the rules for GRIPE, because (for example) the IoT 
device might initially submit mail to a device which is also on an 
isolated network, without DNS access, etc. So it might be that the 
submission server that the IoT device uses, is not capable of meeting 
GRIPE requirements.

It might make more sense to insist that the GRIPE rules apply whenever 
mail is routed to a mail exchanger, i.e. via DNS lookup of the recipient 
address domain.   And a mail exchanger would be free to bounce or 
pessimize mail that doesn't meet the GRIPE service requirements, ideally 
after a predetermined grace period to give everyone time to implement them.

(I have some other questions regarding IoT use of mail submission 
services, e.g. whether RFC8314 is suitable as-is for use on isolated IP 
networks, or whether IoT devices should be required to use port 587 when 
submitting mail so that the servers will know they have to treat such 
traffic differently than message relaying.    So there might need to be 
a separate profile for mail submission on networks that don't have DNS 
or connectivity to the public IP network.)
> You point them at a

Well, maybe not.    Some people see IoT networks as involving millions 
(or even billions) of independent hosts and claim that their networks 
and services are built for that kind of scale.

Happy new year, folks!

Keith

[*] Not a serious proposal for a name; I just wanted a shorthand 
notation for it and that's what I came up with in a couple of minutes.   
Suggestions welcome.

[**] If there's explicit cooperation between two or more mail domains, 
they can make up their own rules for exchanging mail.

[***] Though I should probably point out that spammers will learn to 
conform to GRIPE rules also.   But in the long term I think it makes 
sense for filters to rely more on content, on reliable indications as to 
whether a message was forged, on authenticated sender identity and 
perhaps sender reputation, and absence of protocol violations, than on 
heuristics that don't really relate to any of the above in any strong or 
enduring way.   And GRIPE could also require signing, for instance.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 31 Dec 2019 17:53:55 -0800

> Submission can excuse all sorts of antique stuff that SMTP wouldn't.

Given that there has already been a vigorous effort to demand much more 
stringent (security-related) efforts in the operation of MTAs, it's 
certainly worth considering application of that demand to this revision 
effort.

The question should be what the driving criteria are.  The follow-on 
question will be how to apply them, of course.

Over the last week, I've found myself increasingly thinking that an 
effort to simplify and focus the document, as much as possible, would be 
especially helpful, notably distinguishing more general email 'systems' 
discussion from the specific transfer functionality that is SMTP's domain.

d/