Re: [Last-Call] Last Call: <draft-billon-expires-06.txt> (Updated Use of the Expires Message Header Field) to Proposed Standard

[Keith Moore <[e-mail]>]

On 12/4/22 22:16, Bron Gondwana wrote:

> My use case (and the tooling I would build for myself if we don't make 
> it a standard Fastmail feature) would be to flag particular senders as 
> "auto-expire messages from this sender when their Expires header says 
> to) - and I'd use for a bunch of transactional edge trigger "reminder" 
> emails, which contain no content other than a "please go check over here".
>
> For example: the "you have pending moderation messages" that Mailman 
> sends every day.  If the previous day's one expired at the time a new 
> one would be sent out, I could have them auto-clear, and they would 
> either have been superseded by a newer "you have things to action" 
> email, or be no longer relevant.

Yes, I've often wanted this kind of feature for messages emitted by cron 
jobs, or other "daily alert" kinds of processes.

But I also ask myself "how would this field be used in practice, not by 
geeks like myself, but by ordinary people, or by miscreants?"

Enabling auto-delete based on Expires only on a per-sender basis makes 
some sense, and appears to make it less likely to be abused.

> Obviously, we all agree - and the draft agrees - that this MUST never 
> be turned on by default.  At least to the kind of MUST that you can 
> apply on any system - business logic might automatically turn it on 
> for some senders inside a business who know their own senders, and we 
> can't force them to do otherwise with strong words in a draft - but 
> generally I think the risks of defining this header with this 
> behaviour are not as great as you suggest.  Yes it could be abused but 
> receipients with a legal requirement to not destroy emails will 
> already have protections around archiving all incoming email and 
> that's not going to change because there's a header there.

Right, but there's also a possibility that intermediate systems, or the 
recipient's mail service provider, will delete messages based on 
Expires.   And this draft doesn't make it clear which component has the 
responsibility of deleting based on Expires.  To me that's one of the 
biggest potential sources of problems.  If it's clear that deletion 
based on Expires is ALWAYS a function of the recipient's MUA (even if 
it's a webmail interface, it's still acting as an MUA) and ALWAYS 
enabled only by the recipient, it's less likely to cause trouble.  But 
in practice Internet email doesn't have a great envelope/header 
separation anyway, and this draft just further muddies the distinction.  
(I've often wished that the email header was opaque to the mail 
transport, but that ship sailed decades ago.)

And I really don't think that there should be a general expectation that 
Expires in email should be interpreted in the Usenet sense.  Or maybe 
the field name shouldn't be Expires because it's too easily interpreted 
as "any component that processes this message has permission to drop or 
delete this message after this date-time".

I didn't say that Expires was an inherently Bad Idea, I said the draft 
needs more work and clarity.   It needs to benefit from more of this 
very kind of discussion.

Keith