G.14. The FOR Clause in Received header field: Semantics, Security Considerations, and Other Issues

[ietf-svn-bot]

type_defect | by alexey.melnikov@isode.com

---

John Klensin wrote:

The FOR clause in time-stamp ("Received:") fields is seriously under- defined. It is optional, the syntax is clear, but its semantics and use, while perhaps obvious from content and the application of common sense, have never been defined ("never" going back to 821). Do we want to better define it? Is there any chance that a definition would invalid existing, conforming and sensible, implementations? If we do want to define semantics, draft text and advice as to where it should go are invited.

Note the existing discussions in Section 7.2 and Section 7.6 as they may need adjustment, or at least cross-references, especially if FOR is more precisely defined.

There is probably an error in Section 7.6. Its last sentence implies a possible interaction between messages with multiple recipients and the FOR clause of trace fields. However, because the syntax of the FOR clause only allows one Mailbox (or Path), it isn't clear if that statement is meaningful. Should it be revised to discuss other situations in which including FOR might not be desirable from a security or privacy standpoint?

---

Issue migrated from trac:55 at 2022-01-31 12:38:28 +0000

[ietf-svn-bot]

@alexey.melnikov@isode.com commented

---

Also see Ned Freed's comments:

https://mailarchive.ietf.org/arch/msg/ietf-smtp/hMkwHT-6bi_AwYIxbFJBX5pqjiA

[aamelnikov]

Remind Pete to propose some text.

[aamelnikov]

The last sentence of 7.6 that John mentioned above reads:

Also, the optional FOR clause should be supplied with caution or not at all when multiple recipients are involved lest it inadvertently disclose the identities of "blind copy" recipients to others.

I agree it is confusing. Suggested replacement:

Also, the optional FOR clause should not be supplied when the same message body is sent to multiple recipients in order not to inadvertently disclose the identities of "blind copy" recipients to others.

[aamelnikov]

After a small tweak as per the above the rest (in particular Ned's feedback) should be discussed in the A/S document

[ksmurchison]

@aamelnikov Can I assume that the statements that we want to make are something along the line of:

"I think a statement to the effect that the value of the for clause must contain one of the addresses that caused the message to be routed to the recipient of this message copy. Discussion of which value to use - if we want to go there - is an AS matter."

"There's another security issue lurking in all this: If the system inserts a "for" clause when there's only one recipient, and doesn't when there are more than one, the absence of the field is itself an indication that there's another recipient, which may allow someone to infer a Bcc: is involved."

[ksmurchison]

Here is the new section that I added to my working copy of the draft. Feel free to bash, with suggested text.

2.4. Use of the FOR clause in Received header fields

Email addresses are commonly classified as Personally Identifiable Information (PII). Improper application of the FOR clause in Received header fields can result in disclosure of PII. As such, the FOR clause MUST NOT be generated if the message copy is associated with multiple recipients from mutliple SMTP RCPT commands. Otherwise, the value of the FOR clause MUST contain the RCPT address that caused the message to be routed to the recipient of the given copy of the message.

Note however, that if a mail system generates a FOR clause when there is only a single recipient, and doesn't generate one when there are multiple recipients, the absence of the field is an indication that there is another recipient, which may allow someone to infer that a "blind" copy is involved.

[aamelnikov]

@ksmurchison I don't see the above text in draft-ietf-emailcore-as-06?

[aamelnikov]

draft-ietf-emailcore-as-07 seemed to resolved outstanding issues related to A/S.

[aamelnikov]

Closing as per https://mailarchive.ietf.org/arch/msg/emailcore/RyEQ0hXI1rTNykc7O8l0_HA--sw/