Subject: Re: [Emailcore] EHLO domain validation requirement in RFC 5321

From: "Randall Gellens" <[email-masked]>
Date: Sat, 03 Oct 2020 16:49:40 -0700

On 28 Sep 2020, at 13:48, John Levine wrote:

> In article <[email-masked]> you 
> write:
>> On 28/09/2020 18:56, Alessandro Vesely wrote:
>>> The wording in Section 4.1.4 needs to be changed so as to 
>>> distinguish
>>> submission[*] from server to server relaying.  As for the latter, 
>>> there
>>> seems to be consensus on "SHOULD NOT":
>>
>> Side issue: should the standard point out that a local MTA 
>> transmitting
>> to a "smarthost MTA" counts, at least in some senses, as submission?
>
> Take a look at RFC 6409 which I don't think we're planning to update.
>
> Its section 3 describes the differences between submission and SMTP
> relay. If the client is authenticated somehow (SMTP AUTH or known
> local IP range) that sure sounds like submission to me.
>
> There's also other criteria, submission usually cleans up the message
> and adds missing headers, and allows relay to non-local addresses.

The stuff about cleaning up messages and adding missing headers was 
based on the environment in the late '90s, when email clients tended to 
be awful and sites used sendmail to add or replace Date and other header 
fields.  The earliest impetus for separating submission and relay was to 
stop sendmail "fixing" messages that weren't submission.  Of course, 
once email became popular, authenticating submission and prohibiting 
receipt of non-local messages became crucial.  I don't know that 
cleaning up submitted messages is still done much.

---

From: "John R Levine" <[email-masked]>
Date: 3 Oct 2020 20:59:47 -0400

On Sat, 3 Oct 2020, Randall Gellens wrote:
> fields.  ...
>  I don't know that cleaning up submitted messages is  still done much.

It definitely is.  Look for example at the "cleanup" daemon in Postfix.

You are right that many desktop or phone MUAs do a better job of composing 
mail than they used to, but that just means that the cleanup process 
should leave headers alone if they is already OK.  But there's plenty of 
mail sent by primitive MUAs like my printer when it runs out of paper, 
which needs a lot of cleanup.

There's plenty of cleanup that is overenthusiastic, e.g., Office 365 will 
always put in its own Message-ID on submitted, replacing any that's 
already there which is a pain.

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

---

From: "Randall Gellens" <[email-masked]>
Date: Sat, 03 Oct 2020 20:04:20 -0700

Thanks, I hadn't realized that (my printer just beeps and causes the Mac 
print utility to display up a caution symbol).

--Randall

On 3 Oct 2020, at 17:59, John R Levine wrote:

>> based on the environment in the late '90s, when email clients tended 
>> to be awful and sites used sendmail to add or replace Date and other 
>> header fields.  ...
> You are right that many desktop or phone MUAs do a better job of 
> composing mail than they used to, but that just means that the cleanup 
> process should leave headers alone if they is already OK.  But there's 
> plenty of mail sent by primitive MUAs like my printer when it runs out 
> of paper, which needs a lot of cleanup.
>
> There's plenty of cleanup that is overenthusiastic, e.g., Office 365 
> will always put in its own Message-ID on submitted, replacing any 
> that's already there which is a pain.
>
> Regards,

---

From: John C Klensin <[email-masked]>
Date: Sun, 04 Oct 2020 12:59:00 -0400

--On Saturday, 03 October, 2020 20:59 -0400 John R Levine
<[email-masked]> wrote:

>...
> You are right that many desktop or phone MUAs do a better job
> of composing mail than they used to, but that just means that
> the cleanup process should leave headers alone if they is
> already OK.  But there's plenty of mail sent by primitive MUAs
> like my printer when it runs out of paper, which needs a lot
> of cleanup.

But that is an example of an imbedded application using email as
a notification mechanism.  To the extent to which we really mean
"agent for a human" when we say "MUA", there isn't one in there.
Perhaps we should be talking about "MGA" ("mail gremlin agent").
And, without knowing anything about your printer or its
manufacturer, I'd think the odds of its email interface being
"fixed" any time soon, no matter what the IETF says, are slim to
none.  

Randy may disagree, but this is one of the key reasons why I
thought that strengthening the "Submission server" distinction
was important although, in some ways, it just strengthens the
language of 2821/5321 about what was permitted to escape onto
the public Internet.  And, for that reason, it isn't clear that
this discussion, or at least this part of it, justifies any
change in 5321bis.

> There's plenty of cleanup that is overenthusiastic, e.g.,
> Office 365 will always put in its own Message-ID on submitted,
> replacing any that's already there which is a pain.

And, depending on the role Office 365 is playing when it does
that, it isn't "overenthusiastic".  It is, instead, a flat-out
violation of the standard with nasty interoperability
implications under some circumstances.  Not the only one,
unfortunately.  And, were we to put in any language that
authorized it (not that anyone has suggested doing so), it would
take us a step closer to saying "the real email standards are
whatever the handful of largest mail service providers say they
are, everyone else needs to conform if they want their mail to
reliability reach people, and the IETF should get out of the
business lest our work become an expensive and time-consuming
exercise in futility".

    best,
     john

---

From: "John R Levine" <[email-masked]>
Date: 4 Oct 2020 13:52:43 -0400

I'm not entirely sure what your point is but I don't think we disagree.

Message cleanup on submission remains useful, but once that happens, SMTP 
relay should only add trace headers and otherwise not mess with the 
message.  (Not sure what the formal status of 8/7 MIME downcoding is but 
I doubt it's very common any more other than by accidental inertia.)

I also agree that it would be useful to emphasize that submission is 
different and it's not what this document is about.

The O365 message ID's were replaced during authenticated port 587 
submission so it was annoying but not obviously wrong.  On the other hand, 
the syntax of the Received: headers it adds is totally wrong.

R's,
John

Regards,

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 04 Oct 2020 12:16:11 -0700

I agree with both of you.  I agree that it would be helpful to say very 
clearly that message alteration (aside from Received header fields) is 
for message submission only.

There's an argument to be made for combining the SMTP and Submission 
documents, but I think the cost outweighs the benefit.

--Randall

On 4 Oct 2020, at 10:52, John R Levine wrote:

> Message cleanup on submission remains useful, but once that happens, 
> SMTP relay should only add trace headers and otherwise not mess with 
> the message.  (Not sure what the formal status of 8/7 MIME downcoding 
> is but I doubt it's very common any more other than by accidental 
> inertia.)
>
> submission so it was annoying but not obviously wrong.  On the other 
> hand, the syntax of the Received: headers it adds is totally wrong.
>
> R's,
> John
>
>

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Oct 2020 12:33:56 -0700

On 10/4/2020 12:16 PM, Randall Gellens wrote:
> I agree that it would be helpful to say very clearly that message 
> alteration (aside from Received header fields) is for message submission 
> only.

fwiw...

https://tools.ietf.org/html/rfc5598

> 4.3.1.  Mail Submission Agent (MSA)
> 
>    A Mail Submission Agent (MSA) accepts the message submitted by the
>    aMUA and enforces the policies of the hosting ADMD and the
>    requirements of Internet standards.  An MSA represents an unusual
>    functional dichotomy.  It represents the interests of the Author
>    (aMUA) during message posting, to facilitate posting success; it also
>    represents the interests of the MHS.  In the architecture, these
>    responsibilities are modeled, as shown in Figure 5, by dividing the
>    MSA into two sub-components, aMSA and hMSA, respectively.  Transfer
>    of responsibility for a single message, from an Author's environment
>    to the MHS, is called "posting".  In Figure 5, it is marked as the
>    (S) transition, within the MSA.
> 
>    The hMSA takes transit responsibility for a message that conforms to
>    the relevant Internet standards and to local site policies.  It
>    rejects messages that are not in conformance.  The MSA performs final
>    message preparation for submission and effects the transfer of
>    responsibility to the MHS, via the hMSA.  The amount of preparation
>    depends upon the local implementations.  Examples of aMSA tasks
>    include adding header fields, such as Date: and Message-ID:, and
>    modifying portions of the message from local notations to Internet
>    standards, such as expanding an address to its formal IMF
>    representation.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Sun, 04 Oct 2020 17:48:45 -0400

--On Sunday, 04 October, 2020 12:16 -0700 Randall Gellens
<[email-masked]> wrote:

> I agree with both of you.  I agree that it would be helpful to
> say very clearly that message alteration (aside from Received
> header fields) is for message submission only.

Yes.  And John and I are in agreement about that, whether most
of the rest of my earlier message is relevant or not.  The part
that is, and that I hope all of us are in agreement about, is
that saying much more on this subject is potential material for
the A/S, rather than a 5321bis topic, except as noted below.

> There's an argument to be made for combining the SMTP and
> Submission documents, but I think the cost outweighs the
> benefit.

Well, at this stage in the game, I think even trying would
create more confusion.   What I think would be reasonable to do,
especially since 6409 is at Internet Standard, would be to look
at the text of 5321 that circles around the submission issue and
see if it could be reasonably replaced by a sentence or short
paragraph that explains that those issues are covered in 6409
(and maybe its potential successors).  Someone to do the
research as to what might be removed and suggested text to
replace it would be appreciated.

   john

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Oct 2020 14:54:09 -0700

> documents, but I think the cost outweighs the benefit.

There's a stronger argument against.

Submission and relaying are fundamentally different in role and 
authority.  At a minimum, submissions agents have local authority to 
mess with the message in way that would be entirely inappropriate for a 
relay.

That they share protocol constructs is mostly distracting from the major 
differences in their architectural role.

d/

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 04 Oct 2020 15:04:24 -0700

On 4 Oct 2020, at 14:48, John C Klensin wrote:

> (and maybe its potential successors).

I agree.

> Someone to do the

I'm not in a position to volunteer much time right now (racing to finish 
a large project) but if someone is still needed in a month or so, let me 
know.

--Randall

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 04 Oct 2020 16:53:49 -0700

On 4 Oct 2020, at 14:54, Dave Crocker wrote:

> mess with the message in way that would be entirely inappropriate for 
> a relay.
>
> That they share protocol constructs is mostly distracting from the 
> major differences in their architectural role.

Sure, but our documents tend to be protocol-focused, not 
architecture-focused.  If we were doing email from scratch (ha!), we'd 
probably have one document that describes the basic protocol and the 
roles of submission client, submission server, relay client, and relay 
server.

At any rate, I'm not proposing that we do it, so it's more of a bar chat 
or interminable conference hotel elevator ride at dinnertime debate.

--Randall

---

From: Dave Crocker <[email-masked]>
Date: Sun, 4 Oct 2020 18:39:43 -0700

> roles of submission client, submission server, relay client, and relay 

In fact there are quite a few architecture documents, independent of the 
protocol components.  The order of development varies, of course. 
Obvious example: RFC 5598.

d/

---

From: "Randall Gellens" <[email-masked]>
Date: Sun, 04 Oct 2020 18:48:56 -0700

On 4 Oct 2020, at 18:39, Dave Crocker wrote:

>> architecture-focused.  If we were doing email from scratch (ha!), 
>> we'd probably have one document that describes the basic protocol and 
>> the roles of submission client, submission server, relay client, and 
>> relay server.
>
> In fact there are quite a few architecture documents, independent of 
> the protocol components.  The order of development varies, of course. 

I never doubted the existence of architectural documents.  I'd wager 
that there are far more protocol RFCs than architecture.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 6 Oct 2020 12:08:58 +0100

Hi all,

> mess with the message in way that would be entirely inappropriate for 

I think based on this thread we will leave SMTP Submission and 
rfc5321bis as separate documents.

Best Regards,

Alexey

---

From: Ned Freed <[email-masked]>
Date: Wed, 07 Oct 2020 12:17:21 -0700 (PDT)

> > header fields) is for message submission only.

So adding Authentication-Results: is forbidden? Original recipient information?
Return path?

There are many fields that get added after submission and before final
delivery. And not all of them really qualify as "trace" IMO.

Moreover, making a list of these fields is a hopeless task, since all
it takes is one more document to outdate the list.

I see two possible solutions:

(1) Craft some text saying something like, "Only add fields specified as OK
    to be added in other specifications."

(2) Create a registry.

I kind of like the idea of a registory, but it is a fair bit more work.

> replace it would be appreciated.

Any attempt to incorporate 6409 would almost certainly be met with the
desire for further "clarifications" of that document.

And trying to come up any sort of list of the things submit agents should be
doing or not doing is orders of magnitude more difficult than the relay case,
and goes out of date even faster.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 7 Oct 2020 16:05:49 -0400

On Wed, 7 Oct 2020, Ned Freed wrote:
> I kind of like the idea of a registry, but it is a fair bit more work.

Sounds like a new column or two in the existing Message Headers registry, 
with options like "trace", "add once", and "add multiple".

Regards,

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Oct 2020 18:28:02 -0400

--On Wednesday, October 7, 2020 12:17 -0700 Ned Freed
<[email-masked]> wrote:

>> > I agree with both of you.  I agree that it would be helpful
>> > to say very clearly that message alteration (aside from
>> > Received header fields) is for message submission only.
> 
> So adding Authentication-Results: is forbidden? Original
> recipient information? Return path?

I should have said something closer to "message alteration in
transit other than trace fields" or, to be a little more
precise, "message alteration in transit from the initiating MUA
or, if one is in use, the Submission server (acting as an SMTP
client) or gateway at the boundary of the public Internet to the
delivery MTA or gateway from the public Internet to some other
system".  I'm not certain what "original recipient information
is" but assume it is probably covered by that reformulation.
Return-path is added by the delivery MTA.   And, if something
other than the delivery server adds information about
Authentication-Results, I don't see any reason why that should
not be sufficiently distrusted to be a security problem.

Does that come closer?  Sorry for being sloppy.

> There are many fields that get added after submission and
> before final delivery. And not all of them really qualify as
> "trace" IMO.

At the risk of being a little bit of a purist here, I may have
missed a good example but I haven't seen anything added to the
headers by intermediate relays that seems like a good idea,
things like Authentication-Results notwithstanding.  One could
get around most of the problem by, e.g., introducing ex-X.400
ADMD terminology, trying to insist that anything listed in an MX
record be part of the same ADMD as the delivery server, and then
rewriting the above so that "delivery MTA" reads something like
"same ADMD as the destination system" but I have doubts about
whether we could get that right.

> Moreover, making a list of these fields is a hopeless task,
> since all it takes is one more document to outdate the list.

Yes.

> (1) Craft some text saying something like, "Only add fields
> specified as OK     to be added in other specifications."
> 
> (2) Create a registry.
> 

Noting John Levine's comment (without agreeing or disagreeing),
are you thinking about some sort of FCFS or DE-type registry or
requiring that the IETF do a serious review and grant permission?

>> create more confusion.   What I think would be reasonable to
>> do, especially since 6409 is at Internet Standard, would be
>> to look at the text of 5321 that circles around the
>> submission issue and see if it could be reasonably replaced
>> by a sentence or short paragraph that explains that those
>> issues are covered in 6409 (and maybe its potential
>> successors).  Someone to do the research as to what might be
>> removed and suggested text to replace it would be appreciated.
> 
> Any attempt to incorporate 6409 would almost certainly be met
> with the desire for further "clarifications" of that document.

Agreed.  I was just suggesting a pointer and maybe removing some
text from 5321bis.

> And trying to come up any sort of list of the things submit
> agents should be doing or not doing is orders of magnitude
> more difficult than the relay case, and goes out of date even
> faster.

Indeed.

   john

---

From: "John R Levine" <[email-masked]>
Date: 7 Oct 2020 18:43:20 -0400

On Wed, 7 Oct 2020, John C Klensin wrote:
> things like Authentication-Results notwithstanding.

A-R actually is a trace field, no problem there.

Given that we already have a header registry, it seems that we're a large 
fraction of the way there already.

5322 already describes what trace headers are and which non-trace headers 
can occur more than once. It'd probably be adequate to say not to delete 
any headers without specific permission*, and to observe the limits about 
number of headers with the same name when deciding whether to add a 
non-trace header to a message in transit,

R's,
John

* - there's a special case about deleting multiple authentication-results

---

From: John C Klensin <[email-masked]>
Date: Wed, 07 Oct 2020 19:32:18 -0400

--On Wednesday, October 7, 2020 18:43 -0400 John R Levine
<[email-masked]> wrote:

>...
> 5322 already describes what trace headers are and which
> non-trace headers can occur more than once. It'd probably be
> adequate to say not to delete any headers without specific
> permission*, and to observe the limits about number of headers
> with the same name when deciding whether to add a non-trace
> header to a message in transit,

Be a tad careful here.  Except for gateways, I believe there
still is no actual requirement in 5321 that the message body
(absent extensions, defined as whatever follows DATA up that
CRLF.CRLF) conform to 5322 other than that it not be screwed up
by having Trace Fields inserted.  And, while neither the CREF in
Section 3.9 nor Appendix G.7.5 call it out,  Section 3.9 of 5321
and the current version of 5321bis says

	"...the message header section (RFC 5322 [11]) MUST be
	left unchanged; in particular, the "From" field of the
	header section is unaffected."

which makes some obvious current practice non-conforming.  Do we
change it to a SHOULD and point to the A/S?

    john

---

From: Ned Freed <[email-masked]>
Date: Thu, 08 Oct 2020 03:20:10 -0700 (PDT)

> with options like "trace", "add once", and "add multiple".

That sounds like the right way to handle it, but this is just a registration
organization detail. The hard part is writing the text explinaing the criteria
for giving agents permission to add a field to a message as it transits the
infrastructure.

Of course one way to do it is to say that only trace fields can be added. Which
simplifies the registration issue but puts the onus on the documents under
revision to define what a trace field is.

And this turns out to be harder than I thought, because there's no actual
definition of a trace field in either RFC 5321 or RFC 5322. They simply
list Return-Path: and Received: as the trace fields and stop.

Going back to RFC 822, we have this definition:

     Trace information is used to provide an audit trail of  mes-
     sage  handling.   In  addition,  it indicates a route back to the
     sender of the message.
     
It's a starting point, I guess, but only that.

Now that I've researched this, I think we need to have a better definition of
trace field, irrespective of what we end up with in regards to message
modification.

For one thing, the definition in RFC 822 calls into question the legitimacy of
classifying Authentication-Restuls as a trace field. All of the other fields
I'm aware of that warranr this status are either added at a specified point
during message processing (final delivery)  or contain a timestamp.  A-R pesses
neither property, instead depending on location alone - which doesn't really
fit with the notion of an audit trail, at least not as I understand it.

There's also the issue that neither RFC 8098 nor RFC 3461 say that
Original-Recipient is a trace field, but I guess this can be fixed with
a registration update, once that's possible.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 08 Oct 2020 03:40:15 -0700 (PDT)

> requiring that the IETF do a serious review and grant permission?

Another issue that would have to be addessed, but as I noted in my
previous response, there's the even more fundamental issue of the critieria
for declaring something a trace field.

> Agreed.  I was just suggesting a pointer and maybe removing some

Not sure I'd remove anything, but a pointer would be good.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Oct 2020 09:33:11 -0400

--On Thursday, October 8, 2020 03:40 -0700 Ned Freed
<[email-masked]> wrote:

>> Noting John Levine's comment (without agreeing or
>> disagreeing), are you thinking about some sort of FCFS or
>> DE-type registry or requiring that the IETF do a serious
>> review and grant permission?
> 
> Another issue that would have to be addessed, but as I noted
> in my previous response, there's the even more fundamental
> issue of the critieria for declaring something a trace field.

Yes.  I can't remember whether we deliberately dropped the text
you quoted from 822 or whether it got lost in the "what belongs
in *21 versus *22" discussion/ transition.   The argument (going
forward) for putting it in the former is a view that trace
fields are added in transit or the very beginning of delivery so
we should be defining them for those who put them in.  For the
latter, that some are added earlier or later.  For example, is
"X-Original-MUA-Name" a trace field?  Certainly it is trace
information (and/or free advertising) in the usual sense.  I
suppose we need to have a definition to decide where it belongs
but predict that getting consensus on one won't be easy.

I think some saying about opening cans of worms might be in
order here.

>> >> create more confusion.   What I think would be reasonable
>> >> to do, especially since 6409 is at Internet Standard,
>> >> would be to look at the text of 5321 that circles around
>> >> the submission issue and see if it could be reasonably
>> >> replaced by a sentence or short paragraph that explains
>> >> that those issues are covered in 6409 (and maybe its
>> >> potential successors).  Someone to do the research as to
>> >> what might be removed and suggested text to replace it
>> >> would be appreciated.
>> > 
>> > Any attempt to incorporate 6409 would almost certainly be
>> > met with the desire for further "clarifications" of that
>> > document.
> 
>> Agreed.  I was just suggesting a pointer and maybe removing
>> some text from 5321bis.
> 

Yeah.  I've got a mild desire to try to remove anything from
5321bis that appears elsewhere, especially if it appears in more
details and with better explanation, incorporating it by
reference.  I'm not sure we will find such text about submission
in 5321 and, unless someone else wants to do the research, I'll
probably lose interest.... and I'll probably get over the desire
if the first two or three paragraphs proposed for removal turn
out to be controversial.

     john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Oct 2020 08:18:06 -0700

> for declaring something a trace field.

Does it help to use the word "handling" rather than "trace"

d/

ps. In looking at this thread and considering the kinds of legitimate 
changes being contemplated, I fear that dealing with such issues puts 
the reasonableness of seeking full standard at risk.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Oct 2020 08:20:38 -0700

On 10/8/2020 6:33 AM, John C Klensin wrote:
> reference. 

+10

> I'm not sure we will find such text about submission

IMO 5321biss should specify nothing about submission.  It should be 
/only/ an MTA specification.

d/

---

From: Ned Freed <[email-masked]>
Date: Thu, 08 Oct 2020 09:41:34 -0700 (PDT)

> Does it help to use the word "handling" rather than "trace"

Maybe a little.

The problem is we now have other specifications talking about trace fields.
Dealing with that substantially increases the cost of any wording change.

I don't think the benefits measure up to the costs.

> the reasonableness of seeking full standard at risk.

Part of it boils down to how much do we want to try and put limits on the
things intermediaries can do. If we truly want to do this, then yes, it
does have status implications.

That said, now that the issue of a lack of any real specificity as to what a
trace field is has come up, and we have a history of other specifications
creating them, I really don't think we can avoid defining them. Full standards
aren't supposed to leave this sort of thing unspecified.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 8 Oct 2020 13:25:21 -0400

On Thu, 8 Oct 2020, Ned Freed wrote:

> That sounds like the right way to handle it, but this is just a 
> registration organization detail. The hard part is writing the text 
> explinaing the criteria for giving agents permission to add a field to a 
> message as it transits the infrastructure.

Given that mail systems add headers with wild abandon, it would be nice to 
have some guardrails to point to.  We might have to distinguish between 
headers added in final delivery and those added during relay, since 
there's a lot more of the former but they matter less.

I'm also wondering how much work it's worth to try to catalog existing 
practice.  For example, "Delivered-To" has been a widely used trace header 
at least since qmail came out in 1998, it's used as an example in RFCs 
5293, 7681, and 8904, but it's not in any registry.

Regards,

---

From: Ned Freed <[email-masked]>
Date: Thu, 08 Oct 2020 10:53:21 -0700 (PDT)

> there's a lot more of the former but they matter less.

Agreed. But as previously noted, there may be a process cost. Right now I'm
thinking it's worth it, if only to try and rein in the behavior of spam
filters. Dunno about you, but I think the ones that add many Kbs to messages
are truly out of control.

> 5293, 7681, and 8904, but it's not in any registry.

Seems like a case that needs registration. On the opposite end, clearly trying
to catalog X-<spamfilter>-<foo>-<bar> is a waste of time. Beyond that, there's
room for negotiation.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Oct 2020 12:13:01 -0700

On 10/8/2020 10:25 AM, John R Levine wrote:
> it would be nice to have some guardrails to point to.  We might have to 
> distinguish between headers added in final delivery and those added 
> during relay, since there's a lot more of the former but they matter less.

The wild abandon includes lack of clarity about role.

Having a registry that distinguishes among submission, transfer, and 
delivery roles could helpful. (hope spring eternal, even during the Fall.)

I'd suggest separation of the registry creation effort from the registry 
populating effort, so that the latter is out of the critical path and 
can even be done in increments.

d/

---

From: "John Levine" <[email-masked]>
Date: 8 Oct 2020 18:19:28 -0400

>delivery roles could helpful. (hope spring eternal, even during the Fall.)

Good points.

>can even be done in increments.

We already have a header registry, shared among mail, usenet news and
http. I hope we don't invent another one.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Thu, 8 Oct 2020 15:31:19 -0700

> http. I hope we don't invent another one.

Some of the discussion, and I think my own suggestion of functional 
roles, would be amenable to adding columns to the existing table, I suspect.

d/

---

From: "John R Levine" <[email-masked]>
Date: 8 Oct 2020 18:36:59 -0400

> Some of the discussion, and I think my own suggestion of functional roles, 
> would be amenable to adding columns to the existing table, I suspect.

Yes, that's what I was assuming.  I suppose at some point we should loop 
in Graham Klyne, the designated expert for the existing registry.

Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 10 Oct 2020 12:57:39 +0200

On Thu 08/Oct/2020 01:32:18 +0200 John C Klensin wrote:
> --On Wednesday, October 7, 2020 18:43 -0400 John R Levine wrote:
> 
>>...

From: doesn't seem to be a trace field, definitely.  But then, the last 
paragraph of Section 3.9 assimilates such mailing lists to MUAs[*], so setting 
message "ownership" is part of their job.[†]

OTOH, in some cases of external aliasing, the backward-pointing address has to 
be modified.  For example, if the final destination must not be disclosed by 
unexpected bounces.

Best
Ale
-- 

[*] MUA is not the right term in that context, since no human user is involved.

[†]  There is also a step in between, where the modifications are so stylized 
as to be programmatically reversible.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 13 Oct 2020 11:17:27 +0100

I have created 2 related tickets in trac based on this discussion:

"Better definition for trace header fields": https://trac.ietf.org/trac/emailcore/ticket/7
"Need a registry of header fields that are Ok to add after submission": https://trac.ietf.org/trac/emailcore/ticket/8

I hope I captured most of relevant points in comments in the tickets.