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

--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.
>
> Folks,
>
> 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.
Dave,

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.

best,
   john


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp