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.) > 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 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. > 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. > [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? > 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. Regards, Steve _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
