[Top] [All Lists]

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

2020-07-21 22:54:00

This collection of threads actually started with a claim that
long header field names were causing operational problems. It

When someone makes a claim like that, they need to document it. Nothing in this thread has done anything like documenting the existence of an operational problem. Unless I missed it, but I don't think I did.

Rather, what happened was a claim that then led to lots of /other/ people putting quite a bit of energy into evaluation of all sorts of information, none of which demonstrated any operational problems.

Or even tried to, IMO.

I'm not convinced.  I infer that you are not convinced.  From

Things that cause operational problems are described very differently than what's been happening here. They state the problem(s) that are caused and then give details about how, when, and where.

   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.

There is a difference between saying "I think bad-thing-x is happening and causing problems" from saying "bad-thing-x is causing the following problems, in the following ways and with the following systems."

Someone claiming a problem has the burden of documenting that the problem is real.

It is not reasonable for them to raise a question and expect other people to do the work of proving/disproving. The latter approach is, effectively, a denial of service attack. (There are, of course, exceptions, but the framework of legitimate vs. questionable is really quite straightforward.)

 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.

People continue to love ASs, but my impression is that they have no field utility.

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.

In formal terms, that is of course correct.

But people can choose to not respond to postings lacking in-scope relevance or substance.

That's why I refrained from posting, but the fact that this thread persisted suggested a meta-issue worth broaching early in the wg effort, in the possibility it has continuing relevance. I mean, it's just possible that people will have other opportunities to lose focus from the actual goals of emailcore. Shocking, I know, but...

Dave Crocker
Brandenburg InternetWorking

ietf-smtp mailing list

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