On 06/12/2022 03:35, George Michaelson wrote:
If a message had an EXPIRES-BY header, semantically past it's "due"
date, and an intermediate store-and-forward SMTP MTA decided to look
in its queue, would it be "wrong" for it to return to sender rather
than deliver? If the header could be shown to be origin specified, and
not arbitrarily added?
I admit to having more than one view on that. I can see the utility, I
shudder at the implications for things sent but not seen, expires not
withstanding.
Mail systems already exercise far too much control over what users, such
as the IETF, can do and this I-D is a leap in the wrong direction.
s.5 is a licence to cause damage. 'no email should be silently and
automatically deleted' is far too weak. That is at least a MUST NOT.
The first sentence of that paragraph 'logically leads to deletion ' sets
the wrong tone. It assumes that the party which inserted the 'Expires:'
header is omniscient and benign, which is not the Internet we have today.
The section on Security Considerations is so weak as to be comical.
A parallel situation which irks me is the classification of e-mails by
major mail providers as spam. I receive a mail via a list from an
organisation every week or two which my major mail provider classifies
as spam so I do not receive it and have to log on to their web site to
tell the major mail provider that it is not spam and not to classify any
future e-mail from that organisation as spam. Two weeks later the major
mail provider classifies another such email as spam; it has been doing
this for years. (It also classifies a number of IETF e-mail, typically
responses to a Call for Consensus such as this thread, as spam; usually
a follow up email gets through so I can see I have lost something).
Major email providers do not have the interests of users auch as the
IETF at heart and should not be given permission to do even worse.
Tom Petch
-G
On Tue, Dec 6, 2022 at 1:15 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
On 12/5/22 12:19, Alessandro Vesely wrote:
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.
In my opinion, this is far too vague, and leaves too much room for
parties other than the recipient to impose such "clean up".
Perhaps it should add that any auto-delete configuration should be
under direct user's control.
Recipient's control. And probably a MUST.
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.
And DELIVERBY is presumably specified by the sender of the message,
whereas Expires policy should only be set by the recipient.
It might be good for this draft to explicitly compare Expires to
DELIVERBY. And it should specifically forbid intermediate systems (not
just MTAs but also spam filters) from deleting messages based on Expires.
Keith
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
