Subject: Re: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Dec 2013 00:26:09 -0800

On Wed, Oct 2, 2013 at 3:54 PM, Jim Fenton <[email-masked]> wrote:

> I have not been monitoring this mailing list, but a couple of people
> have asked me to have a look at the DMARC spec.  I apologize for the
> amount of time it has taken for me to get to this.
>
>
Thanks for the review, Jim.  Sorry it's taken so long for me to get all the
way through this.

> I'll leave out the editorial issues, but I'm happy to share those (in
> particular, with the editors) if there is interest.  I'll start with a
> lot of specific comments; there are a few additional comments at the
> very end.
>

Happy to have your editorial comments off-list if you like.

>
> ===
>
> 1. Introduction
>
> Paragraph 3:  I'm surprised to see the use of the word "policy". In the
> context of ADSP (originally Sender Signing Policy), the word "policy"
> was considered inaccurate because it was deemed inappropriate to dictate
> policy to a Receiving Domain. Even though SSP was describing the
> domain's policy with respect to signing messages with DKIM, the word
> "practices" was substituted. Is it now considered acceptable to make
> policy requests of a Receiving Domain?
>

I don't think this has come up during the development of DMARC.  In
contrast, I think the use of "policy" in the SPF context has become widely
understood to indicate it's a request from the author domain.  I do think
it's pretty clear from the document that there are no illusions that
something's being demanded of the receiver.

In the case of SSP and ADSP, I think we were trying to describe the signing
practices of the author domain, so the receiver could make an intelligent
judgement about accepting or rejecting the message.  In DMARC, the
practices are implied by the nature of the protocol except for what
alignment of identifiers a receiver should expect.

> Paragraph 4 #1: "assertions about senders' practices" : shouldn't that
> be Domain Owners' practices, since the sender might include spoofers?
>

Yes, though we haven't introduced that term yet.  I'll change it to the
lowercase form.

>
> Paragraph 3 #1: "Senders make policy assertions" -> "Domain owners
> publish policy assertions". But see comment below about "domain owners",
> and note that DMARC records contain considerably more than policy
> assertions.
>

OK.

>
> Paragraph 3 #2-1: "The receiver" might be interpreted as being an MUA.
> Suggest "Receiving domains". "how the mail is handled" -> "how they
> should handle the mail"
>

The outer bullet refers to SMTP Receivers, which I don't believe includes
MUAs.

OK on the second one.

>
> Last bullet: I immediately went to the case of the From: header field
> with multiple addresses, which had been a significant issue with ADSP.
> More about this later.
>
> 2.1 High-Level Goals
>
> First bullet: senders -> Domain Owners. Similar comment on the word
> "receivers".
>

OK.

>
> Third bullet: "effect on legitimate messages" isn't clear on what the
> "effect" is. Deliverability impact?
>

Will fix.

>
> 2.4 Out of Scope
>
> This section is full of double negatives, e.g., "not in scope for this
> work include: DMARC shall not be required..."
>

Will fix.

>
> Authentication of individuals rather than domains: DMARC doesn't perform
> authentication at all, it acts on the result of two other mechanisms.
> This muddies that point.
>

I'm not sure it's important to dive into this; we're saying this is a topic
we don't want to handle either way.

>
> 3. Terminology and Definitions
>
> The main part of this section is indeed terminology and definitions, but
> the subsections, particularly 3.2, aren't.  This should be reorganized.
>

OK.

>
> Domain Owner: This definition clearly defines the Domain Owner as the
> registrant of a domain. But as we will see much later, DMARC records are
> sometimes published by From domains directly, which could be a person or
> organization delegated by the Domain Owner. Perhaps another term is
> needed, because there are some things that are available only to Domain
> Owners and others that are also available to those able to publish a DNS
> record for a subdomain.
>

The definition does include more complex arrangements than merely the
registering entity.

>
> Organizational Domain: I have many problems with this:
>
> (1) An algorithm like this doesn't belong in the definitions.
>

Fixed.

> (2) This creates a dependency on a public suffix list such as that
> published by Mozilla, but doesn't require the use of a particular list.
> This would create an inconsistency in the result of DMARC that I
> consider to be an interoperability problem.
>

Yes.  We acknowledge that public suffix is far from an ideal solution, but
until some of the ideas being discussed in APPSAWG and elsewhere become a
reality, it's the only operational option.  Your point is taken, though,
that lots of sources for this information is a problem.  I'll add a note
about it.

> (3) During the development of ADSP, it was made clear to me by the DNS
> folks that there is no way, in practice, to determine an Organizational
> Domain.
>

Right; see my comment above about APPSAWG work.

> (4) The last paragraph acknowledges that it is a heuristic, and its use
> of "currently" implies that something better is in the works (which
> needs to be described instead in the spec).
>

It will be once there's a document to which to refer.

>
> 3.2 Overview
>
> Paragraph 1: "Mail sent for such a domain" -> "Mail sent from such a
> domain" (important distinction!)
>

Fixed.

>
> Paragraph 2: Feedback is to the Domain Owner, not the claimed sender.
>

OK.

>
> Paragraph 4: "from the Domain Owner" -> "from the Organizational Domain"
>

OK.

>
> [aside: I see, much later in the spec, that DMARC records can be
> published by the From domain directly, not just from the Domain Owner. A
> lot of earlier text needs to be cleaned up to accommodate that.]
>

Are those not the same?  Or are you talking about the subdomain case?

>
> 3.3 Flow Diagram
>
> "The above diagram shows the flow of messages": But there are lots
> more.  Spoofed messages have a different flow. So do mailing lists,
> domains with multiple layers of MTAs, etc. This is just the simplest
> flow of legitimate messages.
>

I'll label it as a simple or typical example.

>
> Item 6: "author's DNS data".  For SPF and DKIM, what's queried is not
> necessarily the author domain.
>

It is if the identifiers are aligned.  I'll make that more claer.

>
> Item 7: "queries to the author domain": Organizational Domain? (with the
> above aside as a caveat)
>

OK.

>
> 3.4 Identifier Alignment
>
> It would be good to start with a definition of what identifier alignment
> is, and I'm not finding that (perhaps it is buried there somewhere).
>

It's earlier in Section 3.

>
> Paragraph 2 end: "most MUAs represent..." introduces a UI issue, and we
> have considered that out-of-bounds in the past.
>

In DKIM, we require From: to be signed because it's the one guaranteed to
be visible and most likely to impact user understanding of the origin of
the message.  DMARC takes advantage of that same assumption.  But yes, this
is something that could be debated.

>
> Paragraph 4: identity alignment -> identifier alignment
>

Fixed.

>
> This section should discuss the rare-but-legal case of From: header
> fields with multiple addresses.
>

This is covered in Section 10.1.

>
> 3.4.1 DKIM-authenticated identifiers
>
> I got confused here right away by the use of "strict" and "relaxed"
> modes without proper introduction to what they are, since those terms
> are used in DKIM (as canonicalization modes) and mean something very
> different here. It was only when I got to the SPF section and it was
> still talking about strict and relaxed that I realized those terms were
> being used in DMARC as well.
>

DKIM defines "simple", not "strict".  Either way, I'll add a note about the
recycling of the name.

>
> Paragraph 2: must be equal -> must be equal in order to be considered to
> be in alignment
>

Fixed.

>
> Last paragraph: "DMARC pass" hasn't been defined anywhere.  Does DMARC
> produce a pass/fail result?
>

Yes.  I'll mention this earlier.

>
> 3.4.1 and 3.4.2
>
> I'm unclear on the motivation for having both strict and relaxed modes.
> Is it because we don't know what will work in practice, or because
> different sorts of domains will want to choose differently. If the
> latter, please give some guidance for which mode should be used in which
> situation.
>

OK.

>
> 4. Policy
>
> Paragraph 2: sending domains -> Organizational Domains (with above caveat)
>

Changed to "its domains".

>
> Paragraph 4: It's possible to determine non-use of SPF, but not DKIM, in
> this way.
>

The DKIM equivalent is to not sign the message.  What you're trying to
avoid is false positives here.

>
> 5. DMARC Policy Record
>
> Paragraph 2: "matches perfectly with the DNS".  Not at all -- the fact
> that it isn't possible to deterministically determine the organizational
> domain, is an example of the mismatch.  Also, operational limits on DNS
> record sizes prompts the use of non obvious syntax like the !<size>
> construct.
>

I think we're talking here about why we store the record in the DNS, like
SPF and DKIM and various others have done.  We're not saying here that we
espouse ways of determining things like the zone cut from DNS data.

>
> 5.2 General Record Format
>
> Paragraph 2: Last sentence is less about DMARC than about change control
> for the spec itself.
>

Fixed.

>
> adkim tag: Definition unnecessarily limits alignment modes to "s" and
> "anything else". Suggest that it require "s" or "r", with other values
> reserved for future use.
>

Fixed, by just deferring to the ABNF.

>
> fo: The tag value can contain both 0 and 1; what happens then?
>

The union of the two means "0" is a no-op in that case.

>
> d: Not sure why it's interesting to find about broken signatures when
> there's a good signature that meets alignment requirements.
>

Operators do appear to want this information, probably to aid in debugging.

>
> p: quarantine: What does "fails the DMARC mechanism" mean overall? Is
> this defined somewhere?  "suspicious": After all the controversy about
> the use of the use of the word suspicious in SSP/ADSP, I'm highly amused
> to see it here.
>

I've added "failed" earlier in the document to indicate that DMARC produces
a result, so hopefully that's clarified here.

SSP/ADSP tried to define Suspicious as a result, as I recall, or at least
explain what it meant.  We say clearly here that we have no idea by what
criteria a receiver will normally categorize something as suspicious (or
whatever word it uses), but the intent here is to give the receiver
information in that direction.

> pct: DNS domain isn't defined. DMARC mechanism is to be applied -> DMARC
> policy is to be applied
>

"DNS domain" is a term of art that was acceptable in the past during IESG
reviews when use of "domain" was ambiguous.  That's why it's started
appearing here.

Fixed.

>
> rf: This is comma-separated, while other tag values are colon-separated.
> Why the inconsistency?
>

Fixed.

> Initial default values are -> Possible values are (and possibly
> reference a registry)
>

We didn't make a registry for this because there's really only one in use
in this space, and no new ones are anticipated.

> [IODEF] is listed as an Informative Reference; shouldn't it be normative
> like [AFRF]?
>

True.  Fixed.

>
> ri: It seems like everything is best-effort; the Receiving Domain is
> doing a favor here (and sendto: is itself best effort).
>

Right.  This is explicitly described as a request.

>
> sp: Does this apply to subdomains at all levels, or just direct
> subdomains? What's the motivation for specifying a different policy for
> subdomains vs. the organizational domain?  Should also point out that sp
> is meaningful only for DMARC records published in Organizational Domains
> and not From domains, (although  publishing in From domains isn't
> introduced until later in the document).
>

It applies to all subdomains.  I'll make it say so.

The motivation here is the same as it was for ADSP; if I protect
bluepopcorn.net only, the spoofers could send mail with believable
subdomains of that domain without receivers taking any DMARC-specific
action.

I'm not clear on the case you're talking about; in the DMARC context, when
is the OD different from the From domain?

>
> 6. Policy Enforcement Considerations
>
> Paragraph 2: "...not to increase the likelihood of accepting abusive
> mail..." This seems like a qualitative requirement, not sure it belongs
> here.
>

This is a "Considerations" section.  It's just discussion, nothing
normative.

>
> 7.1 Verifying External Destinations
>
> Paragraph 3: SHOULD -- shouldn't that be a MUST?
>

We describe a few paragraphs down a reason why one would elect not to
implement that advice, so SHOULD is more appropriate here.

>
> Item 8: If rua and ruf can be overridden by the report receiver,
> wouldn't it be useful to be able to override at least ri and perhaps
> other values as well?
>

Possibly.  I'll let the rest of the community weigh in on that point.  What
other values might be worth allowing for an override?

>
> Third to last paragraph: "*._report._dmarc.example.com" looks rather
> scary -- mechanisms that depend on DNS wildcarding are always fragile.
> This may very well work, but it looks to me like this record actually
> says that example.com is willing to receive reports for ANY domain, not
> just child domains.
>

Right, that was actually the intent.  The prose has already been updated.

>
> 7.2 Aggregate reports
>
> The format for these reports is critical to interoperability -- should
> it really be specified in an appendix?  It's more important to specify
> the format of the reports than the requirements shown in the bulleted list.
>

The XML definition is quite large.  We found this arrangement -- no huge
gap in the text -- to be more palatable.

>
> 7.3 Failure reports
>
> Paragraph 1 reads as though AFRF is the only reporting format, but needs
> to accommodate IODEF and any future-defined reporting formats as well.
> For extensibility, there should also be a way for the Mail Receiver to
> generate a meta-report saying that they don't support the requested
> report format.
>
>
I think we might consider just yanking IODEF out.  I can't think of a
single implementation to date.  Does anybody know of one?

7.3.1 Reporting Format Update
>
> Are there any updates to IODEF?
>

I don't think there have been any implementations, so presently there are
no updates.

>
> 7.4 Failure Reports
>
> Paragraph 2: "ruf" tag -> "rf" tag
>

Fixed.

>
> 8. Policy Discovery
>
> This is the first mention I have seen that DMARC records are published
> directly on From domains; up to this point it looked like DMARC was only
> published by a Domain Owner on an Administrative Domain.  This changes a
> lot -- like the fact that a delegate of the Domain Owner, and not the
> [administrative] Domain Owner him/herself, can set the policy for a
> domain. This might require a major change of terminology usage, or at
> least a change in the definition of Domain Owner, to fix.
>

I'm not sure where the confusion came in.  The only domain of interest to
DMARC is the From domain; it is from this that the rest of the work (most
importantly, identifier alignment) is derived.

Who would a delegate of the Domain Owner be?  From the perspective of a
receiver, such a delegation is not visible; the query goes the OD.

>
> Items 2 and 4: Effectively, this means that v=DMARC2 records are
> completely independent of v=DMARC1 records. There is no interoperability
> between versions. Is this what is intended?
>

This document defines v1.  v2 could define itself in such a way that it
accepts part or all of a v1 record, but a v1 record is incompatible with
one explicitly declared to be for v2.  This is precisely the same as
"v=DKIM1": If you're extending DKIM v1, you just declare new tags; once you
say v2, you're saying you don't want to keep the old meanings.

> "If the RFC5322.From domain does not exist...": This specifies an action
> that has nothing to do with DMARC. I don't know the history of this but
> it seems like if there was going to be some global "you SHOULD reject
> messages with a nonexistent From domain" action, it belongs someplace
> like RFC 5322, not here. See also comment under A.4.
>

I agree that RFC5322 doesn't establish this requirement.  We're saying that
a DMARC implementation needs to take this action as it, along with normal
DMARC operation, defeats spoof attempts.

> 9. Domain Owner Actions
>
> Paragraph 1: "set up an address to receive reports" -- could also
> delegate that externally
>

Sure.  Do we need to identify all the things a Domain Owner might do
external to itself?  That seems like it could become tedious; I think
that's already implicit.

>
> Paragraph 2: What does "protect those email addresses" mean?
>

Typical abuse prevention is what we have in mind there.

>
> Paragraph 3: What does this have to do with domain owner actions? If
> this is connected to the previous paragraph, note that there is no
> requirement that reports use SPF and/or DKIM authentication (although
> perhaps there should be).
>

The steps listed prior to that advise the reader to deploy authentication
technologies.  This gives references to those materials.

>
> Paragraph 4: Need some specific guidance on how URIs other than mailto:
> are to be used (although there is some discussion of this in section 11;
> maybe a forward reference is needed)
>

There's more being added about using http: reporting from John Levine.

>
> 10.1 Extract Author Domain
>
> Paragraph 3: "Such messages SHOULD be rejected." Again, this specifies
> an action on messages that has nothing to do with DMARC. In particular,
> bullet 2 and 4 describe messages that are legal according to RFC 5322,
> and if they're undesirable should have been addressed there.
>

DMARC-aware operators see those exceptional cases in vanishingly small
numbers.  That specific community appears to be of the consensus opinion
that they aren't worth the introduced complexity for exceptional handling.

> If the messages are rejected, should they be silently discarded or fully
> rejected (per section 15.4)?
>

The action isn't specified.  Their delivery simply needs to be prevented.

>
> 10.3 Messaging Sampling
>
> Much of this section applies generally to the application of policy and
> not specifically to sampling, so perhaps the section heading should be
> "Policy Application" or something like that.
>

I don't understand what you're saying here.  How is this not a message
sampling function?

>
> 11.1 Discovery
>
> Paragraph 1: Does not discuss DMARC policy records associated with
> Administrative Domains, only those associated with the From address
> (converse of everything before section 8).
>

Still not clear on the distinction being made here.

>
> Paragraph 2: Section 7.1 -> Section 8
>

Fixed.

>
> 11.2 Transport
>
> Paragraph 1: "secure transport mechanism" needs to be specified more
> completely. Does SMTP/TLS qualify? Is successful certificate
> verification required?
>

This states a general requirement.  The specific instances (e.g., in the
mail and web spaces) are given in subsequent sections.

>
> Paragraph 3: "Mail Receiver SHOULD send" -- section 11.2.4 (paragraph 1)
> says that an attempt MUST be made.
>

11.2.4 says SHOULD be generated, and if one is generated, it MUST be
attempted across the full URI set.

>
> 11.2.1 Email
>
> Paragraph 1: Is it equally acceptable to send via SMTP over SSL (port 465)?
>

Are there implementations of this?

>
> Filename extensions: Is the .gz format just a GZIPped XML file?  That
> isn't stated clearly, and if it is, why not make the extension .xml.gz?
>

That's fixed in the unpublished version.

>
> 11.2.2 HTTP
>
> Paragraph 2: "POST or PUT" -- which method is used? Must reporting URIs
> support both methods? Or is there a process for discovering which method
> is to be used?
>
> I'm not an expert in HTTP, but I have the feeling that this transport
> (and all transports except possibly mailto:) is underspecified. For
> example, what Content-Types MUST be supported? Are there any other HTTP
> headers that MUST be included?
>

There's a separate submission to fix this.

>
> 11.2.4 Error Reports
>
> Paragraph 1: Last sentence seems to say that mailto: URIs are preferred
> over other transports, which is the opposite of the last paragraph of
> section 9.
>

For error reports, that's correct.

>
> Why is the error report in a text/plain format rather than a text/xml
> format like the feedback reports themselves?
>

There's no encoded data in an error report.  The point is to bring operator
attention to the fact that there's a problem.

>
> "Note: A more rigorous syntax specification...will be added here" says
> this is still an experimental capability.
>

Correct.

>
> 12. Capacity Planning
>
> DNS: This understates the actual DNS load; there will be additional
> queries in connection with looking up and sending feedback and aggregate
> reports, additional queries associated with reporting addresses that are
> outside the current domain, and probably other things I haven't
> considered (like DNSSEC). A more thorough analysis is needed here.
>

I've added text about those cases, except DNSSEC which is an entire layer
that is important to but ultimately not within the DMARC layer.

>
> 13. Minimum Implementations
>
> Please provide separate minimum requirements for Domain Owners (or other
> publishers of DMARC records) and Mail Receivers. Bear in mind that
> Domain Owners, etc. may not themselves receive the reports.
>

Added as a TBD item.

>
> 14. Privacy Considerations
>
> One privacy consideration I don't see listed anywhere is forwarding
> privacy: Basic email provides good protection against message senders
> finding out the actual delivery address of forwarded mail. The reporting
> capabilities of DMARC make it trivially easy for a Domain Owner to
> discover the delivery address of a message delivered to a
> DMARC-compliant Receiving Domain.
>

Added.

>
> 14.2 Report Recipients
>
> It might be noted that the privacy consideration is not that different
> from a domain with an MX record that is handled by someone outside the
> domain.
>

Would that be a useful illustration outside of the prose that's already
there?

>
> 14.4 Secure Protocols
>
> Should there be a requirement that if the original message was sent with
> TLS, that feedback reports be sent securely?
>

Mentioned it.

>
> 15.1 Use of RFC5322.From
>
> Last paragraph: "This document prescribes no specific action, other
> than..."  Section 10.1 does indeed prescribe a specific action that
> SHOULD be taken.
>

Isn't that what this paragraph is saying?

> 15.3 DNS Load and Caching
>
> It would be good to see a more thorough analysis of DNS effects -- both
> the number of queries that DMARC adds and the possible use of DMARC
> records (large records, at well-known locations in DNS) for DNS
> amplification attacks.
>

OK.

>
> 15.5 Identifier Alignment Considerations
>
> Paragraph 1: Don't the concerns about SPF apply apply to DKIM key
> records too?
>

Yes; fixed.

>
> Paragraph 3: "cede" -> "delegate" (administrator doesn't actually lose
> control)
>

Fixed.

>
> 17. Security Considerations
>
> Check RFC 6376 Section 8.x for other attacks that might be documented
> here. In particular, attackers might publish intentionally malformed
> DMARC records in conjunction with domains they control and send mail
> from in an effort to make DMARC less useful or onerous in some way, in
> an effort to discourage its use.
>

OK.

>
>
> 17.2 DNS Security
>
> This should emphasize that both the publication of DNSSEC by Domain
> Owners and the use of DNSSEC-aware resolvers by Mail Receivers is
> needed.  See also RFC 6376 section 8.5.
>

OK.

>
> Appendix A. Technology Considerations
>
> These provide good insight into some of the design choices made in the
> development of DMARC. Is the intent to include this in the
> standards-track document, or is this just information to aid the
> evaluation process?
>

We weren't planning to remove them.

>
> A.4 Domain Existence Test
>
> This section indicates that there was operational experience that the
> error rate was too high. Given that experience, I am surprised that
> section 8 says that the receiver SHOULD reject the message.
>

That may be an oversight, i.e., we removed one but forgot to remove the
other.  What does the community think about this?

>
> A.5 Issues With ADSP In Operation
>
> This section reads like somewhat of a debate with ADSP, or as though
> DMARC is competing with ADSP. DMARC and ADSP have different goals, and
> different constraints (e.g., SPF is explicitly out of scope of ADSP) so
> the list of issues doesn't really make sense.
>

Right; the goal here is to highlight that the use cases were different, as
are the solution spaces.

>
> A.6 Organizational Domain Discovery Issues
>
> Paragraph 3: "Climbing the tree", explored extensively in the
> development of ADSP, can of course be constrained to a specific limited
> number of queries. But ultimately even a one-level climb was considered
> too much and was rejected. Nevertheless, DMARC does look for policy in
> two places (the From domain and the Organizational Domain).
>

Right, but not based directly on the DNS; I think that was the objection
with SSP/ADSP.

>
> The approach being used in DMARC was briefly considered in ADSP, but
> didn't even make it into a draft at the strong advice of the DNS
> Directorate that there is no way to reliably determine the delegation
> level in a domain name.
>

Right; as I said above, we don't intend to keep this method as soon as
something endorsed by the larger community is available.

>
> =====
>
> General Comments
>
> There is no discussion of the effect of the effect of DMARC on some very
> common situations, such as mailing lists and forwarding (except a couple
> of hints at heuristics in the XML Schema). If the deployment of DMARC
> has an effect on the delivery of messages sent through mailing lists,
> that's a serious problem. I'm not aware of a straightforward answer to
> that problem, other than to maintain a whitelist of mailing lists that
> themselves authenticate their messages, which would normally not align
> with the From addresses at all. This has been cited as a serious problem
> with ADSP, so one would not want to repeat that problem here.
>
>
RFC6377 tackled a lot of these points.  It's been pointed out on the list
that (a) DMARC has the same concerns as ADSP with respect to lists as it's
currently defined, and (b) this is something the DMARC community would like
to spend time and energy trying to solve.

But you're right, the document doesn't say anything about this yet, and
probably should.

-MSK

---

From: Jim Fenton <[email-masked]>
Date: Fri, 06 Dec 2013 15:22:25 -0800

A few reply responses inline.

> Happy to have your editorial comments off-list if you like.

I just need to find my marked-up copy of the spec, which is around here
somewhere...
> contrast, I think the use of "policy" in the SPF context has become
> widely understood to indicate it's a request from the author domain. 
> I do think it's pretty clear from the document that there are no
> illusions that something's being demanded of the receiver.
>
> In the case of SSP and ADSP, I think we were trying to describe the
> signing practices of the author domain, so the receiver could make an
> intelligent judgement about accepting or rejecting the message.  In
> DMARC, the practices are implied by the nature of the protocol except
> for what alignment of identifiers a receiver should expect.

I don't see the distinction between what SSP/ADSP and DMARC are trying
to do that might make one "practices" and the other "policy". If our
language has evolved, that's all right; I'm just pointing out the
earlier discussion, which happened at IETF 65:
http://tools.ietf.org/wg/dkim/minutes?item=minutes65.html
> The outer bullet refers to SMTP Receivers, which I don't believe
> includes MUAs.

OK, missed the context set by the outer bullet.
> I'm not sure it's important to dive into this; we're saying this is a
> topic we don't want to handle either way.

But when you say "rather than domains", it gives the impression that
DMARC authenticates at the domain level, which it doesn't do.

> The definition does include more complex arrangements than merely the

I'm still not getting how the more complex arrangements are covered.
Perhaps it's from the definition of ADMD (which I haven't read
recently).  If so, you might want to say that more directly; calling it
"analogous" is a little vague.
> Yes.  We acknowledge that public suffix is far from an ideal solution,
> but until some of the ideas being discussed in APPSAWG and elsewhere
> become a reality, it's the only operational option.  Your point is
> taken, though, that lots of sources for this information is a
> problem.  I'll add a note about it.

I'm still worried about this.
> Are those not the same?  Or are you talking about the subdomain case?

The subdomain case, yes.

> I think we're talking here about why we store the record in the DNS,
> like SPF and DKIM and various others have done.  We're not saying here
> that we espouse ways of determining things like the zone cut from DNS
> data.

I just think the statement "matches perfectly" is overdone.  If DNS had
slightly different capabilities DMARC would be easier, so I'd tone down
that statement.
> The union of the two means "0" is a no-op in that case.

They conflict, so you should either prohibit that case (my preference)
or define the behavior.
> I've added "failed" earlier in the document to indicate that DMARC
> produces a result, so hopefully that's clarified here.
>
> SSP/ADSP tried to define Suspicious as a result, as I recall, or at
> least explain what it meant.  We say clearly here that we have no idea
> by what criteria a receiver will normally categorize something as
> suspicious (or whatever word it uses), but the intent here is to give
> the receiver information in that direction.

Like I said, I was mostly amused to find the word "suspicious". Perhaps
people are more comfortable with it now than when we tried to use it for
SSP/ADSP.
> We didn't make a registry for this because there's really only one in
> use in this space, and no new ones are anticipated.

Two: iodef and afrf, right?
> bluepopcorn.net <http://bluepopcorn.net> only, the spoofers could send
> mail with believable subdomains of that domain without receivers
> taking any DMARC-specific action.

Agreed that you want to cover all subdomains. I'm just not clear on
whether the term "subdomain" includes all "sub-subdomains", etc.  It
might not be clear to other readers of the spec either.
>
> I'm not clear on the case you're talking about; in the DMARC context,
> when is the OD different from the From domain?

Section 8, Policy Discovery, item 1 talks of looking for a DMARC record
at the From domain.  Since it's always looking at the exact domain in
the From address, the sp tag has no effect for this lookup. So sp only
makes sense for DMARC records published at ODs, not for other DMARC
records. It might be a good idea to point that out, lest someone think
that an SP on a DMARC record published at foo.example.com would apply to
bar.foo.example.com.

> implement that advice, so SHOULD is more appropriate here.

Ah. OK.
> The XML definition is quite large.  We found this arrangement -- no
> huge gap in the text -- to be more palatable.

More of a question for the standards-format people: you don't want it to
seem non-normative.  Or should something like this be in a separate
spec?  This one IS getting big...
> I'm not sure where the confusion came in.  The only domain of interest
> to DMARC is the From domain; it is from this that the rest of the work
> (most importantly, identifier alignment) is derived.
>
> Who would a delegate of the Domain Owner be?  From the perspective of
> a receiver, such a delegation is not visible; the query goes the OD.

This goes back to my earlier confusion about the definition of Domain
Owner. I had interpreted it more narrowly as the registrant of the
domain. When you say, "From the perspective of a receiver, such a
delegation is not visible", what about the case where the receiver gets
a message with 5322.From = <[email-masked]>, and looks up and
finds a DMARC record at foo.example.com?  That would be visible, because
the OD is example.com.

But the bigger issue for me was that I came this far in understanding
DMARC and only now find that it's possible to publish a DMARC record on
the actual From domain, and not just on the OD.  That should be
introduced much earlier.
> This document defines v1.  v2 could define itself in such a way that
> it accepts part or all of a v1 record, but a v1 record is incompatible
> with one explicitly declared to be for v2.  This is precisely the same
> as "v=DKIM1": If you're extending DKIM v1, you just declare new tags;
> once you say v2, you're saying you don't want to keep the old meanings.

OK.  I'm not sure we thoroughly thought out the interoperability issues
with version tags in DKIM, and was hoping we might be able to do so
here. I wonder how useful these tags are...if there's ever a DMARC v2,
would it be a better idea to publish the records under _dmarc2 ?
> I agree that RFC5322 doesn't establish this requirement.  We're saying
> that a DMARC implementation needs to take this action as it, along
> with normal DMARC operation, defeats spoof attempts.

Although this is an exceedingly rare usage, I still wonder whether this
(and not 5322) is an appropriate place to place additional restrictions
on otherwise-legal mail.

In the event that the message is rejected during an SMTP transaction,
should there be an error code specified for this?
> external to itself?  That seems like it could become tedious; I think

But the external delegation requires some specific actions of its own to
make sure that the reporting domain is authorized.
> numbers.  That specific community appears to be of the consensus
> opinion that they aren't worth the introduced complexity for
> exceptional handling.
>  
>

Shouldn't there be at least recommended action?
> I don't understand what you're saying here.  How is this not a message

The main focus of the section is the application of policy. Sampling is
a part of that, of course, but seems like a subtopic.
> Still not clear on the distinction being made here.

It talks about finding the DMARC policy record at the 5322.From domain,
but not at the OD domain.
> Are there implementations of this?

Good question. I think I ran across it in my /etc/services file.
> Right, but not based directly on the DNS; I think that was the
> objection with SSP/ADSP.

I'm not sure what you mean by "not based directly on the DNS".
> something endorsed by the larger community is available.

Is there an initiative by the larger community that is addressing this?

===
But I see that there's a -02 version now.  More to read...

-Jim

---

From: Franck Martin <[email-masked]>
Date: Fri, 6 Dec 2013 18:36:27 -0600 (CST)

----- Original Message -----

> From: "Jim Fenton" <[email-masked]>
> To: "Murray S. Kucherawy" <[email-masked]>
> Cc: [email-masked]
> Sent: Friday, December 6, 2013 3:22:25 PM
> Subject: Re: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01

> > a
> > DMARC implementation needs to take this action as it, along with normal

> Although this is an exceedingly rare usage, I still wonder whether this (and
> not 5322) is an appropriate place to place additional restrictions on
> otherwise-legal mail.

> In the event that the message is rejected during an SMTP transaction, should
> there be an error code specified for this?

There may be a BCP to discuss a bit more about it. Also I think we need to stress more these cases in security considerations or inline. 

However, RFC5322 section 3.6 says there must be one and only one From: header for the message to be "valid". So we can point to this rule and say something like with DMARC you should enforce that, and not be lenient ( http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-11 section 1.1 second paragraph) 

Moreover RFC5322 says: 
from            =   "From:" mailbox-list CRLF 
So there must be at least one domain name in this Field. Once again, you can be less lenient here. Not DMARC role, here, but you can point back to this RFC and say stop to be lenient. 

However, IEA RFC 6854, states, that 
from = "From:" (mailbox-list / address-list) CRLF 
is ok between non IEA aware MTAs (section 3). I did not like the change of the From: header because it increases uncertainty in emails. Fortunately it is limited in scope, so once you have an MTA that can do IEA, you can enforce the mailbox-list again . 
Now closer to your point, I don't think any RFC states that the domain name found in the From: must exists or even be mildly "emailable", this is a "common" check you may do for the envelope from (cf http://spamassassin.apache.org/tests_3_3_x.html NO_DNS_FOR_FROM ). It is not common for the From: header but this is something DMARC could point out as something worth considering. 

Finally, you can't imagine what you find in bounces... All the badness , breakages are there... (or nearly).