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

[Keith Moore <[e-mail]>]

This proposal needs work before adoption as Proposed Standard, and in 
general doesn't seem to be thought-out enough for a Last Call.   I 
strongly recommend against adopting this document before revision in 
light of feedback below and presumably from others also, followed by 
another last call.

Section 3 (security considerations):

Should add something like:

Since message headers can in practice be altered by any MTA or other 
intermediary that relays messages from sender to recipient, Expires 
header fields MUST NOT be assumed to be authentically specified by the 
originator of the message, in the absence of some form of verified 
digital signature by the originator of the message (not some 
intermediary) that includes the Expires field.

Section 5:

- In general this section is imprecisely worded and should be 
rewritten.  In particular the roles of the "mailbox provider" (or 
"mailbox") and recipient's mail user agent (MUA) should be explicitly 
specified.

- The language prohibiting silent and automatic deletion of messages 
based on the Expires header field should be stronger, probably something 
like "MUST NOT automatically delete based on Expires header field 
without explicit configuration to do so by the recipient".

- The language "Mailbox providers could indicate..." is bizarre, and 
seems to incorrectly presume that the "mailbox provider" provides the 
recipient's mail user agent.

- In no case should a "mailbox provider" automatically delete messages 
without explicit configuration by the recipient (even if the Expires 
header is authenticated by the originator's signature).   Deletion of 
messages should normally be a MUA function, not a function of the 
"mailbox provider" (or IMAP or POP server).   Granted there are cases 
where the "mailbox provider" provides some MUA functions and the 
separation between the two is not clean, but this should be treated as 
an odd exceptional case rather than the general rule.

- The language "In certain cases, email messages may be used as an 
element of an investigation..."  seems superfluous at best and should be 
out-of-scope for the document.

It should not be assumed that either the "mailbox provider" or the 
recipient's MUA has any responsibility to preserve messages (or not 
preserve messages) for possible use in an investigation, and IETF should 
not adopt a Proposed Standard that assumes or specifies that mailboxes 
or MUAs have any role of surveillance by any 3rd party (other than 
sender and originator).   If there is a legal requirement in some 
jurisdiction that mail service providers retain messages, that 
requirement should not be affected at all by this document, because that 
requirement (if/where it exists) can be implemented entirely separately 
from the storage of messages in a recipient's mailbox.


Keith


On 11/29/22 09:28, The IESG wrote:
> The IESG has received a request from an individual submitter to consider the
> following document: - 'Updated Use of the Expires Message Header Field'
>    <draft-billon-expires-06.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [e-mail] mailing lists by 2022-12-27. Exceptionally, comments may
> be sent to [e-mail] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This document allows broader use of the Expires message header field
>     for mail messages.  Message creators can then indicate when a message
>     sent becomes valueless and can safely be deleted, while recipients
>     would use the information to delete or ignore these valueless
>     messages.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-billon-expires/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>