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

[tom petch <[e-mail]>]

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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/last-call
>