--On Tuesday, 21 July, 2020 20:48 -0400 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:
On 7/21/20 6:01 PM, John C Klensin wrote:
Pete, I think the core issue is the amount of trash we are
accumulating and passing around. I don't see that as a
5322bis problem.
I think it's slightly deeper than that, which is that every
time one party adds a new header field, some number of other
parties decide that they can delete or modify that field, or
use it to validate or invalidate the message. So random
parties making random decisions about message headers are
detrimental to email reliability.
I agree with that. But that is the justification for registered
header field names, preferably well-documented and stable ones.
I contend that:
X-I-know-what-this-means-and-I-am-not-going-to-tell-you: (Longer-
than 35 characters but much shorter than 78)
does no one (other than maybe me) any good (with or without the
"X-". If there are sufficiently many like that, they are
invitations to exactly the behavior to which you object.
I think this is probably a bad idea (or just short of nightmare)
but I wonder whether if we created a registration tree for
headers named
private.* :
required registration of whatever came next, and then declared
open season on the rest if that would make things better. Or
worse.
E.g.
private.<antispam>.MyCOMPANY.MYSTUFF:
private.<antispam>.YourCOMPANY.YourStuff:
private.<trace>.YOURSTUFF:
Noting (to my surprise, I had forgotten) that section 3.6.8 of
RFC5322 allows any printable ASCII character other than SP or
colon in field names.
As I said, probably a bad idea, but the idea that these things
were all going to be registered and documented has obviously
failed.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp