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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux