Subject: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission

From: Alexey Melnikov <[email-masked]>
Date: Mon, 16 Nov 2020 17:10:11 +0000

Dear WG participants,

Based on an earlier discussion on the mailing it looks like there is 
consensus to create (or possible ammend an existing) registry for header 
fields with extra information about which types of SMTP agents are 
allowed to add them in transit or before final delivery. In order to 
stimulate the discussion, I would like to propose the following strawman:

Add to IANA Considerations:

IANA is requested to create a new subregistry for email header fields 
that can be added to a message header section by a “relay” and/or 
“delivery” SMTP system. The new subregistry would show whether a header 
field can be added by a “relay”, “delivery” system or both. It will also 
include information whether the header field is allowed to be added 
multiple times or just once. Only header fields that are already 
registered in 
<https://www.iana.org/assignments/message-headers/message-headers.xhtml> 
(whether it is registered as a Permanent Message Header Field Name or as 
a Provisional Message Header Field Name) can appear in this new 
subregistry. Registration policy for this new subregistry is “Expert 
Review”.

Notes:

a) the reason why I am suggesting to create a new subregistry is because 
I think this will be far less work. The same registry is currently also 
used by HTTP and NNTP, so adding extra columns to convey the above 
information would likely confuse HTTP users of the registry. It would 
also be easier to do this if there is no need to get buy in from other 
users of the registry.

b) I believe John asked whether this should be "First Come First Served" 
or "Expert Review". I proposed to do the latter to make sure that 
somebody checks that a particular header field is indeeded added during 
relay/final delivery/both. The review process can be lightweight.

Comments please.

Best Regards,

Alexey

---

From: Michael Peddemors <[email-masked]>
Date: Mon, 16 Nov 2020 09:32:07 -0800

> relay/final delivery/both. The review process can be lightweight.

While this may be an attractive notion, it will generate critisicm if 
the IETF gets to be the 'police' of which headers are allowed.

AS well, the industry routinely starts using new headers for various 
purposes, and it isn't always feasible to wait on an 'approval' that the 
header is accepted..

While the use of X- headers appears to be no longer encouraged, that was 
a simple way for vendors to add new trial headers safely.

While this 'might' have some benefit in stopping those spammers that 
insert random headers, in the misguided belief that it will help get 
around various filtering or beysean tests, that number is relatively low.

There are a lot more proprietary headers out there, only used by a 
single vendor..

I don't think this is a 'cut and dried' benefit, so yes, it should 
undergo at length discussions..

And there will always be some in the industry that might be concerned 
that the 'Expert Review' might have some prejudicial positions, whether 
true or not.  The only problem with first come/first serve, is that this 
would open the door to abuse, as well becoming a very large list.

My thoughts..

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 17 Nov 2020 12:51:28 +0100

On 16/11/2020 18:10, Alexey Melnikov wrote:
> 
> IANA is requested to create a new subregistry for email header fields that can 
> be added to a message header section by a “relay” and/or “delivery” SMTP 
> system. The new subregistry would show whether a header field can be added by a 
> “relay”, “delivery” system or both.

How about fields set by the MUA and by the MSA?  If we do that distinction, it 
would be worth to consider all MxAs, for x=U, S, T, D.

Best
Ale
--

---

From: Ned Freed <[email-masked]>
Date: Tue, 17 Nov 2020 05:22:55 -0800 (PST)

> would be worth to consider all MxAs, for x=U, S, T, D.

I'm not sure there's a clear distinction to be made between what an MUA does
and what an MSA does - the responsibility split in some cases puts most of the
MUA function in the MSA - but yes, I think it does make sense to include
submission. If only to be able to say that submitted messages really shouldn't
insert a return-path field...

				Ned

> --
> Emailcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emailcore

---

From: "John Levine" <[email-masked]>
Date: 17 Nov 2020 21:54:22 -0500

>> > “relay”, “delivery” system or both.

This is, as I think is fairly obvious, really the same topic as the
forwarding and mailing list headers one.

I think we can come up with a fairly short list of headers that are
fixed by submission time (I agree we don't try to distinguish between
MUA and MSA.) Anything else can be added when a message is relayed or
delivered up to the maxmum number of each header allowed, typically
one.  I also don't think it's useful to try to distinguish at this level
between relay and delivery since for a lot of MTAs (mine for example)
the distinction is pretty fuzzy.

There is a very short list of headers that can be deleted or replaced
when a message is relayed, currently just Authentication-Results.

This has approximately nothing to do with mailing lists which create a
new message by editing the incoming message in all of the fun and
exciting ways we know.

R's,
John