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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
