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

[Alessandro Vesely <[e-mail]>]

On Mon 05/Dec/2022 04:54:29 +0100 Keith Moore wrote:
> 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.


The I-D covers specified creators in Section 5:

                                For instance, systems may allow
    automatic rules to clean up expired email from specific message
    creators or with defined characteristics, or to provide a mode to
    quickly handle all expired email.

Perhaps it should add that any auto-delete configuration should be under direct 
user's control.


>> 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.


I think that delete by the MTA would have its own merit.  Many MTAs still hold 
undelivered messages for days, and rfc5321bis still says that "the give-up time 
generally needs to be at least 4-5 days."  For various kinds of transient 
messages, the give-up time could be much shorter.  MTAs don't need to read 
Expire fields, however, since RFC2852's DELIVERBY addresses exactly that use case.


Best
Ale
--