Re: [ietf-822] Expires header field

[Keith Moore <[e-mail]>]

On 11/8/22 05:36, Murray S. Kucherawy wrote:

> Hi all,
>
> I have received a request to sponsor and publish this document:
>
> https://datatracker.ietf.org/doc/draft-billon-expires/
>
> This is mostly just a change of state for this header field.
>
> Before I send it to an extended Last Call, I wanted to prompt here for 
> any feedback, support, etc.  Please have at it.
>
I missed the earlier announcement but saw it on the last-call list.

If memory serves, similar proposals have been discussed many times in 
the past and always been rejected in the email context, due to several 
problems: mostly, lack of reliable authentication in email, but also 
concerns about tricks that could be used to make it seem like a 
recipient had received a message that they never actually were able to 
read.

IMO automatic expiration of email messages is a Bad Idea as it damages 
the transparency of the email system (especially when it leaves no trace 
of the deletion that's visible to the recipient), and reduces the level 
of consistency between implementations (if some message stores or MUAs 
expire and others don't).   This seems problematic especially if the 
differences in such behavior are detectable, in that it could be 
exploited by someone who wished to send a message to several recipients 
(perhaps also arranging for some kind of proof of delivery to each), but 
also arranging that only some of those recipients could actually read 
the message. (Sure, anyone can craft a message that includes recipients 
in the To or CC fields that aren't actually sent copies of the message, 
but being able to have those deliveries logged or acknowledged but still 
unavailable to recipients adds another wrinkle.)

Having a way to say "this message is no longer relevant after <date>" 
could be useful to MUAs so they could use this information to affect how 
they present such messages to recipients.  But automatic expiration of 
messages based on Expires header with no indication to the recipient, 
seems at least as dubious as automatic deletion of (suspected) spam.

I also have very strong concerns about the way this draft is currently 
worded, especially that it doesn't make a clean separation between the 
recipient's MUA's role vs. the "mailbox provider"'s role.  That much 
could be fixed with some judicious editing.

I have even more concerns that this draft seems to envision a role for 
the "mailbox provider" in implementing government surveillance.  I don't 
think this is something that IETF should be lending any kind of 
legitimacy to.

And sure, I realize this is pretty much what Usenet did, but: Usenet 
mostly existed in a much more benign world than we have today, and even 
then many admins turned off automatic expiration.   Also, Usenet 
discussions differed in character in many ways from email.

In short: PLEASE give this proposal a VERY careful (re)look, as IMO it's 
quite dangerous and not receiving enough scrutiny.

Keith