On Sat, Nov 3, 2018 at 12:00 AM Murray S. Kucherawy <superuser@xxxxxxxxx> wrote:
On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef <rifaat.ietf@xxxxxxxxx> wrote:Section 7.1. Forged Header Fields
In addition to a recommended solution, this section has list a potential
alternative solutions which the document then states that it is not appropriate
for this document to specify which mechanism should be used.
Since an implementer is not expected to do anything with this information, it
might be more appropriate for this to be moved to an appendix at the end of
document.Implementers need to be aware of these things in order to make informed handling decisions, but we also acknowledge that we can't propose a single solution that will work for all operational environments. That's what this text means to convey.
By my read of RFC3552, that's what this section is for, rather than an appendix.Section 7.2. Misleading Results, First paragraph, last sentence
"In particular, this issue is not resolved by forged header field removal
discussed above."
which seems to be in conflict with the following statement from section 5:
"For simplicity and maximum security, a border MTA could remove all
instances of this header field on mail crossing into its trust
boundary."They're not in conflict. Even if I remove all instances of this header field at ingress and then evaluate DKIM (for example), I have no idea if a valid signature from "example.com" should be interpreted such that I trust that message more (or less).The two paragraphs you're talking about solve different problems.
I thought the DKIM signature is part of this header, but I now understand that it is a separate header.
Section 7.2. Misleading Results, Second paragraph
"Hence, MUAs and downstream filters must take some care with use of
this header even after possibly malicious headers are scrubbed.."
How do you expect an MUA or downstream filter to act on "take some care"?
Can you elaborate on that?If you are a spammer or malware distributor, you can elicit a DKIM "pass" by simply creating your own domain and signing your bad email with that domain.. The fact that you got a "pass" doesn't tell you anything about which domain's signature succeeded, nor does it confirm the message content is safe or trustworthy in any way."take some care" means "keep this in mind while deciding how to render a message to end users, who might not know to even look at this".
I guess what I am looking for is a statement about the best case scenario for an MUA to be able to display a message with some confidence given the current state of affair.
For example, if there is a valid DKIM, an Authentication-Results header with dkim pass,and the header was provided by a trusted entity?
7.3. Header Field Position
This section explains that headers fields are *not* guaranteed to be in a
specific order. The section then states that "there will be *some*
indication..."
Since the order is not guaranteed, what do you expect an implementer to take
away from this?"in the general case" and "but most do not".So: Most of the time, you can rely on header field ordering to determine the sequence of handling. You are at least certain about whether you can trust the tail end of that, because you know your own environment from the ingress point..
Fair enough; I think it is worth adding this sentence to make it clear.
7.8. Intentionally Malformed Header Fields
This is a general issue with any header. Is there anything specific to this
header that an implementer should pay attention to?No, not really, but at the time this text was originally written (see RFC5451; this is about the fourth version of this material), it was felt this was worth adding.
I guess it does hurt to remind implementer to pay attention to this issue, but I think it might be useful to state that there is nothing special about this header to avoid possible question like this in the future.
Regards,
Rifaat
-MSK
