[dmarc-ietf] SPF RFC 4408 vs 7208
On Jan 6, Murray S. Kucherawy confirmed fixing the reference for the SPF RFC from the now-obsolete 4408 to 7208 (Fixed in -11). However, -12 still has, in section 3.1. Identifier Alignment: For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] authenticates either the domain that appears in the RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom is null (in the case of Delivery Status Notifications). Actually, RFC 7208 states that: Checking HELO before MAIL FROM is the RECOMMENDED sequence if both are checked. ... and implies that if the first check passes, the second is unnecessary: If a conclusive determination about the message can be made based on a check of HELO, then the use of DNS resources to process the typically more complex MAIL FROM can be avoided. So the RFC5321.EHLO/HELO domain is checked not only if the RFC5321.MailFrom is null - in fact in cases where sites have followed the RFC 7208 recommendation, it will be checked first, at least by a pure SPF implementation. This means, first of all, that the -12 text above needs fixing. But also, I'm struggling with what it means for alignment. I can think of some real-life cases where only one of HELO or MAIL FROM aligns with RFC5322.From, even though both would pass in a pure SPF check. IMHO, Section 3.1.2. SPF-authenticated Identifiers needs to be clarified to better take HELO into account. I'd like to see an approach similar to that for DKIM, where it is explicitly stated that: a single email can contain multiple DKIM signatures, and it is considered to be a DMARC pass if any DKIM signature is aligned and verifies. Similarly, I think that for SPF, it should be considered a pass if either the MAIL FROM or the HELO is aligned and results in a pass at the SPF level. But whether it is decided to take into account both HELO and MAIL FROM, or whether it is decided to ignore HELO (modulo its use to construct an artificial MAIL FROM if the latter is null), the text should IMHO make this clear one way or another, both in 3.1.2. SPF-authenticated Identifiers: In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce identifier alignment. ... and in 4.1. Authentication Mechanisms: o [SPF], which authenticates the domain found in an [SMTP] MAIL command when it is the authorized domain. In both cases, the text should specifically mention HELO, and whether to include or exclude a HELO SPF result, in view of HELO's prominence in RFC 7208. If it is decided to allow both HELO and MAIL FROM results to be passed back to DMARC, then in section 6.6.2. Determine Handling Policy, item 4 should be updated to reflect that as well. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Flow of operations text in -12
In draft 12, Section 4.3 Flow Diagram, we have text which I think is somewhat contradicted by text in the later and more detailed 6.6. Mail Receiver Actions, in particular with respect to parallelizing some of the checks, and there's another small problem with the text as well. Quoting 4.3: 6. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain's DNS data (when identifiers are aligned; see below). ... but the Author Domain (based on RFC5322.From) is not necessarily the domain that will be queried by SPF and DKIM checks, and we won't know if identifiers are aligned until we look at the results of: 7. The results of these are passed to the DMARC module along with the Author's domain. The DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.) 6.6.2 shows clearly that the SPF check (with its DNS queries), the DKIM checks (with its DNS queries), and the DMARC policy determination (with its DNS queries) can be done in parallel, and their results combined when all have arrived, and I imagine that will turn out to be the best way to do it. So 4.2 could perhaps be modified: 6. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to DNS data. The results of these checks are passed back to the DMARC module. 7. Meanwhile, the DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.) Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] ... and two more tiny nits, while I'm at it
Having just spent several hours poring over this document (-12), I might as well send my additional minor observations. I suspect that some of you will consider these items trivial, but they gave me pause as I went back and forth through several sections of the text to make sure I understood correctly. So... In 6.6.2. Determine Handling Policy, items 3 and 4, it would be helpful to make it clear whether only passed checks are passed back from SPF and DKIM to DMARC modules, or only pass/fail, or all results including temporary errors. In 6.6.3 Policy discovery, item 3, I think you mean that the OD must be looked up if AND ONLY IF the set is now empty. Otherwise, one does run the risk of ending up with several records, which item 5 implies is erroneous. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca+1 514 848-2424 x2285 ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
Hello Anne, On Fri, Jan 16, 2015 at 4:41 PM, Anne Bennett a...@encs.concordia.ca wrote: Having just spent several hours poring over this document (-12), I might as well send my additional minor observations. I suspect that some of you will consider these items trivial, but they gave me pause as I went back and forth through several sections of the text to make sure I understood correctly. So... [...] I think all of the points in your three messages are good input for a more solid specification, but the timing is unfortunate as we just got publication approval for -12 a week ago. Making more changes post-approval would probably not be a good idea, and by my reading none of them rise to the level of being urgent to correct. The plan for the DMARC working group is to consider, among other things, whether it wants to produce a new version of the base document on the Standards Track (because of its path to publication, -12 will be Informational). Your points here are ideal for consideration when the working group reaches that juncture. Would the co-chairs object to beginning to track these items using the WG's tracker? If and when we do decide to crack open the base document for a Proposed Standard revision, we'd already have an inventory of topics to consider. It would also help to keep the discussion on this list focused on active topics now that the base draft is done. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
