From franck@peachymango.org Mon Nov 4 09:37:22 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A9021E81F3 for ; Mon, 4 Nov 2013 09:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6XvsXjyVpSg for ; Mon, 4 Nov 2013 09:37:14 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32D21E8214 for ; Mon, 4 Nov 2013 09:34:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 28DB5294051; Mon, 4 Nov 2013 11:34:33 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8yDx7o-2-cK; Mon, 4 Nov 2013 11:34:33 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0956E294128; Mon, 4 Nov 2013 11:34:33 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E7009294123; Mon, 4 Nov 2013 11:34:32 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OlFFpCvctFkY; Mon, 4 Nov 2013 11:34:32 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id B2746294051; Mon, 4 Nov 2013 11:34:32 -0600 (CST) Date: Mon, 4 Nov 2013 11:34:31 -0600 (CST) From: Franck Martin To: Jim Fenton Message-ID: <142331330.25170.1383586471653.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <524CA422.8030008@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF24 (Mac)/8.0.4_GA_5737) Thread-Topic: External review of draft-kucherawy-dmarc-base-01 Thread-Index: 5qoeoCvDbs3Xc89zGJUaUKu0L7n7dg== Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:37:23 -0000 Let me respond to some... I feel a lot is editorial issues that Murray will certainly fix to make the spec clearer. ----- Original Message ----- > From: "Jim Fenton" > To: dmarc@ietf.org > Sent: Wednesday, October 2, 2013 3:54:26 PM > Subject: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01 > > 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. > > 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. > > === > > 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 guess yes, because the receiver is willing to mainly do as told.... > > Paragraph 4 #1: "assertions about senders' practices" : shouldn't that > be Domain Owners' practices, since the sender might include spoofers? > > 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. > > 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" > > 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". > > Third bullet: "effect on legitimate messages" isn't clear on what the > "effect" is. Deliverability impact? > > 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..." > > 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. > > 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. > > 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. I feel a subdomain owner is still a domain owner > > Organizational Domain: I have many problems with this: > > (1) An algorithm like this doesn't belong in the definitions. > (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. > (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. > (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). > > 3.2 Overview > > Paragraph 1: "Mail sent for such a domain" -> "Mail sent from such a > domain" (important distinction!) > > Paragraph 2: Feedback is to the Domain Owner, not the claimed sender. > > Paragraph 4: "from the Domain Owner" -> "from the Organizational Domain" > > [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.] > > 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. > > Item 6: "author's DNS data". For SPF and DKIM, what's queried is not > necessarily the author domain. > > Item 7: "queries to the author domain": Organizational Domain? (with the > above aside as a caveat) > > 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). > > Paragraph 2 end: "most MUAs represent..." introduces a UI issue, and we > have considered that out-of-bounds in the past. Yes, but you should not ignore the reality of what most MUA's present to the end user. > > Paragraph 4: identity alignment -> identifier alignment > > This section should discuss the rare-but-legal case of From: header > fields with multiple addresses. > > 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. > > Paragraph 2: must be equal -> must be equal in order to be considered to > be in alignment > > Last paragraph: "DMARC pass" hasn't been defined anywhere. Does DMARC > produce a pass/fail result? > > 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. The financial industry indicated they wanted a strict method, tho I still have to see an example in the wild. > > 4. Policy > > Paragraph 2: sending domains -> Organizational Domains (with above caveat) > > Paragraph 4: It's possible to determine non-use of SPF, but not DKIM, in > this way. > > 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 ! > construct. > > 5.2 General Record Format > > Paragraph 2: Last sentence is less about DMARC than about change control > for the spec itself. > > 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. > > fo: The tag value can contain both 0 and 1; what happens then? > > d: Not sure why it's interesting to find about broken signatures when > there's a good signature that meets alignment requirements. dkim is hard to diagnose, and any information is useful > > 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. > > pct: DNS domain isn't defined. DMARC mechanism is to be applied -> DMARC > policy is to be applied > > rf: This is comma-separated, while other tag values are colon-separated. > Why the inconsistency? > Initial default values are -> Possible values are (and possibly > reference a registry) > [IODEF] is listed as an Informative Reference; shouldn't it be normative > like [AFRF]? > > ri: It seems like everything is best-effort; the Receiving Domain is > doing a favor here (and sendto: is itself best effort). > > 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). > > 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. > > 7.1 Verifying External Destinations > > Paragraph 3: SHOULD -- shouldn't that be a MUST? > > 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? > > 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. yes it is needed for third party processors which may not know what they "customers" will throw at them. However they should know what they are doing when they wildcard. > > 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. > > 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. > > 7.3.1 Reporting Format Update > > Are there any updates to IODEF? > > 7.4 Failure Reports > > Paragraph 2: "ruf" tag -> "rf" tag > > 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. > > 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? > > "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. this is specified in another RFC but MTA have been accepting malformed emails, it is a reminder that malformed emails should not be accepted for DMARC to work. > > 9. Domain Owner Actions > > Paragraph 1: "set up an address to receive reports" -- could also > delegate that externally > > Paragraph 2: What does "protect those email addresses" mean? > > 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). > > 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) > > 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. > > If the messages are rejected, should they be silently discarded or fully > rejected (per section 15.4)? > > 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. > > 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). > > Paragraph 2: Section 7.1 -> Section 8 > > 11.2 Transport > > Paragraph 1: "secure transport mechanism" needs to be specified more > completely. Does SMTP/TLS qualify? Is successful certificate > verification required? > > Paragraph 3: "Mail Receiver SHOULD send" -- section 11.2.4 (paragraph 1) > says that an attempt MUST be made. > > "MAY discard" -- 11.2.4 calls for error reports > > 11.2.1 Email > > Paragraph 1: Is it equally acceptable to send via SMTP over SSL (port 465)? > > 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? > > 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? > > 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. > > Why is the error report in a text/plain format rather than a text/xml > format like the feedback reports themselves? > > "Note: A more rigorous syntax specification...will be added here" says > this is still an experimental capability. > > 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. > > 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. > > 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. > > 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. > > 14.4 Secure Protocols > > Should there be a requirement that if the original message was sent with > TLS, that feedback reports be sent securely? We should avoid to link too many things together... > > 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. > > 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. > > 15.5 Identifier Alignment Considerations > > Paragraph 1: Don't the concerns about SPF apply apply to DKIM key > records too? > > Paragraph 3: "cede" -> "delegate" (administrator doesn't actually lose > control) > > 16. IANA Considerations > > I didn't review this section. > > 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. > > > 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. > > 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? > > A.3 Sender Header Field > > Item 3: Note that there are already multiple ways to discover policy > (From Domain and Owner Domain), but yes, this would add to the complexity. > > 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. > > Note that while [ADSP] does discuss checks for domain existence, it is > in connection with determining the ADSP result, not with rejection of > the message. > > 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. > > 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). > > 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. > > B. Examples > > It looks like these examples are attempting to define the syntax of > aspects of DMARC, rather than to be illustrative of things that are > defined normatively elsewhere. I have not otherwise reviewed this section > > C. DMARC XML Schema > > Not reviewed. > > ===== > > 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. > I think we will be working on that in the BCP. I'm not sure it has to be in the spec. From superuser@gmail.com Tue Nov 5 14:34:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A27211E80E3 for ; Tue, 5 Nov 2013 14:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKoCy0jYyxEu for ; Tue, 5 Nov 2013 14:33:56 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94711E81EB for ; Tue, 5 Nov 2013 14:33:51 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so4082198wes.23 for ; Tue, 05 Nov 2013 14:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gqn7MY1JC/YCEdQVxx8v/SGHIMg/CVovsunQ5GRrfhU=; b=rIUTKQMA7u1jfw5Zue7nMGwa0gbVPmsUl1FPrLkiHU4fAzUvanIskfTpxxpTzeaHd1 s+7FByh1/BPwTIm1jEe3YZlBcJEd6qB/yPmbaiK1qhzfCRejRm8kM4CEYUwkHoOIWmyJ +Hcutpf0XVYLh0kXR9usTvVvn1IbtA63uvtwjyWS7wPhtr/HIlnZHEL+OzuHEnnbsFn4 WDCyEaOoyRxNNdIrsr8N3UJn/9fXwLHs4kOSntzT1YiwWF2rrrzwcfr/MK1xQ67vTus4 Dmceq032292Dd+6CoLLqGBNc5vE2Xc2vNud1FmvH+lnDkitU+Dvh2XFkg4RUZMubv94M dJlg== MIME-Version: 1.0 X-Received: by 10.194.3.78 with SMTP id a14mr18214wja.77.1383690831165; Tue, 05 Nov 2013 14:33:51 -0800 (PST) Received: by 10.180.18.202 with HTTP; Tue, 5 Nov 2013 14:33:51 -0800 (PST) In-Reply-To: <524CA422.8030008@bluepopcorn.net> References: <524CA422.8030008@bluepopcorn.net> Date: Tue, 5 Nov 2013 14:33:51 -0800 Message-ID: From: "Murray S. Kucherawy" To: Jim Fenton Content-Type: multipart/alternative; boundary=047d7b343d6a787f5f04ea75a03b Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:34:02 -0000 --047d7b343d6a787f5f04ea75a03b Content-Type: text/plain; charset=ISO-8859-1 Hi Jim, I do plan to reply to this as I work on the next revision. Apologies for the delays. I hope to get to this very soon. -MSK On Wed, Oct 2, 2013 at 3:54 PM, Jim Fenton 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. > > 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. > > === > > 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? > > Paragraph 4 #1: "assertions about senders' practices" : shouldn't that > be Domain Owners' practices, since the sender might include spoofers? > > 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. > > 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" > > 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". > > Third bullet: "effect on legitimate messages" isn't clear on what the > "effect" is. Deliverability impact? > > 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..." > > 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. > > 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. > > 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. > > Organizational Domain: I have many problems with this: > > (1) An algorithm like this doesn't belong in the definitions. > (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. > (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. > (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). > > 3.2 Overview > > Paragraph 1: "Mail sent for such a domain" -> "Mail sent from such a > domain" (important distinction!) > > Paragraph 2: Feedback is to the Domain Owner, not the claimed sender. > > Paragraph 4: "from the Domain Owner" -> "from the Organizational Domain" > > [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.] > > 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. > > Item 6: "author's DNS data". For SPF and DKIM, what's queried is not > necessarily the author domain. > > Item 7: "queries to the author domain": Organizational Domain? (with the > above aside as a caveat) > > 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). > > Paragraph 2 end: "most MUAs represent..." introduces a UI issue, and we > have considered that out-of-bounds in the past. > > Paragraph 4: identity alignment -> identifier alignment > > This section should discuss the rare-but-legal case of From: header > fields with multiple addresses. > > 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. > > Paragraph 2: must be equal -> must be equal in order to be considered to > be in alignment > > Last paragraph: "DMARC pass" hasn't been defined anywhere. Does DMARC > produce a pass/fail result? > > 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. > > 4. Policy > > Paragraph 2: sending domains -> Organizational Domains (with above caveat) > > Paragraph 4: It's possible to determine non-use of SPF, but not DKIM, in > this way. > > 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 ! > construct. > > 5.2 General Record Format > > Paragraph 2: Last sentence is less about DMARC than about change control > for the spec itself. > > 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. > > fo: The tag value can contain both 0 and 1; what happens then? > > d: Not sure why it's interesting to find about broken signatures when > there's a good signature that meets alignment requirements. > > 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. > > pct: DNS domain isn't defined. DMARC mechanism is to be applied -> DMARC > policy is to be applied > > rf: This is comma-separated, while other tag values are colon-separated. > Why the inconsistency? > Initial default values are -> Possible values are (and possibly > reference a registry) > [IODEF] is listed as an Informative Reference; shouldn't it be normative > like [AFRF]? > > ri: It seems like everything is best-effort; the Receiving Domain is > doing a favor here (and sendto: is itself best effort). > > 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). > > 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. > > 7.1 Verifying External Destinations > > Paragraph 3: SHOULD -- shouldn't that be a MUST? > > 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? > > 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. > > 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. > > 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. > > 7.3.1 Reporting Format Update > > Are there any updates to IODEF? > > 7.4 Failure Reports > > Paragraph 2: "ruf" tag -> "rf" tag > > 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. > > 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? > > "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. > > 9. Domain Owner Actions > > Paragraph 1: "set up an address to receive reports" -- could also > delegate that externally > > Paragraph 2: What does "protect those email addresses" mean? > > 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). > > 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) > > 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. > > If the messages are rejected, should they be silently discarded or fully > rejected (per section 15.4)? > > 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. > > 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). > > Paragraph 2: Section 7.1 -> Section 8 > > 11.2 Transport > > Paragraph 1: "secure transport mechanism" needs to be specified more > completely. Does SMTP/TLS qualify? Is successful certificate > verification required? > > Paragraph 3: "Mail Receiver SHOULD send" -- section 11.2.4 (paragraph 1) > says that an attempt MUST be made. > > "MAY discard" -- 11.2.4 calls for error reports > > 11.2.1 Email > > Paragraph 1: Is it equally acceptable to send via SMTP over SSL (port 465)? > > 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? > > 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? > > 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. > > Why is the error report in a text/plain format rather than a text/xml > format like the feedback reports themselves? > > "Note: A more rigorous syntax specification...will be added here" says > this is still an experimental capability. > > 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. > > 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. > > 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. > > 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. > > 14.4 Secure Protocols > > Should there be a requirement that if the original message was sent with > TLS, that feedback reports be sent securely? > > 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. > > 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. > > 15.5 Identifier Alignment Considerations > > Paragraph 1: Don't the concerns about SPF apply apply to DKIM key > records too? > > Paragraph 3: "cede" -> "delegate" (administrator doesn't actually lose > control) > > 16. IANA Considerations > > I didn't review this section. > > 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. > > > 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. > > 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? > > A.3 Sender Header Field > > Item 3: Note that there are already multiple ways to discover policy > (From Domain and Owner Domain), but yes, this would add to the complexity. > > 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. > > Note that while [ADSP] does discuss checks for domain existence, it is > in connection with determining the ADSP result, not with rejection of > the message. > > 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. > > 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). > > 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. > > B. Examples > > It looks like these examples are attempting to define the syntax of > aspects of DMARC, rather than to be illustrative of things that are > defined normatively elsewhere. I have not otherwise reviewed this section > > C. DMARC XML Schema > > Not reviewed. > > ===== > > 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. > > -Jim > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7b343d6a787f5f04ea75a03b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jim,

I do plan to reply to this as I work o= n the next revision.=A0 Apologies for the delays.=A0 I hope to get to this = very soon.

-MSK


On Wed, Oct 2, 2013 at 3:54 PM, Jim Fenton <fenton@bluepopcorn.net> 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. =A0I apologize for the
amount of time it has taken for me to get to this.

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

=3D=3D=3D

1. Introduction

Paragraph 3: =A0I'm surprised to see the use of the word "policy&q= uot;. In the
context of ADSP (originally Sender Signing Policy), the word "policy&q= uot;
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 m= ake
policy requests of a Receiving Domain?

Paragraph 4 #1: "assertions about senders' practices" : shoul= dn't that
be Domain Owners' practices, since the sender might include spoofers?
Paragraph 3 #1: "Senders make policy assertions" -> "Doma= in owners
publish policy assertions". But see comment below about "domain o= wners",
and note that DMARC records contain considerably more than policy
assertions.

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"

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".

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

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..."

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

3. Terminology and Definitions

The main part of this section is indeed terminology and definitions, but the subsections, particularly 3.2, aren't. =A0This should be reorganize= d.

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.

Organizational Domain: I have many problems with this:

(1) An algorithm like this doesn't belong in the definitions.
(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.
(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.
(4) The last paragraph acknowledges that it is a heuristic, and its use
of "currently" implies that something better is in the works (whi= ch
needs to be described instead in the spec).

3.2 Overview

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

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

Paragraph 4: "from the Domain Owner" -> "from the Organiz= ational Domain"

[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.]

3.3 Flow Diagram

"The above diagram shows the flow of messages": But there are lot= s
more. =A0Spoofed 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.

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

Item 7: "queries to the author domain": Organizational Domain? (w= ith the
above aside as a caveat)

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).
Paragraph 2 end: "most MUAs represent..." introduces a UI issue, = and we
have considered that out-of-bounds in the past.

Paragraph 4: identity alignment -> identifier alignment

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

3.4.1 DKIM-authenticated identifiers

I got confused here right away by the use of "strict" and "r= elaxed"
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.

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

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

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.

4. Policy

Paragraph 2: sending domains -> Organizational Domains (with above cavea= t)

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

5. DMARC Policy Record

Paragraph 2: "matches perfectly with the DNS". =A0Not at all -- t= he fact
that it isn't possible to deterministically determine the organizationa= l
domain, is an example of the mismatch. =A0Also, operational limits on DNS record sizes prompts the use of non obvious syntax like the !<size> construct.

5.2 General Record Format

Paragraph 2: Last sentence is less about DMARC than about change control for the spec itself.

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.

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

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

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

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

rf: This is comma-separated, while other tag values are colon-separated. Why the inconsistency?
Initial default values are -> Possible values are (and possibly
reference a registry)
[IODEF] is listed as an Informative Reference; shouldn't it be normativ= e
like [AFRF]?

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

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? =A0Should also point out that sp<= br> is meaningful only for DMARC records published in Organizational Domains and not From domains, (although =A0publishing in From domains isn't
introduced until later in the document).

6. Policy Enforcement Considerations

Paragraph 2: "...not to increase the likelihood of accepting abusive mail..." This seems like a qualitative requirement, not sure it belong= s
here.

7.1 Verifying External Destinations

Paragraph 3: SHOULD -- shouldn't that be a MUST?

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?

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.

7.2 Aggregate reports

The format for these reports is critical to interoperability -- should
it really be specified in an appendix? =A0It's more important to specif= y
the format of the reports than the requirements shown in the bulleted list.=

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.

7.3.1 Reporting Format Update

Are there any updates to IODEF?

7.4 Failure Reports

Paragraph 2: "ruf" tag -> "rf" tag

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. =A0This changes a<= br> 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.

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

"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<= br> messages with a nonexistent From domain" action, it belongs someplace<= br> like RFC 5322, not here. See also comment under A.4.

9. Domain Owner Actions

Paragraph 1: "set up an address to receive reports" -- could also=
delegate that externally

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

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).

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)

10.1 Extract Author Domain

Paragraph 3: "Such messages SHOULD be rejected." Again, this spec= ifies
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.

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

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.

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).

Paragraph 2: Section 7.1 -> Section 8

11.2 Transport

Paragraph 1: "secure transport mechanism" needs to be specified m= ore
completely. Does SMTP/TLS qualify? Is successful certificate
verification required?

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

"MAY discard" -- 11.2.4 calls for error reports

11.2.1 Email

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

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

11.2.2 HTTP

Paragraph 2: "POST or PUT" -- which method is used? Must reportin= g 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?

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.

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

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

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.

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.

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.

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.

14.4 Secure Protocols

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

15.1 Use of RFC5322.From

Last paragraph: "This document prescribes no specific action, other than..." =A0Section 10.1 does indeed prescribe a specific action that<= br> SHOULD be taken.

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.

15.5 Identifier Alignment Considerations

Paragraph 1: Don't the concerns about SPF apply apply to DKIM key
records too?

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

16. IANA Considerations

I didn't review this section.

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.


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. =A0See also RFC 6376 section 8.5.

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?

A.3 Sender Header Field

Item 3: Note that there are already multiple ways to discover policy
(From Domain and Owner Domain), but yes, this would add to the complexity.<= br>
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.

Note that while [ADSP] does discuss checks for domain existence, it is
in connection with determining the ADSP result, not with rejection of
the message.

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.

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).

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.

B. Examples

It looks like these examples are attempting to define the syntax of
aspects of DMARC, rather than to be illustrative of things that are
defined normatively elsewhere. =A0I have not otherwise reviewed this sectio= n

C. DMARC XML Schema

Not reviewed.

=3D=3D=3D=3D=3D

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.

-Jim


_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--047d7b343d6a787f5f04ea75a03b-- From superuser@gmail.com Sat Nov 30 22:33:41 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55F1AE0B4 for ; Sat, 30 Nov 2013 22:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqjzIe3UkxQp for ; Sat, 30 Nov 2013 22:33:39 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id D5A251AE329 for ; Sat, 30 Nov 2013 22:33:38 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w62so4949191wes.21 for ; Sat, 30 Nov 2013 22:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5DIxMJOxHBrdAAa/Bmb0ClqB/t+5PzWeqsA+ifHK+xI=; b=GyzVCDvHRgRj4R3xT50EiCoMtBRM84vKLQb+DUDdJmLj+JvvLPIKH9Idw5tzHMJ1FW T1G9++IA483xwe/TglUuMUiGmAVylY5Jgf5qvoRCQH+FzBeYvujKXoYpJ1ngKY+U/oR2 bK66vsmX6GzxqY1ZDeJbFKeHwGddJiA+ofkBoM+wTNRWJ6LUmd5w0guwbiEBddiXVu12 YXbB8BLs4Qn069qO5oE6RzAtvmksMHMYP/5RKYus3FizwNJnFNkmig1YOcituJeovIiM +c6ylrRlW/Lk8DhvtYsBbkGwb+wAZTRSPLekYW/LJd+LDzOCHXJNaLFicU6pkObllpiv u0pA== MIME-Version: 1.0 X-Received: by 10.180.182.136 with SMTP id ee8mr13216032wic.19.1385879616458; Sat, 30 Nov 2013 22:33:36 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sat, 30 Nov 2013 22:33:36 -0800 (PST) In-Reply-To: <20130809234600.Horde.BohsttCU7cC5wFyE1swI8w3@horde.andreasschulze.de> References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> <20130809234600.Horde.BohsttCU7cC5wFyE1swI8w3@horde.andreasschulze.de> Date: Sat, 30 Nov 2013 22:33:36 -0800 Message-ID: From: "Murray S. Kucherawy" To: Andreas Schulze Content-Type: multipart/alternative; boundary=089e016346b43d944c04ec733e85 Cc: "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 06:33:41 -0000 --089e016346b43d944c04ec733e85 Content-Type: text/plain; charset=ISO-8859-1 -02 of the base draft in progress. Regarding outstanding issues, I have some things to bring to the list, starting here: On Fri, Aug 9, 2013 at 2:46 PM, Andreas Schulze wrote: > If nobody implemented http reporting yet > we should consider removing it from the spec... > Any other opinions on this point? -MSK --089e016346b43d944c04ec733e85 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
-02 of the base draft in progress.=A0 Regarding outstandin= g issues, I have some things to bring to the list, starting here:
<= br>On Fri, Aug 9, 2013 at 2:46 PM, Andreas Schulze <sca@andreasschulze= .de> wrote:
If nobody implemented http reporting yet
we should consider removing it from the spec...

Any other opinions on this p= oint?

-MSK
--089e016346b43d944c04ec733e85-- From superuser@gmail.com Sat Nov 30 22:35:27 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6D71AE4B3 for ; Sat, 30 Nov 2013 22:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98BK0R5FQUJt for ; Sat, 30 Nov 2013 22:35:24 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 644DE1AE4E0 for ; Sat, 30 Nov 2013 22:35:24 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so3465112wib.3 for ; Sat, 30 Nov 2013 22:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PE+bN1Etoc3eMaX/rtXAg55SLx9E5ktL9DMAleg+cLA=; b=g8NLKNCI7WZB+G8crbff3Yoor95fUv2+iU7Qm95Smea1gMjq1P98cWQ4JZp570E6e3 /WVuCbN3F/D7fpvC6hs7LY7lR9y+CxkSYVZHtsXhTUYUbFYNU2/x6/s9pElpq3d05Idl /BWDKKXaN4nyvFZJZC+LivEPEi5p2R4xCNQXOTPbRSMQAHFiN24cFF8/X2y1n3Bi6MEZ WNOFN/huqnrFms3qkjBD6OLoidK8MGMXxZl+kTIbxHEm2HBADLdo9uiKVGHZp9vR9tk9 636qLVmRpHCbpuEd04TNFEpKsd0G2m14ho7DjdkMzZDr2oVlSa4nPbTKwDS5wob6r17u ruyg== MIME-Version: 1.0 X-Received: by 10.180.79.38 with SMTP id g6mr13322593wix.60.1385879722134; Sat, 30 Nov 2013 22:35:22 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sat, 30 Nov 2013 22:35:21 -0800 (PST) In-Reply-To: <520C4BE1.7070606@crash.com> References: <5131C5CB-5B7A-43F8-A87B-9C505D8E9001@tnpi.net> <77426B543150464AA3F30DF1A91365DE53CCBA16@ESV4-MBX01.linkedin.biz> <520C4BE1.7070606@crash.com> Date: Sat, 30 Nov 2013 22:35:21 -0800 Message-ID: From: "Murray S. Kucherawy" To: Steven M Jones Content-Type: multipart/alternative; boundary=f46d044287f68a138104ec7344bb Cc: "dmarc@ietf.org" , "dmarc-discuss@dmarc.org" Subject: Re: [dmarc-ietf] [dmarc-discuss] DMARC URI size allowance X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 06:35:27 -0000 --f46d044287f68a138104ec7344bb Content-Type: text/plain; charset=ISO-8859-1 I don't see any action items here in terms of changes to the base draft. Am I correct in that assessment? I'll assume yes; someone should speak up if otherwise. -MSK On Wed, Aug 14, 2013 at 8:32 PM, Steven M Jones wrote: > Adding the [dmarc-ietf] list for spec considerations. Direct follow-up > spec discussion there; operational issues can remain with [dmarc-discuss]. > PLEASE edit your To: and Cc: accordingly. > > > Originating message on [dmarc-discuss] from Tomki Camp queried how many > implementations obeyed the optional report size limitations described in > section 5.1 ... > > > On 08/14/2013 05:21 PM, Franck Martin wrote: > >> On Aug 14, 2013, at 5:07 PM, Matt Simerson wrote: >> >>> I just iterate over the URI list and send the report to each one, >>> skipping over any where the message size exceeds the published limit. >>> >> But this is not the intent, you are supposed to cut the report in smaller >> chunks and send them... (just saying ;) >> > > Can you cite the section(s) for that behavior, Franck? > > Matt, if no reports can be sent based on size limits, do you then send a > "reports too big" notice to all the mailto: URIs per section 11.2.4? > > > Section 11.2 indicates that any reporting URI with a size limit lower than > the current report size should be skipped, with an exception that if no > URIs qualify to receive a report, Mail Receivers should follow section > 11.2.4 to send a "report too big" notice. > > Section 11.2.1 for the Email transport notes the possibility of a report > larger than can be accepted by a mailto: URI and refers to section > 11.2.4. Section 11.2.2 for the HTTP transport does not make a specific > reference to the size limitation; neither does section 11.2.3 which notes > the opportunity to add additional transports in future. I'd recommend that > it just be made clear that the handling specified in section 11.2 applies > across all transports. > > > Pursuant to the original question though, has anybody received an error > report as described in section 11.2.4 in the wild? I'm curious because > there's a note in the spec that a more rigorous definition will be added > based on operational experience... I'll go bodge something to generate > some, but organic examples would probably be better if we've got any. > > Thanks, > --Steve. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f46d044287f68a138104ec7344bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't see any action items here in terms of changes = to the base draft.=A0 Am I correct in that assessment?=A0 I'll assume y= es; someone should speak up if otherwise.

-MSK


On Wed, Aug 14, 2013 at 8:32 PM, Steven = M Jones <smj@crash.com> wrote:
Adding the [dmarc-ietf] list for spec considerations. Direct follow-up spec= discussion there; operational issues can remain with [dmarc-discuss]. PLEA= SE edit your To: and Cc: accordingly.


Originating message on [dmarc-discuss] from Tomki Camp queried how many imp= lementations obeyed the optional report size limitations described in secti= on 5.1 ...


=A0On 08/14/2013 05:21 PM, Franck Martin wrote:
On Aug 14, 2013, at 5:07 PM, Matt Simerson <matt@tnpi.net> wrote:
I just iterate over the URI list and send the report to each one, skipping = over any where the message size exceeds the published limit.
But this is not the intent, you are supposed to cut the report in smaller c= hunks and send them... (just saying ;)

Can you cite the section(s) for that behavior, Franck?

Matt, if no reports can be sent based on size limits, do you then send a &q= uot;reports too big" notice to all the mailto: URIs per section 11.2.4= ?


Section 11.2 indicates that any reporting URI with a size limit lower than = the current report size should be skipped, with an exception that if no URI= s qualify to receive a report, Mail Receivers should follow section 11.2.4 = to send a "report too big" notice.

Section 11.2.1 for the Email transport notes the possibility of a report la= rger than can be accepted by a mailto: URI and refers to section 11.2.4. Se= ction 11.2.2 for the HTTP transport does not make a specific reference to t= he size limitation; neither does section 11.2.3 which notes the opportunity= to add additional transports in future. I'd recommend that it just be = made clear that the handling specified in section 11.2 applies across all t= ransports.


Pursuant to the original question though, has anybody received an error rep= ort as described in section 11.2.4 in the wild? I'm curious because the= re's a note in the spec that a more rigorous definition will be added b= ased on operational experience... =A0I'll go bodge something to generat= e some, but organic examples would probably be better if we've got any.=

Thanks,
--Steve.

_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--f46d044287f68a138104ec7344bb-- From superuser@gmail.com Sat Nov 30 22:39:58 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9026A1AE330 for ; Sat, 30 Nov 2013 22:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmYm1_4xuWBm for ; Sat, 30 Nov 2013 22:39:55 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 401FC1AE10F for ; Sat, 30 Nov 2013 22:39:55 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id z2so1914079wiv.0 for ; Sat, 30 Nov 2013 22:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=il95TrpORqyglKUYZVzLmb0OE9r5RP7PGrlE1vxefqk=; b=l8/Cp4sTotyg5MMv3D8RV2BycbHKfG8F0NkM9SfKxv/StpyA+3BnNH9rs6mvuGI2C0 thfgZOw/LP1N+MEepk2AW+wbPyLRadM8neC6p2bXKF/sPZQD4PJhye3RCRZ4R4Tvc53C LGE8wiaLVyKMZNt4KN+PW8HTCFyQFd3r+y/BdYGW//cw5MVYUgLp1X2RFdk5QWjHCk3n sI2sKIK34+S0fPEOLw1wR4IX3Y9EEQ8NZxDxrUckdJVbn9YyPttSEzbTCb02Yn9+G/2u +t7nU/I6+29Wg3ZnAJkckX3BQxRBB2x2ZPqLcqYTkMQD0EFp5mcoVVooW0IruBNCmNj6 kveg== MIME-Version: 1.0 X-Received: by 10.194.89.233 with SMTP id br9mr47444154wjb.15.1385879992953; Sat, 30 Nov 2013 22:39:52 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sat, 30 Nov 2013 22:39:52 -0800 (PST) In-Reply-To: <52251471.8070001@gmail.com> References: <52251471.8070001@gmail.com> Date: Sat, 30 Nov 2013 22:39:52 -0800 Message-ID: From: "Murray S. Kucherawy" To: Raman Gupta Content-Type: multipart/alternative; boundary=089e0102fb5cae705504ec735408 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 06:39:58 -0000 --089e0102fb5cae705504ec735408 Content-Type: text/plain; charset=ISO-8859-1 Any other input on this point? DMARC currently only considers the SPF result if there is alignment between the return path and the From field. On Mon, Sep 2, 2013 at 3:42 PM, Raman Gupta wrote: > I encountered a use case recently with an auto-generated email with > RFC5322.From domain foo.com, sent from a host in domain bar.com. > Because the email was auto-generated by sieve, it contained a null > return path. The host in bar.com is a valid SPF sender for domain foo.com. > > DMARC failed the SPF check despite the valid SPF, since the > RFC5322.From address was not aligned with the domain bar.com extracted > from the HELO/EHLO. > > A valid way to circumvent this problem is to use DKIM signing, aligned > with foo.com, in which case DMARC is designed to ignore the SPF > failure and pass overall. > > However, I do think this is a valid situation which the SPF alignment > rules should consider. > > I hope I have explained this sufficiently. Thank you to Steven Jones > and Scott Kitterman and others on the dmarc-discuss list for > clarifying the situation presented here. > > Regards, > Raman Gupta > Principal > VIVO Systems > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --089e0102fb5cae705504ec735408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Any other input on this point?=A0 DMARC currently only con= siders the SPF result if there is alignment between the return path and the= From field.


On Mon, Sep 2, 2013 at 3:42 PM, Raman Gupta <rocketraman@gmail.com> wrote:
I encountered a use case recently with an auto-generated email with
RFC5322.From domain foo.com, sent from a host in domain = bar.com.
Because the email was auto-generated by sieve, it contained a null
return path. The host in bar.c= om is a valid SPF sender for domain foo.com.

DMARC failed the SPF check despite the valid SPF, since the
RFC5322.From address was not aligned with the domain bar.com extracted
from the HELO/EHLO.

A valid way to circumvent this problem is to use DKIM signing, aligned
with foo.com, in which cas= e DMARC is designed to ignore the SPF
failure and pass overall.

However, I do think this is a valid situation which the SPF alignment
rules should consider.

I hope I have explained this sufficiently. Thank you to Steven Jones
and Scott Kitterman and others on the dmarc-discuss list for
clarifying the situation presented here.

Regards,
Raman Gupta
Principal
VIVO Systems
_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--089e0102fb5cae705504ec735408-- From superuser@gmail.com Sat Nov 30 22:47:54 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1941AE329 for ; Sat, 30 Nov 2013 22:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnkwEhyOrrx6 for ; Sat, 30 Nov 2013 22:47:52 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id A686A1AE2DE for ; Sat, 30 Nov 2013 22:47:51 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so10380750wes.26 for ; Sat, 30 Nov 2013 22:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1ub8yQxRvTpBBBAyz1TxF5c3m+Ey7wO1B78TJRLlUVo=; b=NWCpNzWp1sAdeNt/b3DRNz5g0wEt23Ha0etZFEGpv+wqUiM1co2kJiWv4P+5ai7wsL Myv3WuD1QfeUv62aK9flW3aYHHi+AvDjVfVa2YoIgb2UF5070Ww5mLwGXtU8buRe7Pay Lr7LzjBnZTnVHJXhIkdRxRIddL75ZRR1fjEvqelbA699lUnSwo6Q2x5UrBE1DhfHZ+51 8tfv2shfm+y/xbgcde/K6ZUSEdqU4yZcgZlmU1NK2WeAEYIJvWkwy9oUc66oMKpr9qEX mM5PVUdTfiKBXYYn6urOztYbGxLbmIxlVceA8mB7uuWoMrUVl4dd8qfPsb7bF3duGtuh ZB0g== MIME-Version: 1.0 X-Received: by 10.180.75.115 with SMTP id b19mr13255179wiw.19.1385880469248; Sat, 30 Nov 2013 22:47:49 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sat, 30 Nov 2013 22:47:49 -0800 (PST) In-Reply-To: References: Date: Sat, 30 Nov 2013 22:47:49 -0800 Message-ID: From: "Murray S. Kucherawy" To: Greg Colburn Content-Type: multipart/alternative; boundary=f46d043be23c121f5c04ec7371c5 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] XSD concern, policy_evaluated should be required X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 06:47:54 -0000 --f46d043be23c121f5c04ec7371c5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do any others wish to comment on this point? -MSK On Wed, Oct 16, 2013 at 5:31 AM, Greg Colburn wrote: > We noticed some stray aggregate reports without policy_evaluated blocks. = According to page 70 in the current draft, policy_evaluated is minOccurs= =3D"0". Here is the relevant XSD. > > > > > > > > > > > type=3D"PolicyEvaluatedType" > minOccurs=3D"0"/> > > > > > In my mind the policy_evaluated block is very important, in many ways its= the entire point of the report. It generally answers the question of "wha= t happened". Without policy_evaluated a significant amount of the value of= the data is lost. I propose that we update the XSD to set the minOccurs = to 1. > > > > > > > > > > > type=3D"PolicyEvaluatedType" > minOccurs=3D"1"/> > > > > > Sincerely, > > > Greg Colburn > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --f46d043be23c121f5c04ec7371c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Do any others wish to comment on this point?

<= /div>-MSK


On Wed, Oct 16, 2013 at 5:31 AM, Greg Colburn <<= a href=3D"mailto:Greg.Colburn@returnpath.com" target=3D"_blank">Greg.Colbur= n@returnpath.com> wrote:
We noticed some stray aggregate reports without policy_evaluated blocks.  A=
ccording to page 70 in the current draft, policy_evaluated is minOccurs=3D&=
quot;0".  Here is the relevant XSD.

   <xs:complexType name=3D"RowType">

     <xs:all>
       <!-- The connecting IP. -->
       <xs:element name=3D"source_ip" type=3D"IPAddress&q=
uot;/>
       <!-- The number of matching messages -->
       <xs:element name=3D"count" type=3D"xs:integer"=
;/>
       <!-- The DMARC disposition applying to matching
            messages. -->
       <xs:element name=3D"policy_evaluated"
                   type=3D"PolicyEvaluatedType"
                   minOccurs=3D"0"/>
     </xs:all>
   </xs:complexType>

In my mind the policy_evaluated block is very important, in many ways its t=
he entire point of the report.  It generally answers the question of "=
what happened".  Without policy_evaluated a significant amount of the =
value of the data is lost.  I propose that we update the XSD to  set the mi=
nOccurs to 1.



   <xs:complexType name=3D"RowType">

     <xs:all>
       <!-- The connecting IP. -->
       <xs:element name=3D"source_ip" type=3D"IPAddress&q=
uot;/>
       <!-- The number of matching messages -->
       <xs:element name=3D"count" type=3D"xs:integer"=
;/>
       <!-- The DMARC disposition applying to matching
            messages. -->
       <xs:element name=3D"policy_evaluated"
                   type=3D"PolicyEvaluatedType"
                   minOccurs=3D"1"/>
     </xs:all>
   </xs:complexType>

Sincerely,

Greg Colburn



_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc


--f46d043be23c121f5c04ec7371c5-- From superuser@gmail.com Sat Nov 30 23:04:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DEB1AE343 for ; Sat, 30 Nov 2013 23:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2cC34wrHN7V for ; Sat, 30 Nov 2013 23:04:37 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6817A1AE337 for ; Sat, 30 Nov 2013 23:04:37 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so10522010wes.24 for ; Sat, 30 Nov 2013 23:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oEyM2pis+xJVnpnXJMlRLpLRodndgPSzfemsb9HHG8c=; b=0hpf489NFKIclpsupXw5nwP1OgRKgI6Sbd5QnpJp899wzxY0jFyiXLDLUUwGVQ9ZHz nQoc7P7AVSjY9tv9AehODXc4tztbe/zq4PEpm/iA2TjsIz+CSbZ99LnzhV7QhcQiX6i+ v+X95PgG9rCJpvVUh/Kjlq2cMGkO3sytIfH6lVQxOgao8kucyST2fZ3hTelGQXzcQHVT HMyTMk3/1zqEF0Y6O7diPlBWmnQMw2JFUEix9c2yE79JDiLHPr1IGdwgCmBLlEwybatH QbM6YFS8xkWSXyR5DWknbGIk0h5hP0/P3Yo6Rjvlv417C7cJ1z36P82m9qX4JnlyhFP6 WHQA== MIME-Version: 1.0 X-Received: by 10.180.37.237 with SMTP id b13mr12172375wik.52.1385881475080; Sat, 30 Nov 2013 23:04:35 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sat, 30 Nov 2013 23:04:34 -0800 (PST) In-Reply-To: <5263B5AE.6050602@rolandturner.com> References: <183070991.120390.1380145453453.JavaMail.zimbra@peachymango.org> <5243620F.9010500@sonnection.nl> <507BB779-6542-4ED1-BE2D-95E332EC12CE@tnpi.net> <52439054.3040005@rolandturner.com> <5243ED1C.8040207@sonnection.nl> <5263B5AE.6050602@rolandturner.com> Date: Sat, 30 Nov 2013 23:04:34 -0800 Message-ID: From: "Murray S. Kucherawy" To: Roland Turner Content-Type: multipart/alternative; boundary=e89a8f64673d05e79604ec73adbe Cc: "" , Matt Simerson , "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] text correction on DMARC spec re reporting DNS record X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 07:04:40 -0000 --e89a8f64673d05e79604ec73adbe Content-Type: text/plain; charset=ISO-8859-1 I've added a definition for Report Receiver and Author Domain, and made use of them in a few key places. Is there really a need to define Submission Domain and Receiver Domain? I can't recall, nor find in a brief scan, any places where those would be especially useful for this draft. -MSK On Sun, Oct 20, 2013 at 3:51 AM, Roland Turner wrote: > Hi Rolf, > > > On 09/26/2013 04:15 PM, Rolf E. Sonneveld wrote: > >> Hi, Roland, >> >> On 09/26/2013 03:39 AM, Roland Turner wrote: >> >>> Rolf, are you suggesting that the [already deployed, working] mechanism >>> described in 7.1 whereby a putative report receiver can purportedly do that >>> exact thing (confirm willingness to receive, via DNS) is unworkable? >>> >> >> No. >> > > My mistake, I read (and replied to) the thread out of sequence. > > > >> Something else? >>> >> >> The text I proposed is in the category 'minor improvements'. As "[...] >> The mission of the IETF is to produce high quality, relevant technical and >> engineering documents [...]" (RFC3935, BCP95) the proposed text is an >> attempt to differentiate between the various roles that exists in any >> medium to large organization. >> >> All in all, when trying to come up with some text I realized that it >> would help when some 'domain' definitions would be added to the DMARC spec, >> to address the various sorts of domains there are in the context of DMARC. >> I'd suggest to move the currently present Domain definitions from the intro >> of chapter 3 to a separate paragraph ("3.1 Domain Definitions", for >> example) and add definitions for: >> >> - Author Domain >> - Submission Domain (see RFC5598, par 4.1.4, discussion on >> RFC5321.MailFrom) >> - Receiver Domain >> - Report Receiver Domain >> >> and then use these names/definitions throughout the document. >> >> I'd be happy to come up with some text, but maybe it's better to wait for >> the formal review phase? >> > > This all makes sense. I'm guessing that Murray's pass through the list > archive for changes to document will consider this. > > Murray? > > - Roland > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --e89a8f64673d05e79604ec73adbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've added a definition for Report Receiver and A= uthor Domain, and made use of them in a few key places.=A0 Is there really = a need to define Submission Domain and Receiver Domain?=A0 I can't reca= ll, nor find in a brief scan, any places where those would be especially us= eful for this draft.

-MSK


On Sun, Oct 20, 2013 at 3:51 AM, Roland Turner <roland@ro= landturner.com> wrote:
Hi Rolf,


On 09/26/2013 04:15 PM, Rolf E. Sonneveld wrote:
Hi, Roland,

On 09/26/2013 03:39 AM, Roland Turner wrote:
Rolf, are you suggesting that the [already deployed, working] mechanism des= cribed in 7.1 whereby a putative report receiver can purportedly do that ex= act thing (confirm willingness to receive, via DNS) is unworkable?

No.

My mistake, I read (and replied to) the thread out of sequence.



Something else?

The text I proposed is in the category 'minor improvements'. As &qu= ot;[...] The mission of the IETF is to produce high quality, relevant techn= ical and engineering documents [...]" (RFC3935, BCP95) the proposed te= xt is an attempt to differentiate between the various roles that exists in = any medium to large organization.

All in all, when trying to come up with some text I realized that it would = help when some 'domain' definitions would be added to the DMARC spe= c, to address the various sorts of domains there are in the context of DMAR= C. I'd suggest to move the currently present Domain definitions from th= e intro of chapter 3 to a separate paragraph ("3.1 Domain Definitions&= quot;, for example) and add definitions for:

- Author Domain
- Submission Domain (see RFC5598, par 4.1.4, discussion on RFC5321.MailFrom= )
- Receiver Domain
- Report Receiver Domain

and then use these names/definitions throughout the document.

I'd be happy to come up with some text, but maybe it's better to wa= it for the formal review phase?

This all makes sense. I'm guessing that Murray's pass through the l= ist archive for changes to document will consider this.

Murray?

- Roland

_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--e89a8f64673d05e79604ec73adbe-- From prvs=00406d3484=johnl@taugh.com Sat Nov 30 23:09:03 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601D91AE35A for ; Sat, 30 Nov 2013 23:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQJKCIPP5xHd for ; Sat, 30 Nov 2013 23:09:02 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B725B1AE4E3 for ; Sat, 30 Nov 2013 23:08:57 -0800 (PST) Received: (qmail 78593 invoked from network); 1 Dec 2013 07:08:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Dec 2013 07:08:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=529ae086.xn--i8sz2z.k1310; i=sendmail-bs@submit.iecc.com; bh=lzp6uc+Qdi5SchW6s0rxl6YwvigQGWWMZSzaVjmBKyQ=; b=ijFez1Sgq68nTQgpFHD3kJDyzdpJeXXU3nmS1Od5vhP1ywuPYlXFkeaZzMjUvIqAaL1larB2hlzDg32kyk5fj+n77N9oEX7KIMFa8cnZesqgru6DwCuurW4Tma5TV3LADMpLx+CSAT9cljyfujhzquLWWWwIFYhfw6Rvc7uSZLAc1CxxvXT+FMj7yjYFfLSp6jQF9yVAoNgIGbzvGP3g5QhA2WijYaICuWyf9MwJjWD0Hsv9410Mi8jAajouqIuj DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=529ae086.xn--i8sz2z.k1310; olt=sendmail-bs@submit.iecc.com; bh=lzp6uc+Qdi5SchW6s0rxl6YwvigQGWWMZSzaVjmBKyQ=; b=iX25j340et/N22Mx9Ek1QWBUx3jdY8zATdCx7KIENh/RshQKahGg8cbzPeHYWkhb6dxkmRdcTp1Zl/kE5UdxVLryaNyILjW5ZsdBLoKk7EVJGKQ2C5UawKZFddsB4au2lbWaCHvtsRVai7PTwgyfzw1yJ0TaAIwzqLGYeuK3dLSloWUxUhnnZQZaTk6sdz+ypgNo23ohm+wGyXizglyi639pE1bHgKnZpvtet71nH8tgy7OVIEBYBjxQN2WkmKBZ Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Dec 2013 07:08:54 -0000 Date: Sun, 1 Dec 2013 02:08:54 -0500 (EST) From: John R Levine To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> <20130809234600.Horde.BohsttCU7cC5wFyE1swI8w3@horde.andreasschulze.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dmarc@ietf.org" , Andreas Schulze Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 07:09:03 -0000 >> If nobody implemented http reporting yet >> we should consider removing it from the spec... > > Any other opinions on this point? The current spec is too messed up to allow interoperable implementations. (PUT and POST are not the same thing at all.) For large reports, http PUT is a much better way to deliver them than mail, since it's basically just a file upload to the target's web server, no base64 encoding or decoding needed, and no extra copies filling up mail spools. It's easily made snoop and spoof resistant by using https, and it's easy to program because all of the usual http libraries support it. If any of the usual suspects are interested, I can tell you how to fix the spec. It's not very hard, change it to be only PUT, and specify how to construct the PUT filename for each report. R's, John