I support making no change in dmarc-base-05 that might change how current mailbox providers implement dmarc-base. But to the extent this collection of contributors would like to see the recommendations/requirements in section 5.6.1 updated to better harmonize with related RFC's, I support Trent's proposal as it seems to introduce the least amount of increased risk to fraud.
That said, we do have people here familiar with large-scale mailbox provider deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask them if they expect Trent's changes to have any impact on how they implement dmarc-base today. If it will, I think we should consider these changes for a future version of dmarc-base and let this version go through with these requirements unchanged. As you all know, there are now years of experience deploying dmarc-base with these requirements as written. Those deployments have had tremendous success protecting users from domain-spoofing the RFC5322.From field. The importance of the current dmarc-base specification's efficacy at blocking domain-spoofed phishing attacks should not be underestimated. I advise extreme caution when considering any normative changes at the 11th hour. Dear high volume MBP's, will any of these changes in Trent's proposal alter how you implement dmarc-base today? -Brett On Sat, Nov 8, 2014 at 2:26 AM, Murray S. Kucherawy <superu...@gmail.com> wrote: > On Fri, Nov 7, 2014 at 8:57 PM, <turnb...@sk.tsukuba.ac.jp> wrote: > >> Trent Adams writes: >> >> > ----- >> > It is important to note that identifier alignment cannot occur, and >> > DMARC determination applied, with a message that is not valid per RFC >> > 5322 [MAIL]. This is particularly true when a message has a malformed >> > or absent RFC5322.From field. >> > ----- >> >> I occasionally see non-ASCII octets introduced by spam/virus checkers in >> X-Spam-* fields in the header or in the (non-8-bit) message body, due to >> copying message content into those contexts. The From field is perfectly >> valid, however. Does that really mean that identifier alignment cannot >> occur? >> >> (I think that is a plausible policy choice, since in an invalid message >> "anything can happen". But I don't see that it's a no-brainer.) >> > > Do you have another suggestion? > > Note that there's nothing normative in Trent's suggestion. If a receiver > thinks it can continue with the X-Spam-* fields malformed as described, > then it can continue on that basis. > > >> > Starting off, we can ignore a <null> address in the RFC5322.From field >> > as DMARC will have no bearing in that case. Similarly, when there is >> > exactly one address in the RFC5322.From field, application of DMARC is >> > reasonably straight forward. >> >> By "DMARC", you really mean "DMARC policy", right? DMARC the protocol >> does need to say something about what happens if alignment fails or no >> policy can be discovered. >> > > That's how I understood what he said. > > >> > That leaves taking some action based on the DMARC policies associated >> > with the set of domains represented in the RFC5322.From field. It seems >> > that the most reasonable approach is to gather the DMARC policies for >> > all addresses, and then apply the most strict. >> >> I wouldn't call that "reasonable". It's the only plausible option, but >> here's the problematic use case: >> >> Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. >> For organizational political reasons it is necessary that (a) both names >> appear on the memo and (b) Stephen has to do the dirty work. Stephen >> sends the mail "From: tr...@example.com, step...@example.org", with >> proper >> SPF and DKIM setups. Unfortunately, example.com publishes p=reject, >> example.com alignment fails because Stephen sent the message, the MTAs >> reject the message, and nobody except Trent and Stephen shows up to the >> meeting. I see two ways this message could pass DMARC: Stephen has the >> keys for example.com, or the Japanese "ringi" system, where I write and >> sign the message, send it to Trent, who then signs the message but >> otherwise forwards it verbatim. Both seem fragile to me. > > >> OTOH, only checking policies of aligned SPF source domains and DKIM >> signers means that Stephen (or any scammer) can add "po...@whitehouse.gov >> " >> to the From field and pass DMARC. It's obvious what the Felons of April >> would do with that. >> > >> I guess the most plausible approach to this issue is to say that if you >> want to use DMARC and have multiple authors, you must contrive to give all >> the authors mailboxes in the same domain. In the example, I could create >> the-committee.example.org for committee members, or give trent a >> forwarding mailbox at example.org itself. >> > > Ned, do you concur with this analysis? Is Trent's proposal coupled with > this caveat a valid remedy for your point? > > >> > Given all that, here's my suggested revision to Section 5.6.1.: >> > >> > ----- >> > 5.6.1. Extract Author Domain >> > >> > In order to be processed by DMARC, the domain(s) must be extracted from >> > the domain of the email address(es) within the addr-spec portion of the >> > RFC5322.From field. If the domain is encoded with UTF-8, the domain name >> > must be converted to an A-label for further processing. If no domain is >> > found, the message SHOULD be rejected (as it is forbidden under RFC 5322 >> >> I still don't think a null From filed is any business of DMARC the >> protocol. That's really an issue for (a) the security considerations >> section or (b) the planned BCP. >> > > I think we're all in agreement on that point so far. > > >> > [MAIL]). If more than one domain identifier is found, the full set of >> > domains MAY be collected as a set of identifiers for DMARC processing. >> >> But this seems to be the insecure approach I describe above: >> >> > 5. Conduct identifier alignment checks. With authentication checks >> > and policy discovery performed, the Mail Receiver checks if >> > Authenticated Identifiers fall into alignment as described in >> > Section 3. If one or more of the Authenticated Identifiers align >> > with an identifier extracted from the addr-spec of the >> > RFC5322.From domain, the message is considered to pass the >> > DMARC mechanism check. >> >> AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to >> send spam that passes DMARC on your behalf, as long as my mailbox appears >> in From, too. Am I misunderstanding your proposed algorithm? >> > > No, because in (6) the strictest rule applies. Your throwaway domain > might pass, but the other advertised author's would not. > > >> > All other conditions (authentication >> > failures, identifier mismatches) are considered to be DMARC >> > mechanism check failures. >> >> Bottom line, I think both messages where no Authenticated Identifiers can >> be extracted and those where multiple Authenticated Identifiers can be >> extracted should be defined to be mechanism check failures. In the former >> case, policy discovery is impossible, in the latter, the strictest policy >> should be applied. >> > > Right, I think that's what Trent is also saying. > > And everyone seems to agree on just dropping STARTTLS as well. > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
