Subject: Re: [ietf-smtp] Email standard revision, was address maximum length

From: Dave Crocker <[email-masked]>
Date: Mon, 2 Dec 2019 10:55:47 -0800

On 11/30/2019 11:07 AM, John C Klensin wrote:
> While, as you know, I've never been a huge fan of parts of 5598,

I have personal disagreements with parts of it, too. So what?  It 
represents community consensus, not personal opinion.

So how is a personal attitude relevant to the role of a consensus 
document, especially one that had extensive community review and input 
over an extended time and gets cited a fair amount?(*)

> no I don't think moving it to historic would be helpful.  I do
> think that things have gotten more complicated (or at least
> different) in the decade since it was published.   

The statistics of some practices have changed.  The architecture hasn't.

To the extent that you feel otherwise, please document specifics.

> I also note
> that it, particularly its Section 5.3, appears to say that
> 
> * all mailing list redistribution activity occurs at MUA level
> (that is inconsistent with 5321, which came earlier and which
> 5598 does not claim to update or otherwise supercede)

The 'came earlier' perspective is fascinating.  It opens an exciting 
door for dismissing all sorts of later work in the IETF, including work 
that explicitly and obviously is meant to provide improvements on that 
earlier work.

As for the lack of a claim to update, sure, let's focus on process 
rather than substance.

But to that end, an errata entry has been submitted:

    https://www.rfc-editor.org/errata/eid5925

> * RFC5322.From: should remain as set by the original author
> (inconsistent with current practice on many lists and part of
> where this thread started)

The words 'should' and 'may' do not appear in RFC 5598.  As I recall, 
that was intentional.  The use of should here is significantly off the 
mark, not as editorial nit-picking but as misplaced interpretation.

The document sought to describe existing practice.  I assume your 
reference to the document's stance on RFC5322.From is based on:

      "Names and email addresses for the original Author of the
          message content are retained."

which describes common behavior, not required behavior. But yes, an 
adjustment in that language to acknowledge other behaviors would be helpful.

(fwiw, to be  bit formally picky, note that even with rewriting of that 
field, most systems do 'retain' the original information; they simply 
add more.)

Also note that the document's Section 2.14, Mediator says:

    "A Mediator attempts to preserve the original Author's information in
    the message it reformulates but is permitted to make meaningful
    changes to the message content or envelope."

This underscores that the altered statistics on mailing list treatment 
of the rfc5322.From field does /not/ represent a change in architecture.

> IMO, the inconsistencies between the first bullet and 5321 and
> between the second and tampering with "From:" to work around the
> difficulties between DMARC and mailing lists are evidence of
> precisely what I described as a gray area. 

The deeper issue is that SMTP is rife with layer violations and that 
this has never been fixed. The biggest error Postel and I made with the 
original documents was not making layer issues clearer and not enforcing 
a rule that a normative technical detail is specified in exactly one 
document.

To be fair, though, even the basics of UA/MTA distinction were extremely 
new at the time and discussions in terms of layering were not yet common 
in the community.  (That's not a defense, merely an observation.)

  I don't have an
> opinion at the moment as to whether 5598 should be revised (or,
> in principle, retired) as part of whatever the ADs think should
> be addressed in a 2019/2020 email review and update. 

This appears to espouse the view that major technical work is chosen by 
ADs, rather than the community.  Historically, a top-down model for 
formulating work in the IETF -- in the absence of extensive community 
activity and support -- has a remarkably poor outcome.

d/

(*) https://www.arkko.com/tools/allstats/citations-rfc5598.html

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Mon, 2 Dec 2019 11:01:54 -0800

On 12/2/2019 10:55 AM, Dave Crocker wrote:
> The deeper issue is that SMTP is rife with layer violations

drat. not worded carefully enough.  sorry.

I meant:

      The deeper issue is that RFC 821 was rife with layer violations 
and that this has never been fixed.

d/