From fenton@bluepopcorn.net Wed Oct 2 15:55:35 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 9CB2D21F9E95 for ; Wed, 2 Oct 2013 15:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 BDvcI5Tk690e for ; Wed, 2 Oct 2013 15:55:26 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id AE77621F9EA8 for ; Wed, 2 Oct 2013 15:54:33 -0700 (PDT) Received: from splunge.local (mobile-166-137-184-219.mycingular.net [166.137.184.219]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r92MrfIv027074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Oct 2013 15:53:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1380754423; bh=aHVZPRyFon1Z3LKUlYMHj1LLuRU7baPWbSuZnpbdogE=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=pojrcel7jlVaDYnpQ4XvcUNr+9w49daOJ3sCBjJN2cUM/u8VLq0Rw9ahUv0ZD2L0Q 9rAGsQZSYzknZObHm1vglS+3rkXRDLxKo/DTFTy9ShKfRDSimZtK2TTtHRSw4EapHb EaDGj11nLDAWEZdS9Yp3eBOIoinnpZV8RVptYSEQ= Message-ID: <524CA422.8030008@bluepopcorn.net> Date: Wed, 02 Oct 2013 15:54:26 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [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: Wed, 02 Oct 2013 22:55:35 -0000 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 From vesely@tana.it Mon Oct 7 08:04:42 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 986ED21E80B5 for ; Mon, 7 Oct 2013 08:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 NOqowTdWcbuo for ; Mon, 7 Oct 2013 08:04:38 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7C721E80B4 for ; Mon, 7 Oct 2013 08:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1381158272; bh=fP8PoJ5hX7k1ppRpAf0tz5sj8BZMPehSb7tHfJEb5xo=; l=2481; h=Date:From:To:References:In-Reply-To; b=eTrjZfU3MdRfpBj+tTCTf0pU7hkeRHtUce3jsy7XDeTLepX9fwf6/f/BO5laSbbB1 yTN16tea95a2Iaf2G69/u86z9etIjFLDCYcSeNGoxq8PsOvrY6zx3vxfz3buZlTpSm SUR+6rj/O3eBL4kINSMRExxNibWp41jJTeaT36ww= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 07 Oct 2013 17:04:32 +0200 id 00000000005DC035.000000005252CD80.000008C7 Message-ID: <5252CD80.1030007@tana.it> Date: Mon, 07 Oct 2013 17:04:32 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9 MIME-Version: 1.0 To: dmarc@ietf.org References: <1510357.FYKYMNnRCL@scott-latitude-e6320> <2042924498.41137.1379376297800.JavaMail.zimbra@peachymango.org> <5237C378.6030807@rolandturner.com> <1945650.hcHt8AHrK6@scott-latitude-e6320> <523EF86F.7070703@rolandturner.com> In-Reply-To: <523EF86F.7070703@rolandturner.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] ADSP Related Mailing List Unsubscriptions Considerations For DMARC 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, 07 Oct 2013 15:04:42 -0000 On Sun 22/Sep/2013 16:02:23 +0200 Roland Turner wrote: > On 09/17/2013 12:33 PM, Scott Kitterman wrote: > >> DMARC does have a few more knobs to turn, but if you don't want >> mail that fails authentication sent to the receiving user, you >> have to use p=reject and that has the exact same problem with >> mailing list subscriptions that ADSP does. > > Noting that we're talking about a very narrow situation (and yes, now > that I look at it, your choice of Subject: points this out) that both > ADSP and DMARC authors accept is beyond their reach (both protocols > are expected to reduce the problems that they address, not to > magically solve them without side-effects), meaning that the broader > argument is not being addressed: > > * DMARC provides domain owners with visibility of this situation ahead > of a decision to switch on p=reject, ADSP does not. This materially > changes the situation. It allows a domain owner to make informed > choices, rather than guess, to plan appropriate trade-offs, to > monitor the situation on an ongoing basis and to discover unexpected > consequences as and when they arise. > * DMARC makes concrete (through override reasons of forwarded, > trusted_forwarder and mailing_list) reasons for receiver's > discretion which ADSP did not. As a practical matter the exercise of > discretion is required in either case, but DMARC raises it to a > recognised element of the protocol rather than an invisible activity. > > So, even for the narrow situation that you're asking about, DMARC does > considerably better than ADSP. While the above is true, DMARC feedback is no crystal ball. Mailing lists are so uncommon that a domain with a small to medium number of users could monitor its feedback for months before stumbling upon lists. At that point they'll be told they should have known that p=reject is only for domains with no users, receivers will learn to only honor such policy for the usual list of heavily phished domains, and perhaps someone will want to move DMARC to historic. IMHO we should pick up one or more of the recipes in RFC 6377, and/or some proposed third party or joint signatures schemata --however little the adoption they have enjoyed thus far-- and proclaim them the official workarounds for this problem. Currently, the spec mentions "local heuristics", which varies too widely from one verifier to another to characterize the override as a protocol element. Ale From superuser@gmail.com Tue Oct 15 17:56:57 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 9EE9A21F9B8D for ; Tue, 15 Oct 2013 17:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 fq95Zd4KdTxj for ; Tue, 15 Oct 2013 17:56:57 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 60A4511E822E for ; Tue, 15 Oct 2013 17:56:53 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id l18so40129wgh.18 for ; Tue, 15 Oct 2013 17:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uetexEFJiEeQWfdnNeA60fWrG0VlY5BE7O9+wTOYvXE=; b=WfbziCNCSR37YkNTkx32PJKA1F09QvusT7NvbCPM1WeZfT8Hkxi8Oqyj9KI6VvFuap v1FT3Jn5qZjl1YR44k804978GvovVG/fche8elWd71ModBwTSpUHMJhTOHXtw6YrYZXN /R+X9czHsSbQkuSk5CcVfFITuCZ2HSX4KuAkc/5iWzjB7Lgzjw/K6M20B6CDhZ6GkjPX ZKR1Eut/WVQyCneYdETAgQN+A/9Iiwr7rf31E1Tl047xc4eMK3Ga3n9zFbO9tfUsyQiS adzNFqwRQuo4cEFR38p3l4VgSSIeaKCYq4feBzRGnW072BSTUb9RQgvK1s3wd3fTKH46 s4VA== MIME-Version: 1.0 X-Received: by 10.180.189.132 with SMTP id gi4mr22148429wic.19.1381885003183; Tue, 15 Oct 2013 17:56:43 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Tue, 15 Oct 2013 17:56:42 -0700 (PDT) Date: Tue, 15 Oct 2013 17:56:42 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c35294bc3ef304e8d12cfa Subject: [dmarc-ietf] Document update 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: Wed, 16 Oct 2013 00:56:57 -0000 --001a11c35294bc3ef304e8d12cfa Content-Type: text/plain; charset=ISO-8859-1 Hi all, I'm planning to scrape this list for items that would be good to include in a revision to the draft and post it prior to the cutoff. I'll post again when I have a diff available for review. I'll reply to the list as I go through the feedback. -MSK --001a11c35294bc3ef304e8d12cfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm planning to scrape this list f= or items that would be good to include in a revision to the draft and post = it prior to the cutoff.=A0 I'll post again when I have a diff available= for review.

I'll reply to the list as I go through the feedback.

-= MSK
--001a11c35294bc3ef304e8d12cfa-- From roland@rolandturner.com Tue Oct 15 21:31:43 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 2009C11E80EA for ; Tue, 15 Oct 2013 21:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 Vq80uAmQ3FdF for ; Tue, 15 Oct 2013 21:31:38 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 00B2C21F9A4A for ; Tue, 15 Oct 2013 21:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=8UXoR8HG0r2VabVDvPVbgJOYoJ23N07d/5199smi5wA=; b=PphFk9rD3qmP9JyCc4fqkflDGAqFQK3NAZjesqo+8wEBInWrz9kwn3AwZ7eENbEJmRZEu6OrJkyCTFnWZCrt7M+dYCsU6TMw38JHqKcLl/7XFLFzEh1VgSjyPBCjBqcpAdohmd51vYvEWYl69paT0ImzcLIsYIzc+X+VmAUPMVE=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=48408 helo=[10.100.1.108]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VWIlh-0000o6-6B; Wed, 16 Oct 2013 04:31:34 +0000 Message-ID: <525E16A3.1020601@rolandturner.com> Date: Wed, 16 Oct 2013 12:31:31 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "dmarc@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000600070904070302080303" Subject: Re: [dmarc-ietf] Document update 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: Wed, 16 Oct 2013 04:31:43 -0000 This is a multi-part message in MIME format. --------------000600070904070302080303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Ah, this suggests an answer to a process question that I'd been meaning to ask: which cutoff? (More broadly, are the remaining steps documented somewhere?) - Roland On 10/16/2013 08:56 AM, Murray S. Kucherawy wrote: > Hi all, > > I'm planning to scrape this list for items that would be good to > include in a revision to the draft and post it prior to the cutoff. > I'll post again when I have a diff available for review. > > I'll reply to the list as I go through the feedback. > > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --------------000600070904070302080303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Ah, this suggests an answer to a process question that I'd been meaning to ask: which cutoff? (More broadly, are the remaining steps documented somewhere?)

- Roland


On 10/16/2013 08:56 AM, Murray S. Kucherawy wrote:
Hi all,

I'm planning to scrape this list for items that would be good to include in a revision to the draft and post it prior to the cutoff.  I'll post again when I have a diff available for review.

I'll reply to the list as I go through the feedback.

-MSK


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

--------------000600070904070302080303-- From dcrocker@gmail.com Tue Oct 15 21:44:35 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 DE0A511E8253 for ; Tue, 15 Oct 2013 21:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 sFWGR8jb4TDU for ; Tue, 15 Oct 2013 21:44:35 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 775F811E8255 for ; Tue, 15 Oct 2013 21:44:31 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so312201pdj.1 for ; Tue, 15 Oct 2013 21:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gl3hBGKyMHUnNShN5ybVp9xxLfSsPEjtcTx4d7jm4P8=; b=jxSojwD7soM5IDyJjANEwfjBTc8lNqrydXEeOxoUdP9Mv46fAxtr08XPDFRnr0vm5c Sp/2ek56lY10kwRS6lK0V/hFNC0cVL5g2YToevVzT0cniSdzyjTrDaQIvYZgGi6SkRXb Pv7CYQm1etWgT9lJELQ3o8nowSRgrFTZwspig4/LEUjt/En+nAkgFPbw0VR6jXBQKZMR SMsRvci5MOONySvnmrwgJKxg/uBDV5EYinh27P7ZcAQ0D/cORgEFy24nBZu5L2ti9wRg dZuhIXsDESwkYo3ts8o0LfzzwuQMT+2ItCYJ0Bp4iw4XGOtLg8k3kIcH3bywchbNmb6i 9FZQ== X-Received: by 10.68.143.74 with SMTP id sc10mr346697pbb.190.1381898664021; Tue, 15 Oct 2013 21:44:24 -0700 (PDT) Received: from [10.100.255.252] ([122.56.34.234]) by mx.google.com with ESMTPSA id ik1sm44380551pbc.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Oct 2013 21:44:23 -0700 (PDT) Message-ID: <525E1990.5000704@gmail.com> Date: Wed, 16 Oct 2013 17:44:00 +1300 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Roland Turner , "Murray S. Kucherawy" , "dmarc@ietf.org" References: <525E16A3.1020601@rolandturner.com> In-Reply-To: <525E16A3.1020601@rolandturner.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Document update 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: Wed, 16 Oct 2013 04:44:36 -0000 On 10/16/2013 5:31 PM, Roland Turner wrote: > Ah, this suggests an answer to a process question that I'd been meaning > to ask: which cutoff? (More broadly, are the remaining steps documented > somewhere?) There is a formal 'sequence' for getting IETF approval and publication, but they don't have timing deadlines, except for getting comments in during a phase called Last Call, which will probably be a 4-week window, eventually. At the moment, we are the pre-formal stage of getting the sponsoring Area Director to agree to do the sponsoring. He's decided on an ad hoc requirement of some reviews, which I think we all agree is reasonable, for this case. Other deadlines are merely related to the IETF meeting, in this case Vancouver shortly. They lock-out new versions of internet-drafts for 2-3 weeks, prior the meeting, with the idea of keeping the flood from hitting at the very last minute. For DMARC, that deadline is only a matter of convenience. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Tue Oct 15 23:45:58 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 4343011E8107 for ; Tue, 15 Oct 2013 23:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 CnuzWqqvIso3 for ; Tue, 15 Oct 2013 23:45:57 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E39FE21F9E54 for ; Tue, 15 Oct 2013 23:45:56 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so404038pbb.14 for ; Tue, 15 Oct 2013 23:45:56 -0700 (PDT) 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=zE9Pg1rT+co53jpHqPX/yLDHdu70uw6U5DdnbMjKzdY=; b=UXfdLSW1ZNAvdQMFMgQkXXBmyfo2yiqFTTyuuVpZxKwuZc9v6HjNYLtqj3m2XWJV7c iA1G0dLshmzWiuGg8QGXfHuxiBFrxjJ4Uiypu6T/40b8ARp5IT6ALpFo6Z9rphkkzqGc apccsou8mP4M3IY/aKpMeNDlKA5BeBgg8urjksiTIaxc4uy1qPOVJ4Q1cpNXrdqMncnu KtZPlJLsfJvO2CExoVE0do46ejnI7ah2ISCmdFHYxO7qUpBArB61i7x9OmxxQibojkEx SBP5cb1Lshp4wqf1fPmMLBwrbWXjtl/5MTrMqrpIxWT7QYzGIsRAjcyxPZ6BV6CLW1fv Yrzg== MIME-Version: 1.0 X-Received: by 10.66.19.137 with SMTP id f9mr1926880pae.138.1381905956608; Tue, 15 Oct 2013 23:45:56 -0700 (PDT) Received: by 10.67.5.225 with HTTP; Tue, 15 Oct 2013 23:45:56 -0700 (PDT) In-Reply-To: <525E16A3.1020601@rolandturner.com> References: <525E16A3.1020601@rolandturner.com> Date: Tue, 15 Oct 2013 23:45:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Roland Turner Content-Type: multipart/alternative; boundary=bcaec520e97ba824e304e8d60d08 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Document update 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: Wed, 16 Oct 2013 06:45:58 -0000 --bcaec520e97ba824e304e8d60d08 Content-Type: text/plain; charset=ISO-8859-1 Just to concur with Dave's points: We're not in any kind of formal process at this stage. There is a deadline to getting updates published prior to the Vancouver meeting just so we are all reasonably sure we're all looking at the same draft when we meet there. It's this coming Monday. On the Monday of the conference (November 4th), the embargo is lifted, and normal document evolution resumes. That's the deadline to which I was referring. -MSK On Tue, Oct 15, 2013 at 9:31 PM, Roland Turner wrote: > Ah, this suggests an answer to a process question that I'd been meaning > to ask: which cutoff? (More broadly, are the remaining steps documented > somewhere?) > > - Roland > > > > On 10/16/2013 08:56 AM, Murray S. Kucherawy wrote: > > Hi all, > > I'm planning to scrape this list for items that would be good to include > in a revision to the draft and post it prior to the cutoff. I'll post > again when I have a diff available for review. > > I'll reply to the list as I go through the feedback. > > -MSK > > > _______________________________________________ > dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc > > > --bcaec520e97ba824e304e8d60d08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Just to concur with Dave's points: We're not = in any kind of formal process at this stage.=A0 There is a deadline to gett= ing updates published prior to the Vancouver meeting just so we are all rea= sonably sure we're all looking at the same draft when we meet there.=A0= It's this coming Monday.=A0 On the Monday of the conference (November = 4th), the embargo is lifted, and normal document evolution resumes.=A0 That= 's the deadline to which I was referring.

-MSK


On Tue, Oct 15, 2013 at 9:31 PM, Roland Turner <roland@ro= landturner.com> wrote:
=20 =20 =20
Ah, this suggests an answer to a process question that I'd been meaning to ask: which cutoff? (Mor= e broadly, are the remaining steps documented somewhere?)

- Roland



On 10/16/2013 08:56 AM, Murray S. Kucherawy wrote:
Hi all,

I'm planning to scrape this list for items that would be good to include in a revision to the draft and post it prior to the cutoff.=A0 I'll post again when I have a diff available for review.

I'll reply to the list as I go through the feedback.

-MSK


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


--bcaec520e97ba824e304e8d60d08-- From superuser@gmail.com Tue Oct 15 23:47:15 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 2AAB111E8110 for ; Tue, 15 Oct 2013 23:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 bCZw68eczRFw for ; Tue, 15 Oct 2013 23:47:14 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7B79F21F9E54 for ; Tue, 15 Oct 2013 23:47:14 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so402242pbb.33 for ; Tue, 15 Oct 2013 23:47:14 -0700 (PDT) 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=GYECQlBKM7YLp6ceEeEYd0J5jFBeMtYqLetozpQq3VM=; b=yXbaHa4AoTLAnKlNNAMQHDiJrgjYHiLtLwwZW+LP1FigLSyZ5d+wlCJTgeFOlV4PZr 1451dS8nlrFi2Xpxl8u0EQHXQ1myFwpbNL/0H6y0R2VOCcnYMgfe0PHI8Cm16R2vQ4f3 HKP6WGCrNNBaV04+xpr9yY3g80Qp1hww2pu4SOtDT16QMyt525McJRPtI3p3KgRu+Wfh eBjKU6gZiugHIDm3gir9S99iKbgNDp330eb6/qLmIbu1l9LKeSgZWg+tZtCaGD+saJFO KBfLMdWTecESje6dRGyDzQMBATeEgU1rZnNPsyBQByEDC14AYfnhXZUqTGv8PdzY5Y4W BAQw== MIME-Version: 1.0 X-Received: by 10.66.192.8 with SMTP id hc8mr1940426pac.66.1381906034310; Tue, 15 Oct 2013 23:47:14 -0700 (PDT) Received: by 10.67.5.225 with HTTP; Tue, 15 Oct 2013 23:47:14 -0700 (PDT) In-Reply-To: References: <525E16A3.1020601@rolandturner.com> Date: Tue, 15 Oct 2013 23:47:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Roland Turner Content-Type: multipart/alternative; boundary=047d7bf0f22049c5cb04e8d612b3 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Document update 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: Wed, 16 Oct 2013 06:47:15 -0000 --047d7bf0f22049c5cb04e8d612b3 Content-Type: text/plain; charset=ISO-8859-1 (oops, hit "Send" too soon) On Tue, Oct 15, 2013 at 11:45 PM, Murray S. Kucherawy wrote: > Just to concur with Dave's points: We're not in any kind of formal process > at this stage. There is a deadline to getting updates published prior to > the Vancouver meeting just so we are all reasonably sure we're all looking > at the same draft when we meet there. It's this coming Monday. On the > Monday of the conference (November 4th), the embargo is lifted, and normal > document evolution resumes. That's the deadline to which I was referring. > > I'm just using the Monday deadline as encouragement to take a revision pass at the draft based on the feedback we have so far. Feedback isn't by any means closed after that. -MSK --047d7bf0f22049c5cb04e8d612b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(oops, hit "Send" too soon)

On Tue, Oct 15, 2013 at 11:45 PM, Murray S. Kucher= awy <superuser@gmail.com> wrote:
=
Just to concur with Dave's points: We're not in any kind of fo= rmal process at this stage.=A0 There is a deadline to getting updates publi= shed prior to the Vancouver meeting just so we are all reasonably sure we&#= 39;re all looking at the same draft when we meet there.=A0 It's this co= ming Monday.=A0 On the Monday of the conference (November 4th), the embargo= is lifted, and normal document evolution resumes.=A0 That's the deadli= ne to which I was referring.=


I'm just= using the Monday deadline as encouragement to take a revision pass at the = draft based on the feedback we have so far.=A0 Feedback isn't by any me= ans closed after that.

-MSK
--047d7bf0f22049c5cb04e8d612b3-- From Greg.Colburn@returnpath.com Wed Oct 16 05:31:44 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 779B221F9DA9 for ; Wed, 16 Oct 2013 05:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.198 X-Spam-Level: X-Spam-Status: No, score=-11.198 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, HTML_MESSAGE=0.001, RCVD_IN_BSP_TRUSTED=-4.3] 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 BSwPzSBcSMev for ; Wed, 16 Oct 2013 05:31:39 -0700 (PDT) Received: from o1.corpout.returnpath.com (o1.corpout.returnpath.com [50.31.61.183]) by ietfa.amsl.com (Postfix) with SMTP id 8931421F9D68 for ; Wed, 16 Oct 2013 05:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=returnpath.com; h=from:to:subject:content-type:mime-version; s=smtpapi; bh=1raK+PO26Eze3d1kvtQH3N1LyYY=; b=bg7LzAtTYVjs0DVm1tng5NYp3qRs9 3d2olCbxw5Fnr+sXwRQ3FcxIsIeJlMzdGX1z+JTfQu1PJuYBp82TNlK6XMnvGWwU MvDo2YfaMUXNJDaMdt5qgU6Xcp5QRoHOnqsZuGgkvRBy5ALyTvz+k4bSmC6rZ8Zu M53R5dvwZvao18= DomainKey-Signature: a=rsa-sha1; c=nofws; d=returnpath.com; h=from:to:subject:content-type:mime-version; q=dns; s=smtpapi; b =apyJHAV/rCpuGr2v87RXV8dQaUCMM7fZlol2y6ZGYO9VMG4WVRalOpU/LO2HBPU 7wQCnDx4cgUXYGmrDyOgZKh4I6BfLpaALkkcfwS9EoB7N7ptp3N6UT7eX3qKIIF2 +1e8FTd6RqDTPJoLr+LvpriSgHly9JQ1CEGGLMxghP1I= Received: by filter-131.sjc1.sendgrid.net with SMTP id filter-131.8186.525E87264 Wed, 16 Oct 2013 12:31:34 +0000 (GMT) Received: from smtp.corp.returnpath.net (smtp.corp.returnpath.net [50.201.69.7]) by mi21 (SG) with ESMTP id 141c13fec60.6c10.1d74fd5 for ; Wed, 16 Oct 2013 12:31:33 +0000 (UTC) Received: from rpcoex01.rpcorp.local ([10.0.1.142]) by rpcoex01.rpcorp.local ([10.0.1.142]) with mapi; Wed, 16 Oct 2013 06:31:33 -0600 From: Greg Colburn To: "dmarc@ietf.org" Date: Wed, 16 Oct 2013 06:31:29 -0600 Thread-Topic: XSD concern, policy_evaluated should be required Thread-Index: Ac7Ka6XJGN5Cu4yqT76pUs+yWGaXLw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CE83E3413B48Fgregcolburnreturnpathcom_" MIME-Version: 1.0 X-SG-EID: ttWHLwNw6rhAFWw30n9Iv9H9bTFVLrGYwa7KMAiUt5J6ShxjlnvAO2r1PgPDaEh9lSv0zEUdv1B0b6dRjNNQ5G0BW9O/ag8jA9ivaTiOEK1SKdgCY7AdvBiKrJZobvnKT/izFHvmVUPcWeEQr0PbjRWDlHejtIgB48D9Kk/qyyE= Subject: [dmarc-ietf] XSD concern, policy_evaluated should be required 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: Wed, 16 Oct 2013 12:31:44 -0000 --_000_CE83E3413B48Fgregcolburnreturnpathcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We noticed some stray aggregate reports without policy_evaluated blocks. A= ccording to page 70 in the current draft, policy_evaluated is minOccurs=3D"= 0". Here is the relevant XSD. 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 t= he data is lost. I propose that we update the XSD to set the minOccurs to= 1. Sincerely, Greg Colburn --_000_CE83E3413B48Fgregcolburnreturnpathcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
We noticed some s=
tray 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.

   <xs:complexType name=3D"RowT=
ype">

     <xs:all>
       <!-- The connecting IP. -->
       <xs:element name=3D"source_ip" type=3D"IPAddress"/>
       <!-- 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 the entire point=
 of the report.  It generally answers the question of "what happened".  Wit=
hout 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.
=

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

     <xs:all&=
gt;
       <!-- The connecting IP. -->
       <xs:element name=3D"source_ip" type=3D"IPAddress"/>
       <!-- 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>

Si=
ncerely,

Greg Colburn

<=
pre class=3D"newpage" style=3D"font-size: 1em; margin-top: 0px; margin-bott=
om: 0px; page-break-before: always; color: rgb(0, 0, 0); font-style: normal=
; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: normal; orphans: auto; text-align: start; text-indent: 0px; text-tra=
nsform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0=
px;">
--_000_CE83E3413B48Fgregcolburnreturnpathcom_-- From fenton@bluepopcorn.net Wed Oct 16 15:19:52 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 48C5D11E82E1 for ; Wed, 16 Oct 2013 15:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Qk9FmQm8+oku for ; Wed, 16 Oct 2013 15:19:51 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6672011E830C for ; Wed, 16 Oct 2013 15:19:49 -0700 (PDT) Received: from splunge.local (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r9GMIr4h007531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Oct 2013 15:18:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1381961935; bh=FANvUAH2qxgQZm7m6VtBgdxp/cEeXvLp4gWdZH0Cm5Q=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=A+8w9TJskdC6p179xYF+kqSrF9UgwVpIfIZ0yUmqxWKwdRDsWctpeUEfeqVx65ivo oVoNk23COVqvVSOud4KeRCHaadtJ0N7xeNTWMjF+eDChXk5QcBK+P4OozT422ueiWH hEp8Z98JBYe/DmdV2NrjFw9oUsuOo1r+q0ZC502E= Message-ID: <525F10FF.3000706@bluepopcorn.net> Date: Wed, 16 Oct 2013 15:19:43 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Document update 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: Wed, 16 Oct 2013 22:19:52 -0000 On 10/15/13 5:56 PM, Murray S. Kucherawy wrote: > Hi all, > > I'm planning to scrape this list for items that would be good to > include in a revision to the draft and post it prior to the cutoff. > I'll post again when I have a diff available for review. > > I'll reply to the list as I go through the feedback. > I was wondering if there would be any discussion resulting from the rather lengthy review I posted to the list. I did get a couple of nice thank-you messages off-list, but it would be much more satisfying to see some discussion of the issues. -Jim From kurta@drkurt.com Sat Oct 19 05:52:14 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 08A2E11E81C5 for ; Sat, 19 Oct 2013 05:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 sv4nFriJD+51 for ; Sat, 19 Oct 2013 05:52:13 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DE44411E8176 for ; Sat, 19 Oct 2013 05:52:09 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so4875353wes.32 for ; Sat, 19 Oct 2013 05:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Bw2O4QepCLSyLguQ4mw3Ev/LlvQQXOJ4ilotMmpa1Og=; b=T0Dy8p64xu1k7GF5HPOHXk36oLkzR7R5OrgwfVcjfz9FH29MjprvH8SOu2WSmPzFLx 8lE9tKTOHvsFn4VsUDrCVXJQReMsDvoJKW+qKr6az1i29Ig2GwjmOiBz8kSFKzkihCgX StG2op24H5SZ8qxSFXzLHFOcVj5Hp1iXGQ6bI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=Bw2O4QepCLSyLguQ4mw3Ev/LlvQQXOJ4ilotMmpa1Og=; b=ARmgXlWwMg4U+cXuzQX/78zfYWNZQX5hFdL8hwtBbwKKckXw7anBto/uEQ0dP4CoJI eZoOH1RmO1OxMX5bhHzqLjfl8SNL6qQ1Zz8sXuZi0pV98/hjhB7u2B0o8cxrbN0rmn0A oYjSvkTIRsibqdU7tF8mGbM8QBwtyl5qvBdjt7XejxqzS3dFiCiW44cJQyXHmSF25HVG Bf7fpfzpar1PXNdUHuKJq5ezKOgmfd6JhCa1hSYgTr0Vwybxmwf95g/RsET0IDMGG2kH 0L/H1U3NqMKJef19zj1VJE8tZcaCL8LFJSvq7CnL1XcERiTq/9EBSP9B4l6FDDV9ULEy gkeA== X-Gm-Message-State: ALoCoQneRzmv3XdoFkynQCkEOjVpPc8QMe/BycIWICrct3vruJgc1k+Sp15gVRgbQ1lo5hoSpXLq MIME-Version: 1.0 X-Received: by 10.180.9.139 with SMTP id z11mr3148867wia.22.1382187128924; Sat, 19 Oct 2013 05:52:08 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.152.68 with HTTP; Sat, 19 Oct 2013 05:52:08 -0700 (PDT) Date: Sat, 19 Oct 2013 07:52:08 -0500 X-Google-Sender-Auth: yT-k0kiMQ2W1CCUIEUq7BaLQmV4 Message-ID: From: Kurt Andersen To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=001a11c2430ad53ad604e917845b Subject: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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: Sat, 19 Oct 2013 12:52:14 -0000 --001a11c2430ad53ad604e917845b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable There will be an open discussion meeting hosted at the impending M^3AAWG training day with a teleconference dial-in option for any interested parties. The bridge line is: U.S. Toll Free Dial-In: 1-800-820-4690 Direct (Toll): +1 702-696-5291 International Toll Free: France #: 0800911910, Germany #: 08001824395 , Spain #: 900941732, UK #: 08082348428 Conference Code: 250-041-2259 Here is the session description: Spend 60 minutes with some of the authors of the DMARC specification and discuss how their experience deploying DMARC can help you implement it in your organization. They=92ve learned a lot over the nearly two years of public operation and now is your chance to tap their expertise in answering your questions. This isn't a formal training session but rather an opportunity for you to interact directly with DMARC experts, discuss the issues you're facing and ask for suggested guidance. Session will be moderated by Franck Martin (LinkedIn) and Mike Jones (Agari). This open discussion session is sponsored by the M^3AAWG Training Committee. Cheers, Kurt Andersen M^3AAWG Training Committee Co-Chair --001a11c2430ad53ad604e917845b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
There will be an open discussion meeting hosted at the imp= ending M^3AAWG training day with a teleconference dial-in option for any in= terested parties. The bridge line is:

U.S. Toll Free Dial-In:=A0=A0 1-800-820-4690
Direct (Toll): +1 702-696-5291=A0=A0=A0=A0
International Toll Free: France #: 0800911910, Germany #: 08001824395 = , Spain #: 900941732, UK #: 08082348428

Conference Code: 250-041-2259

Here is the session description:

Spend 60 minutes with some of the authors of the DMARC specification a= nd discuss how their experience deploying DMARC can help you implement it i= n your organization.=A0 They=92ve learned a lot over the nearly two years o= f public operation and now is your chance to tap their expertise in answering your questions. This isn't a forma= l training session but rather an opportunity for you to interact directly w= ith DMARC experts, discuss the issues you're facing and ask for suggest= ed guidance.

Session will be moderated by Franck Martin (LinkedIn) and Mike Jones (= Agari).

This open discussion session is sponsored by the M^3AAWG Training Comm= ittee.

Cheers,
=A0 Kurt Andersen
=A0 M^3AAWG Training Committee Co-Chair

--001a11c2430ad53ad604e917845b-- From roland@rolandturner.com Sun Oct 20 03:51:44 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 C7A4411E83A1 for ; Sun, 20 Oct 2013 03:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 bsqAPzzIxb23 for ; Sun, 20 Oct 2013 03:51:39 -0700 (PDT) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4F311E83A5 for ; Sun, 20 Oct 2013 03:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=oBdFPq/8tw3FJZeAmeGWzpCEpbW9iBypTgPOgO8xjMI=; b=KK7mkwcEHTuuQDOmBrOPbGif0i5ndHW+YfB0vQv8FLiQDY4DlhrJ78JqB0lTzAxiPkHjFLXpnzElucas5uPWjJTFyTThXEGg4oXhRSVlatmZk7nXMemzxBBn4upRJckEvKgQmgPuJnhUExIHagqEERMSWzNm2wprJ7XsYL3J3hI=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=42.61.222.177 Received: from [42.61.222.177] (port=47800 helo=[192.168.1.73]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1VXqba-00056D-0n; Sun, 20 Oct 2013 10:51:30 +0000 Message-ID: <5263B5AE.6050602@rolandturner.com> Date: Sun, 20 Oct 2013 18:51:26 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: R.E.Sonneveld@sonnection.nl 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> In-Reply-To: <5243ED1C.8040207@sonnection.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org, Matt Simerson , 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.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: Sun, 20 Oct 2013 10:51:44 -0000 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 From kurta@drkurt.com Mon Oct 21 05:39:07 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 7F23511E84AE for ; Mon, 21 Oct 2013 05:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 oJy96e8u9uYQ for ; Mon, 21 Oct 2013 05:39:05 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id BAF7B11E83A7 for ; Mon, 21 Oct 2013 05:39:03 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ez12so3893401wid.15 for ; Mon, 21 Oct 2013 05:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=/bNTBaF5zjE74fOeJxoxmFcJ7mgrABdVmbr4E4LV2D0=; b=Nbek+iQUuNlchhvq+4s9BKm7INs0XFjzEHoGBcz71PK504DxtIInpOHOpUM4ZGyYOW EiXWHZXMAkzLHl9R2gdIQ1RKNLZ7w4ZED6l/IuIa7zSue2qWaIHzNiJe0eAdXbWypEll d9qN0J0OOisfM1PvxibifLL4cdpDg25b9Uc4o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=/bNTBaF5zjE74fOeJxoxmFcJ7mgrABdVmbr4E4LV2D0=; b=a3rQA+cpKIGxn9BUGAfDcQ3LHHU9a4qzy6e82/89M+D6pXtyRGkP7PDqBt7j2G9PtX wDkt3tox2t6pUbYPTTy2/GhupRejjsdljatXI5ys+uhguuaTdeFYv91QvEemYTalau1j m+VUgDAAFSRdIRrUWP68i6GtV6hQF3ZhLHrVoac2tvQJ9+BmQKBMF1t+KqQ0lPx6vVFk B1KLo6y1Y52AYXG1oXROHOfJ4Er4k7TBSUC/DNwvBX8Zgo26guaU0S3wV0IrCu9kUiNj Lv/EvnzKzKvphn4b+ZWkDNMb54uDNZF6Oh/pCF4jeflCcpZVv+dgv4m82NAT6V0lhAu0 R4/A== X-Gm-Message-State: ALoCoQlhIDjFj00kpUYCihXecwZO2RXWIV6hnoANteJ0Pss8SodG9nIGaCvFe+AdkYoWhpzsLt+v MIME-Version: 1.0 X-Received: by 10.194.20.170 with SMTP id o10mr13391814wje.4.1382359139326; Mon, 21 Oct 2013 05:38:59 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.152.68 with HTTP; Mon, 21 Oct 2013 05:38:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Oct 2013 07:38:59 -0500 X-Google-Sender-Auth: ojiXq-AmwJS0BqqtUIGZseXVUwo Message-ID: From: Kurt Andersen To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d5c8273acec04e93f91f5 Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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, 21 Oct 2013 12:39:07 -0000 --047d7b5d5c8273acec04e93f91f5 Content-Type: text/plain; charset=ISO-8859-1 The conference bridge is open now for anyone to attend - though I'm not sure how well the audio pickup will work because of the configuration of the room. There will be an open discussion meeting hosted at the impending M^3AAWG training day with a teleconference dial-in option for any interested parties. The bridge line is: U.S. Toll Free Dial-In: 1-800-820-4690 Direct (Toll): +1 702-696-5291 International Toll Free: France #: 0800911910, Germany #: 08001824395 , Spain #: 900941732, UK #: 08082348428 Conference Code: 250-041-2259 The correct date is indeed 10-21 @ 1230 UTC/0830 EDT/0530 PDT. Cheers, Kurt Andersen M^3AAWG Training Committee Co-Chair --047d7b5d5c8273acec04e93f91f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The conference bridge is open now for anyone to attend - t= hough I'm not sure how well the audio pickup will work because of the c= onfiguration of the room.

There will be an open discussion meeting h= osted at the impending M^3AAWG training day with a teleconference dial-in option for any interested=20 parties. The bridge line is:

U.S. Toll Free Dial-In:=A0=A0 1-800-820-4690
Direct (Toll): +1 702-696-5291=A0=A0=A0=A0
International Toll Free: France #: 0800911910, Germany #: 08001824395 = , Spain #: 900941732, UK #: 08082348428

Conference Code: 250-041-2259

The correct date is indeed 10-21 @ 1230 UTC/0830 EDT/0= 530 PDT.


Cheers,
=A0 Kurt Andersen
=A0 M^3AAWG Training Committee Co-Chair
--047d7b5d5c8273acec04e93f91f5-- From superuser@gmail.com Sun Oct 27 20:08: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 89DC611E8265 for ; Sun, 27 Oct 2013 20:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 4KiIDCwEI1JA for ; Sun, 27 Oct 2013 20:08:21 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4622711E82FA for ; Sun, 27 Oct 2013 20:08:17 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id n12so5883809wgh.11 for ; Sun, 27 Oct 2013 20:08:17 -0700 (PDT) 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=xRfH3gJzw6D31SMUsk1GSAT7PMwEgumxDfyvw26izkw=; b=tevdpBFQ3GZp5tdzPmL5igiLertgfy5StKxXEkhd+i4VFiKzaUfhJgZCZx6Ay7EtWa 49gJD8oRcvah4ul6DgKBtAe89tuK/axQX2Yc3nSbsPJhvZorRqZrIx7G4jmzZ3WyNUTc jORaY0MhiwbINbY7fxGXQ83gaCA+yp1GcjH+EuCDd8vHNUbezz1TM/lTOq5v/k6ktaps 01cgUjPH8ke6RBSzUjhw1JZcaLfbaD+ub9zWswxSBXfC3plE855ZPGguc/dpvTBIxQWL lTQmyOPm0PSi8FnKzYrMLiLMHlVNChFvuGchrkSTfd8GQf0h6ODTjgeU0RFRrvNuibZM iTDg== MIME-Version: 1.0 X-Received: by 10.180.83.194 with SMTP id s2mr7220453wiy.60.1382929697194; Sun, 27 Oct 2013 20:08:17 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Sun, 27 Oct 2013 20:08:17 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Oct 2013 20:08:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Kurt Andersen Content-Type: multipart/alternative; boundary=f46d0434bc1459c87a04e9c46955 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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, 28 Oct 2013 03:08:22 -0000 --f46d0434bc1459c87a04e9c46955 Content-Type: text/plain; charset=ISO-8859-1 Kurt, Was there any output from this meeting that would be of interest to this audience? I didn't get a chance to finish my draft updates before the posting embargo went into effect, but I hope to have something ready when it lifts on the 4th. Now would be a good time to have any relevant feedback. -MSK On Mon, Oct 21, 2013 at 5:38 AM, Kurt Andersen wrote: > The conference bridge is open now for anyone to attend - though I'm not > sure how well the audio pickup will work because of the configuration of > the room. > > > There will be an open discussion meeting hosted at the impending M^3AAWG > training day with a teleconference dial-in option for any interested > parties. The bridge line is: > > U.S. Toll Free Dial-In: 1-800-820-4690 > Direct (Toll): +1 702-696-5291 > International Toll Free: France #: 0800911910, Germany #: 08001824395 , > Spain #: 900941732, UK #: 08082348428 > > Conference Code: 250-041-2259 > > The correct date is indeed 10-21 @ 1230 UTC/0830 EDT/0530 PDT. > > Cheers, > Kurt Andersen > M^3AAWG Training Committee Co-Chair > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --f46d0434bc1459c87a04e9c46955 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Kurt,

Was there any output from this meeting t= hat would be of interest to this audience?

I didn't get a chance= to finish my draft updates before the posting embargo went into effect, bu= t I hope to have something ready when it lifts on the 4th.=A0 Now would be = a good time to have any relevant feedback.

-MSK



On Mon, Oct 21, 2013 at 5:38 AM, Kurt Andersen <kboth@dr= kurt.com> wrote:
The conference bridge is op= en now for anyone to attend - though I'm not sure how well the audio pi= ckup will work because of the configuration of the room.


There will be an open discussion meeting hosted at the impending M^= 3AAWG training day with a teleconference dial-in option for any interested=20 parties. The bridge line is:

U.S. Toll Free Dial-In:=A0=A0 1-800-820-4690
Direct (Toll): +1 702-696-5291=A0=A0=A0=A0
International Toll Free: France #: 0800911910, Germany #: 08001824395 = , Spain #: 900941732, UK #: 08082348428

Conference Code: 250-041-2259

The correct date is indeed 10-21 @ 1230 UTC/0830= EDT/0530 PDT.


Cheers,
=A0 Kurt Andersen
=A0 M^3AAWG Training Committee Co-Chair

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


--f46d0434bc1459c87a04e9c46955-- From prvs=007fc5310=kandersen@linkedin.com Tue Oct 29 14:14:44 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 3918411E8297 for ; Tue, 29 Oct 2013 14:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 a2Ni7j5bzO+U for ; Tue, 29 Oct 2013 14:14:40 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id B06D611E829A for ; Tue, 29 Oct 2013 14:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1383081278; x=1414617278; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=JmCq6/4tWfa3+xnxXPgtn8arO/DnknAcMHAIAsZw0II=; b=e0zt5dpnf0peWDDz5IoYoefCKFVTR+4MzksAfcnhHJwrACfrhp/CVwLF WnTdZSblMR5pv2StBZi/WVBaZLfqFgzBHAdNwKYkmQgWMSyMP27Wbm5CG 88DCWT0WLh6Y0Muk4cCo/Rj3VhEZiCILvNl6JdK5nt7H8uJT6xN/PSGB8 o=; X-IronPort-AV: E=Sophos;i="4.93,596,1378882800"; d="scan'208,217";a="68329218" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Tue, 29 Oct 2013 14:14:38 -0700 From: Kurt Andersen To: "Murray S. Kucherawy" , Kurt Andersen , Mike Hammer , Franck Martin , Mike Jones Thread-Topic: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 Thread-Index: AQHO04r2TzEYk8x9LUSvQXn0Xx+vLJoMMKcA Date: Tue, 29 Oct 2013 21:14:37 +0000 Message-ID: <3560C13B3A3EC9408B4BFEDB3B728395098759AA@ESV4-EXC02.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.251] Content-Type: multipart/alternative; boundary="_000_3560C13B3A3EC9408B4BFEDB3B728395098759AAESV4EXC02linked_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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, 29 Oct 2013 21:14:44 -0000 --_000_3560C13B3A3EC9408B4BFEDB3B728395098759AAESV4EXC02linked_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It would be good to get Mike Hammer, Franck Martin and Mike Jone's take on = the discussion too. I did not take notes per se but the room was pretty pac= ked with attendees. The general take-away is that people are interested, bu= t feel like the steps to get started (beyond publishing the DNS record =96 = more along the lines of what do I do with the reports I get back) are still= unclear. I would say that the attendees in the room probably represent the next "seg= ment" in the adoption curve beyond the early adopters group. They are looki= ng for a bit more of a turn-key approach or are looking for the value equat= ion to implement for either smaller receivers and senders or enterprise dep= loyments (which are frequently both senders and receivers). One topic that received some discussion was around the best way to deal wit= h third-parties and DMARC =96 how to do it, etc. Mike, Mike, Franck =96 care to chime in with any other thoughts? --Kurt On 2013-10-27 20:08 , "Murray S. Kucherawy" > wrote: Kurt, Was there any output from this meeting that would be of interest to this au= dience? I didn't get a chance to finish my draft updates before the posting embargo= went into effect, but I hope to have something ready when it lifts on the = 4th. Now would be a good time to have any relevant feedback. -MSK On Mon, Oct 21, 2013 at 5:38 AM, Kurt Andersen > wrote: The conference bridge is open now for anyone to attend - though I'm not sur= e how well the audio pickup will work because of the configuration of the r= oom. There will be an open discussion meeting hosted at the impending M^3AAWG tr= aining day with a teleconference dial-in option for any interested parties.= The bridge line is: U.S. Toll Free Dial-In: 1-800-820-4690 Direct (Toll): +1 702-696-5291 International Toll Free: France #: 0800911910, Germany #: 08001824395 , Spa= in #: 900941732, UK #: 08082348428 Conference Code: 250-041-2259 The correct date is indeed 10-21 @ 1230 UTC/0830 EDT/0530 PDT. Cheers, Kurt Andersen M^3AAWG Training Committee Co-Chair _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --_000_3560C13B3A3EC9408B4BFEDB3B728395098759AAESV4EXC02linked_ Content-Type: text/html; charset="Windows-1252" Content-ID: <786931FD4697F248AF268A2AF4984E8B@linkedin.com> Content-Transfer-Encoding: quoted-printable
It would be good to get Mike Hammer, Franck Martin and Mike Jone's tak= e on the discussion too. I did not take notes per se but the room was prett= y packed with attendees. The general take-away is that people are intereste= d, but feel like the steps to get started (beyond publishing the DNS record =96 more along the lines of what= do I do with the reports I get back) are still unclear.

I would say that the attendees in the room probably represent the next= "segment" in the adoption curve beyond the early adopters group.= They are looking for a bit more of a turn-key approach or are looking for = the value equation to implement for either smaller receivers and senders or enterprise deployments (which are frequen= tly both senders and receivers).

One topic that received some discussion was around the best way to dea= l with third-parties and DMARC =96 how to do it, etc.

Mike, Mike, Franck =96 care to chime in with any other thoughts?

--Kurt

On 2013-10-27 20:08 , "Murray S. Kucherawy" <superuser@gmail.com> wrote:

Kurt,

Was there any output from this meeting that would be of interest to this au= dience?

I didn't get a chance to finish my draft updates before the posting embargo= went into effect, but I hope to have something ready when it lifts on the = 4th.  Now would be a good time to have any relevant feedback.

-MSK



On Mon, Oct 21, 2013 at 5:38 AM, Kurt Andersen <= span dir=3D"ltr"> <kboth@drkurt.com<= /a>> wrote:
The conference bridge is open now for anyone to attend - t= hough I'm not sure how well the audio pickup will work because of the confi= guration of the room.


There will be an open discussion meeting hosted at the impending M^3AAWG tr= aining day with a teleconference dial-in option for any interested parties.= The bridge line is:

Direct (Toll): +1 702-696-5291    
International Toll Free: France #: 0800911910, Germany #: 08001824395 = , Spain #: 900941732, UK #: 08082348428

Conference Code: 250-041-2259

The correct date is indeed 10-21 @ 1230 UTC/0830 EDT/0530 PD= T.


Cheers,
  Kurt Andersen
  M^3AAWG Training Committee Co-Chair

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


 --_000_3560C13B3A3EC9408B4BFEDB3B728395098759AAESV4EXC02linked_-- From R.E.Sonneveld@sonnection.nl Tue Oct 29 14:20:46 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 E36A211E8297 for ; Tue, 29 Oct 2013 14:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 1EyCDZRT66W8 for ; Tue, 29 Oct 2013 14:20:41 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 410CF11E8295 for ; Tue, 29 Oct 2013 14:20:40 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3d8Qgp6dxWz5Mhcq; Tue, 29 Oct 2013 22:20:38 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3d8Qgp5NxWz5MhcZ; Tue, 29 Oct 2013 22:20:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 5D1C2122F0A; Tue, 29 Oct 2013 22:20:38 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NsrXGSm8DnK5; Tue, 29 Oct 2013 22:20:34 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 2C841122F07; Tue, 29 Oct 2013 22:20:34 +0100 (CET) Message-ID: <527026A1.2070104@sonnection.nl> Date: Tue, 29 Oct 2013 22:20:33 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Kurt Andersen , "Murray S. Kucherawy" , Kurt Andersen , Mike Hammer , Franck Martin , Mike Jones References: <3560C13B3A3EC9408B4BFEDB3B728395098759AA@ESV4-EXC02.linkedin.biz> In-Reply-To: <3560C13B3A3EC9408B4BFEDB3B728395098759AA@ESV4-EXC02.linkedin.biz> Content-Type: multipart/alternative; boundary="------------080301060309010304070509" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1383081638; bh=IvrjAC0Z5sJuAPwh6+Y4acpaX8QsqCpxrTM5JIkNyWE=; h=Message-ID:Date:From:To:Subject:From; b=WeOm0YpckbJcBnJWIXuaK2HSsbveYKy620j+y6k223GLjZnqi64dXjWJjt7ZHoYPp wyZmh9zynQH1C7ZKVEpn/KxIh152DkoBAgQjdGC8XqRIfG2+VLtNg7zLV9HLao4oY/ ufxMVLmpg9LQA1cFSg6/zoU8L2I9B0PwPSmC/B98= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3d8Qgp6dxWz5Mhcq Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl 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, 29 Oct 2013 21:20:47 -0000 This is a multi-part message in MIME format. --------------080301060309010304070509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kurt, On 10/29/2013 10:14 PM, Kurt Andersen wrote: > It would be good to get Mike Hammer, Franck Martin and Mike Jone's > take on the discussion too. I did not take notes per se but the room > was pretty packed with attendees. The general take-away is that people > are interested, but feel like the steps to get started (beyond > publishing the DNS record -- more along the lines of what do I do with > the reports I get back) are still unclear. > > I would say that the attendees in the room probably represent the next > "segment" in the adoption curve beyond the early adopters group. They > are looking for a bit more of a turn-key approach or are looking for > the value equation to implement for either smaller receivers and > senders or enterprise deployments (which are frequently both senders > and receivers). > > One topic that received some discussion was around the best way to > deal with third-parties and DMARC -- how to do it, etc. > > Mike, Mike, Franck -- care to chime in with any other thoughts? is there an audio/video/jabber/meetecho/whatever recording of the meeting available? /rolf --------------080301060309010304070509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Kurt,

On 10/29/2013 10:14 PM, Kurt Andersen wrote:
It would be good to get Mike Hammer, Franck Martin and Mike Jone's take on the discussion too. I did not take notes per se but the room was pretty packed with attendees. The general take-away is that people are interested, but feel like the steps to get started (beyond publishing the DNS record – more along the lines of what do I do with the reports I get back) are still unclear.

I would say that the attendees in the room probably represent the next "segment" in the adoption curve beyond the early adopters group. They are looking for a bit more of a turn-key approach or are looking for the value equation to implement for either smaller receivers and senders or enterprise deployments (which are frequently both senders and receivers).

One topic that received some discussion was around the best way to deal with third-parties and DMARC – how to do it, etc.

Mike, Mike, Franck – care to chime in with any other thoughts?

is there an audio/video/jabber/meetecho/whatever recording of the meeting available?

/rolf

--------------080301060309010304070509-- From prvs=007fc5310=kandersen@linkedin.com Tue Oct 29 14:41:15 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 9030C11E829A for ; Tue, 29 Oct 2013 14:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] 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 a2YpyTyROElO for ; Tue, 29 Oct 2013 14:41:11 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 56EFA21E809B for ; Tue, 29 Oct 2013 14:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1383082866; x=1414618866; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=2LnL7Ajop13ZuRj/cMqU5ou+sITturd6ImNu9R9MyHs=; b=yXGR78xPZAAwLF5EukouLuMaxtBmWRkl0ldtc/sLHjMCuSBtThSSu7nn Fo8kObQdzudbW/3ZryD28BXoFn+3NYOLvSjd+4r6uHUUGzdoH/aWmZyTs vWiNPFWJzl4DkZpGndaAK9T0JogAooG8D5qlT4MWPpQL8fWxbkw/qH9LO 0=; X-IronPort-AV: E=Sophos;i="4.93,596,1378882800"; d="scan'208,217";a="69071985" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 29 Oct 2013 14:40:59 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Tue, 29 Oct 2013 14:41:00 -0700 From: Kurt Andersen To: "R.E.Sonneveld@sonnection.nl" Thread-Topic: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 Thread-Index: AQHO04r2TzEYk8x9LUSvQXn0Xx+vLJoMMKcAgAB3AoD//5BcAA== Date: Tue, 29 Oct 2013 21:40:59 +0000 Message-ID: <3560C13B3A3EC9408B4BFEDB3B72839509875BE4@ESV4-EXC02.linkedin.biz> In-Reply-To: <527026A1.2070104@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: multipart/alternative; boundary="_000_3560C13B3A3EC9408B4BFEDB3B72839509875BE4ESV4EXC02linked_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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, 29 Oct 2013 21:41:15 -0000 --_000_3560C13B3A3EC9408B4BFEDB3B72839509875BE4ESV4EXC02linked_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2013-10-29 14:20 , "Rolf E. Sonneveld" > wrote: > > is there an audio/video/jabber/meetecho/whatever recording of the meeting= available? No. --_000_3560C13B3A3EC9408B4BFEDB3B72839509875BE4ESV4EXC02linked_ Content-Type: text/html; charset="us-ascii" Content-ID: <0150F4300CC64C4C8D65469BEB05C148@linkedin.com> Content-Transfer-Encoding: quoted-printable
On 2013-10-29 14:20 , "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl> wrote:=
> 
> is there an audio/video/jabb= er/meetecho/whatever recording of the meeting available?
No.



 --_000_3560C13B3A3EC9408B4BFEDB3B72839509875BE4ESV4EXC02linked_-- From prvs=00766df5d=fmartin@linkedin.com Tue Oct 29 15:03:48 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 7802921F8E97 for ; Tue, 29 Oct 2013 15:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.664 X-Spam-Level: X-Spam-Status: No, score=-5.664 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 xfb5mcfUb31e for ; Tue, 29 Oct 2013 15:03:44 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C69921F9D18 for ; Tue, 29 Oct 2013 15:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1383084224; x=1414620224; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CwoFuUnQpR65+/+3r7tKLVED+uUlq3Ir4RkIJKs2WoU=; b=YFwvwm10l/YonXxt7kzSuawFcPamOhO4Yqi3h4xU1+nWNBwygldvMera LanaJXJ5nTGB/si232AbAqxyz0FhFYTWuZhgwBdRmBmyB1BptQneE4TYu ftoaDmVtsXl6nOQOcpd76KtYa1OpxFUJ8BH3/LEPovzHq7LRPyx5B1Y2L Q=; X-IronPort-AV: E=Sophos;i="4.93,596,1378882800"; d="asc'?scan'208,217";a="68336091" Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Tue, 29 Oct 2013 15:03:43 -0700 From: Franck Martin To: Kurt Andersen Thread-Topic: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 Thread-Index: AQHO04sRr6FRNwhtMU+egHlzef0NjJoMpgGAgAABqICAAAW2gIAABleA Date: Tue, 29 Oct 2013 22:03:42 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE6ABAEF02@ESV4-MBX02.linkedin.biz> References: <3560C13B3A3EC9408B4BFEDB3B72839509875BE4@ESV4-EXC02.linkedin.biz> In-Reply-To: <3560C13B3A3EC9408B4BFEDB3B72839509875BE4@ESV4-EXC02.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/signed; boundary="Apple-Mail=_BAFF1D9C-7205-4D0E-8273-70C3B8D49FC0"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: "R.E.Sonneveld@sonnection.nl" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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, 29 Oct 2013 22:03:48 -0000 --Apple-Mail=_BAFF1D9C-7205-4D0E-8273-70C3B8D49FC0 Content-Type: multipart/alternative; boundary="Apple-Mail=_A1896365-DC7D-4560-A74D-843541E90782" --Apple-Mail=_A1896365-DC7D-4560-A74D-843541E90782 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We put on one slide a quick FAQ to remove the common questions (and = corrected them), I hope to have it published on dmarc.org site I found out that people like the idea of controlling your email streams = when you are in p=3Dreject as much as fighting exact domain spoofing. The dream of an IT administrator, no one in your organization can send = an email with your domain, without talking to you :P On Oct 29, 2013, at 2:40 PM, Kurt Andersen = wrote: > On 2013-10-29 14:20 , "Rolf E. Sonneveld" = wrote: > >=20 > > is there an audio/video/jabber/meetecho/whatever recording of the = meeting available? >=20 > No. --Apple-Mail=_A1896365-DC7D-4560-A74D-843541E90782 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii We put on one slide a quick FAQ to remove the common questions (and corrected them), I hope to have it published on dmarc.org site

I found out that people like the idea of controlling your email streams when you are in p=reject as much as fighting exact domain spoofing.

The dream of an IT administrator, no one in your organization can send an email with your domain, without talking to you :P

On Oct 29, 2013, at 2:40 PM, Kurt Andersen <kandersen@linkedin.com> wrote:

On 2013-10-29 14:20 , "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl> wrote:
> 
> is there an audio/video/jabber/meetecho/whatever recording of the meeting available?
No.

--Apple-Mail=_A1896365-DC7D-4560-A74D-843541E90782-- --Apple-Mail=_BAFF1D9C-7205-4D0E-8273-70C3B8D49FC0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJScDC9AAoJEJHd9Bbysc+a3jAH/jDPdKWagRP7maa7PaaajXgL UuMu5vReAzqBVndiQx81h0CBg1A61dYVUb9us7U5ZSholN7ROJSzcoXJ2rUCecun b6S6ksT4ZgX+/v7I4vFIOpF6iYfuRQxuj/HzqsB4cJaK6kmCrT77UBpQqJK0243n MPCwCsovKPU5A8OXfhxMSCbci+ggqFU2XE6vnzUhmdCYR2OcQd5txXO5kKc6eT5u Yhnbz3+o4KlGtbfUqjCmC03v+n+ij11v2Hq/mWbYLvW0rdSY/Ge07SUPkuW6K9mh cQQf64VjpYw+xaKEy1iK5F9vUz4pNfFPbVe9kiJS1kV5TzTN3QkhJo68UrqHHYk= =pHSI -----END PGP SIGNATURE----- --Apple-Mail=_BAFF1D9C-7205-4D0E-8273-70C3B8D49FC0-- From MHammer@ag.com Thu Oct 31 06:35:21 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 E250321F9DB8 for ; Thu, 31 Oct 2013 06:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=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 V5bxsoLsjUbq for ; Thu, 31 Oct 2013 06:35:13 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECDF11E8196 for ; Thu, 31 Oct 2013 06:35:08 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Thu, 31 Oct 2013 09:34:59 -0400 From: "MH Michael Hammer (5304)" To: Kurt Andersen , "Murray S. Kucherawy" , Kurt Andersen , Franck Martin , Mike Jones Thread-Topic: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 Thread-Index: AQHO04sFqeAz1eJ7A0u/TJAz5iGYMJoMc7aAgAJeXUA= Date: Thu, 31 Oct 2013 13:34:59 +0000 Message-ID: References: <3560C13B3A3EC9408B4BFEDB3B728395098759AA@ESV4-EXC02.linkedin.biz> In-Reply-To: <3560C13B3A3EC9408B4BFEDB3B728395098759AA@ESV4-EXC02.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.201] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CE39F90A45FF0C49A1EA229FC9899B0507C4C3EDUSCLES544agnaam_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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: Thu, 31 Oct 2013 13:35:21 -0000 --_000_CE39F90A45FF0C49A1EA229FC9899B0507C4C3EDUSCLES544agnaam_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apologies for my delayed response. I was impressed with the number of people in the room but only a small numb= er appeared to be truly engaged in the conversation. Perhaps it was too ear= ly in the morning. Based on a question someone asked me afterwards - "Why weren't we shown how= to create a record?" - it appears that some people don't even understand h= ow to publish a DMARC record. Other than that, the questions/comments were what I call the "usual suspect= s": 1) How to deal with the mailing list issue for organizations with end = users on the domain desired to be protected. 2) How can we implement validation when our vendor doesn't support it?= (A number of major vendors will be announcing support over the next few qu= arters - speak with your vendor) 3) How to handle 3rd parties mailing on our behalf. 4) The <> bounce issue. So no particular suprises. I do think it was useful to have the meeting and= I think we should try to organize meetings/sessions in conjunction with ot= her events. From: Kurt Andersen [mailto:kandersen@linkedin.com] Sent: Tuesday, October 29, 2013 5:15 PM To: Murray S. Kucherawy; Kurt Andersen; MH Michael Hammer (5304); Franck Ma= rtin; Mike Jones Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 = 0830-0930 UTC-0400 It would be good to get Mike Hammer, Franck Martin and Mike Jone's take on = the discussion too. I did not take notes per se but the room was pretty pac= ked with attendees. The general take-away is that people are interested, bu= t feel like the steps to get started (beyond publishing the DNS record - mo= re along the lines of what do I do with the reports I get back) are still u= nclear. I would say that the attendees in the room probably represent the next "seg= ment" in the adoption curve beyond the early adopters group. They are looki= ng for a bit more of a turn-key approach or are looking for the value equat= ion to implement for either smaller receivers and senders or enterprise dep= loyments (which are frequently both senders and receivers). One topic that received some discussion was around the best way to deal wit= h third-parties and DMARC - how to do it, etc. Mike, Mike, Franck - care to chime in with any other thoughts? --Kurt --_000_CE39F90A45FF0C49A1EA229FC9899B0507C4C3EDUSCLES544agnaam_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Apologies for my delayed = response.

 <= /p>

I was impressed with the = number of people in the room but only a small number appeared to be truly e= ngaged in the conversation. Perhaps it was too early in the morning.

 <= /p>

Based on a question someo= ne asked me afterwards – “Why weren’t we shown how to cre= ate a record?” - it appears that some people don’t even underst= and how to publish a DMARC record.

 <= /p>

Other than that, the ques= tions/comments were what I call the “usual suspects”:

 <= /p>

1) = ;     How to deal with = the mailing list issue for organizations with end users on the domain desir= ed to be protected.

2) = ;     How can we implem= ent validation when our vendor doesn’t support it? (A number of major= vendors will be announcing support over the next few quarters – speak with your vendor)

3) = ;     How to handle 3rd parties mailing on our behalf.

4) = ;     The <> boun= ce issue.

 <= /p>

So no particular suprises= . I do think it was useful to have the meeting and I think we should try to= organize meetings/sessions in conjunction with other events.

 <= /p>

From: Kurt And= ersen [mailto:kandersen@linkedin.com]
Sent: Tuesday, October 29, 2013 5:15 PM
To: Murray S. Kucherawy; Kurt Andersen; MH Michael Hammer (5304); Fr= anck Martin; Mike Jones
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013= -10-20 0830-0930 UTC-0400

 

It would be good to get Mik= e Hammer, Franck Martin and Mike Jone's take on the discussion too. I did n= ot take notes per se but the room was pretty packed with attendees. The general take-away is that people are interested, but feel l= ike the steps to get started (beyond publishing the DNS record – more= along the lines of what do I do with the reports I get back) are still unc= lear.

 <= /p>

I would say that the attend= ees in the room probably represent the next "segment" in the adop= tion curve beyond the early adopters group. They are looking for a bit more of a turn-key approach or are looking for the value equation to i= mplement for either smaller receivers and senders or enterprise deployments= (which are frequently both senders and receivers).

 

One topic that received som= e discussion was around the best way to deal with third-parties and DMARC &= #8211; how to do it, etc.

 

Mike, Mike, Franck – = care to chime in with any other thoughts?

 

--Kurt

 

--_000_CE39F90A45FF0C49A1EA229FC9899B0507C4C3EDUSCLES544agnaam_-- From mjones@agari.com Thu Oct 31 08:40:55 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 8F68D11E8167 for ; Thu, 31 Oct 2013 08:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 p250kRbTEN5A for ; Thu, 31 Oct 2013 08:40:54 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 8B01321F9E43 for ; Thu, 31 Oct 2013 08:40:54 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id w10so2533571pde.2 for ; Thu, 31 Oct 2013 08:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GKVceaYfzOuBpT/Lk/muq8OODrpXtXgUUycnc1uoOac=; b=bRP37quWHNmAv2qcZx135deQLKk077X+N0NXnt07b2Nx/9wgUIOSYN6WHjQrVEnXAN ZlC1p61nAPu+bztdLYjsLbqMMSWgHxqijT7AE2qd7ChSivZ6cSZv3kxp2RG9H2wSCadM IpE/LFE/z7XrJ3uK2GOsJC1Mu4hg5wz9Qq4LQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=GKVceaYfzOuBpT/Lk/muq8OODrpXtXgUUycnc1uoOac=; b=K7zAbAFaqci2ry0QJHPbwsgYPjAw0f+Cn7c0qK+iPJ7f/vrU9Wt2kQS/2hfWHdgKCR vt2EySv1W9bQnWfKCsiXM23WfVrOsChnclwtArpmnWuKNg4nj66sGMtTJ1DCcG7rEeDD MqAcJjlqZcT/vu7DoWC1SSv5SUiQX67zt10vyYDdbrIWN9Yr7DC4R9l/f7m7r86gphpR 7xW+1a/+yja3H6UWUWbdXHGCHz2BU5vvqwJxBS8wKTZHxzZi/S2gFaoTJ4+3VWVckCgF 9puLnfDVEBRFfzQ+C5JIyr/KYOR2vZaoRNxErDf1HGyWabbL5ho+r38bFSvUP+9MM9x1 c1Ng== X-Gm-Message-State: ALoCoQlpNGMd5hPoWo7eqCnYYmB6FvSBleL8cu3XKbRGTKusjv7sPg8p0KOM9saMeSzTDiCufRyQ X-Received: by 10.68.197.1 with SMTP id iq1mr2581612pbc.131.1383234054154; Thu, 31 Oct 2013 08:40:54 -0700 (PDT) Received: from [192.168.0.14] (c-24-4-3-179.hsd1.ca.comcast.net. [24.4.3.179]) by mx.google.com with ESMTPSA id xe9sm6288899pab.0.2013.10.31.08.40.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 08:40:52 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_318FC9EC-3727-42D7-9972-DB59BE914FAC" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Mike Jones In-Reply-To: Date: Thu, 31 Oct 2013 08:40:51 -0700 Message-Id: <8706792D-6B91-4E51-889E-7FDF26B798A3@agari.com> References: <3560C13B3A3EC9408B4BFEDB3B728395098759AA@ESV4-EXC02.linkedin.biz> To: "MH Michael Hammer (5304)" , Kurt Andersen , "dmarc@ietf.org" X-Mailer: Apple Mail (2.1510) Cc: Franck Martin , Kurt Andersen , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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: Thu, 31 Oct 2013 15:40:55 -0000 --Apple-Mail=_318FC9EC-3727-42D7-9972-DB59BE914FAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree with all of Mike's summary. I would add that in addition to the = question Mike received about creating a DMARC record, there were a = couple of other very basic questions about DMARC. To me it indicated = that even in a crowd like MAWWG where DMARC has been discussed for some = time, training has occurred, and the general level of email expertise is = high, there is still a need for a BCP document and continued education. =20= Mike J. On Oct 31, 2013, at 6:34 AM, MH Michael Hammer (5304) = wrote: > Apologies for my delayed response. > =20 > I was impressed with the number of people in the room but only a small = number appeared to be truly engaged in the conversation. Perhaps it was = too early in the morning. > =20 > Based on a question someone asked me afterwards =96 =93Why weren=92t = we shown how to create a record?=94 - it appears that some people don=92t = even understand how to publish a DMARC record. > =20 > Other than that, the questions/comments were what I call the =93usual = suspects=94: > =20 > 1) How to deal with the mailing list issue for organizations with = end users on the domain desired to be protected. > 2) How can we implement validation when our vendor doesn=92t = support it? (A number of major vendors will be announcing support over = the next few quarters =96 speak with your vendor) > 3) How to handle 3rd parties mailing on our behalf. > 4) The <> bounce issue. > =20 > So no particular suprises. I do think it was useful to have the = meeting and I think we should try to organize meetings/sessions in = conjunction with other events. > =20 > From: Kurt Andersen [mailto:kandersen@linkedin.com]=20 > Sent: Tuesday, October 29, 2013 5:15 PM > To: Murray S. Kucherawy; Kurt Andersen; MH Michael Hammer (5304); = Franck Martin; Mike Jones > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday = 2013-10-20 0830-0930 UTC-0400 > =20 > It would be good to get Mike Hammer, Franck Martin and Mike Jone's = take on the discussion too. I did not take notes per se but the room was = pretty packed with attendees. The general take-away is that people are = interested, but feel like the steps to get started (beyond publishing = the DNS record =96 more along the lines of what do I do with the reports = I get back) are still unclear. > =20 > I would say that the attendees in the room probably represent the next = "segment" in the adoption curve beyond the early adopters group. They = are looking for a bit more of a turn-key approach or are looking for the = value equation to implement for either smaller receivers and senders or = enterprise deployments (which are frequently both senders and = receivers). > =20 > One topic that received some discussion was around the best way to = deal with third-parties and DMARC =96 how to do it, etc. > =20 > Mike, Mike, Franck =96 care to chime in with any other thoughts? > =20 > --Kurt --Apple-Mail=_318FC9EC-3727-42D7-9972-DB59BE914FAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I agree with all of Mike's = summary. I would add that in addition to the question Mike received = about creating a DMARC record, there were a couple of other very basic = questions about DMARC.  To me it indicated that even in a crowd = like MAWWG where DMARC has been discussed for some time, training has = occurred, and the general level of email expertise is high, there is = still a need for a BCP document and continued education. =  

Mike J.
MHammer@ag.com> = wrote:

Apologies for my delayed = response.
 
I was impressed with the number of people in = the room but only a small number appeared to be truly engaged in the = conversation. Perhaps it was too early in the = morning.
 
Based on a question someone asked me = afterwards =96 =93Why weren=92t we shown how to create a record?=94 - it = appears that some people don=92t even understand how to publish a DMARC = record.
 
Other than that, the questions/comments were = what I call the =93usual suspects=94:
 
1) How to deal with the mailing list issue for = organizations with end users on the domain desired to be = protected.
2) How can we implement validation when our vendor = doesn=92t support it? (A number of major vendors will be announcing = support over the next few quarters =96 speak with your = vendor)
3) How to handle 3rd parties mailing on our = behalf.
4) The <> bounce = issue.
 
So no particular suprises. I do think it was = useful to have the meeting and I think we should try to organize = meetings/sessions in conjunction with other = events.
 
 Kurt = Andersen [mailto:kandersen@linkedin.com] 
Sent: Tuesday, October 29, 2013 = 5:15 PM
To: Murray S. Kucherawy; Kurt = Andersen; MH Michael Hammer (5304); Franck Martin; Mike = Jones
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Open DMARC = discussion meeting: Monday 2013-10-20 0830-0930 = UTC-0400
It would = be good to get Mike Hammer, Franck Martin and Mike Jone's take on the = discussion too. I did not take notes per se but the room was pretty = packed with attendees. The general take-away is that people are = interested, but feel like the steps to get started (beyond publishing = the DNS record =96 more along the lines of what do I do with the reports = I get back) are still unclear.
I would = say that the attendees in the room probably represent the next "segment" = in the adoption curve beyond the early adopters group. They are looking = for a bit more of a turn-key approach or are looking for the value = equation to implement for either smaller receivers and senders or = enterprise deployments (which are frequently both senders and = receivers).
One = topic that received some discussion was around the best way to deal with = third-parties and DMARC =96 how to do it, = etc.
Mike, = Mike, Franck =96 care to chime in with any other = thoughts?
, Franck Martin , "dmarc@ietf.org" , "Murray S. Kucherawy" , Kurt Andersen Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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: Thu, 31 Oct 2013 16:23:49 -0000 MAAWG newcomers tend to gravitate to these discussions, so that's part of the reason why it feels like the same questions are asked over and over. FWIW, I knew the answer to the question I asked; I didn't see it in Franck's slides and wanted to hear it answered. I thought some of the people in the room probably didn't even know what to ask, it was pretty quiet. It was helpful to hear both Franck's and Mike's answers to the same question, which are pretty much opposite ends of the spectrum ("we hold individual users to the same constraints as our automated messages," vs. "we know our users will never adhere to this, so we put them in a different domain entirely.") On Thu, Oct 31, 2013 at 8:40 AM, Mike Jones wrote: > I agree with all of Mike's summary. I would add that in addition to the > question Mike received about creating a DMARC record, there were a couple= of > other very basic questions about DMARC. To me it indicated that even in = a > crowd like MAWWG where DMARC has been discussed for some time, training h= as > occurred, and the general level of email expertise is high, there is stil= l a > need for a BCP document and continued education. > > Mike J. > > > > On Oct 31, 2013, at 6:34 AM, MH Michael Hammer (5304) > wrote: > > Apologies for my delayed response. > > I was impressed with the number of people in the room but only a small > number appeared to be truly engaged in the conversation. Perhaps it was t= oo > early in the morning. > > Based on a question someone asked me afterwards =96 =93Why weren=92t we s= hown how > to create a record?=94 - it appears that some people don=92t even underst= and how > to publish a DMARC record. > > Other than that, the questions/comments were what I call the =93usual > suspects=94: > > 1) How to deal with the mailing list issue for organizations with en= d > users on the domain desired to be protected. > 2) How can we implement validation when our vendor doesn=92t support= it? > (A number of major vendors will be announcing support over the next few > quarters =96 speak with your vendor) > 3) How to handle 3rd parties mailing on our behalf. > 4) The <> bounce issue. > > So no particular suprises. I do think it was useful to have the meeting a= nd > I think we should try to organize meetings/sessions in conjunction with > other events. > > From: Kurt Andersen [mailto:kandersen@linkedin.com] > Sent: Tuesday, October 29, 2013 5:15 PM > To: Murray S. Kucherawy; Kurt Andersen; MH Michael Hammer (5304); Franck > Martin; Mike Jones > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-2= 0 > 0830-0930 UTC-0400 > > It would be good to get Mike Hammer, Franck Martin and Mike Jone's take o= n > the discussion too. I did not take notes per se but the room was pretty > packed with attendees. The general take-away is that people are intereste= d, > but feel like the steps to get started (beyond publishing the DNS record = =96 > more along the lines of what do I do with the reports I get back) are sti= ll > unclear. > > I would say that the attendees in the room probably represent the next > "segment" in the adoption curve beyond the early adopters group. They are > looking for a bit more of a turn-key approach or are looking for the valu= e > equation to implement for either smaller receivers and senders or enterpr= ise > deployments (which are frequently both senders and receivers). > > One topic that received some discussion was around the best way to deal w= ith > third-parties and DMARC =96 how to do it, etc. > > Mike, Mike, Franck =96 care to chime in with any other thoughts? > > --Kurt > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From prvs=00912ddd0=kandersen@linkedin.com Thu Oct 31 09:49:46 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 19EC811E8173 for ; Thu, 31 Oct 2013 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.592 X-Spam-Level: X-Spam-Status: No, score=-5.592 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] 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 vTnt4rv5U7wn for ; Thu, 31 Oct 2013 09:49:42 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3B41B11E823D for ; Thu, 31 Oct 2013 09:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1383238180; x=1414774180; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Vaamu655eUm9C3AWKIHNmX87Vvz4JRhh34ZGr44wvfg=; b=qRhZwK4BA76q5huzC8+uO4miRTgj05LOLSDVDdv7tD9eMsGUDn9VStK+ TcvvW7zncQEJ5zKtzkEqo1NBgD+7Am8GBJ0E4pjxrLsLgUjy/ThHilGUU CfOj1Fv4C5wu+2H/Uf3QTnZ30hRPgIxCtMjsBX96f9dlbJ09rn7eRfSBD E=; X-IronPort-AV: E=Sophos;i="4.93,609,1378882800"; d="scan'208,217";a="68600064" Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Thu, 31 Oct 2013 09:49:37 -0700 From: Kurt Andersen To: Kurt Andersen , "Murray S. Kucherawy" , Kurt Andersen , Mike Hammer , Franck Martin , Mike Jones Thread-Topic: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 Thread-Index: AQHO04r2TzEYk8x9LUSvQXn0Xx+vLJoMMKcAgALanQA= Date: Thu, 31 Oct 2013 16:49:36 +0000 Message-ID: <3560C13B3A3EC9408B4BFEDB3B7283950987B387@ESV4-EXC02.linkedin.biz> In-Reply-To: <3560C13B3A3EC9408B4BFEDB3B728395098759AA@ESV4-EXC02.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.251] Content-Type: multipart/alternative; boundary="_000_3560C13B3A3EC9408B4BFEDB3B7283950987B387ESV4EXC02linked_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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: Thu, 31 Oct 2013 16:49:46 -0000 --_000_3560C13B3A3EC9408B4BFEDB3B7283950987B387ESV4EXC02linked_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One more note, it was a bit disconcerting to see that ~80% of the 50 or so = attendees were unaware of the existence of the DMARC training videos that M= 3AAWG has made freely available on its public site. Another point of public awareness that could use a boost. --Kurt --_000_3560C13B3A3EC9408B4BFEDB3B7283950987B387ESV4EXC02linked_ Content-Type: text/html; charset="us-ascii" Content-ID: <6529F9AC3425684786345F7976CEA991@linkedin.com> Content-Transfer-Encoding: quoted-printable
One more note, it was a bit disconcerting to see that ~80% of the 50 o= r so attendees were unaware of the existence of the DMARC training videos t= hat M3AAWG has made freely available on its public site. 

Another point of public awareness that could use a boost.

--Kurt


 --_000_3560C13B3A3EC9408B4BFEDB3B7283950987B387ESV4EXC02linked_-- From prvs=009aea02a=fmartin@linkedin.com Thu Oct 31 09:51:09 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 E933B11E823D for ; Thu, 31 Oct 2013 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_110=0.6, RCVD_IN_DNSWL_MED=-4] 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 Y3nu3r20njQU for ; Thu, 31 Oct 2013 09:51:06 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB4A11E822D for ; Thu, 31 Oct 2013 09:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1383238265; x=1414774265; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PQYhSITM+VxhpqwXmtUeDdWKsq47qAxENian0SQQc+Y=; b=H8vwZq6hbvXaLIYtI4/5euvCAK3QmAx72Iypy0MRRM5lEy8a0aKxJw6G A2O0/FT5viRHUb+9fWibPE71J5tdhje31J+XLhN66ofpgpeoeOaw/UEuZ 4W6N+h6QX95GOXuTwC/Cwc3nmr1bF9uxD4sA3b+Hr38CWXu/Xn7vrI2ve A=; X-IronPort-AV: E=Sophos;i="4.93,609,1378882800"; d="asc'?scan'208";a="68600284" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 31 Oct 2013 09:51:05 -0700 Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Thu, 31 Oct 2013 09:51:05 -0700 From: Franck Martin To: John Sweet Thread-Topic: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 Thread-Index: AQHO04sRr6FRNwhtMU+egHlzef0NjJoMpgGAgAKkPoCAACMrgIAAC+KAgAAHu4A= Date: Thu, 31 Oct 2013 16:51:05 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE6ABC0E73@ESV4-MBX02.linkedin.biz> References: <3560C13B3A3EC9408B4BFEDB3B728395098759AA@ESV4-EXC02.linkedin.biz> <8706792D-6B91-4E51-889E-7FDF26B798A3@agari.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: multipart/signed; boundary="Apple-Mail=_7937DA1A-F764-4547-95EA-F0EB55AF66AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: Kurt Andersen , Mike Jones , "MH Michael Hammer \(5304\)" , "dmarc@ietf.org" , Kurt Andersen , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Open DMARC discussion meeting: Monday 2013-10-20 0830-0930 UTC-0400 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: Thu, 31 Oct 2013 16:51:10 -0000 --Apple-Mail=_7937DA1A-F764-4547-95EA-F0EB55AF66AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Oh, and there is a middle ground https://dmarcian.com/dmarc-inspector/google.com with p=3Dquarantine you have the benefit of DMARC without annoying = mailing list administrators, but it is known that people go in their = spam folder to act on fake messages... For the how to create a DMARC record, there was on point 2 of the slide, = what initial record to publish.... On Oct 31, 2013, at 9:23 AM, John Sweet wrote: > MAAWG newcomers tend to gravitate to these discussions, so that's part > of the reason why it feels like the same questions are asked over and > over. >=20 > FWIW, I knew the answer to the question I asked; I didn't see it in > Franck's slides and wanted to hear it answered. I thought some of the > people in the room probably didn't even know what to ask, it was > pretty quiet. >=20 > It was helpful to hear both Franck's and Mike's answers to the same > question, which are pretty much opposite ends of the spectrum ("we > hold individual users to the same constraints as our automated > messages," vs. "we know our users will never adhere to this, so we put > them in a different domain entirely.") >=20 --Apple-Mail=_7937DA1A-F764-4547-95EA-F0EB55AF66AD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJScop4AAoJEJHd9Bbysc+ahrYIAJ+GZZiJQ9zZxEC0OIHSgAvm Z6DO+/l8Ig6CWrntXmZtzcv4UeaZZgN4mMmhLAbE//B4QyGUo87fMNtSfXJMZ1Yp rAX/G7fLURYLQRmsfvSiSZz7MV7yqfj3vsggEE/IcJu+9m1kn5z81wWxRQw7ZY5C FmQxTOBtpIoMQFeYXXicqqLDsqze1Y8MVdXoVIMNliTdU6f/WvaDWu5i/NYt6DCh 5ttbnAgZiI1hStSmHfqxqqr+UxvgTdyocSIMui1kc78Zd6z42jDlbzuIJ9Y0Irzb o5rp+7Fk0es60NXRdIgC5eFKyvQCa3DEV+4dWQJ2WFRrzo3ylIj52wh7ZWKaSEI= =7E2x -----END PGP SIGNATURE----- --Apple-Mail=_7937DA1A-F764-4547-95EA-F0EB55AF66AD--