Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it
On Mon, Jan 19, 2015 at 6:30 AM, Tim Draegen t...@eudaemon.net wrote: No objection — please do use the WG’s tracker for these items. Anne’s thorough review will be picked up (and not rediscovered!) if we’ve got an obvious place to start from. Done for Anne's points, and I'll do so for Jim Fenton's remaining ones as well. -MSK ___ 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
On Mon, Jan 19, 2015 at 6:43 AM, Tim Draegen t...@eudaemon.net wrote: DMARC implementations are already in the wild and deployed. Input to the existing specification will be largely based on working implementations. You might have your own reasons for waiting for this WG to review the DMARC base draft, but if you want to provide input based on operational implementation experience, it's probably best to not wait. Indeed, -12 represents what's been deployed, and that was always the intent of this ISE submission. One could thus conclude that it is solid enough for everyone that has already deployed it, and that's not exactly a small or obscure list. Still, as has been said before: If there's more work to be done on this document, the working group is chartered to generate a Standards Track version using this document as a starting point once its other deliverables have been completed. We can record issues we'd like to see addressed in the tracker if there are some, and, if and when the WG gets there, we'll be off to the races. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] [dmarc] #5 (): Definition of pct parameter
#5: Definition of pct parameter Message-ID: 54ab056c.2090...@bluepopcorn.net Date: Mon, 05 Jan 2015 13:43:08 -0800 From: Jim Fenton fen...@bluepopcorn.net To: dmarc@ietf.org dmarc@ietf.org Subject: [dmarc-ietf] Comments on dmarc-base-09 [...] Section 5.3, definition of pct: parameter: However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered. This is strong normative language, but there is no procedure specified anywhere for how to identify a DMARC-generated report in order to apply this requirement. Consider the possibility that bad actors may try to craft messages to look like DMARC reports. [...] -- -+- Reporter:| Owner: superu...@gmail.com| Status: new Type: defect| Milestone: Deliverable #3 (changes to DMARC Priority: major | base spec + DMARC Usage Guide Version:| Severity: - Keywords:| -+- Ticket URL: http://trac.tools.ietf.org/wg/dmarc/trac/ticket/5 dmarc http://tools.ietf.org/dmarc/ ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] [dmarc] #2 (): Flow of operations text in dmarc-base
#2: Flow of operations text in dmarc-base To: dmarc@ietf.org From: Anne Bennett a...@encs.concordia.ca Date: Fri, 16 Jan 2015 19:26:41 -0500 Subject: [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.) -- -+- Reporter:| Owner: superu...@gmail.com| Status: new Type: defect| Milestone: Deliverable #3 (changes to DMARC Priority: major | base spec + DMARC Usage Guide Version:| Severity: - Keywords:| -+- Ticket URL: http://trac.tools.ietf.org/wg/dmarc/trac/ticket/2 dmarc http://tools.ietf.org/dmarc/ ___ 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
On Jan 17, 2015, at 12:00 PM, Hector Santos hsan...@isdg.net wrote: I have two concerns. It seems you jumped the gun to accept the RFC 4408 obsolete idea. Is 7208 backward compatible or not? Does DMARC require 7208 operations or 4408 operations? And is this -12 publication worthy of even considering for implementation? Or should we wait for the more solid specification? Hi Hector, if you review: https://www.rfc-editor.org/rfc/rfc7208.txt ..you'll see at the very top Obsoletes: 4408. If there are discrepancies between 4408 and 7208, it's best to file an errata (erratum?): http://www.rfc-editor.org/how_to_report.html DMARC implementations are already in the wild and deployed. Input to the existing specification will be largely based on working implementations. You might have your own reasons for waiting for this WG to review the DMARC base draft, but if you want to provide input based on operational implementation experience, it's probably best to not wait. =- Tim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
