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

From: Jeremy Harris <[email-masked]>
Date: Wed, 1 Jan 2020 12:20:07 +0000

On 27/12/2019 00:29, Keith Moore wrote:
> (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.)

Both Exim and Postfix can be configured to support client certificates.

According to
http://www.securityspace.com/s_survey/data/man.201912/mxsurvey.html
that covers 90% of identifiable public-facing MX systems.
-- 
Cheers,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 1 Jan 2020 12:55:09 -0500

>recommendation worth considering.)

Several, as noted, and there are some old patches for qmail to do it, too.

But once again, this is submission, not SMTP.  A client certificate is
a plausible way for a submission client to authenticate itself to the
submission server.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Jan 2020 12:58:36 -0500

On 1/1/20 12:55 PM, John Levine wrote:

> In article<[email-masked]>  you write:

Agreed that client certs can be useful for mail submission 
authentication.   But I was wondering about the feasibility of migrating 
to use of client certificates for relay to mail exchangers, i.e. across 
administrative mail domain boundaries.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 1 Jan 2020 13:06:20 -0500

> On Jan 1, 2020, at 12:55 PM, John Levine <[email-masked]> wrote:
> 

Well, I think what Keith was hinting at is that in some idealized Internet
we don't have, "real" SMTP clients could be authenticated via client certs,
making it harder for botnets (on machines that lack such certs) to be seen
as real SMTP clients.

Of course the bad guys can register a new domain for $5/year, get a Let's
Encrypt cert, and have the botnet use that domain and cert for a few hours,
and then register another domain...   So I don't see how client certs would
in fact keep abuse at bay.

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Jan 2020 13:27:39 -0500

> making it harder for botnets (on machines that lack such certs) to be seen
Yes, that was what I was wondering.
> in fact keep abuse at bay.

FWIW, Let's Encrypt doesn't currently issue client certificates.

And since this would be entirely new practice, it would at least be 
possible to require Organization Validation or Extended Validation 
certificates as a condition of accepting mail, or more likely, as a 
condition of not pessimizing mail... and/or set up email-specific CAs 
for the purpose of authenticating SMTP clients.

I don't claim that it's simple to make this work - the devil is, as 
always, in the details.   I don't think there is a magic bullet.   But I 
do see client cert authentication of SMTP-over-TLS as another potential 
tool in the toolbox.

Keith

---

From: "John Levine" <[email-masked]>
Date: 1 Jan 2020 13:34:27 -0500

>administrative mail domain boundaries.

I don't see what problem it would solve.

The only path authentication that MTAs do now is SPF, which most
people agree is pretty lousy, and in the other direction IP based
DNSBLs.

Most certs are signed by Let's Encrypt, who promise little more than
that the entity presenting the cert is the same one that presented the
signing request.  That doesn't impress me as any better than using an
IP address.

Whitelisting mail by source on the assumption that you can identify
sources that send good mail is a Well Known Bad Idea.  Any source big
enough to be worth whitelisting is big enough to have accounts that
get compromised and users infected by malware, so legit mail sources
all send some spam, too.

Apropos whitelisting, I can tell you long tedious stories about all
the people who insisted that Spamhaus needed to publish a whitelist.
When we did, we found that nobody who qualified cared if they were
whitelisted, and nobody who wanted to be listed met the criteria.

R's,
John

---

From: Richard Clayton <[email-masked]>
Date: Wed, 1 Jan 2020 18:40:10 +0000

In message <[email-masked]>,
Keith Moore <[email-masked]> writes

>condition of not pessimizing mail... 

We cannot prescribe whether a receiver is going to accept email, you can
merely state what the correct protocol is for the transfer and for
efficient signalling of accept/reject decisions.

>and/or set up email-specific CAs 

No-one in the world of large scale transfer thought that server certs
from existing CAs (or DANE and its reliance on DNSSEC) were going to
work reliably at scale ... so the bulk handlers of email went for (and
have deployed) MTA-STS (RFC8461) instead.

I doubt that the views of the practicality of using client certs would
be all that different.

Note that the driver for MTA-STS was nothing to do with preventing abuse
in the sense its used in this thread so far (the bad guys are far better
at adopting new standards, configuring correctly etc than the good guys
are) ... but to address the threat of events such as BGP hijacks causing
mail flows to go to the wrong place... or middleboxes removing
encryption from connections

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: "John Levine" <[email-masked]>
Date: 1 Jan 2020 13:42:02 -0500

>for the purpose of authenticating SMTP clients.

It's still a WKBI.  Whitelisting by source doesn't work at scale, and
for source scoring, I don't see any reason that a cert would tell you
anything more useful than an IP and a host name.  It's not like we have
any trouble now telling when mail is coming from Google or Yahoo or
the university down the road.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 1 Jan 2020 14:01:33 -0500

> On Jan 1, 2020, at 1:27 PM, Keith Moore <[email-masked]> wrote:
> 

Actually, it does, for example:

        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
        Validity
            Not Before: Oct 24 07:01:29 2019 GMT
            Not After : Jan 22 07:01:29 2020 GMT
        Subject: CN = box.ezemailserver.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:  
                    [...]
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication

The EKU lists both TLS server and TLS client roles.

> And since this would be entirely new practice, it would at least be possible to require Organization Validation or Extended Validation certificates as a condition of accepting mail, or more likely, as a condition of not pessimizing mail... and/or set up email-specific CAs for the purpose of authenticating SMTP clients.

That's a non-starter.  I am not going to pay for EV certs (a dead-end idea
that failed and is going away).  There's no scalable mechanism for a third
party to whitelist the good guys.  The only thing that can work is for ISPs
to list CIDR blocks that are authorised SMTP relays.

A decade and a half ago, there was:

   https://www.ietf.org/archive/id/draft-crocker-csv-csa-00.txt

   [ which would IMHO need to be simplified, probably too much baggage in an
     effort to reconcile CSV vs. CSA, ... ]

that I was sure stood a much better chance of addressing spam from botnets and
the like than SPF, Sender-ID, DKIM, ... which only touch on the much narrower
issue of "From" forgery in phishing. [ And don't really solve that either, since
naïve users still fall for phishing email that doesn't bother to forge the message
origin. ] But for various reasons addressing "phishing" got more attention.

Client certs from a CA cannot address botnet spam, but explicit records in DNS
from a domain that stands behind the client's role as an outbound MTA can help,
modulo the same $5/domain that means that makes disposable domains attractive
to the spammer.  Which means we'd need technology to blacklist the rogue domains
very quickly (before the spammer earns $5 in revenue by abusing it).

> I don't claim that it's simple to make this work - the devil is, as always, in
> the details.   I don't think there is a magic bullet.   But I do see client cert
> authentication of SMTP-over-TLS as another potential tool in the toolbox.

I think they could be useful forensically, and even potentially to show a user
that email arrived along an expected "trusted path", but not for screening out
unauthorised senders.  That is sadly not possible.

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Wed, 1 Jan 2020 14:18:17 -0500

> The EKU lists both TLS server and TLS client roles.

Interesting.   I misread the text on their web site.   Thanks for 
pointing that out.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Wed, 1 Jan 2020 12:43:11 -0800

> have deployed) MTA-STS (RFC8461) instead.

This reminds me of a basic suggestion in trying to deal with interesting 
problems...

For every proposal here, I strongly suggest that it begin with a 
functional description that is entirely non-technical.  No acronyms and 
no protocols.

Just say:

    1.  What functional/semantic goal is being sought

    2.  What problems there are with not having that goal met

    3.  What current mechanisms, which might serve to meet the goal,
        don't.

    4.  How adopters will be motivated

After getting agreement on these 4 point, it will be reasonable to 
consider specific mechanisms for achieving the goals.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Jan 2020 09:56:42 -0500

On 1/1/2020 1:40 PM, Richard Clayton wrote:

> efficient signaling of accept/reject decisions.

+1.

We am supportive of focusing on SMTP compliancy fine tuning. The 
administrative local policy stuff, while all good to know, good for an 
Informational Status doc, but not a BCP, nor for RFC5321bis PS work, 
it would be never ending with extremely rough positions.  If some 
local sites decide to reject IP-literals based on decision that 
contains bias so be it, they will deal with the false positives, but 
it is not SMTP.

We should double down on HELO/EHLO IP-literal correct syntax and 
definition.

However, I might be supportive of a relaxation of the field definition 
so that EHLO only basically functions as a server/client capabilities 
negotiation.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Jan 2020 10:20:45 -0500

> contains bias so be it, they will deal with the false positives, but

arggh! I am ....

-- 
HLS

---

From: Keith Moore <[email-masked]>
Date: Thu, 2 Jan 2020 12:14:13 -0500

On 1/2/20 9:56 AM, Hector Santos wrote:

> If some local sites decide to reject IP-literals based on decision 
> that contains bias so be it, they will deal with the false positives, 
> but it is not SMTP.

I agree that it doesn't belong in the SMTP spec.  But the cumulative 
effect of receiving sites' ad hoc and ill-informed filtering policies is 
to degrade the utility of Internet email for everyone.    It's not only 
a problem for the sites that set the policies.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jan 2020 13:17:12 -0500

--On Thursday, 02 January, 2020 12:14 -0500 Keith Moore
<[email-masked]> wrote:

>> If some local sites decide to reject IP-literals based on
>> decision  that contains bias so be it, they will deal with
>> the false positives,  but it is not SMTP.

> I agree that it doesn't belong in the SMTP spec.  But the
> cumulative effect of receiving sites' ad hoc and ill-informed
> filtering policies is to degrade the utility of Internet email
> for everyone.    It's not only a problem for the sites that
> set the policies.

With regard to this and many other issues [1], I think there is
a higher-level answer if we know that "many" sites are doing
something other than what the spec recommends.  Whether we
change the spec to follow their practices or retain and clarify
the recommendation, it seems to me that we are going to need
text, somewhere, that explains our decisions, why we are giving
whatever advice we are providing, and why people should follow
that advice.  That text, which probably belongs in a separate
document from RFC531bis, may actually be more important than
whatever we put in 5321bis. Absent our providing a persuasive
explanation of why people should, or should not, do something,
experience, both on the anti-spam side and based on continuing
references to 2821, suggests that sites will do whatever they
(locally) think best and that some of those decisions will be
ill-informed.

The same principle applies, IMO, to suggestions that we pull
material out of 5321 that is considered obsolete, irrelevant, or
not belonging there. Some of the arguments about what should be
included ultimately date from the 1980s and involve questions of
whether the envelope-message body (with headers) separation
arrived at then was correct, whether we should have placed more
reliance on message processing rather than transport processing
or vice versa, and so on.  That even includes such questions as
whether RFC 974 was the right solution to that problem and
remains the right solution in a world in which the DNS is being
optimized for other things and we have strongly discouraged open
relays (something else 5321 says little or nothing about) and
whether, when we introduced EHLO, we should also have introduced
a three-layer envelope [2] and whether we should do that now via
a new but strongly-recommended extension.

In any event, I believe the discussion we need now is how we get
to a WG and how to sort out the details of Barry's suggested
approach for moving forward.  As just one example, as I read his
suggestion, I don't think it allows making major scope changes
in 5321bis, especially because, because of the way it is
constructed, different parts of that document are sufficiently
intertwined that simply adding or removing a substantive
sections or two may lead to inconsistencies that would require
very careful examination and revisions to sort out [3] [4].

back to lurking.
    john

[1] As I mentioned earlier in another context, I don't have time
to follow all of this traffic and my motivation goes down as it
becomes more repetitive.   I'm unlikely to try to make that time
before there is a WG and a consensus-determining mechanism
rather than people just stating their positions with great
passion and conviction.

[2] Somewhat like the X.400 P1/P2/P3 distinction but not
necessarily using that model.  I note that many of the rough
edges associated with the relationship between trace information
from xx21 and the header specifications of xx22 and many of the
issues with signatures over message headers would be at least
considerably simplified by pushing that type of information into
an intermediate layer or structure.

[3] The unresolved question of whether acceptance of IP address
literals is encouraged or mandated by 5321 because references
are not exact and apparently-different things are said in
different places is probably a good example of a situation we
don't want to accidentally make worse.

[4] Of course, 2821 and hence 5321 are paste-together jobs
rather than a complete rewrite and integration job because, at
the time the effort that produced 2821 was underway, we (for
some value of "we"( made an explicit decision that, given the
complexities and available energy and expertise, we'd be
unlikely to be able to take the other approach without
introducing errors that would talk a long time to find and sort
out.   Unless there is evidence that there is more energy now,
it is probably still the right decision.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Jan 2020 10:23:51 -0800

On 1/2/2020 10:17 AM, John C Klensin wrote:
> That even includes such questions as

Where is there indication that this mechanism has been having 
operational problems?

Where is the discussion of an alternative?

Failing to obtain some history covering both of these questions, 
pursuing this topic doesn't seem likely to be productive, though it 
could be wonderfully expensive in time and frustration.

> a new but strongly-recommended extension.

Where is the indication that the existing model is behaving inadequately?

Where is the discussion of a 3-layer model and its efficacy.

Failing to obtain...

d/

---

From: Keith Moore <[email-masked]>
Date: Thu, 2 Jan 2020 14:20:46 -0500

> (locally) think best and that some of those decisions will be

Agree with this, and (as I just wrote in a separate message) I think 
policy recommendations need to be in a separate document from syntax anyway.

For me the test of whether something belongs in the revised SMTP 
specification is: do implementors of SMTP protocol engines need to know 
about it?   That's entirely a question of protocol rather than policy.   
So for instance, does the revised SMTP specification need to specify 
HELO?   I would argue yes, because there are probably still SMTP servers 
out there not supporting EHLO.   But the protocol specification could 
also say something like "clients MUST try EHLO before falling back to 
RSET then HELO if necessary".   That's still a matter of protocol 
because it affects the client's state machine.

But does the revised SMTP specification need to specify VRFY and EXPN?   
Here I would probably argue no, except perhaps to point out that certain 
commands defined in previous specifications cannot be reused, because 
there's already a well-defined error code for command not implemented 
and it's not necessary or helpful for a client to use those when sending 
mail.   A modern SMTP implementation doesn't need to handle those cases 
specially.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Jan 2020 11:27:45 -0800

On 1/2/2020 10:17 AM, John C Klensin wrote:
>    Whether we
> whatever we put in 5321bis. 

If it turns out to be more important than the actual protocol spec, 
we've got bigger problems.

But explanatory text certainly can be helpful.  Here is is worth 
distinguishing text that explains utility of what is specified -- and 
one of the benefits of the IETF style of specification, as opposed to 
that of many other standards organization, is that such text can be 
inline with the spec -- versus discussion of group decision-making that 
produced the spec.

While production of this latter type of history review can be 
interesting, I'm not aware of that being a regular -- or even 
established? -- practice in the IETF.

I don't recall specific examples, but believe it has been done, though 
not very often.  Perhaps you can cite some examples?

> Absent our providing a persuasive

Such explanation has pretty much never altered independent 
decision-making in the adoption or rejection of Internet mail practices. 
  Perhaps you have counter-examples?

> or vice versa, and so on.  

The topic of the envelope received significant discussion during the 
development of RFC 5598:

> 4.1.  Message Data
> 
>    The purpose of the Message Handling System (MHS) is to exchange an
>    IMF message object among participants [RFC5322].  All of its
>    underlying mechanisms serve to deliver that message from its Author
>    to its Recipients.  A message can be explicitly labeled as to its
>    nature [RFC3458].
> 
>    A message comprises a transit-handling envelope and the message
>    content.  The envelope contains information used by the MHS.  The
>    content is divided into a structured header and the body.  The header
>    comprises transit-handling trace information and structured fields
>    that are part of the Author's message content.  The body can be
>    unstructured lines of text or a tree of multimedia subordinate
>    objects, called "body-parts" or, popularly, "attachments".
>    [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

and

> 4.1.1.  Envelope
> 
>    Internet Mail has a fragmented framework for transit-related handling
>    information.  Information that is used directly by the MHS is called
>    the "envelope".  It directs handling activities by the transfer
>    service and is carried in transfer-service commands.  That is, the
>    envelope exists in the transfer protocol SMTP [RFC5321].
> 
>    Trace information, such as RFC5322.Received, is recorded in the
>    message header and is not subsequently altered [RFC5322].

If there has been discussion that deviates from this and/or calls for 
modifications to this, please cite it.

> a new but strongly-recommended extension.

Again, please document indications of current community concern of these 
issues.

> approach for moving forward.

Whereas I think there's been some significant attempt to do just that.

>  As just one example, as I read his

Ahh.  I think there's been some very useful discussion about work to be 
done, but apparently you think that Barry's suggestions somehow 
constrain what constructive discussions we are permitted to have?  So, 
ummm, his suggestions were really a mandate?

> an intermediate layer or structure.

Whereas I think that any issues with disparities, ambiguities, etc. 
between RFC *21 and RFC *22 involves the occurrence of redundant text 
rather than thoughtful incorporation by citation from one to the other.

d/

---

From: Keith Moore <[email-masked]>
Date: Thu, 2 Jan 2020 14:28:11 -0500

> could be wonderfully expensive in time and frustration.

Some of us remember these things and the references are potentially 
useful to those who do.    Are we constrained to only talk about what 
we're sure everyone already knows?   I certainly don't want us to have 
to revisit the entire history of email in this discussion (and to have 
to repeat that discussion every few years), but I assume that people 
seriously involved in email are motivated to do that anyway.   So I 
don't think it's wrong to refer to history, and I think that sometimes 
it provides valuable context.

I doubt that much, if any, historical discussion should be in the 
5321bis spec(s).   If someone really feels motivated there could be an 
informational document but I wouldn't want it to be a work item for a WG.

Keith

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Jan 2020 16:49:04 -0500

--On Thursday, 02 January, 2020 14:28 -0500 Keith Moore
<[email-masked]> wrote:

>> Failing to obtain some history covering both of these
>> questions,  pursuing this topic doesn't seem likely to be
>> productive, though it  could be wonderfully expensive in time
>> and frustration.
> 
> Some of us remember these things and the references are
> potentially useful to those who do.    Are we constrained
> to only talk about what we're sure everyone already knows?  
> I certainly don't want us to have to revisit the entire
> history of email in this discussion (and to have to repeat
> that discussion every few years), but I assume that people
> seriously involved in email are motivated to do that
> anyway.   So I don't think it's wrong to refer to history,
> and I think that sometimes it provides valuable context.
> 
> I doubt that much, if any, historical discussion should be in
> the 5321bis spec(s).   If someone really feels motivated
> there could be an informational document but I wouldn't want
> it to be a work item for a WG.

Keith (and, to some extent, Dave),

I'm not suggesting a historical description.  I am suggesting a
rationale for any changes we make, one that is persuasive enough
to overcome the natural resistance to making changes for anyone
(and, where relevant, their management) who thinks they have a
system that is working well for them.  Otherwise, while a few
clarifications (including tracking the errata and issues at a
level similar to most of them) may still be in order, it is not
clear to me a major revision of 5321 is likely to be a good use
of time.

As to whether the IETF usually or normally or even sometimes
does an authoritative rationale document like I'm suggesting,
two examples may help.  Many of the "discussion" materials in
RFC 1122 and 1123 do precisely what I'm suggesting -- explain
why a particular recommendation or requirement is being made in
the hope that people will pay attention rather than expecting
them to do something different (and "different" is important)
just because the IETF said so.  And, of course, when IPv6 was
adopted, the reasons for the decision, as well as the alternate
proposals, were published.  Only in part because I don't think
it would take much hair-splitting to argue that one or both
examples don't apply, consider how many application-level
protocols we have that are as old as SMTP and whose basic
assumptions or coverage are still being actively reviewed and
revised.  Telnet is older, but not as heavily used today as it
was 20 or 30 years ago, the basic model has not changed in a
very long time, and the most recent standards-track extension I
can find is the data encryption stuff from 2000.   FTP is also
older, but, the additional of the HOST command in 2014 (for
which I've seen little evidence of wide adoption but may not
have been looking in the right places) notwithstanding, no
changes to the basic model since RFC 959 (and, if we were to
start counting from there, it postdates SMTP).

At least IMO and although I can name exceptions, the IETF has
almost always done better (in terms of quality and wide
adoption) with new protocols, especially ones that fill a
vacuum, than with revisions to long-established ones.  Maybe
that is how it should be but, if we are going to make revisions
to widely-deployed protocols, especially revisions that imply
that people should (or MUST) do things differently, I think
doing something differently than what it is perceived we have
"always" done may be entirely appropriate lest people look at
our work and paraphrase the comment about doing things the same
way multiple times that is attributed to Einstein.

Finally,

>...
> The established terms are actually rather precise and refer to
the 
> networking abstraction, not an implementation.

Good luck trying to get everyone to use these or any other
terms, in exactly the way you want them to use them, on any
particular occasion.

As far as I can tell, people use words imprecisely, and to mean
slightly different things in different contexts, because it's so
often useful or necessary for them to do so.  There's nothing
new or odd about this.

If we are going to treat RFC 5598 and/or the discussions that
led up to it as final and normative, or even "as established
terms" and therefore align 5321bis (or any subsequent document)
with what it says (or appears to say), then let's do what my
reading of RFC 2026 requires, which is to put 5321bis aside for
a while and issue a 5598bis as a PS or BCP that makes clear
which sections or terminology of 5321 it is updating or
replacing, then come back to 5321bis.  I think a better
strategy, and more consistent with IETF practices in which no
document is so much the last work on a subject as to make it
never subject to future debate or revision, to treat 5588 as
useful guidance as we undertake 5321bis but with the
understanding that the terminology and models of 5321, 5598, or
even something else may ultimately prevail.  With that approach,
if the answer is not the terminology and model of 5321, then
5321bis should also update whatever is relevant to [re-]achieve
consistency, but that should be no big deal.   YMMD, of course.

best,
   john

---

From: Keith Moore <[email-masked]>
Date: Thu, 2 Jan 2020 16:58:41 -0500

On 1/2/20 4:49 PM, John C Klensin wrote:

> led up to it as final and normative

For multiple reasons, I recommend that we NOT do that.   It might make 
sense to consider it as a starting point for language used in 5321bis, 
and perhaps, to revise 5598 in light of the 5321bis discussions, 
probably after the bits are dry for 5321bis.

But no matter what 5598 or any successor document says, people are going 
to continue to use e.g. "MTA" in several of slightly varying ways, 
depending on context.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Thu, 2 Jan 2020 15:55:47 -0800

> (and, where relevant, their management) who thinks they have a

The change will have taken place in the past.

Talking about the reasons that changes /were/ made is by definition 
talking about history.  That the reasons might be more or less 
compelling doesn't change the fact that the perspective is historical.

In contrast, taking the new document only on its terms  -- that is, not 
in terms of its predecessor -- and talking only about why the current 
details are wonderful is not historical.  But that's not the perspective 
you suggested, which is why I drew the distinction between inline versus 
historical.  (Having historical discussion in a spec is mostly 
distracting, especially for someone seeking to implement a current spec, 
without concern for the history.  Such as 10 or 20 years after the spec 
is published.)

> clear to me a major revision of 5321 is likely to be a good use

There seems to be some confusion about the difference between changing 
the protocol versus changing (or removing) portions of text.

For the portions I've suggested removing, the text is, at best, obsolete 
and at worst plain wrong.

And while you offer the generic concern for unintended consequences, 
that won't have substance until it gets applied to specifics.

> them to do something different (and "different" is important)

To keep things simple:  OK.  Two docs. One data point. 30 years ago. And 
for a very, very broad range of issues, rather than a bis specification.

>  And, of course, when IPv6 was

Just looked for the RFC that gave the reasons, but couldn't find it. 
Please cite.

As for publishing alternate proposals doesn't seem relevant to the 
current point.  But that was 25 years ago and not for an incremental bis 
specification.

> examples don't apply,

indeed.

> consider how many application-level

Sorry, but I don't understand what point you intend to be making with 
this paragraph.

821 and 822 have gone through multiple significant changes since they 
were first published.  So it isn't as if making some changes to them has 
never been done before.

> vacuum, than with revisions to long-established ones.  Maybe

Filling a vacuum is always easier and generally safer than displacing 
something.  Installed base being messy, and all that.

But, umm... So you think revision of TCP's re transmission mechanism, 
after 10 years of operation, didn't go well?  Or that adding options to 
SMTP didn't go well?  Or fixing the security mechanism for SNMP didn't 
go well?  Or that pressing to require SMTP to run over TLS hasn't gone 
well?  Or...

> way multiple times that is attributed to Einstein.

Don't bis or ter documents pretty much always include parts that 
/change/ rather than just add?

More generally, I'm not understanding the point of that paragraph.

> terms, in exactly the way you want them to use them, on any

Forgive me.  I thought this was a technical forum and that as 
technicians we tend to value reliability and precision in terminology.

The view you espouse does make things easier, though.  For one thing, it 
means that specifications can skip the part where they define terms, 
since apparently no one will use them as defined.

> led up to it as final and normative,

You mean treat it as if it were the IETF-approved consensus document it 
actually is?  Seems risky.

>            or even "as established

Interesting.  What's easy to miss is that the parts of RFC 5321 that RFC 
5598 "updates" are parts of RFC 5321 that are larger architectural 
issues that are outside the basics of the transfer of mail between MTAs 
and received more recent, detailed, and community-vetted discussion in 
RFC 5598.

That is, by removing these extra parts of the SMTP document, we get a 
much more focused document AND it doesn't collide with RFC 5598, and can 
call on RFC 5598 for context.

There's a common challenge in the reference and incorporation 
relationship among document collections.  Simplistically put:  which way 
do the arrows point?

If this is not answered carefully, the result is that readers bounce 
back and forth and maybe get confused, but also the result is a 
maintenance nightmare.

Consider:

1) Point down
                       +---> Specific 1
       Architecture  --|
                       +---> Specific 2
                       |
                       +---> ...

2) Point up
                       +---  Specific 1
       Architecture <--|
                       +---  Specific 2
                       |
                       +---  ...

3) Point Everywhere

                       +---> Specific 1
       Architecture <--|
                       +---> Specific 2
                       |
                       +---> ...

Now change the document Specific 2 and think about what needs to be 
updated for each model.

Then to make it more interesting, consider what happens if 1 or 3 
applies to a collection of different documents referencing each other in 
the set.

That is, clean, downward-pointing references tend to produce simpler use 
and simpler maintenance.

> useful guidance as we undertake 5321bis but with the

Most IETF documents are little more than useful guidance, including the 
ones labeled standards track.

So if things have changed since RFC 5598 obtained approval and there are 
changes to the document that you deem necessary, what are they?

> even something else may ultimately prevail.

Yes indeed.  Always appealing to re-litigate, especially without any 
apparent and substantial basis.

d/