From superuser@gmail.com Sun Dec 1 11:08:08 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB78D1AE126 for ; Sun, 1 Dec 2013 11:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRVgQI6JSGaw for ; Sun, 1 Dec 2013 11:08:06 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D5C741AE035 for ; Sun, 1 Dec 2013 11:08:05 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so3839063wid.11 for ; Sun, 01 Dec 2013 11:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wbpUz/tvPM8jJDfOhJSATNZvNQmQbNN1X2BGhXtLFKY=; b=elg4xtMbeZQeELTF806x1JFuXlAc3moGDf5MTFA9fBZXAKcqPHfuBL1Z/0bC7nOCyH 5bxDJXfiu7pv2KeHph/Ga3L74wwaVxRxig3k/RgjghUA61NpqSMPNkB0s0VUTpI9qfbl 2vySXTxd3xRO+3Xy7mJ8SW7vGGdk3+/mOFHdS5ovYn3u24VJCPXcdyCa+2B5w8Rc6Tnq KsGhYwdYfa+63efa0yDojVyT0S5vQvNdqisooUKCUbWsRoXctWaGR8ToLl3mvoNtlQxM HGrfvMe3HoXKs0qe3AGL9Szz3C7BqrSLw7HT3ljor5PU7zkZgyzI1SDM/pwsrUY6SlTf zKPQ== MIME-Version: 1.0 X-Received: by 10.180.79.38 with SMTP id g6mr15281403wix.60.1385924883429; Sun, 01 Dec 2013 11:08:03 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sun, 1 Dec 2013 11:08:03 -0800 (PST) In-Reply-To: References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> <20130809234600.Horde.BohsttCU7cC5wFyE1swI8w3@horde.andreasschulze.de> Date: Sun, 1 Dec 2013 11:08:03 -0800 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=f46d044287f65cbfb204ec7dc8ad Cc: "dmarc@ietf.org" , Andreas Schulze Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 19:08:09 -0000 --f46d044287f65cbfb204ec7dc8ad Content-Type: text/plain; charset=ISO-8859-1 On Sat, Nov 30, 2013 at 11:08 PM, John R Levine wrote: > If nobody implemented http reporting yet >>> we should consider removing it from the spec... >>> >> >> Any other opinions on this point? >> > > The current spec is too messed up to allow interoperable implementations. > (PUT and POST are not the same thing at all.) > > For large reports, http PUT is a much better way to deliver them than > mail, since it's basically just a file upload to the target's web server, > no base64 encoding or decoding needed, and no extra copies filling up mail > spools. It's easily made snoop and spoof resistant by using https, and > it's easy to program because all of the usual http libraries support it. > > If any of the usual suspects are interested, I can tell you how to fix the > spec. It's not very hard, change it to be only PUT, and specify how to > construct the PUT filename for each report. > Sure, can you send specific "change this to that" sets? I'll change it in the working copy. Thanks, -MSK --f46d044287f65cbfb204ec7dc8ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Nov 30, 2013 at 11:08 PM, John R Levine <johnl@tau= gh.com> wrote:
If nobody implemented http reporting yet
we should consider removing it from the spec...

Any other opinions on this point?

The current spec is too messed up to allow interoperable implementations. (= PUT and POST are not the same thing at all.)

For large reports, http PUT is a much better way to deliver them than mail,= since it's basically just a file upload to the target's web server= , no base64 encoding or decoding needed, and no extra copies filling up mai= l spools. =A0It's easily made snoop and spoof resistant by using https,= and it's easy to program because all of the usual http libraries suppo= rt it.

If any of the usual suspects are interested, I can tell you how to fix the = spec. =A0It's not very hard, change it to be only PUT, and specify how = to construct the PUT filename for each report.

Sure, can you send specific "change this to that" sets= ?=A0 I'll change it in the working copy.

Thanks,
-= MSK
--f46d044287f65cbfb204ec7dc8ad-- From prvs=00406d3484=johnl@taugh.com Sun Dec 1 12:51:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62481AE109 for ; Sun, 1 Dec 2013 12:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNG2iz9PCTVn for ; Sun, 1 Dec 2013 12:51:36 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E74911AE10E for ; Sun, 1 Dec 2013 12:51:30 -0800 (PST) Received: (qmail 20682 invoked from network); 1 Dec 2013 20:51:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Dec 2013 20:51:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=529ba14f.xn--hew.k1310; i=sendmail-bs@submit.iecc.com; bh=zPQHATB9Hs3hBnk5u8tNSZTdLm0IiHU65+zyVfpiObw=; b=JTfRDPEpYdCH2zIWjDjLy+zeQDx3aMUGdlkhefHPwNBI4JoaX/OM0qdGQqgMjyQllJmRTF/nntyEdIoaKj9AD9EHmsOLykrYHkTncibK6oRHk0fyPPcR4lGVqyWBKvECb0v0nMFFpuN9S6GM0KW95JRK5gvnwVaCYGSaqHuzmVUX7LltDH9rfySnbBOLLsy3eTwFC/K4qYsxN/MsiLuEcqlRbeNzhpO7mnAAsCGMH/taup5OyHnbBDR5q4M9a4Sg DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=529ba14f.xn--hew.k1310; olt=sendmail-bs@submit.iecc.com; bh=zPQHATB9Hs3hBnk5u8tNSZTdLm0IiHU65+zyVfpiObw=; b=faPzzSvuczUBi4m9esKHbqi6DNXN0m3BMa+/ui3ZNRNgLuH2331x+KUxJG0NrRNndW/Cl9m5uVtWZvnxuOCCF705fwWN25ViuIj0XuMxkPIcl4gJRqaSyzvGbWsmGj0E9Z6KiPp6azA9mYRAcSEvtVbfQhLgMiaAgVYeWWKLNpgreePGMotfmrTVPiHAAY+qIhCpEz7jj1lfF1UT7ih+EQJaoOxvbNy2OLLDXcMKEZIZELFI9C/wxqkC9tkwqKhy Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Dec 2013 20:51:27 -0000 Date: Sun, 1 Dec 2013 15:51:26 -0500 (EST) From: John R Levine To: "Murray S. Kucherawy" In-Reply-To: Message-ID: References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> <20130809234600.Horde.BohsttCU7cC5wFyE1swI8w3@horde.andreasschulze.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-824759681-1385931087=:67215" Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 20:51:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-824759681-1385931087=:67215 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > Sure, can you send specific "change this to that" sets? I'll change it in > the working copy. Replace section 11.2.2, which I gather is now 12.2.2, with this: 11.2.2. HTTP Where an "http" or "https" method is requested in a Domain Owner's URI list, the Mail Receiver delivers the the data using a PUT http request. The URI for the PUT request is the URI from the list concatenated with a filename constructed as described in the previous section. The extension in the filename MUST be .xml. The filename SHOULD contain a unique-id that is difficult to guess. For example, if the URI in the list were "http://example.com/dmarc-report/" the URI for the PUT request might be http://example.com/dmarc-report/mail.receiver.example!example.com!1013662812!1013749130!!~q!}{..xml The Mail Receiver MUST send the Appendix C data as a text/xml media type and SHOULD use the gzip content-coding. I checked that the http and URI specs specifically allow exclamation points. The semantics of a PUT is that the URI is the name of a file that's being uploaded. If you do two puts with the same URI, the second one replaces the first one, so don't do that unless the first one was a mistake. Bad guys can send fake reports, which they can also do through e-mail, but they can't stomp on real reports unless they know the filename, which seems unlikely with a unique-id. R's, John PS: The rule for unique-id imports "token" from MIME, which allows exclamation points and periods tildes and and curly braces. Is that really what you want? --3825401791-824759681-1385931087=:67215 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMjAxMjA1MTI3WjAjBgkqhkiG 9w0BCQQxFgQUFHfpXbc62AYdcErvBEE/poH0MvcweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEACQpGFfQIZx3Z h5k6Yex3lnYWuzAq7rZNlM1vBCjbF14cM4uojS4QVR94gTf1zxSPJko3k9Vq DEA+iD8h2qFm2qQqX+1plB52pRokRd8vSi2Jg3z/Ab4QLUE4XJ153Gy62kee DWVxwuEE/QC+e16IET2v39VQ1hfxkYkNFMhIKL1h1neNxroTWg227hZgDoAh 9FQKrc2GombA5klObY1hBTqPyB3IcEWSzc9d/Lmi9uRBoKq5mAIrgYVFIA0h q8gWtrwo3aXCzrePMV1RFnHfi90aj9fr3fX6ILKr1xYCRJe2a0k8U9//MXUV z2yYu+Fs7dL+5N3jWu4Sk4Um9OcOcQ== --3825401791-824759681-1385931087=:67215-- From franck@peachymango.org Sun Dec 1 13:36:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562A01AE19F for ; Sun, 1 Dec 2013 13:36:47 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqoasy3E-0C4 for ; Sun, 1 Dec 2013 13:36:44 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id C68511AE183 for ; Sun, 1 Dec 2013 13:36:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 8FA334F41C2; Sun, 1 Dec 2013 15:36:42 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lr1IdKXmRjOR; Sun, 1 Dec 2013 15:36:42 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6E0004F41CC; Sun, 1 Dec 2013 15:36:42 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 587F54F41C6; Sun, 1 Dec 2013 15:36:42 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 69l4GTupKded; Sun, 1 Dec 2013 15:36:42 -0600 (CST) Received: from [10.0.0.12] (c-24-5-172-97.hsd1.ca.comcast.net [24.5.172.97]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 6FF7C4F41C2; Sun, 1 Dec 2013 15:36:41 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E867E268-31FA-4ED9-8521-900A6018981E" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Franck Martin In-Reply-To: Date: Sun, 1 Dec 2013 13:36:44 -0800 Message-Id: <61D26087-7352-481F-A710-A04CF4062F84@peachymango.org> References: <52251471.8070001@gmail.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1822) Cc: "dmarc@ietf.org" , Raman Gupta Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 21:36:47 -0000 --Apple-Mail=_E867E268-31FA-4ED9-8521-900A6018981E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Murray, Raman was talking when the return-path is empty like for bounces. DMARC follows SPF and uses for alignment whatever SPF used to give a = result. So when there is a return path, this is the domain in the = return-path (envelope from) otherwise when the return-path is empty this = is the domain in the helo/ehlo. =46rom the text below from Raman, which describes the way DMARC works = accurately, I'm not sure what alternate behavior DMARC should have? May be the issue is: "The host in bar.com is a valid SPF sender for = domain foo.com". However I have no idea how you can infer this statement = programatically. There is no DNS record today that allows you to infer = it (?). On Nov 30, 2013, at 10:39 PM, Murray S. Kucherawy = wrote: > Any other input on this point? DMARC currently only considers the SPF = result if there is alignment between the return path and the =46rom = field. >=20 >=20 > On Mon, Sep 2, 2013 at 3:42 PM, Raman Gupta = wrote: > I encountered a use case recently with an auto-generated email with > RFC5322.=46rom domain foo.com, sent from a host in domain bar.com. > Because the email was auto-generated by sieve, it contained a null > return path. The host in bar.com is a valid SPF sender for domain = foo.com. >=20 > DMARC failed the SPF check despite the valid SPF, since the > RFC5322.=46rom address was not aligned with the domain bar.com = extracted > from the HELO/EHLO. >=20 > A valid way to circumvent this problem is to use DKIM signing, aligned > with foo.com, in which case DMARC is designed to ignore the SPF > failure and pass overall. >=20 > However, I do think this is a valid situation which the SPF alignment > rules should consider. >=20 > I hope I have explained this sufficiently. Thank you to Steven Jones > and Scott Kitterman and others on the dmarc-discuss list for > clarifying the situation presented here. >=20 > Regards, > Raman Gupta > Principal > VIVO Systems > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail=_E867E268-31FA-4ED9-8521-900A6018981E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Murray,

Raman was talking when = the return-path is empty like for = bounces.

DMARC follows SPF and uses for = alignment whatever SPF used to give a result. So when there is a return = path, this is the domain in the return-path (envelope from) otherwise = when the return-path is empty this is the domain in the = helo/ehlo.

=46rom the text below from Raman, = which describes the way DMARC works accurately, I'm not sure what = alternate behavior DMARC should have?

May be = the issue is: "The host in bar.com is a valid SPF sender for = domain foo.com". However I have no idea how you can infer this = statement programatically. There is no DNS record today that allows you = to infer it (?).

On Nov 30, 2013, at 10:39 PM, = Murray S. Kucherawy <superuser@gmail.com> = wrote:

Any other input on this = point?  DMARC currently only considers the SPF result if there is = alignment between the return path and the =46rom field.


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

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

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

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

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

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

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

= --Apple-Mail=_E867E268-31FA-4ED9-8521-900A6018981E-- From franck@peachymango.org Sun Dec 1 13:44:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032AB1AE1AD for ; Sun, 1 Dec 2013 13:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvtRJ1QQhqfB for ; Sun, 1 Dec 2013 13:44:00 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 681991AE1AA for ; Sun, 1 Dec 2013 13:44:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 834C24F4086; Sun, 1 Dec 2013 15:43:58 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryS_Frmh-TNE; Sun, 1 Dec 2013 15:43:58 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 60DE04F41D5; Sun, 1 Dec 2013 15:43:58 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 4AE4D4F41D0; Sun, 1 Dec 2013 15:43:58 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ct_Ca9VeOxeW; Sun, 1 Dec 2013 15:43:58 -0600 (CST) Received: from [10.0.0.12] (c-24-5-172-97.hsd1.ca.comcast.net [24.5.172.97]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 51DDB4F4086; Sun, 1 Dec 2013 15:43:57 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Franck Martin In-Reply-To: Date: Sun, 1 Dec 2013 13:44:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> <20130809234600.Horde.BohsttCU7cC5wFyE1swI8w3@horde.andreasschulze.de> To: John R Levine X-Mailer: Apple Mail (2.1822) Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 21:44:02 -0000 On Dec 1, 2013, at 12:51 PM, John R Levine wrote: >> Sure, can you send specific "change this to that" sets? I'll change = it in >> the working copy. >=20 > Replace section 11.2.2, which I gather is now 12.2.2, with this: >=20 > 11.2.2. HTTP >=20 > Where an "http" or "https" method is requested in a Domain Owner's > URI list, the Mail Receiver delivers the the data using a PUT http > request. The URI for the PUT request is the URI from the list > concatenated with a filename constructed as described in the = previous > section. The extension in the filename MUST be .xml. The filename > SHOULD contain a unique-id that is difficult to guess. For example, > if the URI in the list were "http://example.com/dmarc-report/" the = URI > for the PUT request might be >=20 > = http://example.com/dmarc-report/mail.receiver.example!example.com!10136628= 12!1013749130!!~q!}{..xml >=20 > The Mail Receiver MUST send the Appendix C data as a text/xml media > type and SHOULD use the gzip content-coding. >=20 > I checked that the http and URI specs specifically allow exclamation = points. >=20 > The semantics of a PUT is that the URI is the name of a file that's = being uploaded. If you do two puts with the same URI, the second one = replaces the first one, so don't do that unless the first one was a = mistake. Bad guys can send fake reports, which they can also do through = e-mail, but they can't stomp on real reports unless they know the = filename, which seems unlikely with a unique-id. >=20 For email, we do recommend, that the report be sufficiently = authenticated (pass DMARC). What kind of protection we could provide for = http? Client certificate, which would require https only? Add some sort = of DNS record to say these reports come only from these IPs? I think we should drop http, anyhow, and mandate https. This is = fashionable lately. From prvs=00406d3484=johnl@taugh.com Sun Dec 1 14:15:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182341AE1B5 for ; Sun, 1 Dec 2013 14:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14_QNT-6KFeN for ; Sun, 1 Dec 2013 14:15:14 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3F51ADF26 for ; Sun, 1 Dec 2013 14:15:13 -0800 (PST) Received: (qmail 32254 invoked from network); 1 Dec 2013 22:15:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Dec 2013 22:15:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=529bb4ef.xn--hew.k1310; i=sendmail-bs@submit.iecc.com; bh=LGeCpXPHQd1bZiTVmdPeZXwklhH9QT7ca5mFuaEuj3M=; b=vrAjtSdGP0jBrJlAljAf6euEvhQF3nqZvTMXGzn5g21duq/IAfnzq8+V3UeWO4PdMF/BFWsfeD/mD5ZjN+j7mIWKuOJDGKaJhExXsX3ZCvZBnYzxwchrY4aiuAPPEjm1SSJghZl56l+9RNq8DiERynfUQv0rfQIr6a58ygThlsX8DAuFFJdOBNj6riX6PqNcRHrCAwMO6CuZ1g+gXlrlCrQZkI+XIHpzD7DfRdqpAEgYMKPlfzIvRYcEmzorWyGz DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=529bb4ef.xn--hew.k1310; olt=sendmail-bs@submit.iecc.com; bh=LGeCpXPHQd1bZiTVmdPeZXwklhH9QT7ca5mFuaEuj3M=; b=oShgkps3Im4Oj4iV+DHfC4eSUugz2dILlWhdHAe4LoCutcpHqTPO27mpx3qLlVjKYNu1ihwvDo0oWIcQNpjOYba1lcsrIt+EoEO3jywNrTwZee0WstpIi9mCSTj0I+xaBRbuHxczGsGS+r7WcLwQHdxWfYm3w+0lza2d/hoL6O2EWwOWMA6WUGvfTA5ZjvZbqL80eRnzpMrw1l9sMAz4bqGhkrbJyT7nsSAhaXZyogv0HETvNG+BbY8jrsl+njX/ Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Dec 2013 22:15:11 -0000 Date: Sun, 1 Dec 2013 17:15:10 -0500 (EST) From: John R Levine To: Franck Martin In-Reply-To: Message-ID: References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> <20130809234600.Horde.BohsttCU7cC5wFyE1swI8w3@horde.andreasschulze.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-275686907-1385936111=:67496" Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 22:15:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-275686907-1385936111=:67496 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > For email, we do recommend, that the report be sufficiently > authenticated (pass DMARC). What kind of protection we could provide for > http? Client certificate, which would require https only? Add some sort > of DNS record to say these reports come only from these IPs? Client certificates work now, anything else requires moving parts that don't exist yet. Replace section 11.2.2, which I gather is now 12.2.2, with this: 11.2.2. HTTP Where an "http" or "https" method is requested in a Domain Owner's URI list, the Mail Receiver delivers the the data using a PUT http request. The URI for the PUT request is the URI from the list concatenated with a filename constructed as described in the previous section. The extension in the filename MUST be .xml. The filename SHOULD contain a unique-id that is difficult to guess. For example, if the URI in the list were "http://example.com/dmarc-report/" the URI for the PUT request might be http://example.com/dmarc-report/mail.receiver.example!example.com!1013662812!1013749130!!~q!}{..xml The Mail Receiver MUST send the Appendix C data as a text/xml media type and SHOULD use gzip content-coding. If the URI has an "https" method the Mail Receiver SHOULD present a client certificate that includes the domain in its report (in the example above, mail.receiver.example) to authenticate itself. R's, John --3825401791-275686907-1385936111=:67496 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMjAxMjIxNTExWjAjBgkqhkiG 9w0BCQQxFgQUbJqUjxEnwDuxyaQ6Sa1Sy9vwZJYweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEARVFoofwa+AP1 spgDNyrkildKsd499NxO9jipH1pqvOH7SXmqDmU3lxy0DrA8EiHeLYQB2Jck hyLXjeTHq3ifQifB+0Ns02K+avqp4zMm5hTWz+q5Jzuww65XrJk8ZROrAZKw /4CwaNMoikgPt443sSNw/YtSXN5jCpIulAr29ZD+U2ZMTmMEoDUNyj2vzfXz mdjbz2VJAl4cmvH98oHS3AwoZMugXUn/bQtUz38sPKNfIBS/svNar9e0YfvQ RtW92b2kSwP6NlwePAugo/WiosCBmd1CXrG1mAJpcUoUgArmVOcQBCyHethV SUwrtK+wLHqR6nBMjyeMil8Ywx4fUQ== --3825401791-275686907-1385936111=:67496-- From sca@andreasschulze.de Sun Dec 1 23:08:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B418A1AE43D for ; Sun, 1 Dec 2013 23:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.246 X-Spam-Level: X-Spam-Status: No, score=0.246 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3UiTkuoR0fQ for ; Sun, 1 Dec 2013 23:08:08 -0800 (PST) Received: from mout.andreasschulze.de (mout.andreasschulze.de [84.201.4.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3A31AE3E0 for ; Sun, 1 Dec 2013 23:08:08 -0800 (PST) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=GzhbMIk; t=1385968080; r=y; bh=w8LCB5A/QXSWrJpCaA34irF8gIZ3p2u+fN93IGPiGG4=; h=Date:From:To:Subject:References:In-Reply-To; b=IrNK0cTDEqBtQIyknhOpJq1FDR3Oz2NBTiHaeEPbedYM3jfiWXGfibmuezMG/cltp gN2JZS4AbW6mUCwMxvvTP9P+X5wHofhoIL+uKzKuluI1GNTPOqjjs5gxFq4GhBSkcF cz9cxeC9nTJ+uRIIN/mF4+GEe/8GS6l8bJUvhR7ofHn4JCbDj6zh4g0DvO9a8Q/jFo MndASjXQK6iTbDWgL80/mb4E0pjLQUQKdGGop7wJ4gAOnRIlwBG+ScgE1M/7hLhT8l ZPeYk72zd/p7e5g5wN/qgxxvhdIr6u2NKV0ExbYA2y+TW6xjyQfrkrs1bYx0uMwNI8 1nM+jXFgWoqdWn5+KD9z09Nzw/WHreUmscKxt5+LpDx9gRQrnh+EhUYME09d/vZ9tJ MpUBd59mGysxcB542yy8AQVu9xsRyt49nwl42imNXFmCcV/LSpfkFyzsFNL7nJDEL2 UPUF8ctjPwvcrje2rnBUyoyQqJJEOs6vGPcNuMb+VLPCpPNfYqaKNUVV13pzXBwSCa hPJWqW4KXaA1K+mB451yoUbWqEMEkJ5LhcmtPbhnRLzl+H6hs1/yAybbmKo436EMi9 LxBPsmd0NpyDxlvJgfUmWQfP/hTgz6s0MTaDhK3HUmeIH4hZ+6e9DRb8Rer1PEbDWn eLzx92sR73H5phSNNW2euj7k= X-Received: line deleted by mout Date: Mon, 02 Dec 2013 08:07:58 +0100 Message-ID: <20131202080758.Horde.QeBC6E23JVJtnEoI-fytdA1@horde.andreasschulze.de> From: Andreas Schulze To: dmarc@ietf.org References: <20130809215557.Horde.NqTAQuKnN8mOfxFmS6Uf4g1@horde.andreasschulze.de> <20130809234600.Horde.BohsttCU7cC5wFyE1swI8w3@horde.andreasschulze.de> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.6) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [dmarc-ietf] Section 12.2.2 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 07:08:09 -0000 Zitat von John R Levine : >> For email, we do recommend, that the report be sufficiently >> authenticated (pass DMARC). What kind of protection we could >> provide for http? Client certificate, which would require https >> only? Add some sort of DNS record to say these reports come only >> from these IPs? > > Client certificates work now, anything else requires moving parts > that don't exist yet. yes, the requirement for authentication could be satisfied by client certificates. But this introduces additional complexity. I'm sure, I would get less more reports if I would request them https. So it could be an second way a reporter could send *full* reports if mailto: limit it's size. Andreas From mjones@agari.com Mon Dec 2 11:59:49 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8851F1AD8D5 for ; Mon, 2 Dec 2013 11:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbJ69avXsTGD for ; Mon, 2 Dec 2013 11:59:48 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id D881D1AD845 for ; Mon, 2 Dec 2013 11:59:47 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id r10so18815466pdi.38 for ; Mon, 02 Dec 2013 11:59:45 -0800 (PST) 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=5XCA0VjDg5Hz6hm96RRgF0VQTKFUNxtWgjBP/N5FmVE=; b=EE1CFTCdCugc765sxgLWn836NXwpzBjoavlsMHGgnyACq3+gGjKZJ94kuXi6hO1dgp NRhqRFsE/7Ho+QL5nwcwIfvCfaw40Ig4mh48QUZ44bQ8VieEn9vDTKPnlJFQdboJCrkz Y8Q1dAPg4Zu1lWTJK2epggoqvEHPxhJ9CYomE= 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=5XCA0VjDg5Hz6hm96RRgF0VQTKFUNxtWgjBP/N5FmVE=; b=HTV0bh+3neha3ImtSg2nAqN+4A21Omnrm1zf3JgqN/eX0FoBYW5rxmrqjV7/R+9mbK YeS1jOeTQesgkjVFtEbKbRQezp6DcTZ06ALoT3gcL1lVbB7Xs9D3eSL+cjHNUmRIvEB3 ZQM+nvt9MMc+XlPCQ8zk+VX7KHfDVmeiMrV67CMwRM65gHLQYlsqcZp4qz4y5x1D8Vjd wPEo9extcJiSFketMYaWeN925yrQBzbI2R0BBsac1Gfthl0kPveF1ILrg/lu7SiZzAuL /GNiSP+HxgSmAiLnYyC5ei1+Yls/Un1c7fEo8IEv9ecYyeOLZMEDGEFCGMJG13r+DX0U edFA== X-Gm-Message-State: ALoCoQn9vaEpyAGAL/nf0rWezhaWAkLRSzCDWhta1AYUh+w5EtG+1XmUjWHDdghTkp0bOhILMiOR X-Received: by 10.66.192.198 with SMTP id hi6mr70530883pac.87.1386014385560; Mon, 02 Dec 2013 11:59:45 -0800 (PST) Received: from [10.0.1.162] (50-197-151-169-static.hfc.comcastbusiness.net. [50.197.151.169]) by mx.google.com with ESMTPSA id oj6sm141198784pab.9.2013.12.02.11.59.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Dec 2013 11:59:44 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_71923185-5971-4D7B-AC34-2A041E6ACE7F" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Mike Jones In-Reply-To: Date: Mon, 2 Dec 2013 11:59:42 -0800 Message-Id: <3D832EE3-06F7-47C6-AC06-65A1CCF789E2@agari.com> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1822) Cc: "dmarc@ietf.org" , Greg Colburn Subject: Re: [dmarc-ietf] XSD concern, policy_evaluated should be required X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 19:59:49 -0000 --Apple-Mail=_71923185-5971-4D7B-AC34-2A041E6ACE7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I agree with Greg's point, the min0ccurs should be 1. What is the = purpose of the report without this data included?=20 Thanks, Mike Jones On Nov 30, 2013, at 10:47 PM, Murray S. Kucherawy = wrote: > Do any others wish to comment on this point? >=20 > -MSK >=20 >=20 > On Wed, Oct 16, 2013 at 5:31 AM, Greg Colburn = wrote: > We noticed some stray aggregate reports without policy_evaluated = blocks. According to page 70 in the current draft, policy_evaluated is = minOccurs=3D"0". Here is the relevant XSD. >=20 > > > > > > > > type=3D"PolicyEvaluatedType" > minOccurs=3D"0"/> > > >=20 > 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". Without policy_evaluated a significant amount of = the value of the data is lost. I propose that we update the XSD to set = the minOccurs to 1. >=20 >=20 > > > > > > > > type=3D"PolicyEvaluatedType" > minOccurs=3D"1"/> > > >=20 > Sincerely, >=20 > Greg Colburn >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail=_71923185-5971-4D7B-AC34-2A041E6ACE7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = agree with Greg's point, the min0ccurs should be 1.  What is the = purpose of the report without this data = included? 

Thanks,
Mike = Jones





On Nov 30, 2013, at 10:47 PM, Murray S. Kucherawy <superuser@gmail.com> = wrote:

Do any others wish to comment on = this point?

-MSK


On Wed, Oct 16, = 2013 at 5:31 AM, Greg Colburn <Greg.Colburn@returnpath.com> wrote:
We noticed some stray aggregate reports without policy_evaluated =
blocks.  According to page 70 in the current draft, policy_evaluated is =
minOccurs=3D"0".  Here is the relevant XSD.

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

     <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".  Without policy_evaluated a significant amount of =
the value of the data is lost.  I propose that we update the XSD to  set =
the minOccurs to 1.



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

     <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"1"/>
     </xs:all>
   </xs:complexType>

Sincerely,

Greg Colburn



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


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

= --Apple-Mail=_71923185-5971-4D7B-AC34-2A041E6ACE7F-- From superuser@gmail.com Mon Dec 2 19:35:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825CF1ADFC1 for ; Mon, 2 Dec 2013 19:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy0OcZ8nSwAU for ; Mon, 2 Dec 2013 19:35:19 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id CDC2D1ADEA7 for ; Mon, 2 Dec 2013 19:35:18 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hq4so5871054wib.8 for ; Mon, 02 Dec 2013 19:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mV5zzUCn5Suw5wTmbptnfTxKidhbBkRmfVNH5fzZ3Bs=; b=U36SBjqyQE6g7Gj74wqCvDtzlW7rcYu+I2f+CRRAkgIJrGRfGuvlbu7mZuz3CpXgc1 YES37BGspvwMHVDgoi7fQAYWRc0KKpTUV0u64KZ3TWFxNvbcUufTWLi5wtxhNBLz2Dve HzLJUMcQLtDmCS8pH6Z4RELdxIVV5jtN+DoBT4/VNH3WpHSxgmHpeJ/AxOhRYkb9qFG0 MCv9Z7ecykt1I9aCFI0HnIW5fez02BXFEKPbNXorl13wJzDZb6BiQBrma03kPqSzaIr+ VYdloleYsVbQethweWtdqGEDZUoPe2A7bUV9/yr2dXk57KSuFpw+r5Ju9N7AiolyV3nt dJdA== MIME-Version: 1.0 X-Received: by 10.180.24.137 with SMTP id u9mr432272wif.5.1386041715834; Mon, 02 Dec 2013 19:35:15 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 2 Dec 2013 19:35:15 -0800 (PST) In-Reply-To: <61D26087-7352-481F-A710-A04CF4062F84@peachymango.org> References: <52251471.8070001@gmail.com> <61D26087-7352-481F-A710-A04CF4062F84@peachymango.org> Date: Mon, 2 Dec 2013 19:35:15 -0800 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d04447f671dc61604ec98fcd5 Cc: "dmarc@ietf.org" , Raman Gupta Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 03:35:21 -0000 --f46d04447f671dc61604ec98fcd5 Content-Type: text/plain; charset=ISO-8859-1 I understood what he was saying; my issue was with my mis-remembering of what DMARC does with SPF. For some reason I was remembering that only an SPF check against the envelope sender mattered. I must've been decaffeinated. Regardless, I agree that I don't know what algorithm, short of a heuristic or something more liberal, could be used to match foo.com and bar.com in the example. The more liberal the matching is, the easier we open up an abuse vector. If this does become a pain point, we could adopt something like ATPS, but that's only something this group should consider if there's plenty of evidence that it's necessary. -MSK On Sun, Dec 1, 2013 at 1:36 PM, Franck Martin wrote: > Murray, > > Raman was talking when the return-path is empty like for bounces. > > DMARC follows SPF and uses for alignment whatever SPF used to give a > result. So when there is a return path, this is the domain in the > return-path (envelope from) otherwise when the return-path is empty this is > the domain in the helo/ehlo. > > From the text below from Raman, which describes the way DMARC works > accurately, I'm not sure what alternate behavior DMARC should have? > > May be the issue is: "The host in bar.com is a valid SPF sender for > domain foo.com". However I have no idea how you can infer this statement > programatically. There is no DNS record today that allows you to infer it > (?). > > On Nov 30, 2013, at 10:39 PM, Murray S. Kucherawy > wrote: > > Any other input on this point? DMARC currently only considers the SPF > result if there is alignment between the return path and the From field. > > > On Mon, Sep 2, 2013 at 3:42 PM, Raman Gupta wrote: > >> I encountered a use case recently with an auto-generated email with >> RFC5322.From domain foo.com, sent from a host in domain bar.com. >> Because the email was auto-generated by sieve, it contained a null >> return path. The host in bar.com is a valid SPF sender for domain foo.com >> . >> >> DMARC failed the SPF check despite the valid SPF, since the >> RFC5322.From address was not aligned with the domain bar.com extracted >> from the HELO/EHLO. >> >> A valid way to circumvent this problem is to use DKIM signing, aligned >> with foo.com, in which case DMARC is designed to ignore the SPF >> failure and pass overall. >> >> However, I do think this is a valid situation which the SPF alignment >> rules should consider. >> >> I hope I have explained this sufficiently. Thank you to Steven Jones >> and Scott Kitterman and others on the dmarc-discuss list for >> clarifying the situation presented here. >> >> Regards, >> Raman Gupta >> Principal >> VIVO Systems >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > > --f46d04447f671dc61604ec98fcd5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I understood what he was saying; my issue was wi= th my mis-remembering of what DMARC does with SPF.=A0 For some reason I was= remembering that only an SPF check against the envelope sender mattered.= =A0 I must've been decaffeinated.

Regardless, I agree that I don't know what algorithm, short o= f a heuristic or something more liberal, could be used to match foo.com and bar.com in t= he example.=A0 The more liberal the matching is, the easier we open up an a= buse vector.=A0 If this does become a pain point, we could adopt something = like ATPS, but that's only something this group should consider if ther= e's plenty of evidence that it's necessary.

-MSK



On Sun, Dec 1, 2013 at 1:36 PM, Franck= Martin <franck@peachymango.org> wrote:
Murray,<= div>
Raman was talking when the return-path is empty like for= bounces.

DMARC follows SPF and uses for alignment whatever SPF u= sed to give a result. So when there is a return path, this is the domain in= the return-path (envelope from) otherwise when the return-path is empty th= is is the domain in the helo/ehlo.

From the text below from Raman, which describes the way= DMARC works accurately, I'm not sure what alternate behavior DMARC sho= uld have?

May be the issue is: "The host in= =A0bar.com=A0is a valid SP= F sender for domain=A0foo.com<= /a>". However I have no idea how you can infer this statement programa= tically. There is no DNS record today that allows you to infer it (?).


Any other input on this point?=A0 DMARC currently only considers the SPF re= sult if there is alignment between the return path and the From field.
<= /div>


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

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

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

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

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

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

_______________________________________________
dmarc mailing list
dmarc@ietf.org
http= s://www.ietf.org/mailman/listinfo/dmarc


--f46d04447f671dc61604ec98fcd5-- From superuser@gmail.com Tue Dec 3 00:26:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A1F1ADF73 for ; Tue, 3 Dec 2013 00:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqIHipCh0eWx for ; Tue, 3 Dec 2013 00:26:13 -0800 (PST) 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 B1BCA1ADF98 for ; Tue, 3 Dec 2013 00:26:12 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so6086475wid.9 for ; Tue, 03 Dec 2013 00:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p1UDqHTvmVe04JXFjc2TPrg+9jwuf2KSWdnlp3zueco=; b=DiWCe1oJKd8BJF+Dh5QkVRKa5FAvPVnpfHviHCYPRiuSnx77ZBpy5Ha+KChHkntyNT gh6hL0r6vUUbPrAYz7lp0t6TUIdhoA9qONai7Ma8sLaWIbX5XFaZx+EJ3M11imsUPn2A qgCKWSYOdRy7mLLhJlkN8WyOg/WVWfpZXbXkH4ev0f675cNRCxgmudH2wP6Hy/JkazpE N5KT5t3TqSTsjQk+65ycVTL6oWRrWnD+tkBM7e2wpAhwV0IPYtfm2hGb2VsZD8nj9uBI Uhb1lApHUvFBcf6oGWJtW7XRnF2OujhUlfxLFBZz+PV36wyhrgf8unjw5sdHJlOG6IOt ON9A== MIME-Version: 1.0 X-Received: by 10.194.104.66 with SMTP id gc2mr1028387wjb.75.1386059169651; Tue, 03 Dec 2013 00:26:09 -0800 (PST) Received: by 10.181.13.230 with HTTP; Tue, 3 Dec 2013 00:26:09 -0800 (PST) In-Reply-To: <524CA422.8030008@bluepopcorn.net> References: <524CA422.8030008@bluepopcorn.net> Date: Tue, 3 Dec 2013 00:26:09 -0800 Message-ID: From: "Murray S. Kucherawy" To: Jim Fenton Content-Type: multipart/alternative; boundary=089e0102ef8471e21704ec9d0cbc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 08:26:21 -0000 --089e0102ef8471e21704ec9d0cbc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 2, 2013 at 3:54 PM, Jim Fenton wrote: > I have not been monitoring this mailing list, but a couple of people > have asked me to have a look at the DMARC spec. I apologize for the > amount of time it has taken for me to get to this. > > Thanks for the review, Jim. Sorry it's taken so long for me to get all the way through this. > I'll leave out the editorial issues, but I'm happy to share those (in > particular, with the editors) if there is interest. I'll start with a > lot of specific comments; there are a few additional comments at the > very end. > Happy to have your editorial comments off-list if you like. > > === > > 1. Introduction > > Paragraph 3: I'm surprised to see the use of the word "policy". In the > context of ADSP (originally Sender Signing Policy), the word "policy" > was considered inaccurate because it was deemed inappropriate to dictate > policy to a Receiving Domain. Even though SSP was describing the > domain's policy with respect to signing messages with DKIM, the word > "practices" was substituted. Is it now considered acceptable to make > policy requests of a Receiving Domain? > I don't think this has come up during the development of DMARC. In contrast, I think the use of "policy" in the SPF context has become widely understood to indicate it's a request from the author domain. I do think it's pretty clear from the document that there are no illusions that something's being demanded of the receiver. In the case of SSP and ADSP, I think we were trying to describe the signing practices of the author domain, so the receiver could make an intelligent judgement about accepting or rejecting the message. In DMARC, the practices are implied by the nature of the protocol except for what alignment of identifiers a receiver should expect. > Paragraph 4 #1: "assertions about senders' practices" : shouldn't that > be Domain Owners' practices, since the sender might include spoofers? > Yes, though we haven't introduced that term yet. I'll change it to the lowercase form. > > Paragraph 3 #1: "Senders make policy assertions" -> "Domain owners > publish policy assertions". But see comment below about "domain owners", > and note that DMARC records contain considerably more than policy > assertions. > OK. > > Paragraph 3 #2-1: "The receiver" might be interpreted as being an MUA. > Suggest "Receiving domains". "how the mail is handled" -> "how they > should handle the mail" > The outer bullet refers to SMTP Receivers, which I don't believe includes MUAs. OK on the second one. > > Last bullet: I immediately went to the case of the From: header field > with multiple addresses, which had been a significant issue with ADSP. > More about this later. > > 2.1 High-Level Goals > > First bullet: senders -> Domain Owners. Similar comment on the word > "receivers". > OK. > > Third bullet: "effect on legitimate messages" isn't clear on what the > "effect" is. Deliverability impact? > Will fix. > > 2.4 Out of Scope > > This section is full of double negatives, e.g., "not in scope for this > work include: DMARC shall not be required..." > Will fix. > > Authentication of individuals rather than domains: DMARC doesn't perform > authentication at all, it acts on the result of two other mechanisms. > This muddies that point. > I'm not sure it's important to dive into this; we're saying this is a topic we don't want to handle either way. > > 3. Terminology and Definitions > > The main part of this section is indeed terminology and definitions, but > the subsections, particularly 3.2, aren't. This should be reorganized. > OK. > > Domain Owner: This definition clearly defines the Domain Owner as the > registrant of a domain. But as we will see much later, DMARC records are > sometimes published by From domains directly, which could be a person or > organization delegated by the Domain Owner. Perhaps another term is > needed, because there are some things that are available only to Domain > Owners and others that are also available to those able to publish a DNS > record for a subdomain. > The definition does include more complex arrangements than merely the registering entity. > > Organizational Domain: I have many problems with this: > > (1) An algorithm like this doesn't belong in the definitions. > Fixed. > (2) This creates a dependency on a public suffix list such as that > published by Mozilla, but doesn't require the use of a particular list. > This would create an inconsistency in the result of DMARC that I > consider to be an interoperability problem. > Yes. We acknowledge that public suffix is far from an ideal solution, but until some of the ideas being discussed in APPSAWG and elsewhere become a reality, it's the only operational option. Your point is taken, though, that lots of sources for this information is a problem. I'll add a note about it. > (3) During the development of ADSP, it was made clear to me by the DNS > folks that there is no way, in practice, to determine an Organizational > Domain. > Right; see my comment above about APPSAWG work. > (4) The last paragraph acknowledges that it is a heuristic, and its use > of "currently" implies that something better is in the works (which > needs to be described instead in the spec). > It will be once there's a document to which to refer. > > 3.2 Overview > > Paragraph 1: "Mail sent for such a domain" -> "Mail sent from such a > domain" (important distinction!) > Fixed. > > Paragraph 2: Feedback is to the Domain Owner, not the claimed sender. > OK. > > Paragraph 4: "from the Domain Owner" -> "from the Organizational Domain" > OK. > > [aside: I see, much later in the spec, that DMARC records can be > published by the From domain directly, not just from the Domain Owner. A > lot of earlier text needs to be cleaned up to accommodate that.] > Are those not the same? Or are you talking about the subdomain case? > > 3.3 Flow Diagram > > "The above diagram shows the flow of messages": But there are lots > more. Spoofed messages have a different flow. So do mailing lists, > domains with multiple layers of MTAs, etc. This is just the simplest > flow of legitimate messages. > I'll label it as a simple or typical example. > > Item 6: "author's DNS data". For SPF and DKIM, what's queried is not > necessarily the author domain. > It is if the identifiers are aligned. I'll make that more claer. > > Item 7: "queries to the author domain": Organizational Domain? (with the > above aside as a caveat) > OK. > > 3.4 Identifier Alignment > > It would be good to start with a definition of what identifier alignment > is, and I'm not finding that (perhaps it is buried there somewhere). > It's earlier in Section 3. > > Paragraph 2 end: "most MUAs represent..." introduces a UI issue, and we > have considered that out-of-bounds in the past. > In DKIM, we require From: to be signed because it's the one guaranteed to be visible and most likely to impact user understanding of the origin of the message. DMARC takes advantage of that same assumption. But yes, this is something that could be debated. > > Paragraph 4: identity alignment -> identifier alignment > Fixed. > > This section should discuss the rare-but-legal case of From: header > fields with multiple addresses. > This is covered in Section 10.1. > > 3.4.1 DKIM-authenticated identifiers > > I got confused here right away by the use of "strict" and "relaxed" > modes without proper introduction to what they are, since those terms > are used in DKIM (as canonicalization modes) and mean something very > different here. It was only when I got to the SPF section and it was > still talking about strict and relaxed that I realized those terms were > being used in DMARC as well. > DKIM defines "simple", not "strict". Either way, I'll add a note about the recycling of the name. > > Paragraph 2: must be equal -> must be equal in order to be considered to > be in alignment > Fixed. > > Last paragraph: "DMARC pass" hasn't been defined anywhere. Does DMARC > produce a pass/fail result? > Yes. I'll mention this earlier. > > 3.4.1 and 3.4.2 > > I'm unclear on the motivation for having both strict and relaxed modes. > Is it because we don't know what will work in practice, or because > different sorts of domains will want to choose differently. If the > latter, please give some guidance for which mode should be used in which > situation. > OK. > > 4. Policy > > Paragraph 2: sending domains -> Organizational Domains (with above caveat) > Changed to "its domains". > > Paragraph 4: It's possible to determine non-use of SPF, but not DKIM, in > this way. > The DKIM equivalent is to not sign the message. What you're trying to avoid is false positives here. > > 5. DMARC Policy Record > > Paragraph 2: "matches perfectly with the DNS". Not at all -- the fact > that it isn't possible to deterministically determine the organizational > domain, is an example of the mismatch. Also, operational limits on DNS > record sizes prompts the use of non obvious syntax like the ! > construct. > I think we're talking here about why we store the record in the DNS, like SPF and DKIM and various others have done. We're not saying here that we espouse ways of determining things like the zone cut from DNS data. > > 5.2 General Record Format > > Paragraph 2: Last sentence is less about DMARC than about change control > for the spec itself. > Fixed. > > adkim tag: Definition unnecessarily limits alignment modes to "s" and > "anything else". Suggest that it require "s" or "r", with other values > reserved for future use. > Fixed, by just deferring to the ABNF. > > fo: The tag value can contain both 0 and 1; what happens then? > The union of the two means "0" is a no-op in that case. > > d: Not sure why it's interesting to find about broken signatures when > there's a good signature that meets alignment requirements. > Operators do appear to want this information, probably to aid in debugging. > > p: quarantine: What does "fails the DMARC mechanism" mean overall? Is > this defined somewhere? "suspicious": After all the controversy about > the use of the use of the word suspicious in SSP/ADSP, I'm highly amused > to see it here. > I've added "failed" earlier in the document to indicate that DMARC produces a result, so hopefully that's clarified here. SSP/ADSP tried to define Suspicious as a result, as I recall, or at least explain what it meant. We say clearly here that we have no idea by what criteria a receiver will normally categorize something as suspicious (or whatever word it uses), but the intent here is to give the receiver information in that direction. > pct: DNS domain isn't defined. DMARC mechanism is to be applied -> DMARC > policy is to be applied > "DNS domain" is a term of art that was acceptable in the past during IESG reviews when use of "domain" was ambiguous. That's why it's started appearing here. Fixed. > > rf: This is comma-separated, while other tag values are colon-separated. > Why the inconsistency? > Fixed. > Initial default values are -> Possible values are (and possibly > reference a registry) > We didn't make a registry for this because there's really only one in use in this space, and no new ones are anticipated. > [IODEF] is listed as an Informative Reference; shouldn't it be normative > like [AFRF]? > True. Fixed. > > ri: It seems like everything is best-effort; the Receiving Domain is > doing a favor here (and sendto: is itself best effort). > Right. This is explicitly described as a request. > > sp: Does this apply to subdomains at all levels, or just direct > subdomains? What's the motivation for specifying a different policy for > subdomains vs. the organizational domain? Should also point out that sp > is meaningful only for DMARC records published in Organizational Domains > and not From domains, (although publishing in From domains isn't > introduced until later in the document). > It applies to all subdomains. I'll make it say so. The motivation here is the same as it was for ADSP; if I protect bluepopcorn.net only, the spoofers could send mail with believable subdomains of that domain without receivers taking any DMARC-specific action. I'm not clear on the case you're talking about; in the DMARC context, when is the OD different from the From domain? > > 6. Policy Enforcement Considerations > > Paragraph 2: "...not to increase the likelihood of accepting abusive > mail..." This seems like a qualitative requirement, not sure it belongs > here. > This is a "Considerations" section. It's just discussion, nothing normative. > > 7.1 Verifying External Destinations > > Paragraph 3: SHOULD -- shouldn't that be a MUST? > We describe a few paragraphs down a reason why one would elect not to implement that advice, so SHOULD is more appropriate here. > > Item 8: If rua and ruf can be overridden by the report receiver, > wouldn't it be useful to be able to override at least ri and perhaps > other values as well? > Possibly. I'll let the rest of the community weigh in on that point. What other values might be worth allowing for an override? > > Third to last paragraph: "*._report._dmarc.example.com" looks rather > scary -- mechanisms that depend on DNS wildcarding are always fragile. > This may very well work, but it looks to me like this record actually > says that example.com is willing to receive reports for ANY domain, not > just child domains. > Right, that was actually the intent. The prose has already been updated. > > 7.2 Aggregate reports > > The format for these reports is critical to interoperability -- should > it really be specified in an appendix? It's more important to specify > the format of the reports than the requirements shown in the bulleted list. > The XML definition is quite large. We found this arrangement -- no huge gap in the text -- to be more palatable. > > 7.3 Failure reports > > Paragraph 1 reads as though AFRF is the only reporting format, but needs > to accommodate IODEF and any future-defined reporting formats as well. > For extensibility, there should also be a way for the Mail Receiver to > generate a meta-report saying that they don't support the requested > report format. > > I think we might consider just yanking IODEF out. I can't think of a single implementation to date. Does anybody know of one? 7.3.1 Reporting Format Update > > Are there any updates to IODEF? > I don't think there have been any implementations, so presently there are no updates. > > 7.4 Failure Reports > > Paragraph 2: "ruf" tag -> "rf" tag > Fixed. > > 8. Policy Discovery > > This is the first mention I have seen that DMARC records are published > directly on From domains; up to this point it looked like DMARC was only > published by a Domain Owner on an Administrative Domain. This changes a > lot -- like the fact that a delegate of the Domain Owner, and not the > [administrative] Domain Owner him/herself, can set the policy for a > domain. This might require a major change of terminology usage, or at > least a change in the definition of Domain Owner, to fix. > I'm not sure where the confusion came in. The only domain of interest to DMARC is the From domain; it is from this that the rest of the work (most importantly, identifier alignment) is derived. Who would a delegate of the Domain Owner be? From the perspective of a receiver, such a delegation is not visible; the query goes the OD. > > Items 2 and 4: Effectively, this means that v=DMARC2 records are > completely independent of v=DMARC1 records. There is no interoperability > between versions. Is this what is intended? > This document defines v1. v2 could define itself in such a way that it accepts part or all of a v1 record, but a v1 record is incompatible with one explicitly declared to be for v2. This is precisely the same as "v=DKIM1": If you're extending DKIM v1, you just declare new tags; once you say v2, you're saying you don't want to keep the old meanings. > "If the RFC5322.From domain does not exist...": This specifies an action > that has nothing to do with DMARC. I don't know the history of this but > it seems like if there was going to be some global "you SHOULD reject > messages with a nonexistent From domain" action, it belongs someplace > like RFC 5322, not here. See also comment under A.4. > I agree that RFC5322 doesn't establish this requirement. We're saying that a DMARC implementation needs to take this action as it, along with normal DMARC operation, defeats spoof attempts. > 9. Domain Owner Actions > > Paragraph 1: "set up an address to receive reports" -- could also > delegate that externally > Sure. Do we need to identify all the things a Domain Owner might do external to itself? That seems like it could become tedious; I think that's already implicit. > > Paragraph 2: What does "protect those email addresses" mean? > Typical abuse prevention is what we have in mind there. > > Paragraph 3: What does this have to do with domain owner actions? If > this is connected to the previous paragraph, note that there is no > requirement that reports use SPF and/or DKIM authentication (although > perhaps there should be). > The steps listed prior to that advise the reader to deploy authentication technologies. This gives references to those materials. > > Paragraph 4: Need some specific guidance on how URIs other than mailto: > are to be used (although there is some discussion of this in section 11; > maybe a forward reference is needed) > There's more being added about using http: reporting from John Levine. > > 10.1 Extract Author Domain > > Paragraph 3: "Such messages SHOULD be rejected." Again, this specifies > an action on messages that has nothing to do with DMARC. In particular, > bullet 2 and 4 describe messages that are legal according to RFC 5322, > and if they're undesirable should have been addressed there. > DMARC-aware operators see those exceptional cases in vanishingly small numbers. That specific community appears to be of the consensus opinion that they aren't worth the introduced complexity for exceptional handling. > If the messages are rejected, should they be silently discarded or fully > rejected (per section 15.4)? > The action isn't specified. Their delivery simply needs to be prevented. > > 10.3 Messaging Sampling > > Much of this section applies generally to the application of policy and > not specifically to sampling, so perhaps the section heading should be > "Policy Application" or something like that. > I don't understand what you're saying here. How is this not a message sampling function? > > 11.1 Discovery > > Paragraph 1: Does not discuss DMARC policy records associated with > Administrative Domains, only those associated with the From address > (converse of everything before section 8). > Still not clear on the distinction being made here. > > Paragraph 2: Section 7.1 -> Section 8 > Fixed. > > 11.2 Transport > > Paragraph 1: "secure transport mechanism" needs to be specified more > completely. Does SMTP/TLS qualify? Is successful certificate > verification required? > This states a general requirement. The specific instances (e.g., in the mail and web spaces) are given in subsequent sections. > > Paragraph 3: "Mail Receiver SHOULD send" -- section 11.2.4 (paragraph 1) > says that an attempt MUST be made. > 11.2.4 says SHOULD be generated, and if one is generated, it MUST be attempted across the full URI set. > > 11.2.1 Email > > Paragraph 1: Is it equally acceptable to send via SMTP over SSL (port 465)? > Are there implementations of this? > > Filename extensions: Is the .gz format just a GZIPped XML file? That > isn't stated clearly, and if it is, why not make the extension .xml.gz? > That's fixed in the unpublished version. > > 11.2.2 HTTP > > Paragraph 2: "POST or PUT" -- which method is used? Must reporting URIs > support both methods? Or is there a process for discovering which method > is to be used? > > I'm not an expert in HTTP, but I have the feeling that this transport > (and all transports except possibly mailto:) is underspecified. For > example, what Content-Types MUST be supported? Are there any other HTTP > headers that MUST be included? > There's a separate submission to fix this. > > 11.2.4 Error Reports > > Paragraph 1: Last sentence seems to say that mailto: URIs are preferred > over other transports, which is the opposite of the last paragraph of > section 9. > For error reports, that's correct. > > Why is the error report in a text/plain format rather than a text/xml > format like the feedback reports themselves? > There's no encoded data in an error report. The point is to bring operator attention to the fact that there's a problem. > > "Note: A more rigorous syntax specification...will be added here" says > this is still an experimental capability. > Correct. > > 12. Capacity Planning > > DNS: This understates the actual DNS load; there will be additional > queries in connection with looking up and sending feedback and aggregate > reports, additional queries associated with reporting addresses that are > outside the current domain, and probably other things I haven't > considered (like DNSSEC). A more thorough analysis is needed here. > I've added text about those cases, except DNSSEC which is an entire layer that is important to but ultimately not within the DMARC layer. > > 13. Minimum Implementations > > Please provide separate minimum requirements for Domain Owners (or other > publishers of DMARC records) and Mail Receivers. Bear in mind that > Domain Owners, etc. may not themselves receive the reports. > Added as a TBD item. > > 14. Privacy Considerations > > One privacy consideration I don't see listed anywhere is forwarding > privacy: Basic email provides good protection against message senders > finding out the actual delivery address of forwarded mail. The reporting > capabilities of DMARC make it trivially easy for a Domain Owner to > discover the delivery address of a message delivered to a > DMARC-compliant Receiving Domain. > Added. > > 14.2 Report Recipients > > It might be noted that the privacy consideration is not that different > from a domain with an MX record that is handled by someone outside the > domain. > Would that be a useful illustration outside of the prose that's already there? > > 14.4 Secure Protocols > > Should there be a requirement that if the original message was sent with > TLS, that feedback reports be sent securely? > Mentioned it. > > 15.1 Use of RFC5322.From > > Last paragraph: "This document prescribes no specific action, other > than..." Section 10.1 does indeed prescribe a specific action that > SHOULD be taken. > Isn't that what this paragraph is saying? > 15.3 DNS Load and Caching > > It would be good to see a more thorough analysis of DNS effects -- both > the number of queries that DMARC adds and the possible use of DMARC > records (large records, at well-known locations in DNS) for DNS > amplification attacks. > OK. > > 15.5 Identifier Alignment Considerations > > Paragraph 1: Don't the concerns about SPF apply apply to DKIM key > records too? > Yes; fixed. > > Paragraph 3: "cede" -> "delegate" (administrator doesn't actually lose > control) > Fixed. > > 17. Security Considerations > > Check RFC 6376 Section 8.x for other attacks that might be documented > here. In particular, attackers might publish intentionally malformed > DMARC records in conjunction with domains they control and send mail > from in an effort to make DMARC less useful or onerous in some way, in > an effort to discourage its use. > OK. > > > 17.2 DNS Security > > This should emphasize that both the publication of DNSSEC by Domain > Owners and the use of DNSSEC-aware resolvers by Mail Receivers is > needed. See also RFC 6376 section 8.5. > OK. > > Appendix A. Technology Considerations > > These provide good insight into some of the design choices made in the > development of DMARC. Is the intent to include this in the > standards-track document, or is this just information to aid the > evaluation process? > We weren't planning to remove them. > > A.4 Domain Existence Test > > This section indicates that there was operational experience that the > error rate was too high. Given that experience, I am surprised that > section 8 says that the receiver SHOULD reject the message. > That may be an oversight, i.e., we removed one but forgot to remove the other. What does the community think about this? > > A.5 Issues With ADSP In Operation > > This section reads like somewhat of a debate with ADSP, or as though > DMARC is competing with ADSP. DMARC and ADSP have different goals, and > different constraints (e.g., SPF is explicitly out of scope of ADSP) so > the list of issues doesn't really make sense. > Right; the goal here is to highlight that the use cases were different, as are the solution spaces. > > A.6 Organizational Domain Discovery Issues > > Paragraph 3: "Climbing the tree", explored extensively in the > development of ADSP, can of course be constrained to a specific limited > number of queries. But ultimately even a one-level climb was considered > too much and was rejected. Nevertheless, DMARC does look for policy in > two places (the From domain and the Organizational Domain). > Right, but not based directly on the DNS; I think that was the objection with SSP/ADSP. > > The approach being used in DMARC was briefly considered in ADSP, but > didn't even make it into a draft at the strong advice of the DNS > Directorate that there is no way to reliably determine the delegation > level in a domain name. > Right; as I said above, we don't intend to keep this method as soon as something endorsed by the larger community is available. > > ===== > > General Comments > > There is no discussion of the effect of the effect of DMARC on some very > common situations, such as mailing lists and forwarding (except a couple > of hints at heuristics in the XML Schema). If the deployment of DMARC > has an effect on the delivery of messages sent through mailing lists, > that's a serious problem. I'm not aware of a straightforward answer to > that problem, other than to maintain a whitelist of mailing lists that > themselves authenticate their messages, which would normally not align > with the From addresses at all. This has been cited as a serious problem > with ADSP, so one would not want to repeat that problem here. > > RFC6377 tackled a lot of these points. It's been pointed out on the list that (a) DMARC has the same concerns as ADSP with respect to lists as it's currently defined, and (b) this is something the DMARC community would like to spend time and energy trying to solve. But you're right, the document doesn't say anything about this yet, and probably should. -MSK --089e0102ef8471e21704ec9d0cbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 2, 2013 at 3:54 PM, Jim Fenton <fenton@bluepopcorn.n= et> wrote:
I have not been monitorin= g this mailing list, but a couple of people
have asked me to have a look at the DMARC spec. =A0I apologize for the
amount of time it has taken for me to get to this.


Thanks for the review, Jim.=A0 Sorry it's tak= en so long for me to get all the way through this.
=A0
I'll leave out the editorial issues, but I'm happy to share those (= in
particular, with the editors) if there is interest. =A0I'll start with = a
lot of specific comments; there are a few additional comments at the
very end.

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

=3D=3D=3D

1. Introduction

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

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

In the case of SSP and ADSP, I think we were trying to descr= ibe the signing practices of the author domain, so the receiver could make = an intelligent judgement about accepting or rejecting the message.=A0 In DM= ARC, the practices are implied by the nature of the protocol except for wha= t alignment of identifiers a receiver should expect.



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

Yes, though we haven't introduced th= at term yet.=A0 I'll change it to the lowercase form.
=A0

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

OK.
=A0

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

The outer = bullet refers to SMTP Receivers, which I don't believe includes MUAs.
OK on the second one.
=A0

Last bullet: I immediately went to the case of the From: header field
with multiple addresses, which had been a significant issue with ADSP.
More about this later.

2.1 High-Level Goals

First bullet: senders -> Domain Owners. Similar comment on the word
"receivers".

OK.
=A0

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

Will fix.
=A0

2.4 Out of Scope

This section is full of double negatives, e.g., "not in scope for this=
work include: DMARC shall not be required..."
Will fix.
=A0

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

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

3. Terminology and Definitions

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

OK.
=A0

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

The definition = does include more complex arrangements than merely the registering entity.<= br>=A0

Organizational Domain: I have many problems with this:

(1) An algorithm like this doesn't belong in the definitions.

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

=
Yes.=A0 We acknowledge that public suffix is far from an ideal solutio= n, but until some of the ideas being discussed in APPSAWG and elsewhere bec= ome a reality, it's the only operational option.=A0 Your point is taken= , though, that lots of sources for this information is a problem.=A0 I'= ll add a note about it.
=A0
(3) During the development of ADSP, it was made clear to me by the DNS
folks that there is no way, in practice, to determine an Organizational
Domain.

Right; see my comment above abo= ut APPSAWG work.
=A0
(4) The last paragraph acknowledges that it is a heuristic, and its use
of "currently" implies that something better is in the works (whi= ch
needs to be described instead in the spec).

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

3.2 Overview

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

F= ixed.
=A0

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

OK.
=A0

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

OK.
=A0

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

Are those not the same?=A0 Or are you talking abo= ut the subdomain case?
=A0

3.3 Flow Diagram

"The above diagram shows the flow of messages": But there are lot= s
more. =A0Spoofed messages have a different flow. So do mailing lists,
domains with multiple layers of MTAs, etc. This is just the simplest
flow of legitimate messages.

I'll l= abel it as a simple or typical example.
=A0

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

It is if= the identifiers are aligned.=A0 I'll make that more claer.
=A0
<= /div>

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

OK.
=A0
=

3.4 Identifier Alignment

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

It's earlier in Section 3.
=A0
=

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

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

Paragraph 4: identity alignment -> identifier alignment
=

Fixed.
=A0

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

This is= covered in Section 10.1.
=A0

3.4.1 DKIM-authenticated identifiers

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

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

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

Fixed.
=A0
=

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

Yes.=A0 I&#= 39;ll mention this earlier.
=A0

3.4.1 and 3.4.2

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

OK.
=A0

4. Policy

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

Changed to "its domains".<= br>=A0

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

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

5. DMARC Policy Record

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

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

5.2 General Record Format

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

Fixed.
=A0
<= /div>

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

Fixed, by just= deferring to the ABNF.
=A0

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

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

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

Operators do appear to want this information, prob= ably to aid in debugging.
=A0

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

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

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


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

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

Fixed.

=A0

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

Fixed.
=A0
Initial default values are -> Possible values are (and possibly
reference a registry)

We didn't mak= e a registry for this because there's really only one in use in this sp= ace, and no new ones are anticipated.
=A0
[IODEF] is listed as an Informative Reference; shouldn't it be normativ= e
like [AFRF]?

True.=A0 Fixed.
=A0
=

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

Right.=A0 This is explicitly described as a request.
= =A0

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

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

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

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

6. Policy Enforcement Considerations

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

This is a "Considerations&qu= ot; section.=A0 It's just discussion, nothing normative.
=A0

7.1 Verifying External Destinations

Paragraph 3: SHOULD -- shouldn't that be a MUST?
<= br>
We describe a few paragraphs down a reason why one would elec= t not to implement that advice, so SHOULD is more appropriate here.
=A0

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

Possibly.=A0 I= 9;ll let the rest of the community weigh in on that point.=A0 What other va= lues might be worth allowing for an override?
=A0

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

Right, that was act= ually the intent.=A0 The prose has already been updated.
=A0

7.2 Aggregate reports

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

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

7.3 Failure reports

Paragraph 1 reads as though AFRF is the only reporting format, but needs to accommodate IODEF and any future-defined reporting formats as well.
For extensibility, there should also be a way for the Mail Receiver to
generate a meta-report saying that they don't support the requested
report format.


I think we might consider just yanking= IODEF out.=A0 I can't think of a single implementation to date.=A0 Doe= s anybody know of one?

7.3.1 Reporting Format Update

Are there any updates to IODEF?

I don&#= 39;t think there have been any implementations, so presently there are no u= pdates.
=A0

7.4 Failure Reports

Paragraph 2: "ruf" tag -> "rf" tag
<= div>
Fixed.
=A0

8. Policy Discovery

This is the first mention I have seen that DMARC records are published
directly on From domains; up to this point it looked like DMARC was only published by a Domain Owner on an Administrative Domain. =A0This changes a<= br> lot -- like the fact that a delegate of the Domain Owner, and not the
[administrative] Domain Owner him/herself, can set the policy for a
domain. This might require a major change of terminology usage, or at
least a change in the definition of Domain Owner, to fix.
<= div>
I'm not sure where the confusion came in.=A0 The onl= y domain of interest to DMARC is the From domain; it is from this that the = rest of the work (most importantly, identifier alignment) is derived.

Who would a delegate of the Domain Owner be?=A0 From the per= spective of a receiver, such a delegation is not visible; the query goes th= e OD.
=A0

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

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


"If the RFC5322.From domain does not exist...": This specifies an= action
that has nothing to do with DMARC. I don't know the history of this but=
it seems like if there was going to be some global "you SHOULD reject<= br> messages with a nonexistent From domain" action, it belongs someplace<= br> like RFC 5322, not here. See also comment under A.4.
<= br>
I agree that RFC5322 doesn't establish this requirement.= =A0 We're saying that a DMARC implementation needs to take this action = as it, along with normal DMARC operation, defeats spoof attempts.


9. Domain Owner Actions

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

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

Paragraph 2: What does "protect those email addresses" mean?
<= /blockquote>

Typical abuse prevention is what we have in= mind there.
=A0

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

The steps lis= ted prior to that advise the reader to deploy authentication technologies.= =A0 This gives references to those materials.
=A0

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)

Th= ere's more being added about using http: reporting from John Levine.=A0

10.1 Extract Author Domain

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

DMARC-aware operators see those exceptional cases in = vanishingly small numbers.=A0 That specific community appears to be of the = consensus opinion that they aren't worth the introduced complexity for = exceptional handling.
=A0
If the messages are rejected, should they be silently discarded or fully rejected (per section 15.4)?

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

10.3 Messaging Sampling

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

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

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

<= div>Still not clear on the distinction being made here.
=A0

Paragraph 2: Section 7.1 -> Section 8

Fixed.
=A0

11.2 Transport

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

This states a ge= neral requirement.=A0 The specific instances (e.g., in the mail and web spa= ces) are given in subsequent sections.
=A0

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

11.2= .4 says SHOULD be generated, and if one is generated, it MUST be attempted = across the full URI set.
=A0

11.2.1 Email

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

Are there implementations of this?
= =A0

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

That's fixed in the unpublished ve= rsion.
=A0

11.2.2 HTTP

Paragraph 2: "POST or PUT" -- which method is used? Must reportin= g URIs
support both methods? Or is there a process for discovering which method is to be used?

I'm not an expert in HTTP, but I have the feeling that this transport (and all transports except possibly mailto:) is underspecified. For
example, what Content-Types MUST be supported? Are there any other HTTP
headers that MUST be included?

There= 9;s a separate submission to fix this.
=A0

11.2.4 Error Reports

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

For error reports, that'= s correct.
=A0

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

Correct.
=A0

12. Capacity Planning

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

I've added text about those cases, except D= NSSEC which is an entire layer that is important to but ultimately not with= in the DMARC layer.
=A0

13. Minimum Implementations

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

Added as a TBD item.
=A0

14. Privacy Considerations

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

Added= .
=A0

14.2 Report Recipients

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

Would that be a useful illustra= tion outside of the prose that's already there?
=A0

14.4 Secure Protocols

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

Mentioned it.
=A0

15.1 Use of RFC5322.From

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

Isn't that what th= is paragraph is saying?


15.3 DNS Load and Caching

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

OK.
=A0

15.5 Identifier Alignment Considerations

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

Yes; fixed.
=A0

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

Fixed.
=A0

17. Security Considerations

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

OK.=A0


17.2 DNS Security

This should emphasize that both the publication of DNSSEC by Domain
Owners and the use of DNSSEC-aware resolvers by Mail Receivers is
needed. =A0See also RFC 6376 section 8.5.

OK.
=A0

Appendix A. Technology Considerations

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

We weren't plan= ning to remove them.
=A0

A.4 Domain Existence Test

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

That may be an oversight, i.e., we removed one but for= got to remove the other.=A0 What does the community think about this?
=A0
=A0
A.5 Issues With ADSP In Operation

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

=
Right; the goal here is to highlight that the use cases were dif= ferent, as are the solution spaces.
=A0

A.6 Organizational Domain Discovery Issues

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

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

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

Right; as I sai= d above, we don't intend to keep this method as soon as something endor= sed by the larger community is available.
=A0

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

General Comments

There is no discussion of the effect of the effect of DMARC on some very common situations, such as mailing lists and forwarding (except a couple of hints at heuristics in the XML Schema). If the deployment of DMARC
has an effect on the delivery of messages sent through mailing lists,
that's a serious problem. I'm not aware of a straightforward answer= to
that problem, other than to maintain a whitelist of mailing lists that
themselves authenticate their messages, which would normally not align
with the From addresses at all. This has been cited as a serious problem with ADSP, so one would not want to repeat that problem here.


RFC6377 tackled a lot of these points.= =A0 It's been pointed out on the list that (a) DMARC has the same conce= rns as ADSP with respect to lists as it's currently defined, and (b) th= is is something the DMARC community would like to spend time and energy try= ing to solve.

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

-MSK
--089e0102ef8471e21704ec9d0cbc-- From rocketraman@gmail.com Tue Dec 3 09:50:22 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2839E1AE1A6 for ; Tue, 3 Dec 2013 09:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id echj_gZk5LZv for ; Tue, 3 Dec 2013 09:50:20 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 628F71AE1A2 for ; Tue, 3 Dec 2013 09:50:20 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so24334263ieb.36 for ; Tue, 03 Dec 2013 09:50:17 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BfbSsXXh4XZgCNGKXJ9Hs20WaOHV585x00TUtQW1N10=; b=vlFrR7GyrfKms4XW/mZMinafNAOmW0FWIDfX9qTMzwgJAxOtZRF3lGx1fdmWS2j6bJ LTtQWVCLyRg06l1e3zDaxKC5Y8UMRSQ3gAetO8B93a/7I+oh4/SQxX9Jn4pg2VrPQ8tX R2YFg2AuR+BFq2kNtE45M5NZjiAmHbRr6kvLh+VE4L34ha0sultiVWn2N9XQpp1SBdt+ Z9D3rvh1Rl5ZIwVCfF/AuzvlOVx7CCWnVb5Zc5rggzS/PrTc9d3gDlokWQCIsrcwScm9 uGrfp1H4n8jWDH3gRMiO7Th0raKTFmXplzIwE3ahFvdQ4wZCruoAMIh0kvGNU3W8v2eK wJLQ== X-Received: by 10.50.141.133 with SMTP id ro5mr3777311igb.35.1386093017652; Tue, 03 Dec 2013 09:50:17 -0800 (PST) Received: from mail.rocketraman.com (CPEc86000c77d08-CM602ad06d1aa0.cpe.net.cable.rogers.com. [99.224.82.85]) by mx.google.com with ESMTPSA id j16sm4179932igf.6.2013.12.03.09.50.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Dec 2013 09:50:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.rocketraman.com (Postfix) with ESMTP id 6EDAE1DE0285; Tue, 3 Dec 2013 12:50:16 -0500 (EST) X-Virus-Scanned: amavisd-new at rocketraman.com Received: from mail.rocketraman.com ([127.0.0.1]) by localhost (mail.rocketraman.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djVnrQO2uDVm; Tue, 3 Dec 2013 12:50:13 -0500 (EST) Received: from [192.168.1.6] (edison.rocketraman.com [192.168.1.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rocketraman.com (Postfix) with ESMTPS; Tue, 3 Dec 2013 12:50:13 -0500 (EST) Message-ID: <529E19D5.5020304@gmail.com> Date: Tue, 03 Dec 2013 12:50:13 -0500 From: Raman Gupta User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <52251471.8070001@gmail.com> <61D26087-7352-481F-A710-A04CF4062F84@peachymango.org> In-Reply-To: <61D26087-7352-481F-A710-A04CF4062F84@peachymango.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Murray S. Kucherawy" , Franck Martin Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:50:22 -0000 On 12/01/2013 04:36 PM, Franck Martin wrote: > Murray, > > Raman was talking when the return-path is empty like for bounces. Right. > DMARC follows SPF and uses for alignment whatever SPF used to give a > result. So when there is a return path, this is the domain in the > return-path (envelope from) otherwise when the return-path is empty > this is the domain in the helo/ehlo. > > From the text below from Raman, which describes the way DMARC works > accurately, I'm not sure what alternate behavior DMARC should have? The alternate behavior could be: DMARC alignment rules for RFC5322.From would apply when there is an RFC521.MailFrom address available. Otherwise, DMARC falls back to the regular DKIM and/or SPF identification rules. See below. > May be the issue is: "The host in bar.com is a valid > SPF sender for domain foo.com". However I have no idea how you can > infer this statement programatically. There is no DNS record today > that allows you to infer it (?). I may have stated the initial situation slightly incorrectly. I should have said: the evaluation of the SPF record linked to the HELO/EHLO FQDN was valid. See, for example: http://www.openspf.org/FAQ/Common_mistakes#helo In this case, the SPF evaluation based on the HELO/EHLO identification and linked record is that the email is valid, but the extra DMARC alignment rules cause a DMARC failure, since the HELO/EHLO domain does not match the RFC5322.From domain. If there was no DMARC RFC5322.From alignment rule against the SPF HELO/EHLO identification in this case, is there a new abuse vector? Regards, Raman > On Nov 30, 2013, at 10:39 PM, Murray S. Kucherawy > wrote: > >> Any other input on this point? DMARC currently only considers the >> SPF result if there is alignment between the return path and the >> From field. >> >> >> On Mon, Sep 2, 2013 at 3:42 PM, Raman Gupta > > wrote: >> >> I encountered a use case recently with an auto-generated email >> with RFC5322.From domain foo.com , sent from a >> host in domain bar.com . Because the email was >> auto-generated by sieve, it contained a null return path. The >> host in bar.com is a valid SPF sender for >> domain foo.com . >> >> DMARC failed the SPF check despite the valid SPF, since the >> RFC5322.From address was not aligned with the domain bar.com >> extracted from the HELO/EHLO. >> >> A valid way to circumvent this problem is to use DKIM signing, >> aligned with foo.com , in which case DMARC is >> designed to ignore the SPF failure and pass overall. >> >> However, I do think this is a valid situation which the SPF >> alignment rules should consider. >> >> I hope I have explained this sufficiently. Thank you to Steven >> Jones and Scott Kitterman and others on the dmarc-discuss list >> for clarifying the situation presented here. >> >> Regards, >> Raman Gupta >> Principal >> VIVO Systems >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc From franck@peachymango.org Tue Dec 3 10:20:46 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD621AD791 for ; Tue, 3 Dec 2013 10:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4izP1OETBYrR for ; Tue, 3 Dec 2013 10:20:44 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 44AAC1AD34C for ; Tue, 3 Dec 2013 10:20:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3B5663F43FC; Tue, 3 Dec 2013 12:20:41 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H08zY3dtLdAn; Tue, 3 Dec 2013 12:20:41 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 17FFB3F43A9; Tue, 3 Dec 2013 12:20:41 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 07F9D3F438F; Tue, 3 Dec 2013 12:20:41 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PFdIRFLWDKqf; Tue, 3 Dec 2013 12:20:40 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id DE62B3F4310; Tue, 3 Dec 2013 12:20:40 -0600 (CST) Date: Tue, 3 Dec 2013 12:20:40 -0600 (CST) From: Franck Martin To: Raman Gupta Message-ID: <566070910.92478.1386094840230.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <52251471.8070001@gmail.com> <61D26087-7352-481F-A710-A04CF4062F84@peachymango.org> <529E19D5.5020304@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF25 (Mac)/8.0.5_GA_5839) Thread-Topic: Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain Thread-Index: VlGEltez82HwQsnUhgcx7foLZX3O+Q== Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:20:47 -0000 ----- Original Message ----- > From: "Raman Gupta" > To: dmarc@ietf.org > Cc: "Franck Martin" , "Murray S. Kucherawy" > Sent: Tuesday, December 3, 2013 9:50:13 AM > Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain > > On 12/01/2013 04:36 PM, Franck Martin wrote: > > Murray, > > > > Raman was talking when the return-path is empty like for bounces. > > Right. > > > DMARC follows SPF and uses for alignment whatever SPF used to give a > > result. So when there is a return path, this is the domain in the > > return-path (envelope from) otherwise when the return-path is empty > > this is the domain in the helo/ehlo. > > > > From the text below from Raman, which describes the way DMARC works > > accurately, I'm not sure what alternate behavior DMARC should have? > > The alternate behavior could be: DMARC alignment rules for > RFC5322.From would apply when there is an RFC521.MailFrom address > available. Otherwise, DMARC falls back to the regular DKIM and/or SPF > identification rules. > > See below. > > > May be the issue is: "The host in bar.com is a valid > > SPF sender for domain foo.com". However I have no idea how you can > > infer this statement programatically. There is no DNS record today > > that allows you to infer it (?). > > I may have stated the initial situation slightly incorrectly. I should > have said: the evaluation of the SPF record linked to the HELO/EHLO > FQDN was valid. See, for example: > > http://www.openspf.org/FAQ/Common_mistakes#helo > > In this case, the SPF evaluation based on the HELO/EHLO identification > and linked record is that the email is valid, but the extra DMARC > alignment rules cause a DMARC failure, since the HELO/EHLO domain does > not match the RFC5322.From domain. > > If there was no DMARC RFC5322.From alignment rule against the SPF > HELO/EHLO identification in this case, is there a new abuse vector? > Yes. I see plenty fake bounces with attack payload in them. From rocketraman@gmail.com Tue Dec 3 10:27:53 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7DE1AE17E for ; Tue, 3 Dec 2013 10:27:53 -0800 (PST) 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 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 rvnn9CM9-kKD for ; Tue, 3 Dec 2013 10:27:52 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 79F011AE179 for ; Tue, 3 Dec 2013 10:27:52 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tp5so24432613ieb.36 for ; Tue, 03 Dec 2013 10:27:49 -0800 (PST) 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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QtjE6uLmISV+00neaztygCb75yjq5UfxqDKrMT5Z3ks=; b=Tn0KHFZFzS7FReFB/pGFAtpOylZKifxQWcPwGLfAOVXUwLq++F1YARQ0hu/W4NfpEy og6ctwB2n2BK8si6UYzGsXXM0FpNGpSKbvdeUjjKZNj+Txy7EFT4PBOSlEqq8ZAvSBsb wrYvg/6RMMFUtO8SYpozzh9sgx7kk32P121jT5eO+Zodorr4XW+cnrWJK3oZ+8nfU9xf mE/SERQFd8rGKdgLqaGAUIl4VJ2vXlqrH220Mc+uRAqHI3B/qic6QxfztbJlFX8A27Et dBqVxJ8r/zi9rCK2CJmRILraWUMgRWDm0cgYzpKGnYywQvvYnj71DqrhuHa/fe656RER InsQ== X-Received: by 10.42.82.196 with SMTP id e4mr2682250icl.58.1386095269807; Tue, 03 Dec 2013 10:27:49 -0800 (PST) Received: from mail.rocketraman.com (CPEc86000c77d08-CM602ad06d1aa0.cpe.net.cable.rogers.com. [99.224.82.85]) by mx.google.com with ESMTPSA id k6sm4350607igx.8.2013.12.03.10.27.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Dec 2013 10:27:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.rocketraman.com (Postfix) with ESMTP id 9E0F71DE02C4; Tue, 3 Dec 2013 13:27:48 -0500 (EST) X-Virus-Scanned: amavisd-new at rocketraman.com Received: from mail.rocketraman.com ([127.0.0.1]) by localhost (mail.rocketraman.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EleH4Gu-AhvO; Tue, 3 Dec 2013 13:27:46 -0500 (EST) Received: from [192.168.1.6] (edison.rocketraman.com [192.168.1.6]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rocketraman.com (Postfix) with ESMTPS; Tue, 3 Dec 2013 13:27:46 -0500 (EST) Message-ID: <529E22A2.8050804@gmail.com> Date: Tue, 03 Dec 2013 13:27:46 -0500 From: Raman Gupta User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Franck Martin References: <52251471.8070001@gmail.com> <61D26087-7352-481F-A710-A04CF4062F84@peachymango.org> <529E19D5.5020304@gmail.com> <566070910.92478.1386094840230.JavaMail.zimbra@peachymango.org> In-Reply-To: <566070910.92478.1386094840230.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:27:53 -0000 On 12/03/2013 01:20 PM, Franck Martin wrote: >> If there was no DMARC RFC5322.From alignment rule against the SPF >> HELO/EHLO identification in this case, is there a new abuse vector? >> > > Yes. I see plenty fake bounces with attack payload in them. And the fake bounces have a valid SPF? Regards, Raman From franck@peachymango.org Tue Dec 3 15:51:23 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E991AE1D5 for ; Tue, 3 Dec 2013 15:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRhOEGobucEk for ; Tue, 3 Dec 2013 15:51:21 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 11C7E1ADFA9 for ; Tue, 3 Dec 2013 15:51:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id EC5B64F443B; Tue, 3 Dec 2013 17:51:17 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD3LLvUtyDWx; Tue, 3 Dec 2013 17:51:17 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id CAF6F4F4448; Tue, 3 Dec 2013 17:51:17 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B464C4F4442; Tue, 3 Dec 2013 17:51:17 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xQmHAQeomF2U; Tue, 3 Dec 2013 17:51:17 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 8C12C4F443B; Tue, 3 Dec 2013 17:51:17 -0600 (CST) Date: Tue, 3 Dec 2013 17:51:16 -0600 (CST) From: Franck Martin To: Raman Gupta Message-ID: <1048972620.112399.1386114676857.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <52251471.8070001@gmail.com> <61D26087-7352-481F-A710-A04CF4062F84@peachymango.org> <529E19D5.5020304@gmail.com> <566070910.92478.1386094840230.JavaMail.zimbra@peachymango.org> <529E22A2.8050804@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF25 (Mac)/8.0.5_GA_5839) Thread-Topic: Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain Thread-Index: 39L/cK4jNDP2Xdk2gmlZ7An2mrtoOw== Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 23:51:23 -0000 ----- Original Message ----- > From: "Raman Gupta" > To: "Franck Martin" > Cc: dmarc@ietf.org, "Murray S. Kucherawy" > Sent: Tuesday, December 3, 2013 10:27:46 AM > Subject: Re: [dmarc-ietf] Suggestion: handle null reverse path SPF alignment with RFC5322.From in different domain > > On 12/03/2013 01:20 PM, Franck Martin wrote: > >> If there was no DMARC RFC5322.From alignment rule against the SPF > >> HELO/EHLO identification in this case, is there a new abuse vector? > >> > > > > Yes. I see plenty fake bounces with attack payload in them. > > And the fake bounces have a valid SPF? > Considering that many people forgets to put a SPF record on the hostname pointed by the helo, no, but this would not stop spammers to adopt SPF if that gives them an edge. From superuser@gmail.com Fri Dec 6 12:08:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9BA1AE06F for ; Fri, 6 Dec 2013 12:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZuK4XDsljFn for ; Fri, 6 Dec 2013 12:08:56 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E54CD1AE05B for ; Fri, 6 Dec 2013 12:08:55 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id m15so1138244wgh.25 for ; Fri, 06 Dec 2013 12:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rT6jonBnUYr2TvQKRUEzvqE7D4nMBKrleMKj8E0M9uw=; b=dBThUIyvS0qTnBzvipohFhYef5byxvhnt/R8li6wQwpbBnbyNNfYJU0DkNW3XDuJ++ yOFHZuiS7juU35eV3e+hpnqLhqVead+a6Tgb+HkG2Vfe3Pjug3/Rcov4ZuIfSloAiocy 12WZK4Uf35lQM+0LsP0rcTVX8McU+69ni9sPRf9aykdtWJ0HXmX3ILmpTOiOV10GT66i wUGAyg0IYcEWmR65S7mkGmyIwQwrrqEfYDrqy8ZoNr3JP5J0zbXaN6CrQD+CJc4N17JS wuDbV3zdb4nFvENchleXVxMwnGGAWFlwK7bVKBsZaWAgKJ32Ca6vbWXT/pnA+vYEywTs kvBg== MIME-Version: 1.0 X-Received: by 10.194.21.225 with SMTP id y1mr4897714wje.60.1386360531651; Fri, 06 Dec 2013 12:08:51 -0800 (PST) Received: by 10.181.13.230 with HTTP; Fri, 6 Dec 2013 12:08:51 -0800 (PST) In-Reply-To: <20131206195151.11363.70071.idtracker@ietfa.amsl.com> References: <20131206195151.11363.70071.idtracker@ietfa.amsl.com> Date: Fri, 6 Dec 2013 12:08:51 -0800 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d98ab0513ed04ece33770 Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-base-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 20:08:59 -0000 --047d7b5d98ab0513ed04ece33770 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 6, 2013 at 11:51 AM, wrote: > > A new version of I-D, draft-kucherawy-dmarc-base-02.txt > has been successfully submitted by Murray S. Kucherawy and posted to the > IETF repository. > > Filename: draft-kucherawy-dmarc-base > Revision: 02 > Title: Domain-based Message Authentication, Reporting and > Conformance (DMARC) > Creation date: 2013-12-06 > Group: Individual Submission > Number of pages: 78 > URL: > http://www.ietf.org/internet-drafts/draft-kucherawy-dmarc-base-02.txt > Status: > http://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base > Htmlized: http://tools.ietf.org/html/draft-kucherawy-dmarc-base-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-kucherawy-dmarc-base-02 > > Abstract: > This memo presents a proposal for a scalable mechanism by which a > mail sending organization can express, using the Domain Name System, > domain-level policies and preferences for message validation, > disposition, and reporting, and a mail receiving organization can use > those policies and preferences to improve mail handling. > > The email ecosystem currently lacks a cohesive mechanism through > which email senders and receivers can make use of multiple > authentication protocols to establish reliable domain identifiers, > communicate policies about those identifiers, and report about mail > using those identifiers. This lack of cohesion has several effects: > receivers have difficulty providing feedback to senders about > authentication, senders therefore have difficulty evaluating their > authentication deployments, and as a result neither is able to make > effective use of existing authentication technology > > The enclosed proposal is not intended to introduce mechanisms that > provide elevated delivery privilege of authenticated email. The > proposal presents a mechanism for policy distribution that enables a > continuum of increasingly strict handling of messages that fail > multiple authentication checks, from no action, through altered > delivery, up to message rejection. > This version addresses most of the feedback that's been posted to date. It doesn't include unresolved things that are still being discussed on the list. The diff link is probably going to be useful to most people given the size of the document. Have at it! -MSK --047d7b5d98ab0513ed04ece33770 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 6, 2013 at 11:51 AM, <internet-drafts= @ietf.org> wrote:

A new version of I-D, draft-kucherawy-dmarc-base-02.txt
has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-kucherawy-dmarc-base
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Domain-based Message Authentication, Reporting a= nd Conformance (DMARC)
Creation date: =A0 2013-12-06
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 78
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/i= nternet-drafts/draft-kucherawy-dmarc-base-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dr= aft-kucherawy-dmarc-base
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-kuche= rawy-dmarc-base-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdif= f?url2=3Ddraft-kucherawy-dmarc-base-02

Abstract:
=A0 =A0This memo presents a proposal for a scalable mechanism by which a =A0 =A0mail sending organization can express, using the Domain Name System,=
=A0 =A0domain-level policies and preferences for message validation,
=A0 =A0disposition, and reporting, and a mail receiving organization can us= e
=A0 =A0those policies and preferences to improve mail handling.

=A0 =A0The email ecosystem currently lacks a cohesive mechanism through
=A0 =A0which email senders and receivers can make use of multiple
=A0 =A0authentication protocols to establish reliable domain identifiers, =A0 =A0communicate policies about those identifiers, and report about mail<= br> =A0 =A0using those identifiers. =A0This lack of cohesion has several effect= s:
=A0 =A0receivers have difficulty providing feedback to senders about
=A0 =A0authentication, senders therefore have difficulty evaluating their =A0 =A0authentication deployments, and as a result neither is able to make<= br> =A0 =A0effective use of existing authentication technology

=A0 =A0The enclosed proposal is not intended to introduce mechanisms that =A0 =A0provide elevated delivery privilege of authenticated email. =A0The =A0 =A0proposal presents a mechanism for policy distribution that enables a=
=A0 =A0continuum of increasingly strict handling of messages that fail
=A0 =A0multiple authentication checks, from no action, through altered
=A0 =A0delivery, up to message rejection.

This version addresses most of the feedback that's been posted to da= te.=A0 It doesn't include unresolved things that are still being discus= sed on the list.

The diff link is probably going to be useful to most people = given the size of the document.

Have at it!

=
-MSK
--047d7b5d98ab0513ed04ece33770-- From fenton@bluepopcorn.net Fri Dec 6 15:22:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3841C1ADF93 for ; Fri, 6 Dec 2013 15:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNpjx8xKo7fw for ; Fri, 6 Dec 2013 15:22:40 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id 842581ADF63 for ; Fri, 6 Dec 2013 15:22:40 -0800 (PST) Received: from splunge.local ([12.250.97.26]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id rB6NLd6O029891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Dec 2013 15:21:44 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1386372105; bh=vlfsPXsxYXAiDKhvMwjf4ndzcde0sFU+ZojN0YWMyKs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=kjIkT5cn21izTfbh8XBxej7yNXMLDBCRs5Q97RE5ehatdvADLmGqRDWjiHAF1zdJX NGOX6lZaeF0xhD1TQuOvCOC77R7vQa7J4gno6Rr8isRPRvdXceLE7zjSQ00InYtSIg puwKNVb5XwHJIVOGKaLFuPo0cdMfjNt5NP+MUbt0= Message-ID: <52A25C31.4070407@bluepopcorn.net> Date: Fri, 06 Dec 2013 15:22:25 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <524CA422.8030008@bluepopcorn.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------030009040808050707070307" Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 23:22:51 -0000 This is a multi-part message in MIME format. --------------030009040808050707070307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A few reply responses inline. On 12/3/13 12:26 AM, Murray S. Kucherawy wrote: > > > Happy to have your editorial comments off-list if you like. I just need to find my marked-up copy of the spec, which is around here somewhere... > > > > === > > 1. Introduction > > Paragraph 3: I'm surprised to see the use of the word "policy". > In the > context of ADSP (originally Sender Signing Policy), the word "policy" > was considered inaccurate because it was deemed inappropriate to > dictate > policy to a Receiving Domain. Even though SSP was describing the > domain's policy with respect to signing messages with DKIM, the word > "practices" was substituted. Is it now considered acceptable to make > policy requests of a Receiving Domain? > > > I don't think this has come up during the development of DMARC. In > contrast, I think the use of "policy" in the SPF context has become > widely understood to indicate it's a request from the author domain. > I do think it's pretty clear from the document that there are no > illusions that something's being demanded of the receiver. > > In the case of SSP and ADSP, I think we were trying to describe the > signing practices of the author domain, so the receiver could make an > intelligent judgement about accepting or rejecting the message. In > DMARC, the practices are implied by the nature of the protocol except > for what alignment of identifiers a receiver should expect. I don't see the distinction between what SSP/ADSP and DMARC are trying to do that might make one "practices" and the other "policy". If our language has evolved, that's all right; I'm just pointing out the earlier discussion, which happened at IETF 65: http://tools.ietf.org/wg/dkim/minutes?item=minutes65.html > > > Paragraph 3 #2-1: "The receiver" might be interpreted as being an MUA. > Suggest "Receiving domains". "how the mail is handled" -> "how they > should handle the mail" > > > The outer bullet refers to SMTP Receivers, which I don't believe > includes MUAs. OK, missed the context set by the outer bullet. > > Authentication of individuals rather than domains: DMARC doesn't > perform > authentication at all, it acts on the result of two other mechanisms. > This muddies that point. > > > I'm not sure it's important to dive into this; we're saying this is a > topic we don't want to handle either way. But when you say "rather than domains", it gives the impression that DMARC authenticates at the domain level, which it doesn't do. > > > Domain Owner: This definition clearly defines the Domain Owner as the > registrant of a domain. But as we will see much later, DMARC > records are > sometimes published by From domains directly, which could be a > person or > organization delegated by the Domain Owner. Perhaps another term is > needed, because there are some things that are available only to > Domain > Owners and others that are also available to those able to publish > a DNS > record for a subdomain. > > > The definition does include more complex arrangements than merely the > registering entity. I'm still not getting how the more complex arrangements are covered. Perhaps it's from the definition of ADMD (which I haven't read recently). If so, you might want to say that more directly; calling it "analogous" is a little vague. > > > (2) This creates a dependency on a public suffix list such as that > published by Mozilla, but doesn't require the use of a particular > list. > This would create an inconsistency in the result of DMARC that I > consider to be an interoperability problem. > > > Yes. We acknowledge that public suffix is far from an ideal solution, > but until some of the ideas being discussed in APPSAWG and elsewhere > become a reality, it's the only operational option. Your point is > taken, though, that lots of sources for this information is a > problem. I'll add a note about it. I'm still worried about this. > > [aside: I see, much later in the spec, that DMARC records can be > published by the From domain directly, not just from the Domain > Owner. A > lot of earlier text needs to be cleaned up to accommodate that.] > > > Are those not the same? Or are you talking about the subdomain case? The subdomain case, yes. > 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. > > > I think we're talking here about why we store the record in the DNS, > like SPF and DKIM and various others have done. We're not saying here > that we espouse ways of determining things like the zone cut from DNS > data. I just think the statement "matches perfectly" is overdone. If DNS had slightly different capabilities DMARC would be easier, so I'd tone down that statement. > > > fo: The tag value can contain both 0 and 1; what happens then? > > > The union of the two means "0" is a no-op in that case. They conflict, so you should either prohibit that case (my preference) or define the behavior. > > > > p: quarantine: What does "fails the DMARC mechanism" mean overall? Is > this defined somewhere? "suspicious": After all the controversy about > the use of the use of the word suspicious in SSP/ADSP, I'm highly > amused > to see it here. > > > I've added "failed" earlier in the document to indicate that DMARC > produces a result, so hopefully that's clarified here. > > SSP/ADSP tried to define Suspicious as a result, as I recall, or at > least explain what it meant. We say clearly here that we have no idea > by what criteria a receiver will normally categorize something as > suspicious (or whatever word it uses), but the intent here is to give > the receiver information in that direction. Like I said, I was mostly amused to find the word "suspicious". Perhaps people are more comfortable with it now than when we tried to use it for SSP/ADSP. > > > Initial default values are -> Possible values are (and possibly > reference a registry) > > > We didn't make a registry for this because there's really only one in > use in this space, and no new ones are anticipated. Two: iodef and afrf, right? > > > > sp: Does this apply to subdomains at all levels, or just direct > subdomains? What's the motivation for specifying a different > policy for > subdomains vs. the organizational domain? Should also point out > that sp > is meaningful only for DMARC records published in Organizational > Domains > and not From domains, (although publishing in From domains isn't > introduced until later in the document). > > > It applies to all subdomains. I'll make it say so. > > The motivation here is the same as it was for ADSP; if I protect > bluepopcorn.net only, the spoofers could send > mail with believable subdomains of that domain without receivers > taking any DMARC-specific action. Agreed that you want to cover all subdomains. I'm just not clear on whether the term "subdomain" includes all "sub-subdomains", etc. It might not be clear to other readers of the spec either. > > I'm not clear on the case you're talking about; in the DMARC context, > when is the OD different from the From domain? Section 8, Policy Discovery, item 1 talks of looking for a DMARC record at the From domain. Since it's always looking at the exact domain in the From address, the sp tag has no effect for this lookup. So sp only makes sense for DMARC records published at ODs, not for other DMARC records. It might be a good idea to point that out, lest someone think that an SP on a DMARC record published at foo.example.com would apply to bar.foo.example.com. > 7.1 Verifying External Destinations > > > Paragraph 3: SHOULD -- shouldn't that be a MUST? > > > We describe a few paragraphs down a reason why one would elect not to > implement that advice, so SHOULD is more appropriate here. Ah. OK. > > > > 7.2 Aggregate reports > > The format for these reports is critical to interoperability -- should > it really be specified in an appendix? It's more important to specify > the format of the reports than the requirements shown in the > bulleted list. > > > The XML definition is quite large. We found this arrangement -- no > huge gap in the text -- to be more palatable. More of a question for the standards-format people: you don't want it to seem non-normative. Or should something like this be in a separate spec? This one IS getting big... > > > 8. Policy Discovery > > This is the first mention I have seen that DMARC records are published > directly on From domains; up to this point it looked like DMARC > was only > published by a Domain Owner on an Administrative Domain. This > changes a > lot -- like the fact that a delegate of the Domain Owner, and not the > [administrative] Domain Owner him/herself, can set the policy for a > domain. This might require a major change of terminology usage, or at > least a change in the definition of Domain Owner, to fix. > > > I'm not sure where the confusion came in. The only domain of interest > to DMARC is the From domain; it is from this that the rest of the work > (most importantly, identifier alignment) is derived. > > Who would a delegate of the Domain Owner be? From the perspective of > a receiver, such a delegation is not visible; the query goes the OD. This goes back to my earlier confusion about the definition of Domain Owner. I had interpreted it more narrowly as the registrant of the domain. When you say, "From the perspective of a receiver, such a delegation is not visible", what about the case where the receiver gets a message with 5322.From = , and looks up and finds a DMARC record at foo.example.com? That would be visible, because the OD is example.com. But the bigger issue for me was that I came this far in understanding DMARC and only now find that it's possible to publish a DMARC record on the actual From domain, and not just on the OD. That should be introduced much earlier. > > > > Items 2 and 4: Effectively, this means that v=DMARC2 records are > completely independent of v=DMARC1 records. There is no > interoperability > between versions. Is this what is intended? > > > This document defines v1. v2 could define itself in such a way that > it accepts part or all of a v1 record, but a v1 record is incompatible > with one explicitly declared to be for v2. This is precisely the same > as "v=DKIM1": If you're extending DKIM v1, you just declare new tags; > once you say v2, you're saying you don't want to keep the old meanings. OK. I'm not sure we thoroughly thought out the interoperability issues with version tags in DKIM, and was hoping we might be able to do so here. I wonder how useful these tags are...if there's ever a DMARC v2, would it be a better idea to publish the records under _dmarc2 ? > > > "If the RFC5322.From domain does not exist...": This specifies an > action > that has nothing to do with DMARC. I don't know the history of > this but > it seems like if there was going to be some global "you SHOULD reject > messages with a nonexistent From domain" action, it belongs someplace > like RFC 5322, not here. See also comment under A.4. > > > I agree that RFC5322 doesn't establish this requirement. We're saying > that a DMARC implementation needs to take this action as it, along > with normal DMARC operation, defeats spoof attempts. Although this is an exceedingly rare usage, I still wonder whether this (and not 5322) is an appropriate place to place additional restrictions on otherwise-legal mail. In the event that the message is rejected during an SMTP transaction, should there be an error code specified for this? > > > 9. Domain Owner Actions > > Paragraph 1: "set up an address to receive reports" -- could also > delegate that externally > > > Sure. Do we need to identify all the things a Domain Owner might do > external to itself? That seems like it could become tedious; I think > that's already implicit. But the external delegation requires some specific actions of its own to make sure that the reporting domain is authorized. > > > > 10.1 Extract Author Domain > > Paragraph 3: "Such messages SHOULD be rejected." Again, this specifies > an action on messages that has nothing to do with DMARC. In > particular, > bullet 2 and 4 describe messages that are legal according to RFC 5322, > and if they're undesirable should have been addressed there. > > > DMARC-aware operators see those exceptional cases in vanishingly small > numbers. That specific community appears to be of the consensus > opinion that they aren't worth the introduced complexity for > exceptional handling. > > > If the messages are rejected, should they be silently discarded or > fully > rejected (per section 15.4)? > > > The action isn't specified. Their delivery simply needs to be prevented. Shouldn't there be at least recommended action? > > > > 10.3 Messaging Sampling > > Much of this section applies generally to the application of > policy and > not specifically to sampling, so perhaps the section heading should be > "Policy Application" or something like that. > > > I don't understand what you're saying here. How is this not a message > sampling function? The main focus of the section is the application of policy. Sampling is a part of that, of course, but seems like a subtopic. > > > > 11.1 Discovery > > Paragraph 1: Does not discuss DMARC policy records associated with > Administrative Domains, only those associated with the From address > (converse of everything before section 8). > > > Still not clear on the distinction being made here. It talks about finding the DMARC policy record at the 5322.From domain, but not at the OD domain. > > > > 11.2.1 Email > > Paragraph 1: Is it equally acceptable to send via SMTP over SSL > (port 465)? > > > Are there implementations of this? Good question. I think I ran across it in my /etc/services file. > > A.6 Organizational Domain Discovery Issues > > Paragraph 3: "Climbing the tree", explored extensively in the > development of ADSP, can of course be constrained to a specific > limited > number of queries. But ultimately even a one-level climb was > considered > too much and was rejected. Nevertheless, DMARC does look for policy in > two places (the From domain and the Organizational Domain). > > > Right, but not based directly on the DNS; I think that was the > objection with SSP/ADSP. I'm not sure what you mean by "not based directly on the DNS". > > > > The approach being used in DMARC was briefly considered in ADSP, but > didn't even make it into a draft at the strong advice of the DNS > Directorate that there is no way to reliably determine the delegation > level in a domain name. > > > Right; as I said above, we don't intend to keep this method as soon as > something endorsed by the larger community is available. Is there an initiative by the larger community that is addressing this? === But I see that there's a -02 version now. More to read... -Jim --------------030009040808050707070307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
A few reply responses inline.

On 12/3/13 12:26 AM, Murray S. Kucherawy wrote:


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

I just need to find my marked-up copy of the spec, which is around here somewhere...
 

===

1. Introduction

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

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

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

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

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

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

OK, missed the context set by the outer bullet.

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

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

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



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

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

I'm still not getting how the more complex arrangements are covered. Perhaps it's from the definition of ADMD (which I haven't read recently).  If so, you might want to say that more directly; calling it "analogous" is a little vague.
 
(2) This creates a dependency on a public suffix list such as that
published by Mozilla, but doesn't require the use of a particular list.
This would create an inconsistency in the result of DMARC that I
consider to be an interoperability problem.

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

I'm still worried about this.

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

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

The subdomain case, yes.

5. DMARC Policy Record

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

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

I just think the statement "matches perfectly" is overdone.  If DNS had slightly different capabilities DMARC would be easier, so I'd tone down that statement.
 
fo: The tag value can contain both 0 and 1; what happens then?

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

They conflict, so you should either prohibit that case (my preference) or define the behavior.
 

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

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

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

Like I said, I was mostly amused to find the word "suspicious". Perhaps people are more comfortable with it now than when we tried to use it for SSP/ADSP.
 
Initial default values are -> Possible values are (and possibly
reference a registry)

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

Two: iodef and afrf, right?
 

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

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

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

Agreed that you want to cover all subdomains. I'm just not clear on whether the term "subdomain" includes all "sub-subdomains", etc.  It might not be clear to other readers of the spec either.

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

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

7.1 Verifying External Destinations

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

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

Ah. OK.
 

7.2 Aggregate reports

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

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

More of a question for the standards-format people: you don't want it to seem non-normative.  Or should something like this be in a separate spec?  This one IS getting big...
 
8. Policy Discovery

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

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

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

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

But the bigger issue for me was that I came this far in understanding DMARC and only now find that it's possible to publish a DMARC record on the actual From domain, and not just on the OD.  That should be introduced much earlier.
 

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

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

OK.  I'm not sure we thoroughly thought out the interoperability issues with version tags in DKIM, and was hoping we might be able to do so here. I wonder how useful these tags are...if there's ever a DMARC v2, would it be a better idea to publish the records under _dmarc2 ?


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

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

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

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


9. Domain Owner Actions

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

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

But the external delegation requires some specific actions of its own to make sure that the reporting domain is authorized.
 

10.1 Extract Author Domain

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

DMARC-aware operators see those exceptional cases in vanishingly small numbers.  That specific community appears to be of the consensus opinion that they aren't worth the introduced complexity for exceptional handling.
 
If the messages are rejected, should they be silently discarded or fully
rejected (per section 15.4)?

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

Shouldn't there be at least recommended action?
 

10.3 Messaging Sampling

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

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

The main focus of the section is the application of policy. Sampling is a part of that, of course, but seems like a subtopic.
 

11.1 Discovery

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

Still not clear on the distinction being made here.

It talks about finding the DMARC policy record at the 5322.From domain, but not at the OD domain.
 

11.2.1 Email

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

Are there implementations of this?

Good question. I think I ran across it in my /etc/services file.

A.6 Organizational Domain Discovery Issues

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

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

I'm not sure what you mean by "not based directly on the DNS".
 

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

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

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

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

-Jim

--------------030009040808050707070307-- From franck@peachymango.org Fri Dec 6 16:36:36 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DDB1ADF7F for ; Fri, 6 Dec 2013 16:36:36 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVmrstHsGuHn for ; Fri, 6 Dec 2013 16:36:33 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id EC6521AD7BF for ; Fri, 6 Dec 2013 16:36:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id DFE294F422C; Fri, 6 Dec 2013 18:36:28 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOWmeTAyCrJZ; Fri, 6 Dec 2013 18:36:28 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id BFF024F408A; Fri, 6 Dec 2013 18:36:28 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A82284F4288; Fri, 6 Dec 2013 18:36:28 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J6MNqmiI1EDf; Fri, 6 Dec 2013 18:36:28 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 7B9504F408A; Fri, 6 Dec 2013 18:36:28 -0600 (CST) Date: Fri, 6 Dec 2013 18:36:27 -0600 (CST) From: Franck Martin To: Jim Fenton Message-ID: <715316768.247342.1386376587794.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <524CA422.8030008@bluepopcorn.net> <52A25C31.4070407@bluepopcorn.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_247341_1976134241.1386376587791" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF25 (Mac)/8.0.5_GA_5839) Thread-Topic: External review of draft-kucherawy-dmarc-base-01 Thread-Index: Muil9mluiTxISEq/53cPUvAU2e2WBg== Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 00:36:36 -0000 ------=_Part_247341_1976134241.1386376587791 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Jim Fenton" > To: "Murray S. Kucherawy" > Cc: dmarc@ietf.org > Sent: Friday, December 6, 2013 3:22:25 PM > Subject: Re: [dmarc-ietf] External review of draft-kucherawy-dmarc-base-01 > A few reply responses inline. > On 12/3/13 12:26 AM, Murray S. Kucherawy wrote: > > > "If the RFC5322.From domain does not exist...": This specifies an action > > > > > > that has nothing to do with DMARC. I don't know the history of this but > > > > > > it seems like if there was going to be some global "you SHOULD reject > > > > > > messages with a nonexistent From domain" action, it belongs someplace > > > > > > like RFC 5322, not here. See also comment under A.4. > > > > > I agree that RFC5322 doesn't establish this requirement. We're saying that > > a > > DMARC implementation needs to take this action as it, along with normal > > DMARC operation, defeats spoof attempts. > > Although this is an exceedingly rare usage, I still wonder whether this (and > not 5322) is an appropriate place to place additional restrictions on > otherwise-legal mail. > In the event that the message is rejected during an SMTP transaction, should > there be an error code specified for this? There may be a BCP to discuss a bit more about it. Also I think we need to stress more these cases in security considerations or inline. However, RFC5322 section 3.6 says there must be one and only one From: header for the message to be "valid". So we can point to this rule and say something like with DMARC you should enforce that, and not be lenient ( http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-11 section 1.1 second paragraph) Moreover RFC5322 says: from = "From:" mailbox-list CRLF So there must be at least one domain name in this Field. Once again, you can be less lenient here. Not DMARC role, here, but you can point back to this RFC and say stop to be lenient. However, IEA RFC 6854, states, that from = "From:" (mailbox-list / address-list) CRLF is ok between non IEA aware MTAs (section 3). I did not like the change of the From: header because it increases uncertainty in emails. Fortunately it is limited in scope, so once you have an MTA that can do IEA, you can enforce the mailbox-list again . Now closer to your point, I don't think any RFC states that the domain name found in the From: must exists or even be mildly "emailable", this is a "common" check you may do for the envelope from (cf http://spamassassin.apache.org/tests_3_3_x.html NO_DNS_FOR_FROM ). It is not common for the From: header but this is something DMARC could point out as something worth considering. Finally, you can't imagine what you find in bounces... All the badness , breakages are there... (or nearly). ------=_Part_247341_1976134241.1386376587791 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Jim Fenton" <fenton@bluepopcorn.= net>
To: "Murray S. Kucherawy" <superuser@gmail.com>
= Cc: dmarc@ietf.org
Sent: Friday, December 6, 2013 3:22:25 = PM
Subject: Re: [dmarc-ietf] External review of draft-kucherawy-d= marc-base-01

=20 =20 =20 =20
A few reply responses inline.

On 12/3/13 12:26 AM, Murray S. Kucherawy wrote:



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

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

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

In the event that the message is rejected during an SMTP transaction, should there be an error code specified for this?
There may be a BCP to discuss a bit more about it. Al= so I think we need to stress more these cases in security considerations or= inline.

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

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

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

Finally,=
 you can't imagine what you find in bounces... All the badness, breakages are there...=
 (or nearly).
------=_Part_247341_1976134241.1386376587791-- From mstevens@etla.org Sat Dec 7 09:46:01 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1391AE245 for ; Sat, 7 Dec 2013 09:46:01 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQCN1G-HXAmB for ; Sat, 7 Dec 2013 09:45:59 -0800 (PST) Received: from ceres.etla.org (ceres.etla.org [IPv6:2001:ba8:1f1:f1ef::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6901AE16B for ; Sat, 7 Dec 2013 09:45:59 -0800 (PST) Received: from mstevens by ceres.etla.org with local (Exim 4.80) (envelope-from ) id 1VpLwr-0000de-TB; Sat, 07 Dec 2013 17:45:49 +0000 Date: Sat, 7 Dec 2013 17:45:49 +0000 From: Michael Stevens To: "Murray S. Kucherawy" Message-ID: <20131207174549.GA31351@ceres.etla.org> References: <20131206195151.11363.70071.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Phase-Of-Moon: The Moon is Waxing Crescent (29% of Full) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-base-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 17:46:01 -0000 On Fri, Dec 06, 2013 at 12:08:51PM -0800, Murray S. Kucherawy wrote: > On Fri, Dec 6, 2013 at 11:51 AM, wrote: > > > > > A new version of I-D, draft-kucherawy-dmarc-base-02.txt > > has been successfully submitted by Murray S. Kucherawy and posted to the > > IETF repository. > > > > Filename: draft-kucherawy-dmarc-base > > Revision: 02 > > Title: Domain-based Message Authentication, Reporting and > > Conformance (DMARC) > > Creation date: 2013-12-06 > > Group: Individual Submission > > Number of pages: 78 > > URL: > > http://www.ietf.org/internet-drafts/draft-kucherawy-dmarc-base-02.txt > > Status: > > http://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base > > Htmlized: http://tools.ietf.org/html/draft-kucherawy-dmarc-base-02 > > Diff: > > http://www.ietf.org/rfcdiff?url2=draft-kucherawy-dmarc-base-02 > > > > Abstract: > > This memo presents a proposal for a scalable mechanism by which a > > mail sending organization can express, using the Domain Name System, > > domain-level policies and preferences for message validation, > > disposition, and reporting, and a mail receiving organization can use > > those policies and preferences to improve mail handling. > > > > The email ecosystem currently lacks a cohesive mechanism through > > which email senders and receivers can make use of multiple > > authentication protocols to establish reliable domain identifiers, > > communicate policies about those identifiers, and report about mail > > using those identifiers. This lack of cohesion has several effects: > > receivers have difficulty providing feedback to senders about > > authentication, senders therefore have difficulty evaluating their > > authentication deployments, and as a result neither is able to make > > effective use of existing authentication technology > > > > The enclosed proposal is not intended to introduce mechanisms that > > provide elevated delivery privilege of authenticated email. The > > proposal presents a mechanism for policy distribution that enables a > > continuum of increasingly strict handling of messages that fail > > multiple authentication checks, from no action, through altered > > delivery, up to message rejection. > > > > This version addresses most of the feedback that's been posted to date. It > doesn't include unresolved things that are still being discussed on the > list. > > The diff link is probably going to be useful to most people given the size > of the document. > > Have at it! Tiny comments, second paragraph ending "effective use of existing authentication technology". p8 " 2. Log details required to generate forensic and aggreagate reports" spelling mistake in aggreagate? Michael From prvs=0046476b60=johnl@iecc.com Sat Dec 7 15:42:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F0B1AE453 for ; Sat, 7 Dec 2013 15:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUEcng7qHIji for ; Sat, 7 Dec 2013 15:42:13 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7707B1ADF64 for ; Sat, 7 Dec 2013 15:42:13 -0800 (PST) Received: (qmail 8963 invoked from network); 7 Dec 2013 23:42:06 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Dec 2013 23:42:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52a3b24e.xn--btvx9d.k1310; i=johnl@user.iecc.com; bh=XmJ1itaL8jQkHc2/f005yilDnGLKTCtpySbMG9lt+kc=; b=mZ9WHM4HKRESWzuTG3+WSIydZDKO6FWvdV+uGLNgJEpAaTM5Ulqi8YvnwEnhJa5J316N+e4aU6IEmpDGtoO0H8cw358dFHYIcixV3YMypWzGp3rlvHsI6UqztkoGn6iNuwtSHHdpwAQO0B6qR81upu4xqrUW2z3ukMK8W/QFBTcCf7kIN8YWwZGoqJDPfb9cvypQ4yLOXAkp6orcoxJ4M2tGQdmGRuTV31W/9n7nmU/bmkk1swqr7FsM98f9TSk9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52a3b24e.xn--btvx9d.k1310; olt=johnl@user.iecc.com; bh=XmJ1itaL8jQkHc2/f005yilDnGLKTCtpySbMG9lt+kc=; b=H8S4uWNEw4h1f9HUYTgmX8aZrq55yjxCWRVjQkYJdCPPRdptUQ3AXGr/SDshzQ8v0Pr2O5DbFecNo1Fa4E956rPB26+Kdij/eeLLEDhpVzEAYQZtTOAzHpXfmuB55PefLzg7XYaawN6e6UNYY0p8qPUS2Y9Opd2GQvLSmOWxKRIO3MIybh7MkqNS3u8U2xALEwTTVigIrB2Uwe0vQwAdwNkRkD9Q6Pph1MklBRJ2Yfsimj5Xq3deMrq6maf9Rp+C Date: 7 Dec 2013 23:41:44 -0000 Message-ID: <20131207234144.82970.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-base-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 23:42:15 -0000 In case it wasn't obvious, in new 11.2.2, the use of "!~q!}{." as the unique-id in the filename was a hint that you might want to reconsider the ABNF in section 11.2.1 that defines unique-id as a MIME token, which can be nearly any random text characters, and instead constrain it to characters that won't confuse shell scripts or simpleminded filename parsers and the like. (I know that bad people can send anything they want as a filename, but this way you can just reject stuff with crud in the name rather than trying to handle it.) In the existing mail reports, the unique-id is optional, and when I looked through the reports I've gotten, the only reporter that uses one is Linkedin. Theirs is always the string "dhalia" which isn't very unique so I expect it's a bug. I'd suggest changing the unique-id ABNF on page 37 to unique-id = 1*(LETTER | DIGIT) Speaking of ABNF, in section 5.3 are all the tags and values intended to be case independent, including v=DMARC1? If not, you have to turn them into unreadable hex. R's, John From franck@peachymango.org Sat Dec 7 16:55:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9431E1AE471 for ; Sat, 7 Dec 2013 16:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYPur3HgELfV for ; Sat, 7 Dec 2013 16:55:26 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 63C4F1AE46D for ; Sat, 7 Dec 2013 16:55:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C0F133F41B4; Sat, 7 Dec 2013 18:55:21 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwwW6nNUfki3; Sat, 7 Dec 2013 18:55:21 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A2B423F41D0; Sat, 7 Dec 2013 18:55:21 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 8D3CE3F41CD; Sat, 7 Dec 2013 18:55:21 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WMQDrQd9fdVu; Sat, 7 Dec 2013 18:55:21 -0600 (CST) Received: from [10.0.0.12] (c-24-5-172-97.hsd1.ca.comcast.net [24.5.172.97]) by smtp-out-1.01.com (Postfix) with ESMTPSA id B19683F41B4; Sat, 7 Dec 2013 18:55:20 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Franck Martin In-Reply-To: Date: Sat, 7 Dec 2013 16:55:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131207234144.82970.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1822) Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-base-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 00:55:28 -0000 On Dec 7, 2013, at 3:41 PM, John Levine wrote: > In case it wasn't obvious, in new 11.2.2, the use of "!~q!}{." as the > unique-id in the filename was a hint that you might want to reconsider > the ABNF in section 11.2.1 that defines unique-id as a MIME token, > which can be nearly any random text characters, and instead constrain > it to characters that won't confuse shell scripts or simpleminded > filename parsers and the like. (I know that bad people can send > anything they want as a filename, but this way you can just reject > stuff with crud in the name rather than trying to handle it.) >=20 > In the existing mail reports, the unique-id is optional, and when I > looked through the reports I've gotten, the only reporter that uses > one is Linkedin. Theirs is always the string "dhalia" which isn't > very unique so I expect it's a bug. >=20 It is not a bug, and it is not unique. It depends where you report is = generated from. We can generate several reports for the same = (timestart,timeend,domain). The unique id allows you to know you have = not received a duplicate. This is one of the purpose of this uniqueid: to avoid to have to collate = all the data in one location. see = https://github.com/linkedin/dmarc-msys/blob/master/dmarc_report.py#L44 = and = https://github.com/linkedin/dmarc-msys/blob/master/dmarc_report.py#L171 From prvs=0047e5a481=johnl@taugh.com Sat Dec 7 17:00:36 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A011AE471 for ; Sat, 7 Dec 2013 17:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k_RmoydUvvw for ; Sat, 7 Dec 2013 17:00:34 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 64DAC1AE46D for ; Sat, 7 Dec 2013 17:00:34 -0800 (PST) Received: (qmail 23925 invoked from network); 8 Dec 2013 01:00:29 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Dec 2013 01:00:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=52a3c4ad.xn--3zv.k1310; i=sendmail-bs@submit.iecc.com; bh=qHBvi/WpZX5SZRUn/TS6ryP4DYoZoznVZibbNiiTXjU=; b=qxXHa0auw3PhXbVW/YoYLPRgbR4H4tlmgH8HlAtSvFuUldRSky0icPxbo3zOleMAP0OWr8oCdt1bzCCD77zt+HwsE9SVTdIf5SgEz2yrGkrPd1vSIbokOUm8Qwtvcr2oBRB2MIyPSXTLfiVUommrJX9LK9k7nkRpLVwp1vOqwNQFUxxCZa1QclRTRgFmYZ5A0avAbY9bD7V8iMRilYg2D8KrXlB6b2Lviot6uT6TMdDDtFkFmlmBg2/FCb693sJH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=52a3c4ad.xn--3zv.k1310; olt=sendmail-bs@submit.iecc.com; bh=qHBvi/WpZX5SZRUn/TS6ryP4DYoZoznVZibbNiiTXjU=; b=Far2NpSCdUaMuJxwsuYLt8hW4XriTYDIpCr5acebXCftFro0gkZHMVqFAgID62VHiVu46LzSN2hHpE0uVy1+TSYGt8nx2f8NROJ/sQVrLdBY4yBt/Xj8tdsSdbT6PVVWcyEHDqpAQbVHDYmeGHiehTsXN3YaHYvfgh8vKm7j1iQ5WwCxpn/JUn5C7eeVp1qTr3aNWm3bsTJTp11OyB7yApbyLUsaHyLgUOXhhDPlUM0YhbNC6zmTFAVo/em9noPm Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 8 Dec 2013 01:00:28 -0000 Date: Sat, 7 Dec 2013 20:00:28 -0500 (EST) From: John R Levine To: Franck Martin In-Reply-To: Message-ID: References: <20131207234144.82970.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-base-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 01:00:36 -0000 >> In the existing mail reports, the unique-id is optional, and when I >> looked through the reports I've gotten, the only reporter that uses >> one is Linkedin. Theirs is always the string "dhalia" which isn't >> very unique so I expect it's a bug. > > It is not a bug, and it is not unique. It depends where you report is generated from. We can generate several reports for the same (timestart,timeend,domain). The unique id allows you to know you have not received a duplicate. > > This is one of the purpose of this uniqueid: to avoid to have to collate all the data in one location. Oh, OK. Usually people pick something that doesn't look like the the name of the programmer's girlfriend, or maybe his cat. In any event, it still looks like limiting the unique ID to letters and digits won't break anything. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From franck@peachymango.org Sat Dec 7 17:22:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC0E1AE169 for ; Sat, 7 Dec 2013 17:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wZD0qIbPtrJ for ; Sat, 7 Dec 2013 17:22:23 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id E16501AE15A for ; Sat, 7 Dec 2013 17:22:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C89583F418C; Sat, 7 Dec 2013 19:22:18 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9X6DwCYKc6u; Sat, 7 Dec 2013 19:22:18 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A68C93F41C3; Sat, 7 Dec 2013 19:22:18 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 900EF3F41B4; Sat, 7 Dec 2013 19:22:18 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KuubSbTMtjvy; Sat, 7 Dec 2013 19:22:18 -0600 (CST) Received: from [10.0.0.12] (c-24-5-172-97.hsd1.ca.comcast.net [24.5.172.97]) by smtp-out-1.01.com (Postfix) with ESMTPSA id EBA223F418C; Sat, 7 Dec 2013 19:22:17 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Franck Martin In-Reply-To: Date: Sat, 7 Dec 2013 17:22:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <97371680-8922-45DA-BEAC-EA03EA6D15AA@peachymango.org> References: <20131207234144.82970.qmail@joyce.lan> To: John R Levine X-Mailer: Apple Mail (2.1822) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dmarc-base-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 01:22:24 -0000 On Dec 7, 2013, at 5:00 PM, John R Levine wrote: >>> In the existing mail reports, the unique-id is optional, and when I >>> looked through the reports I've gotten, the only reporter that uses >>> one is Linkedin. Theirs is always the string "dhalia" which isn't >>> very unique so I expect it's a bug. >>=20 >> It is not a bug, and it is not unique. It depends where you report is = generated from. We can generate several reports for the same = (timestart,timeend,domain). The unique id allows you to know you have = not received a duplicate. >>=20 >> This is one of the purpose of this uniqueid: to avoid to have to = collate all the data in one location. >=20 > Oh, OK. Usually people pick something that doesn't look like the the = name of the programmer's girlfriend, or maybe his cat. You lack imagination... :P >=20 > In any event, it still looks like limiting the unique ID to letters = and digits won't break anything. >=20 Agreed From jgomez@seryrich.com Mon Dec 23 14:18:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD0D1AE0B0 for ; Mon, 23 Dec 2013 14:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjQnTVUDDNap for ; Mon, 23 Dec 2013 14:18:38 -0800 (PST) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id CB39D1AE2F6 for ; Mon, 23 Dec 2013 14:18:37 -0800 (PST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 23 Dec 2013 23:18:32 +0100 Message-ID: From: "J. Gomez" To: References: <20131218024625.3682.qmail@joyce.lan><77426B543150464AA3F30DF1A91365DE6AE3D350@ESV4-MBX02.linkedin.biz><412E757C-2B55-42AE-9D45-2E77EF5B4D79@schmitt.ca> Date: Mon, 23 Dec 2013 23:24:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] [dmarc-discuss] the endless list argument, was Opinions, Please? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 22:18:40 -0000 On Friday, December 20, 2013 11:26 PM [GMT+1=3DCET], Al Iverson wrote: > I found it trivial to modify my own mailing list software to simply > rewrite the From header so that the sender and visible from are "the > list" instead of "the person." That way the list domain's reputation > and policy apply, not the poster's. I recognize that John abhors this > as a solution, but I do want to remind folks that there are other > options to make everything play together nicely, if desired. Time will > tell with regard to what ends up getting most often adopted. It depends on what you consider "adoption" of DMARC. I see no problem = adopting DMARC to the "p=3Dnone" level, but there is NO WAY I will = publish "p=3Dreject" or "p=3Dquarantine" in any email-enabled domain = under my control. And of course, I will NEVER check DMARC in incoming email, because I = CANNOT trust others publishing DMARC records to understand the fine = nuances of DMARC interoperability issues. Why will I do that? Because life is hard enough, and time is precious = enough, to waste them fighting useless battles. So, does that count as me "adopting" DMARC? I guess it's debatable. Regards, J. Gomez