[Top] [All Lists]

Re: [ietf-smtp] broken signatures, was Curious

2020-07-21 21:55:47

--On Tuesday, 21 July, 2020 18:31 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:

On 7/21/2020 1:19 PM, John Levine wrote:
The amount of bandwidth used by e-mail is a rounding error of
the Internet's total, which is mostly video these dayts, and
the amount used by broken headers is a rounding error on that
rounding error.


My understanding is that the goal of the emailcore work is to
do the minimum necessary to enable promoting the core email
specifications to full standard.

Each of us has a worthy list of wonderful enhancements,
cleanups, and the like, that we would love to see pursued for
email.  None of them is likely to be within scope for this
round of effort.

To the extent that someone thinks otherwise, consider that
each item added to the task list delays completion of this
round of effort, and possibly for quite awhile.

So, as fascinating as this thread has been, unless someone can
explain how it is essential to the work of the emailcore
effort, I'll ask why it is worth taking up this much list
energy? Absent compelling justification, is there a chance
people could stop feeding this thread?

As an aside: X- was deprecated.  It's not illegal, but it's no
longer a formal construct.  I thought it quite a clever
suggestion, when we were doing RFC 822 -- though I don't
remember who suggested it -- but as with many good
suggestions, it had downsides we hadn't anticipated.

Also, as for cleanup of email header fields in transit, I'm
pretty sure that it is fully out of scope for SMTP, IMAP, Mail
Format and any other emailcore work.  It certainly should be,
since it isn't causing actual operational problems.


This collection of threads actually started with a claim that
long header field names were causing operational problems. It
was followed, I think, by at least an implicit claim that the
proliferation of unregistered header fields with very long field
bodies has caused operational problems.

I'm not convinced.  I infer that you are not convinced.  From
his notes, I'm nearly certain that John Levine is not convinced.
However, if I may paraphrase the rules crudely, we don't advance
documents to Internet Standard that specify things that don't
work.  So, if someone really wants to make the case that the
language about <optional-field>s in 5322 causes problems without
some addition specification or restrictions, I think that is,
sadly, in scope.  I would hope that we could handle it in the
Applicability Statement that I hope will accompany
5321bis/5322bis but that is ultimately up to the WG.

And I hope we don't have to fuss with optional header fields at
all and will conclude that the text in 5322 is adequate without
even a reference to the registry.   But I don't think we can
shut off the discussion and prevent those who think there are
operational problems from making their case until someone is in
a position to make a consensus call.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>