[dmarc-ietf] [dmarc] #6 (): Fuzzy normative language around filenames

2015-01-19 Thread dmarc issue tracker 
#6: Fuzzy normative language around filenames

 Message-ID: <54ab056c.2090...@bluepopcorn.net>
 Date: Mon, 05 Jan 2015 13:43:08 -0800
 From: Jim Fenton 
 To: "dmarc@ietf.org" 
 Subject: [dmarc-ietf] Comments on dmarc-base-09

 [...]
 Section 6.2.1.1, "The filename is typically constructed..." Again, this
 is fuzzy normative language; it sounds like it's trying to say, "The
 filename MAY be constructed..."
 [...]

-- 
-+-
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: 
dmarc 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] [dmarc] #5 (): Definition of "pct" parameter

2015-01-19 Thread dmarc issue tracker 
#5: Definition of "pct" parameter

 Message-ID: <54ab056c.2090...@bluepopcorn.net>
 Date: Mon, 05 Jan 2015 13:43:08 -0800
 From: Jim Fenton 
 To: "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: 
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

2015-01-19 Thread dmarc issue tracker 
#2: Flow of operations text in dmarc-base

 To: dmarc@ietf.org
 From: Anne Bennett 
 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: 
dmarc 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] [dmarc] #4 (): Definition of "fo" parameter

2015-01-19 Thread dmarc issue tracker 
#4: Definition of "fo" parameter

 Message-ID: <54ab056c.2090...@bluepopcorn.net>
 Date: Mon, 05 Jan 2015 13:43:08 -0800
 From: Jim Fenton 
 To: "dmarc@ietf.org" 
 Subject: [dmarc-ietf] Comments on dmarc-base-09

 [...]
 Section 5.3, definition of fo: parameter: I had reported that there
 isn't any prohibition on specifying both 0 and 1, and I thought someone
 said that was fixed but I can't find it. More generally, I struggle to
 find any real utility for a colon-separated list of options here.
 [...]

-- 
-+-
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: 
dmarc 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] [dmarc] #3 (): Two tiny nits

2015-01-19 Thread dmarc issue tracker 
#3: Two tiny nits

 To: dmarc@ietf.org
 From: Anne Bennett 
 Date: Fri, 16 Jan 2015 19:41:29 -0500
 Subject: [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.

-- 
-+-
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: 
dmarc 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] [dmarc] #1 (): SPF RFC 4408 vs 7208

2015-01-19 Thread dmarc issue tracker 
#1: SPF RFC 4408 vs 7208

 To: dmarc@ietf.org
 From: Anne Bennett 
 Date: Fri, 16 Jan 2015 19:10:56 -0500
 Subject: [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.

-- 
-+-
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: 
dmarc 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc