On 11/29/22 22:02, John Levine wrote:
It appears that Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> said:
On 11/29/22 16:53, John R. Levine wrote:
I note in passing that if this is a real problem, which I do not
believe it is, an MDA or MUA can easily look at the date on a message
and if it's before 2022, the Expires header is not one of ours.
Oh please. We all know that the date of the message does not imply the
date of the version of the specification that it conforms to.
It's a heuristic, in this case, likely to be a pretty good one.
Disagree, and it might also set a bad precedent.
But it
occurs to me that this same argument could be used to say we can't
ever add any new headers, ever. If I define a new "Flurgle:" header,
how can we know that someone somewhere didn't already use it to mean
something else? It doesn't seem very compelling to me, either for
Expires: or for Flurgle:.
Well, we know that Expires has been used for a long time, and that
except for its use in Usenet it didn't have any effect. If it suddenly
starts having an effect in email, that changes the semantics of the
header field, even if the syntax stays the same.
Of course we used to have X- headers which were intended to be
distinguishable from standard header fields. Then people wanted to get
rid of X-, so they did. We can't have it both ways.
I don't think there's any good way to prevent inconsistent use of header
fields, whether or not they're standardized when originally used.
dangerous feature, especially in the absence of reliable and verifiable
authentication. That, and the sender should not get to dictate when a
message is deleted by the recipient.
Please take a look at section 5, where it says not to do that, and propose
text to make it clearer.
We all know that a significant percentage of implementors never bother
to read the RFCs, or at least not in detail. Anyone seeing an Expires:
header will already "know" what it means, no matter what the RFC says.
It's easier to add a couple of lines of code to remove the message than
it is to check for signature, validate the signature and the credentials
used to sign it, verify that the message was signed by the From address
and that the Expires header is part of that signature, and only then
remove the message. If it's easy to cut corners, people will do that.
And for what? What percentage of storage or bandwidth used by email
will this save?
Also FWIW we've had the Expires: header in usenet since forever, it's
always been purely advisory, never been authenticated, and it has
turned out to be useful.
For most practical purposes, Usenet was a long time ago, and existed in
a more benign 'net than the one we have today.
We need to be finding ways to make email more robust, rather than less.
Keith
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
