From nobody Thu Sep 8 03:27:58 2016 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 B523C12B16E for ; Thu, 8 Sep 2016 03:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6FeREUaPKhD for ; Thu, 8 Sep 2016 03:27:53 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B7312B187 for ; Thu, 8 Sep 2016 03:27:53 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u88ARe4a049127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 8 Sep 2016 03:27:46 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u88ARe4a049127 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1473330466; bh=CnXorIcCmJC/tbUMRtXVfPe/20NCoUSrYCrmA+dfTIE=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type; b=sVl/wamU0w/b3xh8gQGAmpDTIPlaE7Ll8mFaisx0VKeueO73IblK3ma41ijrziXam EFLyTLE6eegei8t4FoBHUQ28LDOK+tfSpA3QJn083lXZlQEE+Mg15MSdzCJ22SqJ5U bphFsd5H5l1zN2zrxZUqQiQy7FzIWz7cfOIgiMGSXrOrrE5yMBjV1bu79EuQnJn43C 3Jp/zX6fnz6G0xda8N/GW9JnkGtwfD52zyDHnKmGiSlPCuZxpgXn87fOuT2QFSH/HN SUBtgLDWEdLfRxglV00RofhAjUssAvLf2IDvJutzmCJzQFQln6EnPJyqEGiXdrtsLE C3Vbho9uJjf8w== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] To: dmarc@ietf.org From: Steven M Jones Organization: Crash Computing Message-ID: <7530787e-19c2-f67a-15b0-c058e3d2704e@crash.com> Date: Thu, 8 Sep 2016 03:27:43 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------373C3D2653D19519FC13AF01" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 08 Sep 2016 03:27:46 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] Most common problems with DMARC records X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 08 Sep 2016 10:27:56 -0000 This is a multi-part message in MIME format. --------------373C3D2653D19519FC13AF01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In June/July I slogged through about six years of captured email authentication records, and wrote a blog post about what I found regarding DMARC policy records. (https://dmarc.org/2016/07/common-problems-with-dmarc-records/) A colleague suggested that a write-up with more numbers would be considered useful for this working group. So I did a lot more slogging, and here's the result. There are undoubtedly shortcomings in the methodology, feel free to point them out if you enjoy that sort of thing. No telling when I could incorporate any suggestions, and I am not able to share the underlying data - sorry. But I will receive any suggestions gladly and save them for later use. tl;dr =3D=3D=3D=3D=3D Two percent of all recognizable DMARC records published were invalid. The three top problems with DMARC records observed over six years were: 1: Missing "p=3D" tag 2: The "DMARC" in "v=3DDMARC1" wasn't capitalized 3: Extraneous escape/quoting characters in record There's a "Summary" at the bottom if you want it. Introduction =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Farsight Security has made over six years of DNS data related to email authentication protocols available to DMARC.org. We recently reviewed DMARC records across this period, which seems like it might provide useful input for the IETF DMARC working group. The Farsight data is captured by network probes proximate to a number of nameservers. While this represents a subset of all Internet nameservice traffic, it nevertheless provides a unique opportunity to extract trends in the use of email authentication over time. Records in the Dataset =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In all, 41 million records were made available, captured in the period from June 2010 through June 2016 (minus three weeks in December 2015). This included over 37 million TXT records and over 1.5 million CNAME records. Almost 924,000 records dealt with labels beginning with "_dmarc." Non-DMARC Records at DMARC Labels =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Out of almost 924,000 records in the dataset at DMARC labels (beginning "_dmarc"), over 435,000 were not even TXT records. Here is a breakdown of all the resource record types appearing at these labels: Resource Record Types at DMARC Labels A records 3,487 AAAA records 10 NS records 9,053 NSEC records 3,793 SOA records 182,959 TXT records 488,656 Many of the TXT records at DMARC labels were in fact records for a different protocol such as SPF, Sender-ID, or DKIM. Other Protocols at DMARC TXT Record Labels SPF records 268,731 Sender-ID records 28,172 DKIM records 176 ------- 297,079 Bear in mind that TXT records are multivalued, and it is common to publish records for multiple protocols at the same label - SPF and Sender-ID are meant to operate this way, and SPF and DMARC are often deployed this way. Unfortunately these records are often (mis-)configured as wildcards for the entire domain, and get returned for an TXT record request under that domain. Fortunately non-DMARC records should have no effect being deployed at a "_dmarc" label. But there are other recognizable schemes or protocols in use that show up here, such as domain- or site-ownership verification. Site Verification Strings at DMARC Labels "bio=3D" 20,094 Google site verification 1,920 "v=3Dmsv1 t=3D" 246 Globalsign domain verification 82 ------ 22,342 Again, this is probably due to the unecessary creation of wildcard records for these functions. Values For DMARC TXT Records =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Examination of more than 488,000 TXT records at labels beginning with "_dmarc" yielded the following breakdown of recognized email authentication protocols: Valid DMARC records 184,805 SPF records 268,731 Sender-ID records 28,172 DKIM records 176 Other values 36,687 Many of these labels include both SPF and DMARC records, and Sender-ID records are almost always seen alongside SPF records, so the above breakdown does not match a simple count of TXT records with "_dmarc" labels in the dataset. Most of these record types were identified by string matching the first several characters of the value. In all cases this was done after any extraneous leading quotation marks or backslashes (the escape character for many nameservers) were removed. Classifying most records involved looking for matches of "v=3Dspf1", "spf/2.0", "v=3DDKIM1", et cetera at the beginning of the value. For evaluating DMARC records, the payload was validated using the Mail::DMARC module written by Matt Simerson. While more rigorous validity checks for the non-DMARC record types could be performed, it did not seem worthwhile for labels in the "_dmarc" namespace. Policies of Valid DMARC Records =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D We will present two views of the distribution of policies expressed in valid DMARC records. One is a count of all policies expressed in the dataset over the entire period. The other is a count based on the last policy published for any given domain during the entire period. So if example.com published one DMARC policy in 2014 and a different policy in 2015, both would appear in the first breakdown below, but only the 2015 policy would be part of the second breakdown. Note that some domains allow the subdomain policy ("sp=3D") to be set via inheritance, while others set it explicitly to the same value despite the inheritance mechanism. We will keep the two counts separate as a reflection of domain owner behavior. All valid DMARC policy records ever observed in dataset: p=3Dnone 121,333 p=3Dnone, sp=3Dnone 19,152 p=3Dnone, sp=3Dquarantine 126 p=3Dnone, sp=3Dreject 509 p=3Dquarantine 9,980 p=3Dquarantine, sp=3Dnone 1,272 p=3Dquarantine, sp=3Dquarantine 1,750 p=3Dquarantine, sp=3Dreject 1,754 p=3Dreject 23,885 p=3Dreject, sp=3Dnone 2,580 p=3Dreject, sp=3Dquarantine 39 p=3Dreject, sp=3Dreject 2,296 ------- 184,676 (Note that sums may not match other sections due to manual correction of the classification of DMARC records after automatic processing.) Last valid DMARC policy observed for any given label: p=3Dnone 72,597 p=3Dnone, sp=3Dnone 12,174 p=3Dnone, sp=3Dquarantine 58 p=3Dnone, sp=3Dreject 241 p=3Dquarantine 5,082 p=3Dquarantine, sp=3Dnone 584 p=3Dquarantine, sp=3Dquarantine 873 p=3Dquarantine, sp=3Dreject 1,205 p=3Dreject 14,134 p=3Dreject, sp=3Dnone 1,640 p=3Dreject, sp=3Dquarantine 17 p=3Dreject, sp=3Dreject 1,052 ------- 109,657 Domain owners and other potential implementors often ask how many domains are using the different policies. For a simplified answer, here is a percentage breakdown of the policy expressed at a given label, ignoring subdomain policies. This will only reflect the last policy observed for any given domain/label over the past six years. Last valid DMARC policy observed for any given label: p=3Dnone 85,070 77.6% p=3Dquarantine 7,744 7.1% p=3Dreject 16,843 15.4% ------- 109,657 Please note that these figures reflect a mix of records still published as of July 2016 (52,000+) and those no longer published (57,000+). It would be far preferable to provide a breakdown of just the records still published, but the raw policy records for those labels are not available as of this writing. Those figures will be captured and produced at the next quarterly update. There are several questions around those DMARC records no longer being published, and they are the subject of a separate analysis. Random Strings in DMARC Labels =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D There are a number of non-standard strings that appear in the invalid DMARC records in the dataset. Records dynamically generated 872 kasserver.com 673 Please contact your registr 152 This domain may be available for purch 113 UPDATE- 20 This domain's zone has been disabled 16 nodigispam 10 * 6 Text 5 ERROR 1 dont do this 1 There are other strings that appear very infrequently, but are a little more personal. Computer Reseller News/Russian Edition 7 Dare Contract Service NZ 1 Entwickler, Admin, Techie ...com/jobs.php 5 Koninklijke Nederlandsche Voetbalbond 1 PC Magazine/Russian Edition 1 Red Cactus Design Limited 1 Shannon Development Authority 2 A small number of other strings appeared because of operator error or confusion in managing the domain's DNS data. The following strings typify these cases: =E2=80=9CFor=E2=80=9D =E2=80=9Ctext=E2=80=9D =E2=80=9Crecord=E2=80=9D = =E2=80=9Cput:=E2=80=9D =E2=80=9Cv=3DDMARC1; p=3Dnone; sp=3Dnone; rua=3Dmailto:dmarc@XXXXXXXX.cf; ruf=3Dmailto:dmarc@XXXXXXXX.cf; rf=3Dafrf; pct=3D100; ri=3D14400=E2=80=B3 =E2=80=9C_dmarc.clementine.XXXXXXXX.fr descriptive text v=3DDMARC1; p=3Dreject;=E2=80=9D Malformed DMARC Records =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Of the more than 36,000 TXT records at DMARC labels that were not valid DMARC records, only about 4,100 feature the string "DMARC" or "v=3Ddmarc". An exhaustive classification hasn't been compiled, but here are the malformations that have been isolated so far. (no "p=3D" tag/value) 1,698 Missing "p=3D" tag/value at policy label (e.g. not ..._report._dmarc...) v=3Ddmarc1 810 The string "DMARC" must be upper case DMARC1; p=3D... 62 Missing "v=3D" \\226\\128\\156v=3DDMARC1 40 Incorrect quoting/escaping _dmarc v=3DDMARC1 19 Extraneous text v=3DDMARC; 15 Missing the "1" in "DMARC1" TXT \\\"v=3DDMARC1 7 Extraneous text and quoting v=3DDMARC1/; 6 Incorrect escape character v=3DDMARC1: 4 Use of ":" instead of ";" v=3DDMARC1p=3D 4 Using "" at all v%253DDMARC1%253B 3 Two levels of character escaping v=3DDMARC1; \\226\\128 3 Incorrect quoting/escaping =3DDMARC1 2 Missing the "v" in "v=3D" tag/value pair v-DMARC1 1 Missing the "=3D" in "v=3D" tag/value pair In addition, a number of records appear with widely varying numbers and arrangements of escape or quoting characters. It is not at all uncommon to see constructs like the following: \"\\\"v=3DDMARC1; 618 Numerous escapes/quotes \"v=3DDMARC1;\" \"p 187 Escapes/quotes within the record \"v=3DDMARC1;\" \"p=3D\" 4 Escapes and missing "p=3D" value \"\" \"v=3DDMARC1\" 2 Escapes, quotes, and spaces... \" \\\"v=3DDMARC1; 1 ... Incorrect Policy Values =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The use of incorrect policy values in the "p=3D" tag/value pair, or of a pre-publication tag name such as "policy" instead of "p", may be of particular interest to the working group when refining the protocol specification. For this reason they appear below instead of above with the general malformed DMARC records. p=3Dmonitor 125 Incorrect "p=3D" value policy=3Dnone 52 Incorrect/outdated tag p=3Dmonitor; sp=3Dmonitor 41 Incorrect "p=3D" and "sp=3D" value p=3Dnonee 20 Incorrect "p=3D" value p=3D; 16 Missing value of "p=3D" tag/value pair p=3Dquarantaine 11 Incorrect "p=3D" value p=3Dquarentine 7 Incorrect "p=3D" value p=3Dquarintine 7 Incorrect "p=3D" value p=3Dnon; 3 Incorrect "p=3D" value p=3Dblocked 1 Incorrect "p=3D" value Summary =3D=3D=3D=3D=3D=3D=3D The majority of non-DMARC DNS TXT records appearing at "_dmarc" labels in the six year Farsight dataset is most likely due to the widespread use of wildcard SPF records. Given that, how many records from the dataset should actually be considered as malformed or problematic DMARC records? Taking the records described in the last two sections, "Malformed DMARC Records" and "Incorrect Policy Values," we can be fairly confident we're considering records intended to be DMARC deployments. That gives us 3,769 invalid DMARC records, recognizing there may be some overlap of records with more than one type of flaw. Since these are all the invalid records captured, they should be compared to all the valid DMARC records captured (184,676). This appears to yield an error rate of little over 2% for all DMARC records in our dataset. What are the most common faults observed? The most common fault in a published DMARC record appears to be omission of the required "p=3D" policy tag. The second most common fault appears to be not ensuring the string "DMARC" in the "v=3D" tag is in fact upper case. And the third most common fault appears to involve using too many escape and quoting characters in the nameserver data, resulting in extraneous characters in the published record. It's known that many mail receiver implementations will strip out some quoting and escaping characters in DMARC records they retrieve, though the details are not known. They may only strip the outermost pair, only operate between the beginning and "v=3D" at the start of the record, etc. While a given receiver's validation methods might produce different totals, this issue is probably still a solid third place ranking as a class of problem. --=20 Steven M Jones DMARC.org e: smj@dmarc.org, smj@crash.com --------------373C3D2653D19519FC13AF01 Content-Type: text/plain; charset=UTF-8; name="IETF-DMARC-WG-common-problems-v1.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IETF-DMARC-WG-common-problems-v1.txt" dGw7ZHIKPT09PT0KClR3byBwZXJjZW50IG9mIGFsbCByZWNvZ25pemFibGUgRE1BUkMgcmVj b3JkcyBwdWJsaXNoZWQgd2VyZSBpbnZhbGlkLgoKVGhlIHRocmVlIHRvcCBwcm9ibGVtcyB3 aXRoIERNQVJDIHJlY29yZHMgb2JzZXJ2ZWQgb3ZlciBzaXggeWVhcnMgd2VyZToKCjE6IE1p c3NpbmcgInA9IiB0YWcKMjogVGhlICJETUFSQyIgaW4gInY9RE1BUkMxIiB3YXNuJ3QgY2Fw aXRhbGl6ZWQKMzogRXh0cmFuZW91cyBlc2NhcGUvcXVvdGluZyBjaGFyYWN0ZXJzIGluIHJl Y29yZAoKVGhlcmUncyBhICJTdW1tYXJ5IiBhdCB0aGUgYm90dG9tIGlmIHlvdSB3YW50IGl0 LgoKCgoKSW50cm9kdWN0aW9uCj09PT09PT09PT09PQoKRmFyc2lnaHQgU2VjdXJpdHkgaGFz IG1hZGUgb3ZlciBzaXggeWVhcnMgb2YgRE5TIGRhdGEgcmVsYXRlZCB0byBlbWFpbAphdXRo ZW50aWNhdGlvbiBwcm90b2NvbHMgYXZhaWxhYmxlIHRvIERNQVJDLm9yZy4gV2UgcmVjZW50 bHkgcmV2aWV3ZWQKRE1BUkMgcmVjb3JkcyBhY3Jvc3MgdGhpcyBwZXJpb2QsIHdoaWNoIHNl ZW1zIGxpa2UgaXQgbWlnaHQgcHJvdmlkZQp1c2VmdWwgaW5wdXQgZm9yIHRoZSBJRVRGIERN QVJDIHdvcmtpbmcgZ3JvdXAuCgpUaGUgRmFyc2lnaHQgZGF0YSBpcyBjYXB0dXJlZCBieSBu ZXR3b3JrIHByb2JlcyBwcm94aW1hdGUgdG8gYSBudW1iZXIKb2YgbmFtZXNlcnZlcnMuIFdo aWxlIHRoaXMgcmVwcmVzZW50cyBhIHN1YnNldCBvZiBhbGwgSW50ZXJuZXQKbmFtZXNlcnZp Y2UgdHJhZmZpYywgaXQgbmV2ZXJ0aGVsZXNzIHByb3ZpZGVzIGEgdW5pcXVlIG9wcG9ydHVu aXR5IHRvCmV4dHJhY3QgdHJlbmRzIGluIHRoZSB1c2Ugb2YgZW1haWwgYXV0aGVudGljYXRp b24gb3ZlciB0aW1lLgoKCgpSZWNvcmRzIGluIHRoZSBEYXRhc2V0Cj09PT09PT09PT09PT09 PT09PT09PT0KCkluIGFsbCwgNDEgbWlsbGlvbiByZWNvcmRzIHdlcmUgbWFkZSBhdmFpbGFi bGUsIGNhcHR1cmVkIGluIHRoZSBwZXJpb2QKZnJvbSBKdW5lIDIwMTAgdGhyb3VnaCBKdW5l IDIwMTYgKG1pbnVzIHRocmVlIHdlZWtzIGluIERlY2VtYmVyCjIwMTUpLiBUaGlzIGluY2x1 ZGVkIG92ZXIgMzcgbWlsbGlvbiBUWFQgcmVjb3JkcyBhbmQgb3ZlciAxLjUgbWlsbGlvbgpD TkFNRSByZWNvcmRzLiBBbG1vc3QgOTI0LDAwMCByZWNvcmRzIGRlYWx0IHdpdGggbGFiZWxz IGJlZ2lubmluZyB3aXRoCiJfZG1hcmMuIgoKCgpOb24tRE1BUkMgUmVjb3JkcyBhdCBETUFS QyBMYWJlbHMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgpPdXQgb2YgYWxt b3N0IDkyNCwwMDAgcmVjb3JkcyBpbiB0aGUgZGF0YXNldCBhdCBETUFSQyBsYWJlbHMKKGJl Z2lubmluZyAiX2RtYXJjIiksIG92ZXIgNDM1LDAwMCB3ZXJlIG5vdCBldmVuIFRYVCByZWNv cmRzLiBIZXJlIGlzCmEgYnJlYWtkb3duIG9mIGFsbCB0aGUgcmVzb3VyY2UgcmVjb3JkIHR5 cGVzIGFwcGVhcmluZyBhdCB0aGVzZQpsYWJlbHM6CgpSZXNvdXJjZSBSZWNvcmQgVHlwZXMg YXQgRE1BUkMgTGFiZWxzCgpBIHJlY29yZHMJCQkgIDMsNDg3CkFBQUEgcmVjb3JkcwkJCSAg ICAgMTAKTlMgcmVjb3JkcwkJCSAgOSwwNTMKTlNFQyByZWNvcmRzCQkJICAzLDc5MwpTT0Eg cmVjb3JkcwkJCTE4Miw5NTkKVFhUIHJlY29yZHMJCQk0ODgsNjU2CgoKTWFueSBvZiB0aGUg VFhUIHJlY29yZHMgYXQgRE1BUkMgbGFiZWxzIHdlcmUgaW4gZmFjdCByZWNvcmRzIGZvciBh CmRpZmZlcmVudCBwcm90b2NvbCBzdWNoIGFzIFNQRiwgU2VuZGVyLUlELCBvciBES0lNLgoK T3RoZXIgUHJvdG9jb2xzIGF0IERNQVJDIFRYVCBSZWNvcmQgTGFiZWxzCgpTUEYgcmVjb3Jk cyAJCQkyNjgsNzMxClNlbmRlci1JRCByZWNvcmRzCQkgMjgsMTcyCkRLSU0gcmVjb3JkcwkJ CSAgICAxNzYKICAgICAJCQkJLS0tLS0tLQoJCQkJMjk3LDA3OQoKQmVhciBpbiBtaW5kIHRo YXQgVFhUIHJlY29yZHMgYXJlIG11bHRpdmFsdWVkLCBhbmQgaXQgaXMgY29tbW9uIHRvCnB1 Ymxpc2ggcmVjb3JkcyBmb3IgbXVsdGlwbGUgcHJvdG9jb2xzIGF0IHRoZSBzYW1lIGxhYmVs IC0gU1BGIGFuZApTZW5kZXItSUQgYXJlIG1lYW50IHRvIG9wZXJhdGUgdGhpcyB3YXksIGFu ZCBTUEYgYW5kIERNQVJDIGFyZSBvZnRlbgpkZXBsb3llZCB0aGlzIHdheS4gVW5mb3J0dW5h dGVseSB0aGVzZSByZWNvcmRzIGFyZSBvZnRlbgoobWlzLSljb25maWd1cmVkIGFzIHdpbGRj YXJkcyBmb3IgdGhlIGVudGlyZSBkb21haW4sIGFuZCBnZXQgcmV0dXJuZWQKZm9yIGFuIFRY VCByZWNvcmQgcmVxdWVzdCB1bmRlciB0aGF0IGRvbWFpbi4gRm9ydHVuYXRlbHkgbm9uLURN QVJDCnJlY29yZHMgc2hvdWxkIGhhdmUgbm8gZWZmZWN0IGJlaW5nIGRlcGxveWVkIGF0IGEg Il9kbWFyYyIgbGFiZWwuCgpCdXQgdGhlcmUgYXJlIG90aGVyIHJlY29nbml6YWJsZSBzY2hl bWVzIG9yIHByb3RvY29scyBpbiB1c2UgdGhhdApzaG93IHVwIGhlcmUsIHN1Y2ggYXMgZG9t YWluLSBvciBzaXRlLW93bmVyc2hpcCB2ZXJpZmljYXRpb24uCgpTaXRlIFZlcmlmaWNhdGlv biBTdHJpbmdzIGF0IERNQVJDIExhYmVscwoKImJpbz08aGV4c3RyaW5nPiIJCTIwLDA5NApH b29nbGUgc2l0ZSB2ZXJpZmljYXRpb24JIDEsOTIwCiJ2PW1zdjEgdD08aGV4c3RyaW5nPiIJ CSAgIDI0NgpHbG9iYWxzaWduIGRvbWFpbiB2ZXJpZmljYXRpb24JICAgIDgyCgkgICAJICAJ CS0tLS0tLQoJCQkJMjIsMzQyCgpBZ2FpbiwgdGhpcyBpcyBwcm9iYWJseSBkdWUgdG8gdGhl IHVuZWNlc3NhcnkgY3JlYXRpb24gb2Ygd2lsZGNhcmQKcmVjb3JkcyBmb3IgdGhlc2UgZnVu Y3Rpb25zLgoKCgpWYWx1ZXMgRm9yIERNQVJDIFRYVCBSZWNvcmRzCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KCkV4YW1pbmF0aW9uIG9mIG1vcmUgdGhhbiA0ODgsMDAwIFRYVCBy ZWNvcmRzIGF0IGxhYmVscyBiZWdpbm5pbmcgd2l0aAoiX2RtYXJjIiB5aWVsZGVkIHRoZSBm b2xsb3dpbmcgYnJlYWtkb3duIG9mIHJlY29nbml6ZWQgZW1haWwKYXV0aGVudGljYXRpb24g cHJvdG9jb2xzOgoKVmFsaWQgRE1BUkMgcmVjb3JkcwkxODQsODA1ClNQRiByZWNvcmRzIAkJ MjY4LDczMQpTZW5kZXItSUQgcmVjb3JkcwkgMjgsMTcyCkRLSU0gcmVjb3JkcwkJICAgIDE3 NgpPdGhlciB2YWx1ZXMJCSAzNiw2ODcKCk1hbnkgb2YgdGhlc2UgbGFiZWxzIGluY2x1ZGUg Ym90aCBTUEYgYW5kIERNQVJDIHJlY29yZHMsIGFuZCBTZW5kZXItSUQKcmVjb3JkcyBhcmUg YWxtb3N0IGFsd2F5cyBzZWVuIGFsb25nc2lkZSBTUEYgcmVjb3Jkcywgc28gdGhlIGFib3Zl CmJyZWFrZG93biBkb2VzIG5vdCBtYXRjaCBhIHNpbXBsZSBjb3VudCBvZiBUWFQgcmVjb3Jk cyB3aXRoICJfZG1hcmMiCmxhYmVscyBpbiB0aGUgZGF0YXNldC4KCk1vc3Qgb2YgdGhlc2Ug cmVjb3JkIHR5cGVzIHdlcmUgaWRlbnRpZmllZCBieSBzdHJpbmcgbWF0Y2hpbmcgdGhlCmZp cnN0IHNldmVyYWwgY2hhcmFjdGVycyBvZiB0aGUgdmFsdWUuIEluIGFsbCBjYXNlcyB0aGlz IHdhcyBkb25lCmFmdGVyIGFueSBleHRyYW5lb3VzIGxlYWRpbmcgcXVvdGF0aW9uIG1hcmtz IG9yIGJhY2tzbGFzaGVzICh0aGUKZXNjYXBlIGNoYXJhY3RlciBmb3IgbWFueSBuYW1lc2Vy dmVycykgd2VyZSByZW1vdmVkLgoKQ2xhc3NpZnlpbmcgbW9zdCByZWNvcmRzIGludm9sdmVk IGxvb2tpbmcgZm9yIG1hdGNoZXMgb2YgInY9c3BmMSIsCiJzcGYvMi4wIiwgInY9REtJTTEi LCBldCBjZXRlcmEgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgdmFsdWUuIEZvcgpldmFsdWF0 aW5nIERNQVJDIHJlY29yZHMsIHRoZSBwYXlsb2FkIHdhcyB2YWxpZGF0ZWQgdXNpbmcgdGhl Ck1haWw6OkRNQVJDIG1vZHVsZSB3cml0dGVuIGJ5IE1hdHQgU2ltZXJzb24uCgpXaGlsZSBt b3JlIHJpZ29yb3VzIHZhbGlkaXR5IGNoZWNrcyBmb3IgdGhlIG5vbi1ETUFSQyByZWNvcmQg dHlwZXMKY291bGQgYmUgcGVyZm9ybWVkLCBpdCBkaWQgbm90IHNlZW0gd29ydGh3aGlsZSBm b3IgbGFiZWxzIGluIHRoZQoiX2RtYXJjIiBuYW1lc3BhY2UuCgoKClBvbGljaWVzIG9mIFZh bGlkIERNQVJDIFJlY29yZHMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKV2Ug d2lsbCBwcmVzZW50IHR3byB2aWV3cyBvZiB0aGUgZGlzdHJpYnV0aW9uIG9mIHBvbGljaWVz IGV4cHJlc3NlZCBpbgp2YWxpZCBETUFSQyByZWNvcmRzLiBPbmUgaXMgYSBjb3VudCBvZiBh bGwgcG9saWNpZXMgZXhwcmVzc2VkIGluIHRoZQpkYXRhc2V0IG92ZXIgdGhlIGVudGlyZSBw ZXJpb2QuIFRoZSBvdGhlciBpcyBhIGNvdW50IGJhc2VkIG9uIHRoZSBsYXN0CnBvbGljeSBw dWJsaXNoZWQgZm9yIGFueSBnaXZlbiBkb21haW4gZHVyaW5nIHRoZSBlbnRpcmUgcGVyaW9k LiBTbyBpZgpleGFtcGxlLmNvbSBwdWJsaXNoZWQgb25lIERNQVJDIHBvbGljeSBpbiAyMDE0 IGFuZCBhIGRpZmZlcmVudCBwb2xpY3kKaW4gMjAxNSwgYm90aCB3b3VsZCBhcHBlYXIgaW4g dGhlIGZpcnN0IGJyZWFrZG93biBiZWxvdywgYnV0IG9ubHkgdGhlCjIwMTUgcG9saWN5IHdv dWxkIGJlIHBhcnQgb2YgdGhlIHNlY29uZCBicmVha2Rvd24uCgpOb3RlIHRoYXQgc29tZSBk b21haW5zIGFsbG93IHRoZSBzdWJkb21haW4gcG9saWN5ICgic3A9IikgdG8gYmUgc2V0CnZp YSBpbmhlcml0YW5jZSwgd2hpbGUgb3RoZXJzIHNldCBpdCBleHBsaWNpdGx5IHRvIHRoZSBz YW1lIHZhbHVlCmRlc3BpdGUgdGhlIGluaGVyaXRhbmNlIG1lY2hhbmlzbS4gV2Ugd2lsbCBr ZWVwIHRoZSB0d28gY291bnRzCnNlcGFyYXRlIGFzIGEgcmVmbGVjdGlvbiBvZiBkb21haW4g b3duZXIgYmVoYXZpb3IuCgpBbGwgdmFsaWQgRE1BUkMgcG9saWN5IHJlY29yZHMgZXZlciBv YnNlcnZlZCBpbiBkYXRhc2V0OgoKcD1ub25lCQkJCTEyMSwzMzMKcD1ub25lLCBzcD1ub25l CQkJIDE5LDE1MgpwPW5vbmUsIHNwPXF1YXJhbnRpbmUJCSAgICAxMjYKcD1ub25lLCBzcD1y ZWplY3QJCSAgICA1MDkKCnA9cXVhcmFudGluZQkJCSAgOSw5ODAKcD1xdWFyYW50aW5lLCBz cD1ub25lCQkgIDEsMjcyCnA9cXVhcmFudGluZSwgc3A9cXVhcmFudGluZQkgIDEsNzUwCnA9 cXVhcmFudGluZSwgc3A9cmVqZWN0CQkgIDEsNzU0CgpwPXJlamVjdCAgICAgIAkJCSAyMyw4 ODUKcD1yZWplY3QsIHNwPW5vbmUJCSAgMiw1ODAKcD1yZWplY3QsIHNwPXF1YXJhbnRpbmUJ CSAgICAgMzkKcD1yZWplY3QsIHNwPXJlamVjdAkJICAyLDI5NgoJICAJCQktLS0tLS0tCgkg IAkJCTE4NCw2NzYKCihOb3RlIHRoYXQgc3VtcyBtYXkgbm90IG1hdGNoIG90aGVyIHNlY3Rp b25zIGR1ZSB0byBtYW51YWwgY29ycmVjdGlvbgpvZiB0aGUgY2xhc3NpZmljYXRpb24gb2Yg RE1BUkMgcmVjb3JkcyBhZnRlciBhdXRvbWF0aWMgcHJvY2Vzc2luZy4pCgoKTGFzdCB2YWxp ZCBETUFSQyBwb2xpY3kgb2JzZXJ2ZWQgZm9yIGFueSBnaXZlbiBsYWJlbDoKCnA9bm9uZQkJ CQkgNzIsNTk3CnA9bm9uZSwgc3A9bm9uZQkJCSAxMiwxNzQKcD1ub25lLCBzcD1xdWFyYW50 aW5lCQkgICAgIDU4CnA9bm9uZSwgc3A9cmVqZWN0CQkgICAgMjQxCgpwPXF1YXJhbnRpbmUJ CQkgIDUsMDgyCnA9cXVhcmFudGluZSwgc3A9bm9uZQkJICAgIDU4NApwPXF1YXJhbnRpbmUs IHNwPXF1YXJhbnRpbmUJICAgIDg3MwpwPXF1YXJhbnRpbmUsIHNwPXJlamVjdAkJICAxLDIw NQoKcD1yZWplY3QgICAgICAJCQkgMTQsMTM0CnA9cmVqZWN0LCBzcD1ub25lCQkgIDEsNjQw CnA9cmVqZWN0LCBzcD1xdWFyYW50aW5lCQkgICAgIDE3CnA9cmVqZWN0LCBzcD1yZWplY3QJ CSAgMSwwNTIKCSAgCQkJLS0tLS0tLQoJCQkJMTA5LDY1NwoKCkRvbWFpbiBvd25lcnMgYW5k IG90aGVyIHBvdGVudGlhbCBpbXBsZW1lbnRvcnMgb2Z0ZW4gYXNrIGhvdyBtYW55CmRvbWFp bnMgYXJlIHVzaW5nIHRoZSBkaWZmZXJlbnQgcG9saWNpZXMuIEZvciBhIHNpbXBsaWZpZWQg YW5zd2VyLApoZXJlIGlzIGEgcGVyY2VudGFnZSBicmVha2Rvd24gb2YgdGhlIHBvbGljeSBl eHByZXNzZWQgYXQgYSBnaXZlbgpsYWJlbCwgaWdub3Jpbmcgc3ViZG9tYWluIHBvbGljaWVz LiBUaGlzIHdpbGwgb25seSByZWZsZWN0IHRoZSBsYXN0CnBvbGljeSBvYnNlcnZlZCBmb3Ig YW55IGdpdmVuIGRvbWFpbi9sYWJlbCBvdmVyIHRoZSBwYXN0IHNpeCB5ZWFycy4KCkxhc3Qg dmFsaWQgRE1BUkMgcG9saWN5IG9ic2VydmVkIGZvciBhbnkgZ2l2ZW4gbGFiZWw6CgpwPW5v bmUJCQk4NSwwNzAJCTc3LjYlCnA9cXVhcmFudGluZQkJIDcsNzQ0CQkgNy4xJQpwPXJlamVj dAkJMTYsODQzCQkxNS40JQoJCSAgICAgICAtLS0tLS0tCgkJICAgICAgIDEwOSw2NTcKClBs ZWFzZSBub3RlIHRoYXQgdGhlc2UgZmlndXJlcyByZWZsZWN0IGEgbWl4IG9mIHJlY29yZHMg c3RpbGwKcHVibGlzaGVkIGFzIG9mIEp1bHkgMjAxNiAoNTIsMDAwKykgYW5kIHRob3NlIG5v IGxvbmdlciBwdWJsaXNoZWQKKDU3LDAwMCspLiBJdCB3b3VsZCBiZSBmYXIgcHJlZmVyYWJs ZSB0byBwcm92aWRlIGEgYnJlYWtkb3duIG9mIGp1c3QKdGhlIHJlY29yZHMgc3RpbGwgcHVi bGlzaGVkLCBidXQgdGhlIHJhdyBwb2xpY3kgcmVjb3JkcyBmb3IgdGhvc2UKbGFiZWxzIGFy ZSBub3QgYXZhaWxhYmxlIGFzIG9mIHRoaXMgd3JpdGluZy4gVGhvc2UgZmlndXJlcyB3aWxs IGJlCmNhcHR1cmVkIGFuZCBwcm9kdWNlZCBhdCB0aGUgbmV4dCBxdWFydGVybHkgdXBkYXRl LgoKVGhlcmUgYXJlIHNldmVyYWwgcXVlc3Rpb25zIGFyb3VuZCB0aG9zZSBETUFSQyByZWNv cmRzIG5vIGxvbmdlciBiZWluZwpwdWJsaXNoZWQsIGFuZCB0aGV5IGFyZSB0aGUgc3ViamVj dCBvZiBhIHNlcGFyYXRlIGFuYWx5c2lzLgoKCgpSYW5kb20gU3RyaW5ncyBpbiBETUFSQyBM YWJlbHMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgpUaGVyZSBhcmUgYSBudW1i ZXIgb2Ygbm9uLXN0YW5kYXJkIHN0cmluZ3MgdGhhdCBhcHBlYXIgaW4gdGhlIGludmFsaWQK RE1BUkMgcmVjb3JkcyBpbiB0aGUgZGF0YXNldC4KClJlY29yZHMgZHluYW1pY2FsbHkgZ2Vu ZXJhdGVkCQk4NzIKa2Fzc2VydmVyLmNvbQkgICAgCQkJNjczClBsZWFzZSBjb250YWN0IHlv dXIgcmVnaXN0cgkJMTUyClRoaXMgZG9tYWluIG1heSBiZSBhdmFpbGFibGUgZm9yIHB1cmNo CTExMwpVUERBVEUtCSAgICAgIAkgICAgICAgCSAgICAJCSAyMApUaGlzIGRvbWFpbidzIHpv bmUgaGFzIGJlZW4gZGlzYWJsZWQJIDE2Cm5vZGlnaXNwYW0gICAgCSAgICAgICAJICAgIAkJ IDEwCiogICAgICAJICAgICAgIAkgICAgCSAgICAJCSAgNgpUZXh0ICAgCSAgICAgICAJICAg IAkJCSAgNQpFUlJPUgkJCQkJICAxCmRvbnQgZG8gdGhpcwkJCQkgIDEKCgpUaGVyZSBhcmUg b3RoZXIgc3RyaW5ncyB0aGF0IGFwcGVhciB2ZXJ5IGluZnJlcXVlbnRseSwgYnV0IGFyZSBh CmxpdHRsZSBtb3JlIHBlcnNvbmFsLgoKQ29tcHV0ZXIgUmVzZWxsZXIgTmV3cy9SdXNzaWFu IEVkaXRpb24JICA3CkRhcmUgQ29udHJhY3QgU2VydmljZSBOWgkJICAxCkVudHdpY2tsZXIs IEFkbWluLCBUZWNoaWUgLi4uY29tL2pvYnMucGhwIDUKS29uaW5rbGlqa2UgTmVkZXJsYW5k c2NoZSBWb2V0YmFsYm9uZAkgIDEKUEMgTWFnYXppbmUvUnVzc2lhbiBFZGl0aW9uCQkgIDEK UmVkIENhY3R1cyBEZXNpZ24gTGltaXRlZAkJICAxClNoYW5ub24gRGV2ZWxvcG1lbnQgQXV0 aG9yaXR5CQkgIDIKCkEgc21hbGwgbnVtYmVyIG9mIG90aGVyIHN0cmluZ3MgYXBwZWFyZWQg YmVjYXVzZSBvZiBvcGVyYXRvciBlcnJvciBvcgpjb25mdXNpb24gaW4gbWFuYWdpbmcgdGhl IGRvbWFpbidzIEROUyBkYXRhLiBUaGUgZm9sbG93aW5nIHN0cmluZ3MKdHlwaWZ5IHRoZXNl IGNhc2VzOgoKICAg4oCcRm9y4oCdIOKAnHRleHTigJ0g4oCccmVjb3Jk4oCdIOKAnHB1dDri gJ0g4oCcdj1ETUFSQzE7IHA9bm9uZTsgc3A9bm9uZTsKICAgcnVhPW1haWx0bzpkbWFyY0BY WFhYWFhYWC5jZjsgcnVmPW1haWx0bzpkbWFyY0BYWFhYWFhYWC5jZjsKICAgcmY9YWZyZjsg cGN0PTEwMDsgcmk9MTQ0MDDigLMKCiAgIOKAnF9kbWFyYy5jbGVtZW50aW5lLlhYWFhYWFhY LmZyIGRlc2NyaXB0aXZlIHRleHQgdj1ETUFSQzE7CiAgIHA9cmVqZWN0O+KAnQoKCgpNYWxm b3JtZWQgRE1BUkMgUmVjb3Jkcwo9PT09PT09PT09PT09PT09PT09PT09PQoKT2YgdGhlIG1v cmUgdGhhbiAzNiwwMDAgVFhUIHJlY29yZHMgYXQgRE1BUkMgbGFiZWxzIHRoYXQgd2VyZSBu b3QKdmFsaWQgRE1BUkMgcmVjb3Jkcywgb25seSBhYm91dCA0LDEwMCBmZWF0dXJlIHRoZSBz dHJpbmcgIkRNQVJDIiBvcgoidj1kbWFyYyIuIEFuIGV4aGF1c3RpdmUgY2xhc3NpZmljYXRp b24gaGFzbid0IGJlZW4gY29tcGlsZWQsIGJ1dApoZXJlIGFyZSB0aGUgbWFsZm9ybWF0aW9u cyB0aGF0IGhhdmUgYmVlbiBpc29sYXRlZCBzbyBmYXIuCgoobm8gInA9IiB0YWcvdmFsdWUp ICAxLDY5OAlNaXNzaW5nICJwPSIgdGFnL3ZhbHVlIGF0IHBvbGljeSBsYWJlbAogICAgCSAJ ICAgICAJCShlLmcuIG5vdCAuLi5fcmVwb3J0Ll9kbWFyYy4uLikKdj1kbWFyYzEJICAgICAg IDgxMAlUaGUgc3RyaW5nICJETUFSQyIgbXVzdCBiZSB1cHBlciBjYXNlCkRNQVJDMTsgcD0u Li4gIAkgICAgCTYyCU1pc3NpbmcgInY9IgpcXDIyNlxcMTI4XFwxNTZ2PURNQVJDMQk0MAlJ bmNvcnJlY3QgcXVvdGluZy9lc2NhcGluZwpfZG1hcmMgdj1ETUFSQzEJCTE5CUV4dHJhbmVv dXMgdGV4dAp2PURNQVJDOwkJMTUJTWlzc2luZyB0aGUgIjEiIGluICJETUFSQzEiClRYVCBc XFwidj1ETUFSQzEJIDcJRXh0cmFuZW91cyB0ZXh0IGFuZCBxdW90aW5nCnY9RE1BUkMxLzsJ CSA2CUluY29ycmVjdCBlc2NhcGUgY2hhcmFjdGVyCnY9RE1BUkMxOgkJIDQJVXNlIG9mICI6 IiBpbnN0ZWFkIG9mICI7Igp2PURNQVJDMTxTUD5wPQkJIDQJVXNpbmcgIjxTUD4iIGF0IGFs bAp2JTI1M0RETUFSQzElMjUzQgkgMwlUd28gbGV2ZWxzIG9mIGNoYXJhY3RlciBlc2NhcGlu Zwp2PURNQVJDMTsgXFwyMjZcXDEyOAkgMwlJbmNvcnJlY3QgcXVvdGluZy9lc2NhcGluZwo9 RE1BUkMxCQkJIDIJTWlzc2luZyB0aGUgInYiIGluICJ2PSIgdGFnL3ZhbHVlIHBhaXIKdi1E TUFSQzEJCSAxCU1pc3NpbmcgdGhlICI9IiBpbiAidj0iIHRhZy92YWx1ZSBwYWlyCgpJbiBh ZGRpdGlvbiwgYSBudW1iZXIgb2YgcmVjb3JkcyBhcHBlYXIgd2l0aCB3aWRlbHkgdmFyeWlu ZyBudW1iZXJzCmFuZCBhcnJhbmdlbWVudHMgb2YgZXNjYXBlIG9yIHF1b3RpbmcgY2hhcmFj dGVycy4gSXQgaXMgbm90IGF0IGFsbAp1bmNvbW1vbiB0byBzZWUgY29uc3RydWN0cyBsaWtl IHRoZSBmb2xsb3dpbmc6CgpcIlxcXCJ2PURNQVJDMTsgICAgICAgNjE4IAlOdW1lcm91cyBl c2NhcGVzL3F1b3RlcwpcInY9RE1BUkMxO1wiIFwicCAgICAgMTg3CUVzY2FwZXMvcXVvdGVz IHdpdGhpbiB0aGUgcmVjb3JkClwidj1ETUFSQzE7XCIgXCJwPVwiICAgIDQJRXNjYXBlcyBh bmQgbWlzc2luZyAicD0iIHZhbHVlClwiXCIgXCJ2PURNQVJDMVwiICAgICAgIDIJRXNjYXBl cywgcXVvdGVzLCBhbmQgc3BhY2VzLi4uClwiIFxcXCJ2PURNQVJDMTsJMQkuLi4KCgoKSW5j b3JyZWN0IFBvbGljeSBWYWx1ZXMKPT09PT09PT09PT09PT09PT09PT09PT0KClRoZSB1c2Ug b2YgaW5jb3JyZWN0IHBvbGljeSB2YWx1ZXMgaW4gdGhlICJwPSIgdGFnL3ZhbHVlIHBhaXIs IG9yIG9mIGEKcHJlLXB1YmxpY2F0aW9uIHRhZyBuYW1lIHN1Y2ggYXMgInBvbGljeSIgaW5z dGVhZCBvZiAicCIsIG1heSBiZSBvZgpwYXJ0aWN1bGFyIGludGVyZXN0IHRvIHRoZSB3b3Jr aW5nIGdyb3VwIHdoZW4gcmVmaW5pbmcgdGhlIHByb3RvY29sCnNwZWNpZmljYXRpb24uIEZv ciB0aGlzIHJlYXNvbiB0aGV5IGFwcGVhciBiZWxvdyBpbnN0ZWFkIG9mIGFib3ZlIHdpdGgK dGhlIGdlbmVyYWwgbWFsZm9ybWVkIERNQVJDIHJlY29yZHMuCgpwPW1vbml0b3IJICAgICAg IDEyNQlJbmNvcnJlY3QgInA9IiB2YWx1ZQpwb2xpY3k9bm9uZQkJNTIJSW5jb3JyZWN0L291 dGRhdGVkIHRhZwpwPW1vbml0b3I7IHNwPW1vbml0b3IJNDEJSW5jb3JyZWN0ICJwPSIgYW5k ICJzcD0iIHZhbHVlCnA9bm9uZWUJICAgCQkyMAlJbmNvcnJlY3QgInA9IiB2YWx1ZQpwPTsJ CQkxNglNaXNzaW5nIHZhbHVlIG9mICJwPSIgdGFnL3ZhbHVlIHBhaXIKcD1xdWFyYW50YWlu ZQkJMTEJSW5jb3JyZWN0ICJwPSIgdmFsdWUKcD1xdWFyZW50aW5lCQkgNwlJbmNvcnJlY3Qg InA9IiB2YWx1ZQpwPXF1YXJpbnRpbmUJCSA3CUluY29ycmVjdCAicD0iIHZhbHVlCnA9bm9u OwkJCSAzCUluY29ycmVjdCAicD0iIHZhbHVlCnA9YmxvY2tlZAkJIDEJSW5jb3JyZWN0ICJw PSIgdmFsdWUKCgoKU3VtbWFyeQo9PT09PT09CgpUaGUgbWFqb3JpdHkgb2Ygbm9uLURNQVJD IEROUyBUWFQgcmVjb3JkcyBhcHBlYXJpbmcgYXQgIl9kbWFyYyIgbGFiZWxzCmluIHRoZSBz aXggeWVhciBGYXJzaWdodCBkYXRhc2V0IGlzIG1vc3QgbGlrZWx5IGR1ZSB0byB0aGUgd2lk ZXNwcmVhZAp1c2Ugb2Ygd2lsZGNhcmQgU1BGIHJlY29yZHMuIEdpdmVuIHRoYXQsIGhvdyBt YW55IHJlY29yZHMgZnJvbSB0aGUKZGF0YXNldCBzaG91bGQgYWN0dWFsbHkgYmUgY29uc2lk ZXJlZCBhcyBtYWxmb3JtZWQgb3IgcHJvYmxlbWF0aWMKRE1BUkMgcmVjb3Jkcz8KClRha2lu ZyB0aGUgcmVjb3JkcyBkZXNjcmliZWQgaW4gdGhlIGxhc3QgdHdvIHNlY3Rpb25zLCAiTWFs Zm9ybWVkCkRNQVJDIFJlY29yZHMiIGFuZCAiSW5jb3JyZWN0IFBvbGljeSBWYWx1ZXMsIiB3 ZSBjYW4gYmUgZmFpcmx5CmNvbmZpZGVudCB3ZSdyZSBjb25zaWRlcmluZyByZWNvcmRzIGlu dGVuZGVkIHRvIGJlIERNQVJDIGRlcGxveW1lbnRzLgpUaGF0IGdpdmVzIHVzIDMsNzY5IGlu dmFsaWQgRE1BUkMgcmVjb3JkcywgcmVjb2duaXppbmcgdGhlcmUgbWF5IGJlCnNvbWUgb3Zl cmxhcCBvZiByZWNvcmRzIHdpdGggbW9yZSB0aGFuIG9uZSB0eXBlIG9mIGZsYXcuCgpTaW5j ZSB0aGVzZSBhcmUgYWxsIHRoZSBpbnZhbGlkIHJlY29yZHMgY2FwdHVyZWQsIHRoZXkgc2hv dWxkIGJlCmNvbXBhcmVkIHRvIGFsbCB0aGUgdmFsaWQgRE1BUkMgcmVjb3JkcyBjYXB0dXJl ZCAoMTg0LDY3NikuIFRoaXMKYXBwZWFycyB0byB5aWVsZCBhbiBlcnJvciByYXRlIG9mIGxp dHRsZSBvdmVyIDIlIGZvciBhbGwgRE1BUkMgcmVjb3JkcwppbiBvdXIgZGF0YXNldC4KCldo YXQgYXJlIHRoZSBtb3N0IGNvbW1vbiBmYXVsdHMgb2JzZXJ2ZWQ/IFRoZSBtb3N0IGNvbW1v biBmYXVsdCBpbiBhCnB1Ymxpc2hlZCBETUFSQyByZWNvcmQgYXBwZWFycyB0byBiZSBvbWlz c2lvbiBvZiB0aGUgcmVxdWlyZWQgInA9Igpwb2xpY3kgdGFnLiBUaGUgc2Vjb25kIG1vc3Qg Y29tbW9uIGZhdWx0IGFwcGVhcnMgdG8gYmUgbm90IGVuc3VyaW5nCnRoZSBzdHJpbmcgIkRN QVJDIiBpbiB0aGUgInY9IiB0YWcgaXMgaW4gZmFjdCB1cHBlciBjYXNlLiBBbmQgdGhlCnRo aXJkIG1vc3QgY29tbW9uIGZhdWx0IGFwcGVhcnMgdG8gaW52b2x2ZSB1c2luZyB0b28gbWFu eSBlc2NhcGUgYW5kCnF1b3RpbmcgY2hhcmFjdGVycyBpbiB0aGUgbmFtZXNlcnZlciBkYXRh LCByZXN1bHRpbmcgaW4gZXh0cmFuZW91cwpjaGFyYWN0ZXJzIGluIHRoZSBwdWJsaXNoZWQg cmVjb3JkLgoKSXQncyBrbm93biB0aGF0IG1hbnkgbWFpbCByZWNlaXZlciBpbXBsZW1lbnRh dGlvbnMgd2lsbCBzdHJpcCBvdXQgc29tZQpxdW90aW5nIGFuZCBlc2NhcGluZyBjaGFyYWN0 ZXJzIGluIERNQVJDIHJlY29yZHMgdGhleSByZXRyaWV2ZSwgdGhvdWdoCnRoZSBkZXRhaWxz IGFyZSBub3Qga25vd24uIFRoZXkgbWF5IG9ubHkgc3RyaXAgdGhlIG91dGVybW9zdCBwYWly LApvbmx5IG9wZXJhdGUgYmV0d2VlbiB0aGUgYmVnaW5uaW5nIGFuZCAidj0iIGF0IHRoZSBz dGFydCBvZiB0aGUKcmVjb3JkLCBldGMuIFdoaWxlIGEgZ2l2ZW4gcmVjZWl2ZXIncyB2YWxp ZGF0aW9uIG1ldGhvZHMgbWlnaHQgcHJvZHVjZQpkaWZmZXJlbnQgdG90YWxzLCB0aGlzIGlz c3VlIGlzIHByb2JhYmx5IHN0aWxsIGEgc29saWQgdGhpcmQgcGxhY2UKcmFua2luZyBhcyBh IGNsYXNzIG9mIHByb2JsZW0uCgo= --------------373C3D2653D19519FC13AF01-- From nobody Fri Sep 9 20:59:35 2016 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 DFD4E12B31F for ; Fri, 9 Sep 2016 20:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykLKKnh6ukEG for ; Fri, 9 Sep 2016 20:59:33 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD31812B31B for ; Fri, 9 Sep 2016 20:59:32 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id y2so184046598oie.0 for ; Fri, 09 Sep 2016 20:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=rBrgAC61p5C9X3xA5AbVAl0xOIo/POTF7IEMuOFg1dQ=; b=JJ/eFzFCGHYnA8xz/Ipa/aNcY305lFBGOdNUgnra9D4u3fazJ1jeS9rNEE3tecKedb ej/LoeNsZwAVQM2wxvgMM1+eZEjQF9e193Zj7JFVlWanLFplfHkrXNB+jvyUxPIP/NsQ KH5Lj7xo2qzWX3yFONyGUirBPUzKs5u69GJcnZYF+JZKwsApkOp4pZpuRsa25VRzZ5wu 25VgiRNmxGQrTyTqypnSlcqEmqlfjpIUAer8+kehfKUYXEwuokfMa06MmNdj6n0Zgh4v TboP/HgWRYryQxV+zPdj4M3ucBrBsKowuHks3a5LbWF5SK+r6wqx/eLsXqNvnHyRmmWY 7OWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=rBrgAC61p5C9X3xA5AbVAl0xOIo/POTF7IEMuOFg1dQ=; b=lVU0vDhS2y5t987WlHJNHsiMX2Ga7DAp6UcWVCqCDikbib3Qu8cbIytzF7T9tyIUbb RP1LT3bgsQeefe2aKzBe+NImTgLwiiFn228q2Qyk1inL1ktsxt7dyP2SPak+ljWL59MG PK7xhXgxk4nNNc7n6exVqzCdx60gB+HdWPzzWQX8DwKyHvAGgcG1bQM/gSlcWRkp9VXa mhgdyE3OpWFH/w/+M2R4VoMD7d7blT/AlbAmbQ42+ZtIPVFzDJTAii90XYOnIP+y7ZQ5 z4w39fPhe9ae0vqxCG0r3//9jDhMK9lVGfjsnXzb/hOs4CsNEbDbIsieJVMgHr6T/2i1 +xSw== X-Gm-Message-State: AE9vXwOcxpDDdT4zFvEhb8xyOCFX1GlKVSWo6k/DgY5L5MsubyEEWNzLXySiUz1bPWMLGw== X-Received: by 10.157.6.232 with SMTP id 95mr8496410otx.200.1473479972049; Fri, 09 Sep 2016 20:59:32 -0700 (PDT) Received: from [192.168.43.51] ([172.56.38.165]) by smtp.gmail.com with ESMTPSA id v185sm2307842oie.24.2016.09.09.20.59.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Sep 2016 20:59:30 -0700 (PDT) To: Steven M Jones , dmarc@ietf.org References: <7530787e-19c2-f67a-15b0-c058e3d2704e@crash.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 9 Sep 2016 20:59:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <7530787e-19c2-f67a-15b0-c058e3d2704e@crash.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Most common problems with DMARC records X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 10 Sep 2016 03:59:34 -0000 The web security workshop I was at today, at Stanford, included the SVP of engineering at Yelp, who was mostly talking about the challenges of building a team that does web security as part of overall development. But at one point he was running through a series of touchpoints and almost as a throwaway said 'deploying DMARC is really hard'. No clarification offered. d/ From nobody Sat Sep 10 08:59:58 2016 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 74F1C12B152 for ; Sat, 10 Sep 2016 08:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I32DsNT6NZop for ; Sat, 10 Sep 2016 08:59:53 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B09B12B097 for ; Sat, 10 Sep 2016 08:59:53 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id y2so210938454oie.0 for ; Sat, 10 Sep 2016 08:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e/7cR1ucqF39BzT3IT+xUGpAI9Fm8C0FcDlP9e4WULg=; b=YWDlyW9K/31DF6Jrr2pmD9X2fsZfQ3DqbbxgY4HsAtrfkM2R32VC1HRvt6Jm++dpf5 K8AuzAkjjiwHtU2eDnug2PfDgsYSwjIm9783AeS+u7/X71xGY/G2LCpCKqAYVpdHeDAZ rQ/pY2oEXJeUXEpiPB7Htgp9LH2Wo3gGZ7QD8yqUoU178gz4u5WAfoIcgeTs99Fu2P2C yv94ij/TYjeGXNrRs0afynwfJ/3wfJKpXdhiyqClorIU0UAIipFhHBgQJGuWnhtidpy9 oegqGXEqhNHHLsaIpNXqJrZ8rKnOAEtfPtCWWgtct4Z+x2GL5LKdj8jGOqOzcXn4xOjT kptw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e/7cR1ucqF39BzT3IT+xUGpAI9Fm8C0FcDlP9e4WULg=; b=UXgvOEmWg8kesG/AACFZuYpGUiRwKsC6kE+sC/CiS+vyFdIY8IlsNMwrAOS3dX5v99 2erQVID9LM7+AEe0UmxAAEaydv5SxmREJ4l+4YR2yeyvU2+YEQFfpE1YMvwj5Du3/x72 iGn7fBKdWgKvQf4CEe7Ft3y6OZhVb6VSsDk9k4QLPILoSWdh7TESwfMHzSmkFMAwXngy DIqrKnJ/pRDaALYETGvYbRfi2Yimc44H4bZ/Yu6dSd//3eYvhQu5rPUTy1DcCQhJ2R5a D7o+V0+PeHHWB8WvDlvoIWbR5dShufm3w15qtA/xsYqCf/WK7wUfu9VZsBWFHS6w0Fd4 dmaQ== X-Gm-Message-State: AE9vXwMie1M8qRlwxwE2NcDRoc3VLpE6+KAslHEf+8OXhkq8KY5AD9OSI3//xP5aXejmHciCLRynIV40Uz7Nfg== X-Received: by 10.202.56.85 with SMTP id f82mr15350162oia.107.1473523192760; Sat, 10 Sep 2016 08:59:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.18.41 with HTTP; Sat, 10 Sep 2016 08:59:52 -0700 (PDT) In-Reply-To: References: <7530787e-19c2-f67a-15b0-c058e3d2704e@crash.com> From: Peter Goldstein Date: Sat, 10 Sep 2016 08:59:52 -0700 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=001a113cc266793824053c295a6e Archived-At: Cc: dmarc@ietf.org, Steven M Jones Subject: Re: [dmarc-ietf] Most common problems with DMARC records X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 10 Sep 2016 15:59:56 -0000 --001a113cc266793824053c295a6e Content-Type: text/plain; charset=UTF-8 Hi Dave, Yes, I can confirm that Yelp was trying to implement DMARC and was having a challenging experience. They spent months trying to identify services and servers in use across the enterprise, as well as working on getting their SPF and DKIM configurations correct. A few weeks ago they became our client and we are now getting them to DMARC enforcement. With their permission, we'd be happy to describe the process and challenges once we're locked down and at enforcement. Best, Peter On Fri, Sep 9, 2016 at 8:59 PM, Dave Crocker wrote: > The web security workshop I was at today, at Stanford, included the SVP of > engineering at Yelp, who was mostly talking about the challenges of > building a team that does web security as part of overall development. But > at one point he was running through a series of touchpoints and almost as a > throwaway said 'deploying DMARC is really hard'. No clarification offered. > > d/ > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a113cc266793824053c295a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dave,
<= br>
Yes, I can confirm that Yelp was t= rying to implement DMARC and was having a challenging experience.=C2=A0

They spent months trying to identify services and servers in use across th= e enterprise, as well as working on getting their SPF and DKIM configuratio= ns correct.=C2=A0 A few weeks ago they became our client and we are now get= ting them to DMARC enforcement.=C2=A0 With their permission, we'd be ha= ppy to describe the process and challenges once we're locked down and a= t enforcement.=C2=A0

Best,
Peter

On Fri, Sep 9, 2016 at 8:59 PM, Dave Crocker <dcrocker@g= mail.com> wrote:
The web = security workshop I was at today, at Stanford, included the SVP of engineer= ing at Yelp, who was mostly talking about the challenges of building a team= that does web security as part of overall development. But at one point he= was running through a series of touchpoints and almost as a throwaway said= 'deploying DMARC is really hard'.=C2=A0 No clarification offered.<= br>
d/

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



--

<= br>

3D"logo

Bringing Trust to Email

Peter Goldstein | CTO &= ; Co-Founder

peter@valimail.com

+1.415.793.5783
=
--001a113cc266793824053c295a6e-- From nobody Sat Sep 10 09:43:15 2016 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 D4C2812B061 for ; Sat, 10 Sep 2016 09:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LOHcnqgz2nZ for ; Sat, 10 Sep 2016 09:43:12 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE38212B049 for ; Sat, 10 Sep 2016 09:43:11 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id y2so212816624oie.0 for ; Sat, 10 Sep 2016 09:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=P6ZX34i0Goh1OkEr/4Hx0URr0oKnkAZuKdnKcKrigaU=; b=Gu/Ed0s1pL6XyHsofYZZ97KLoOfhhsGZ1NEbOQ/6YMsu2oJXhfDWNrwvu5qoZiHWR4 Mv8XQOxKcVnk4j6SMGH6A1GNdbHtsZ66qryjMM1XqBKLMbcOlypCidTGK/B7ORHdt5ll teP2pWoVSUmk7sU2z4QhWDUJGU26pOvA5YaJCxx99NCLtYU7SzGJnEe9qltxWMREqKxZ Cf0W14StbpBjg0+lzMpzVLuS1Y0BXIO/LyyCK3IUuO718Ym05GRMNOfIAOBZlJWQI+Ll mHj3pYJ9nPPM7JJPvKJiKHvnTJppvtDg3oudgbJiOA0Mu1ukwMPJGQmZhZiaqO+YnGQL Dp2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=P6ZX34i0Goh1OkEr/4Hx0URr0oKnkAZuKdnKcKrigaU=; b=C8ZaQbvdhc5OoVoQUcTWmXbxIALwZcH3NI1cPn/BKf9HIPEhG3o4IlP1yWu9eP7Ih9 WKx2ZvaC4vjNmsp0W+clDgj/oTbIijuIqL632NwHV3Ufc6P0DBiyisO5/Ze6b2sQyx22 KXrSm87e00Ynz06Hd3yVqU2SQDDIzns4m9ANVKDU6GacG3Z4k0LJWTe0rimowlubzHmr jU5r4BL3RTE90j9AbNULuO8BtpZp8FqRoBVDSrzYYH6f9Z1HmKl/lz/fkG4X0JD7Hpsa zZg2yf+9FVl7IdZrhd4D2or+16JuhjQK36YqwqmiIRC346Ot3mh+YNiMCk8kVHy1wN7S 5SfA== X-Gm-Message-State: AE9vXwNTXM2hxxFCgBjIXl/HJqFJNaPa446nHOiQN6LvkNKGPp4EMAkaW5kUU5qHhFwX+g== X-Received: by 10.202.72.139 with SMTP id v133mr13011927oia.62.1473525791140; Sat, 10 Sep 2016 09:43:11 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:d83d:c0a3:da47:4bb4? ([2602:304:cda0:8800:d83d:c0a3:da47:4bb4]) by smtp.gmail.com with ESMTPSA id f101sm3112876otf.12.2016.09.10.09.43.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Sep 2016 09:43:10 -0700 (PDT) To: Peter Goldstein References: <7530787e-19c2-f67a-15b0-c058e3d2704e@crash.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sat, 10 Sep 2016 09:43:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org, Steven M Jones Subject: Re: [dmarc-ietf] Most common problems with DMARC records X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 10 Sep 2016 16:43:14 -0000 On 9/10/2016 8:59 AM, Peter Goldstein wrote: > > They spent months trying to identify services and servers in use across > the enterprise, as well as working on getting their SPF and DKIM > configurations correct. A few weeks ago they became our client and we > are now getting them to DMARC enforcement. With their permission, we'd > be happy to describe the process and challenges once we're locked down > and at enforcement I think we do not have a generic and comprehensive discussion of the issues and challenges for adopting SPF, DKIM and DMARC. A paper that is essentially a tutorial for ops managers, about the introduction of authentication standards for messaging, would probably aid adoption. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Sep 12 12:30:58 2016 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 5A77312B0A2 for ; Mon, 12 Sep 2016 12:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQuewidEV3TD for ; Mon, 12 Sep 2016 12:30:55 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3832E12B0C3 for ; Mon, 12 Sep 2016 12:30:55 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id n143so21098577ita.1 for ; Mon, 12 Sep 2016 12:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pDuhSpeIjlFO/p88tDszyHQ5mSVcDUeeyeNLUqTSOZA=; b=RDNDlk883o2QmARFMj7accLkV7Y84It+H1y1kPJMmYqSr+1G5661IVy/PWADEjUl83 QMGy3C6vioO4WGzL9mLs3jnsNutWkMc34mX48PjbXM/hskzhLLMSN7pVUSH/Vm1xz/sH YLEoGPI/Xjk3u3gxE6u34Jrey00Iq5Os1zlJY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pDuhSpeIjlFO/p88tDszyHQ5mSVcDUeeyeNLUqTSOZA=; b=I15Qou69qvWU1q/YocGQG9fouLikFENxvABuxKt5aZg/R1UF44Qrmx9U9nRGvja3NA 52jz5enVi5WdjhqnA00RWzTO0FB20N9mc65C5ep47gdvNvAy3didbqsdN5LxoAB0ha0Z kncVmk/B4pfqVZIcSmqCHK4mgGB48oyjP/UQu9p9W9KMl2+jkvWO9fWW0olyb9H8wTAG ++OmOvUd461ZWKjNyndh31VuiiPQPyfpukfe4O1rquTIYFlCQnXzhWANHZNDuH1yk78m fxLdUF8FlHiLo8D5z7+CWGSIHQJsFrOEaqt0TdjgykCvqzcOJSWJc/VHbdX/lBtFQhfU Lj1g== X-Gm-Message-State: AE9vXwMzBTO6JKHylb/tOzzRzG1P1KfyD7yb3ZysLjd/4Rn6CoxOQmbP1QgtSp8AeI4Gq1tfBOZEWi0sA+y8eQ== X-Received: by 10.157.6.232 with SMTP id 95mr22224860otx.200.1473708654475; Mon, 12 Sep 2016 12:30:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.159.16 with HTTP; Mon, 12 Sep 2016 12:30:53 -0700 (PDT) In-Reply-To: References: <7530787e-19c2-f67a-15b0-c058e3d2704e@crash.com> From: Kurt Andersen Date: Mon, 12 Sep 2016 12:30:53 -0700 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=94eb2c033364da52b4053c548857 Archived-At: Cc: "dmarc@ietf.org" , Peter Goldstein , Steven M Jones Subject: Re: [dmarc-ietf] Most common problems with DMARC records X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 12 Sep 2016 19:30:58 -0000 --94eb2c033364da52b4053c548857 Content-Type: text/plain; charset=UTF-8 On Sat, Sep 10, 2016 at 9:43 AM, Dave Crocker wrote: > > I think we do not have a generic and comprehensive discussion of the > issues and challenges for adopting SPF, DKIM and DMARC. > > A paper that is essentially a tutorial for ops managers, about the > introduction of authentication standards for messaging, would probably aid > adoption. Tim Draegon has presented something like this in a slide deck at a M3AAWG meeting a few sessions ago. I also did a session similar to this aimed at startups at the O'Reilly Velocity conference (Santa Clara) last year. --Kurt --94eb2c033364da52b4053c548857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Sep 10, 2016 at 9:43 AM, Dave Crocker <dcrocker@gmail.com> wrote:

I think we do not have a generic and comprehensive discussion of the issues= and challenges for adopting SPF, DKIM and DMARC.

A paper that is essentially a tutorial for ops managers, about the introduc= tion of authentication standards for messaging, would probably aid adoption= .

Tim Draegon has presented something like = this in a slide deck at a M3AAWG meeting a few sessions ago. I also did a s= ession similar to this aimed at startups at the O'Reilly Velocity confe= rence (Santa Clara) last year.

--Kurt=C2=A0
<= /div>
--94eb2c033364da52b4053c548857-- From nobody Mon Sep 12 12:35:58 2016 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 5957612B0C3 for ; Mon, 12 Sep 2016 12:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkkqLeuoNhyy for ; Mon, 12 Sep 2016 12:35:49 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20E9E12B046 for ; Mon, 12 Sep 2016 12:35:48 -0700 (PDT) Received: by mail-pa0-x231.google.com with SMTP id le4so168799pab.1 for ; Mon, 12 Sep 2016 12:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=289GBPFYhRsPRrb4hL6OeDutcidj5+sP4+2UZfzVQJ8=; b=NeK95+tQHt6EekeCmcgi6azWReLnfGI9Ai3JxJ1UsB/iRe9g6n5ISgDesmkLM9XWPs 42kYOidFfqxLCZ2hW1GiSUbEADjrOblCuoVyd0NoaZX/I7zVyINDGYk1vnfNctnvrcLU qBNPBOmMfx85fmSR0xQopLmZHmUyVpLNkIaREKe+IJUEdsGN6Tu771/UKUgIAY27bkXT hhParseyzN6+kISLjJNagUvJeO0KgbVmYZcUuwB8tKmtyM//whJ5JTGu9H28MZygxO2G gwzc2WG00Dmyav4qYrXs7r7eG8HjESBBeAq3EwLPfhhKG3dF6i/i7ZgKnfXxyUrF4gYX YF7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=289GBPFYhRsPRrb4hL6OeDutcidj5+sP4+2UZfzVQJ8=; b=d9llbfZ6fyfMS2zBa/MTMqozJ+ytleFYFhz+acyU9uQsSxjMW6ernCeTGZrQWrONyA kuO0ce8IA79Z+E7JloI2aD+1BGIrmkuZ4nGU3ewdiqv0b0z2cqAL8f1a+AiBjjB23rkS hHjwyTuj8im7iiGSU260xeA/VSoQqZr41PUEzurXuqy3/fD5mena7QpuYHZJmSMk+ox6 i0qfSviYci94KAmoh+nXOkZSLwz9kE2MmA/7H1ISlI7ITNUltoUH6FxLeAG+9t+E23bK c02jtmm+uBzbWB7dbvi7exieZci01zdbbxRaysDZsHVSvPeSPn5BvdYpScQuiTI0l13P YwpA== X-Gm-Message-State: AE9vXwNgSuEAf4gzXsUgW+cEz4IvCeBy++/BL17u8rLaWhPy0LyEDO5SHm32D8+7221Ixg== X-Received: by 10.66.249.200 with SMTP id yw8mr36022974pac.13.1473708947775; Mon, 12 Sep 2016 12:35:47 -0700 (PDT) Received: from [192.168.11.199] (104-60-96-29.lightspeed.sntcca.sbcglobal.net. [104.60.96.29]) by smtp.gmail.com with ESMTPSA id 24sm26308059pfr.29.2016.09.12.12.35.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Sep 2016 12:35:46 -0700 (PDT) To: Kurt Andersen References: <7530787e-19c2-f67a-15b0-c058e3d2704e@crash.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <05ae79f2-f844-eafb-d6e0-656bee49e5d4@gmail.com> Date: Mon, 12 Sep 2016 12:35:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , Peter Goldstein , Steven M Jones Subject: Re: [dmarc-ietf] Most common problems with DMARC records X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 12 Sep 2016 19:35:57 -0000 On 9/12/2016 12:30 PM, Kurt Andersen wrote: > Tim Draegon has presented something like this in a slide deck at a > M3AAWG meeting a few sessions ago. I also did a session similar to this > aimed at startups at the O'Reilly Velocity conference (Santa Clara) last > year. So, I'll suggest those materials should get turned into a M3AAWG white paper... I'm glad to assist with the grunt work but, of course, don't have the hands-on experience needed to drive this. d? -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 20 10:32:24 2016 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 05BA012B106 for ; Tue, 20 Sep 2016 10:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53iV-wnPHnVw for ; Tue, 20 Sep 2016 10:32:19 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA33C12B0D8 for ; Tue, 20 Sep 2016 10:32:19 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u8KHW91w063583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 20 Sep 2016 10:32:15 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u8KHW91w063583 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1474392735; bh=uBKVs/LeHXR9DPSmkkJY7ly7Oe/oaoHNVmCe45cVZGo=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=WdGMCUy3qK7KR780dMX5wTplszrf4rBAwmKJI6gJdV8cSkIx/kKX4Yfob7ZsrU+h+ kpdmU/hEeI7p6Ya2aYQG2XZq875kljx07GBKVx528dwM4itrhmz0KAsQEuDwSZhl/V wPsN7A430c9dGG+8VG1IpxHW+xihwDqFi3gbW/lXrHpWJ8k0RNyX7ViEU0b4R/hiBL P4F6FB/NtGBw2p0H2VqTAvYeFjZbCQkSxiQjyEh9zH0b1/87XtblL87C2c3JwmtfuA GznLNnRVgKFBA6J5Rtqp4Ew+wPAY1y3oYQUyHyaJemllZTNHTOp+6B7F/cgQk4329m 6DM27TkZuPGVA== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] To: dmarc@ietf.org From: Steven M Jones Organization: Crash Computing Message-ID: <25200867-cbda-a6fa-5318-26cc539dcdd3@crash.com> Date: Tue, 20 Sep 2016 10:32:13 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Tue, 20 Sep 2016 10:32:15 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] ARC Interoperability testing event this Friday, 9/23 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 20 Sep 2016 17:32:22 -0000 Have an implementation of the ARC protocol? We will be holding an interoperability testing event this Friday, 9/23, between 9 and 11:30AM Pacific (Noon and 2:30PM Eastern). Several different implementations will be available for testing with each other, and remote participation is the norm (versus traveling). This is an event for those implementing ARC functionality in a product or service, free or commercial. If you have an implementation, or are actively working on one, and are not already on our interoperability mailing list, please contact me directly via email to be included in these events. Thanks, --Steve. =20 Steven M Jones DMARC.org e: smj@dmarc.org, smj@crash.com From nobody Wed Sep 21 01:11:01 2016 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 AED5512B0EF for ; Wed, 21 Sep 2016 01:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XERkHTFV2JPl for ; Wed, 21 Sep 2016 01:10:57 -0700 (PDT) Received: from lepidum.jp (lepidum.jp [60.32.83.213]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889AF12B02F for ; Wed, 21 Sep 2016 01:10:57 -0700 (PDT) Received: from okadakoujinombp.local.lepidum.net (lepidum.net [60.32.83.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: okd@lepidum.co.jp) by mail06.server.lepidum.net (Postfix) with ESMTPSA id CDA5A2F8000C5; Wed, 21 Sep 2016 17:10:55 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Kouji Okada Date: Wed, 21 Sep 2016 17:10:55 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147444383872.26699.16623751845390083865.idtracker@ietfa.amsl.com> To: dmarc X-Mailer: Apple Mail (2.3124) X-Clamav-Info: Checked(Clean) X-LepidumMailFilterAgent-by: mailfromd (5.1) X-LepidumMailFilterAgent-Info: Original (mailfrom:Inbound) Archived-At: Cc: Kouji Okada Subject: [dmarc-ietf] Fwd: I-D Action: draft-akagiri-dmarc-virtual-verification-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 21 Sep 2016 08:11:01 -0000 We have submitted new version of = draft-akagiri-dmarc-virtual-verification The diffs from 00 are listed below. * Removed Roadmap section * Added focus of document to Introduction and Problem Statement * Added Use cases section Any comments will be appreciated. Best regards, Kouji Okada > =E8=BB=A2=E9=80=81=E3=81=95=E3=82=8C=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB= =E3=83=BC=E3=82=B8=EF=BC=9A >=20 > =E5=B7=AE=E5=87=BA=E4=BA=BA: internet-drafts@ietf.org > =E4=BB=B6=E5=90=8D: I-D Action: = draft-akagiri-dmarc-virtual-verification-01.txt > =E6=97=A5=E4=BB=98: 2016=E5=B9=B49=E6=9C=8821=E6=97=A5 16:43:58 JST > =E5=AE=9B=E5=85=88: > =E8=BF=94=E4=BF=A1=E5=85=88: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : DMARC verification without record definitions > Authors : Genki Yasutaka > Takehito Akagiri > Masaki Kase > Kouji Okada > Kaoru Maeda > Filename : = draft-akagiri-dmarc-virtual-verification-01.txt > Pages : 9 > Date : 2016-09-21 >=20 > Abstract: > While DMARC is a powerful architecture to protect email users from > malicious email activities, its deployment is still a work in > progress. To encourage further adoption of DMARC, in this draft we > propose an incremental deployment procedure. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-akagiri-dmarc-virtual-verification/= >=20 > There's also a htmlized version available at: > = https://tools.ietf.org/html/draft-akagiri-dmarc-virtual-verification-01 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-akagiri-dmarc-virtual-verificati= on-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Sep 22 00:55:23 2016 Return-Path: X-Original-To: dmarc@ietf.org Delivered-To: dmarc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E525112D5A5; Thu, 22 Sep 2016 00:55:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147453091192.22560.6896554083853199059.idtracker@ietfa.amsl.com> Date: Thu, 22 Sep 2016 00:55:11 -0700 Archived-At: Cc: dmarc@ietf.org, dmarc-chairs@ietf.org, barryleiba@gmail.com, aamelnikov@fastmail.fm Subject: [dmarc-ietf] dmarc - Not having a session at IETF 97 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 22 Sep 2016 07:55:12 -0000 Barry Leiba, a chair of the dmarc working group, indicated that the dmarc working group does not plan to hold a session at IETF 97. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu Sep 29 16:40:07 2016 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 6ACCC12B09C; Thu, 29 Sep 2016 16:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.918 X-Spam-Level: X-Spam-Status: No, score=-104.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGOEpiaP09W7; Thu, 29 Sep 2016 16:40:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2860212B268; Thu, 29 Sep 2016 16:40:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2066BB810F9; Thu, 29 Sep 2016 16:40:04 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160929234004.2066BB810F9@rfc-editor.org> Date: Thu, 29 Sep 2016 16:40:04 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, dmarc@ietf.org, rfc-editor@rfc-editor.org Subject: [dmarc-ietf] RFC 7960 on Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 23:40:06 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7960 Title: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows Author: F. Martin, Ed., E. Lear, Ed., T. Draegen. Ed., E. Zwicky, Ed., K. Andersen, Ed. Status: Informational Stream: IETF Date: September 2016 Mailbox: fmartin@linkedin.com, lear@cisco.com, tim@dmarcian.com, zwicky@yahoo-inc.com, kandersen@linkedin.com Pages: 27 Characters: 58739 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dmarc-interoperability-18.txt URL: https://www.rfc-editor.org/info/rfc7960 DOI: http://dx.doi.org/10.17487/RFC7960 Domain-based Message Authentication, Reporting, and Conformance (DMARC) introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. However, the DMARC mechanism enables potentially disruptive interoperability issues when messages do not flow directly from the author's administrative domain to the final Recipients. Collectively, these email flows are referred to as "indirect email flows". This document describes these interoperability issues and presents possible methods for addressing them. This document is a product of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Sep 29 16:55:13 2016 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 6DE5712B1E9 for ; Thu, 29 Sep 2016 16:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.318 X-Spam-Level: X-Spam-Status: No, score=-4.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.316, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J89lf5YnDOCX for ; Thu, 29 Sep 2016 16:55:10 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2C612B13D for ; Thu, 29 Sep 2016 16:55:09 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id u8TNsxci039410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 29 Sep 2016 16:55:05 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com u8TNsxci039410 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1475193305; bh=m6X0EvrvgnAAfUG3YD5JDOFUo/kNWzU5gJAvqxvPwHY=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Vc2LWO50Uak4GufiWoik8XuH8BO8sa1ricF3oFE8VHCFKBapo9O4ad7SSyWTE0a+M EDZEuZZfikmFccfFdSCFx/PGD1xIVCS1POvWZpHUu4Q6YNbSx1+pMpd2ncBzNtTIO3 fXBbvThM9UlcMRw3klpM43OeEn19qMmYHzZARTz2yBPsj2QWxhZwdrw9o+a+xBwlej HkOdNuheq9CT6rKIYmI4shpsmsRjl1L1xF5RMJNKuOwlNy9KqyOqSx7P2VEIj6+fKK QRj2Y2EanHR/Oug9LzfLg9vZynRwtRKU+Xc2fx6qGbWQgEbuVZt8DDiGotlCFUKbKo JSZG+JqUcMKEA== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] To: dmarc@ietf.org From: Steven M Jones Organization: Crash Computing Message-ID: <7b09be4b-5e7b-675d-5d10-64f3a7f29a83@crash.com> Date: Thu, 29 Sep 2016 16:55:03 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 29 Sep 2016 16:55:05 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] ARC: Syntax for ARC-Authentication Results header X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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, 29 Sep 2016 23:55:11 -0000 I've noticed that one ARC implementation in development does *not* use a semi-colon delimiter after the prefixed "i=3DN" sequence tag in the ARC-Authentication-Results: header, but does use it in the other two. This is probably just a bug, but it prompted me to check the spec. In section 5 of the current draft ARC spec, I couldn't find any mention one way or another about this delimiter. (And there's no ABNF, for whatever that's worth.) However if you check the examples in the appendix, I think every example has this delimiter in all three ARC headers, in each set of ARC headers for "multi-hop" examples. The use of the semi-colon is a little different under RFC7601 (Authentication-Results:), in that the semicolon separates "clauses" or "phrases" as opposed to the tag/value pairs within each clause. (And the authserv-id generally isn't a tag/value pair.) But I don't see any problem with the ARC "i=3DN" sequence tag/value being treated as a separate pre-pended clause, so long as it properly references RFC7601 in the spec. Any thoughts on this? Any other areas that need to be tightened up in the ARC draft spec?? Thanks, --Steve. --=20 Steven M Jones DMARC.org e: smj@dmarc.org, smj@crash.com From nobody Thu Sep 29 21:33:41 2016 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 E175312B044 for ; Thu, 29 Sep 2016 21:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bx_1IF9Mq7Rh for ; Thu, 29 Sep 2016 21:33:36 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CDC12B032 for ; Thu, 29 Sep 2016 21:33:36 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id r126so117258628oib.0 for ; Thu, 29 Sep 2016 21:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0k6GO0LFa1aTwiYOXTlgG4bGx4NLXORS4s7AAhYdqqk=; b=bsBPEMRABI/nocZO3Vnjk3xAeomwo68iGcbjWsZHLzlmCI6f6Fs3h+w7ghX5WRkXMz k+YKAqdi0DhR+PIkjfR3fG++ylp2pN+li0c6YytrqezAFBGlF2jEQPFAOMkvq2W5FZ+0 +71aMe0wNA4wzwQdzRfXW/Uc0Zl+fKChZqT78= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0k6GO0LFa1aTwiYOXTlgG4bGx4NLXORS4s7AAhYdqqk=; b=TC0+z/rlh6kFQ6Hll5V/cj0sf0nBKAMYg4YbvWFjeZcKLhiVnkKpCpeHZUsm+c3/Dh UZg869XfEYGHlhl1FuedMJwr94y2V9aNR5u71bedQzpumvZ0g5ZYUZblRTERmKHzj4Gw rN7nNfjsEtooQKbYEHcD+Z3tQyBuVgCkFY61NAP4XbQZR4XsebRAIqy2QKhglRkKiMh6 SgINFhIBoqgFbEgvY2mxr9hy7Enuc+lJMZUinskLkBRrTiphEYUQZ1UirGdY7pP+Q9m5 dz01+NaOAI9GEkzohltsI8jp6hBgbYYmzFzvQhhWJpHSKGo8r+/pIszQa1r9yfOjDGwn sWfQ== X-Gm-Message-State: AA6/9RmqhOW9EBlP+839mhDLXP5OZ2+pGGThV57NH0VnWmrQuAn/mpTG362MLDOgKxIXQ15ua7oXLfxO8ls+EA== X-Received: by 10.202.90.213 with SMTP id o204mr5191289oib.186.1475210015392; Thu, 29 Sep 2016 21:33:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.213.201 with HTTP; Thu, 29 Sep 2016 21:33:34 -0700 (PDT) In-Reply-To: <7b09be4b-5e7b-675d-5d10-64f3a7f29a83@crash.com> References: <7b09be4b-5e7b-675d-5d10-64f3a7f29a83@crash.com> From: Kurt Andersen Date: Thu, 29 Sep 2016 21:33:34 -0700 Message-ID: To: Steven M Jones Content-Type: multipart/alternative; boundary=001a113d5168efd778053db218d3 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ARC: Syntax for ARC-Authentication Results header X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 30 Sep 2016 04:33:39 -0000 --001a113d5168efd778053db218d3 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 29, 2016 at 4:55 PM, Steven M Jones wrote: > I've noticed that one ARC implementation in development does *not* use a > semi-colon delimiter after the prefixed "i=N" sequence tag in the > ARC-Authentication-Results: header, but does use it in the other two. > This is probably just a bug, but it prompted me to check the spec. > > . . . I don't see any > problem with the ARC "i=N" sequence tag/value being treated as a > separate pre-pended clause, so long as it properly references RFC7601 in > the spec. > > Any thoughts on this? Any other areas that need to be tightened up in > the ARC draft spec?? > In the ARC draft spec, as illustrated by the examples, I was considering the prepended i=N to be a clause in itself and thus delimited with a semi-colon. I agree that the description in the I-D for ARC does not clearly state that and the ABNF for the A-R header in 7601 attaches the semi-colon to the trailing clause, as the header gets built up. In the case of ARC's usage, we are building by pre-pending rather than tacking on the end. I can clarify the syntax in the ARC I-D (along with a couple of other minor edit points that were previously raised). If anyone thinks that's a bad idea, please let me know. Steve, thanks for getting this discrepancy highlighted. --Kurt Andersen --001a113d5168efd778053db218d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Sep 29, 2016 at 4:55 PM, Steven M Jones <smj@crash.com> wr= ote:
I've noticed that one ARC implem= entation in development does *not* use a
semi-colon delimiter after the prefixed "i=3DN" sequence tag in t= he
ARC-Authentication-Results: header, but does use it in the other two.
This is probably just a bug, but it prompted me to check the spec.

<elided>=C2=A0
=C2=A0
. . . I don't see any
problem with the ARC "i=3DN" sequence tag/value being treated as = a
separate pre-pended clause, so long as it properly references RFC7601 in the spec.

Any thoughts on this? Any other areas that need to be tightened up in
the ARC draft spec??

In the ARC draft spec, as illustra= ted by the examples, I was considering the prepended i=3DN to be a clause i= n itself and thus delimited with a semi-colon. I agree that the description= in the I-D for ARC does not clearly state that and the ABNF for the A-R he= ader in 7601 attaches the semi-colon to the trailing clause, as the header = gets built up. In the case of ARC's usage, we are building by pre-pendi= ng rather than tacking on the end. I can clarify the syntax in the ARC I-D = (along with a couple of other minor edit points that were previously raised= ). =C2=A0

If anyone thinks that's a bad idea, = please let me know. Steve, thanks for getting this discrepancy highlighted.=

--Kurt Andersen=C2=A0

--001a113d5168efd778053db218d3--