1. The biggest danger of legitimizing the Expires field is that it will be used to delete messages without explicit consent of the recipient, and this document's failure to mention that obvious problem (despite the issue having already been raised in Last Call comments) is a huge red flag.
2. This document should explicitly forbid deleting of messages based on an Expires field by any MTA or other intermediary. (but see also text below about spam filters)3. This document should explicitly forbid deleting of messages based on an Expires field by an MUA, except when the recipient has explicitly configured the MUA to do so.
(The important difference between "MTA and other intermediaries"
and "recipient's MUA" is that the recipient's MUA acts as an agent
for the recipient, and thus carries out the recipient's
wishes. Whereas the mail routing and delivery system are NOT
acting as agents for the recipient and should not presume that
they have the authority to do that.)
4. This document should consider explicitly forbidding
consideration of Expires fields by spam filters, or software that
evaluates messages for legitimacy.
I acknowledge that this is a tricky area to talk about, because
some companies make lots of money selling spam filtering and will
defend their right to do so. And spam filtering is not the
primary subject of this document and is arguably out-of-scope.
But spam filters are hugely damaging to the reliability of the
email system, they routinely delete messages based on extremely
dubious criteria, and their purveyors tend to brazenly claim that
such filtering is a feature. Such filtering is often undetectable
by the recipient (who may not even be able to opt-out of it), and
senders are often entirely without recourse when some anonymous
intermediary deletes their mail or flags it as spam.
And this absolutely should be forbidden; otherwise the risk of legitimizing Expires fields is too great.
4. Advice to Message Readers Message readers, such as mailbox providers, web mail and MUAs
No. Mailbox providers are NOT message readers. Mailbox providers should not assume any role at all in determining how a message is presented to the recipient.
Web mail readers are just another kind of MUA implemented in a
web server and/or browser code. Even if the web mail reader is
supplied by the mailbox provider, it's important to treat the role
of the mail delivery system (including mailbox provider) separate
from the role of the recipient's user agent.
MUAs should NEVER hide messages from recipients by default, that's
usurping the recipient's role. Whether messages should be hidden
is for the recipient to decide. So it's ok if a MUA allows a
recipient to choose for Expired messages to be hidden from the
recipient, not ok if the MUA makes this decision for the
recipient.
5. Security considerations
In general this section seems both poorly worded and inadequate.
- In the absence of both reliable authentication and sender-to-recipient integrity protection for the entire message, intermediaries can (and often do) add message headers in ways that are not easily detected. Therefore message handling software MUST NOT trust Expires header fields to be reliable, and specifically MUST NOT delete or hide messages past their Expires dates without explicit configuration to do so by the recipient.
- To me it seems like there's some potential for senders,
especially those with knowledge of the behavior of recipients'
mail systems, to use Expires fields to send "disappearing"
messages. For example, if a sender knows that a recipient's mail
delivery software will delete an expired message, the sender can
send a message that will expire very quickly, and still be able to
claim that the message was sent (and perhaps obtain proof of
delivery via any of several means). Or if a sender knows that
recipient A's mail system will delete an expired message but
recipient B's mail system will not delete it, sender can send a
message to both A and B (again, perhaps obtaining evidence of
delivery) which B will see and A will not see.
A message creator can put any date in an Expires header field, including dates in the distant past or future. Without further knowledge about the message creator, recipient systems and message readers cannot assume that the contents of the header are accurate or benign.
This paragraph has two problems:
1. While it is perhaps plausible that a "message creator" can
include an Expires field for the purpose of fooling spam filters
(as the text suggests), any MTA or other intermediary that handles
the message is easily capable of inserting a malicious or
misleading Expires field. Message header fields are routinely
added by all kinds of intermediaries today, often for dubious
reasons, and sometimes for malicious reasons. So it would be
unsurprising if intermediaries also started adding Expires
fields. Perhaps this document should explicitly forbid
intermediaries from adding Expires fields, but that wouldn't
address the security issue. The bottom line is that the field
can't be trusted to be authentic, so no destructive action
(including either deleting or hiding the message) should be taken
based on an Expires field.
2. The other problem is that saying "A message creator can..." is
easily misread as "A message creator has permission to..." or
"...is allowed to..." If you want to say that, please be clearer
about that, and move that out of the Security considerations
section.
Keith
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
