Add text to A/S about what mail agents should do/not do with Received header fields

[aamelnikov]

No description provided.

[aamelnikov]

Initial suggestion is to add something like this:

"Received header fields are not normally useful to the
end user, becoming useful only when there are delivery
problems with a message or when the message itself is
problematic or suspicious for some reason. Their
content is also fairly easy to fake should someone
desire to do that. Therefore, if anyone or anything
receiving a message pays attention to such fields that
it did not insert (or otherwise have reason to trust),
they should be used with care, whatever
information seems to be valuable used as appropriate,
but with no assumptions of trust especially when syntax
or values occur that are not defined by the
specifications [rfc5321bis] [rfc5322bis]."

[ksmurchison]

@aamelnikov now prefers the current text in Section 3.2.2:

Received header fields are primarily for use when there are concerns about a message, such as to analyze handling or delivery problems, or to aid evaluation of a message with suspicious content or attributes. Received header fields are easily created and have no direct security or privacy protections.

Therefore, the fields do not warrant automatic trust. They should be used with care, for whatever information is deemed valuable, and especially when syntax or values occur that are not defined by the specifications [I-D.ietf-emailcore-rfc5321bis] [I-D.ietf-emailcore-rfc5322bis].

[ksmurchison]

Dave Crocker suggests tweaking to the current text to:

Received header fields support analysis of handling and delivery problems, as well as aiding evaluation of a message with suspicious content or attributes. The fields are easily created and have no direct security or privacy protections, and the fields can contain personally identifiable information.

Therefore, the fields do not warrant automatic trust and do warrant thoughtful disclosure to others. They should be used with care, for whatever information is deemed valuable, and especially when syntax or values occur that are not defined by the specifications [I-D.ietf-emailcore-rfc5321bis] [I-D.ietf-emailcore-rfc5322bis].