On Sat, Nov 3, 2018 at 12:00 AM Murray S. Kucherawy <[email protected]> wrote:
> On Thu, Nov 1, 2018 at 2:56 AM Rifaat Shekh-Yusef <[email protected]> > 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
