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
