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
last-call@xxxxxxxx mailing lists by 2022-12-27. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
