From nobody Thu Jan 1 08:18:15 2015 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 4ED951A1BFC for ; Thu, 1 Jan 2015 08:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 EA6EYC6JxUIH for ; Thu, 1 Jan 2015 08:18:12 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEB01A1BFB for ; Thu, 1 Jan 2015 08:18:11 -0800 (PST) Received: (qmail 29969 invoked from network); 1 Jan 2015 16:18:10 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Jan 2015 16:18:10 -0000 Date: 1 Jan 2015 16:17:48 -0000 Message-ID: <20150101161748.76449.qmail@ary.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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tB1yZzh5ZQjT80rjw4LB4ahNZjg Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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: Thu, 01 Jan 2015 16:18:13 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >OK, seriously, I hope I don't have to crack this open again. Conflict >review is slated for the 1/8 telechat, and a flurry of last minute edits >might not sit well with the IESG. We need to leave actual work, as much as >at all possible, to the WG, and not to hacking on the ISE version. > >Diffs to -09 which will be in -10 within the next few days: >http://blackops.org/~msk/dmarc/diff.html The current diff shows the entire file deleted and replaced with an empty one. While I would enthusiastically endorse this change, I suspect it's not the one you had in mind. R's, John From nobody Thu Jan 1 09:28:35 2015 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 C37A71A0210 for ; Thu, 1 Jan 2015 09:28:33 -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 5SESKCWuGsqp for ; Thu, 1 Jan 2015 09:28:32 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8DC1A01D5 for ; Thu, 1 Jan 2015 09:28:31 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w61so3589455wes.21 for ; Thu, 01 Jan 2015 09:28:30 -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=oIKtrh2023GY6n5F+RDv3GF+0FIUO4Tnzf2Ttwgb98Q=; b=QSZUdPr+iFgRWZVa50c1EcS7KIwkmhbfZPEsgDsea/SOY2ZhQagYqBJubhXIrjkKrq uUOAF+n50YZA6VWVo2YxRtAKEmWRJQwfV5eKA6Hnd9JONZtiv6SpioTgxo21KTjEPG2a eWxjo7zZM9mKFKxtzNlbhIBHtcGJOp0a8A9BD6xAXTDtUS0OmPspbfq7iszaYw5SCIL0 WZEj1mZ63lp/HqxioXPWvG1rlQp05Fczba9ufrzL1T045C7Rly3AHE8eRpQAaUlr2KUL fyZoXvFNnjV3626haWwdRzX5sHYkiYxOHHFVN87Ccr1JwOYzRfoBQDGhUPFu/Dts8Sca bTwg== MIME-Version: 1.0 X-Received: by 10.194.62.76 with SMTP id w12mr142858839wjr.5.1420133310654; Thu, 01 Jan 2015 09:28:30 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 1 Jan 2015 09:28:30 -0800 (PST) In-Reply-To: <20150101161748.76449.qmail@ary.lan> References: <20150101161748.76449.qmail@ary.lan> Date: Thu, 1 Jan 2015 09:28:30 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7ba977a483eeaa050b9a8d05 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-ZbWHSUhb9mMxIL34tfERePcr-M Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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: Thu, 01 Jan 2015 17:28:34 -0000 --047d7ba977a483eeaa050b9a8d05 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 1, 2015 at 8:17 AM, John Levine wrote: > >OK, seriously, I hope I don't have to crack this open again. Conflict > >review is slated for the 1/8 telechat, and a flurry of last minute edits > >might not sit well with the IESG. We need to leave actual work, as much > as > >at all possible, to the WG, and not to hacking on the ISE version. > > > >Diffs to -09 which will be in -10 within the next few days: > >http://blackops.org/~msk/dmarc/diff.html > > The current diff shows the entire file deleted and replaced with an > empty one. While I would enthusiastically endorse this change, I > suspect it's not the one you had in mind. > I was going for brevity. Actually, xml2rfc was complaining that it's now 2015 and the XML source was trying to force a date in 2014. Fixed now. -MSK --047d7ba977a483eeaa050b9a8d05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 1, 2015 at 8:17 AM, John Levine <johnl@taugh.co= m> wrote:
>OK, seriously, I = hope I don't have to crack this open again.=C2=A0 Conflict
>review is slated for the 1/8 telechat, and a flurry of last minute edit= s
>might not sit well with the IESG.=C2=A0 We need to leave actual work, a= s much as
>at all possible, to the WG, and not to hacking on the ISE version.
>
>Diffs to -09 which will be in -10 within the next few days:
>= http://blackops.org/~msk/dmarc/diff.html

The current diff shows the entire file deleted and replaced with an<= br> empty one.=C2=A0 While I would enthusiastically endorse this change, I
suspect it's not the one you had in mind.

I was going for brevity.

Actually, xml2rfc was com= plaining that it's now 2015 and the XML source was trying to force a da= te in 2014.=C2=A0 Fixed now.

-MSK
--047d7ba977a483eeaa050b9a8d05-- From nobody Thu Jan 1 12:50:49 2015 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 92C971A1AB1 for ; Thu, 1 Jan 2015 12:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 FWVl90tIRq4v for ; Thu, 1 Jan 2015 12:50:46 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18DC1A1A9D for ; Thu, 1 Jan 2015 12:50:46 -0800 (PST) Received: from [10.184.62.244] (18.sub-70-208-151.myvzw.com [70.208.151.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B829AC4001F; Thu, 1 Jan 2015 14:50:44 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1420145445; bh=f31LuIVUeETuFeqicOEoRDttUJ8PM8lf5aH8Y+KVVEA=; h=In-Reply-To:References:Subject:From:Date:To:From; b=xhRX0S15C5caeznvRPna/VZmamZ01Ztq2toOFeQ1n3XI4nuM8tI1/LSjO8Rh5wmRs AZB4YjcZVyDQ6FrKNXesdIArg55ZFIr7Ot8daFpjU1kkATWPYUGrz656DY/e6i3NmJ Tzerx9n6UrayRXk6wJu6gU3luTmhD5lVZwggkp3w= User-Agent: K-9 Mail for Android In-Reply-To: References: <2397001.Fx3SqMl5ZI@scott-latitude-e6320> <3004337.MAocVZ5Co9@scott-latitude-e6320> <66CEE14F-375D-4FE9-9485-6DFE58911E54@kitterman.com> <54A183EB.6080508@dcrocker.net> <01PGOJ9M6F5E00005K@mauve.mrochek.com> <19D0C566-275F-474B-B823-B7D79CACD8C7@kitterman.com> <54A1AC4B.2050500@dcrocker.net> <31BA1A25-D64B-4FA6-B4F5-1AD2342C35DA@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 01 Jan 2015 15:50:36 -0500 To: "dmarc@ietf.org" Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3aHSXIetyqHtdTz1Y_rC3lA12bA Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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: Thu, 01 Jan 2015 20:50:48 -0000 On December 31, 2014 11:43:06 PM EST, "Murray S. Kucherawy" wrote: >OK, seriously, I hope I don't have to crack this open again. Conflict >review is slated for the 1/8 telechat, and a flurry of last minute >edits >might not sit well with the IESG. We need to leave actual work, as >much as >at all possible, to the WG, and not to hacking on the ISE version. > >Diffs to -09 which will be in -10 within the next few days: >http://blackops.org/~msk/dmarc/diff.html > >-MSK > > >On Mon, Dec 29, 2014 at 11:38 AM, Scott Kitterman > >wrote: > >> On December 29, 2014 2:32:27 PM EST, Dave Crocker >> wrote: >> >On 12/29/2014 10:40 AM, Scott Kitterman wrote: >> >TO: >> >>> > >> >DMARC evaluation can only complete and yield a "pass" result when >one >> >of the underlying authentication mechanisms passes for an aligned >> >identifier. If neither passes and one or both of them failed due to >> >>> >a >> >temporary error, the Receiver evaluating the message is also unable >> >>> >to >> >conclude that the DMARC mechanism had a permanent failure and >thereby >> >can apply the advertised DMARC policy. >> >>> > >> >>> >This looks good to me. >> >> Shouldn't it be cannot apply the advertised DMARC policy? >> > >> >Actually, no, but I also was confused. It took me some serious >effort >> >to decide that the current wording was correct. And a spec should >not >> >require that sort of linguistic diligence, IMO. >> > >> >Looks like a small change can make your form correct... >> > >> >So I suggest: >> > >> > DMARC evaluation can only yield a "pass" result after one >> >of the underlying authentication mechanisms passes for an aligned >> >identifier. If neither passes and one or both of them fails due to a >> >temporary error, the Receiver evaluating the message is unable to >> >conclude that the DMARC mechanism had a permanent failure; they >> >therefore cannot (yet) apply the advertised DMARC policy. >> > >> >d/ >> >> I think that's better. I'd prefer to leave out the parenthetical yet >as I >> think it raises ambiguity rather than reduces it. >> >> Scott K >> >> _______________________________________________ >> 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 Personally I prefer what you had for -09. I think it's clearer, but I'm ok with either. Scott K From nobody Thu Jan 1 13:02:30 2015 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 CD78F1A1AB4 for ; Thu, 1 Jan 2015 13:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.978 X-Spam-Level: X-Spam-Status: No, score=-3.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FauSsKVCkHBA for ; Thu, 1 Jan 2015 13:02:27 -0800 (PST) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE98C1A1AB1 for ; Thu, 1 Jan 2015 13:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1420146147; x=1451682147; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=57vxABoD7MlU+dE/f+q8/vktGPDZCS+CW48dIRtvAH0=; b=G7nhNAVneGcS8QNOnhPSI+NHQV0wM/UuGJC8fDzjYcx+NKw842S2E94e upxoDIX5/6rG8QeD/0p+E2nF+9Q1LWEmMEt+uGcNS/NCFRZihYzRvDVvU JmcIddWsSWRnw4pDpENQ+y/Y1DpCAE0OHklSsi2RFMJ3d2wmZGnM2Bx/H s=; X-IronPort-AV: E=Sophos;i="5.07,680,1413270000"; d="scan'208";a="167720327" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by ESV4-HT01.linkedin.biz (172.18.46.235) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 1 Jan 2015 13:02:27 -0800 Received: from ESV4-MB03.linkedin.biz ([fe80::1caa:1422:7ef8:5ceb]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.03.0195.001; Thu, 1 Jan 2015 13:02:27 -0800 From: Kurt Andersen To: "dmarc@ietf.org" Thread-Topic: -10 (was: Jim Fenton's review of -04) Thread-Index: AQHQJgY/azXId/O5m0qEC7oZ5VRUew== Date: Thu, 1 Jan 2015 21:02:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <12151B3CB112A84E8B5CFDD923A47A69@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mpj8kShC3NPrzhl_2DiJdUze0G0 Cc: "Murray S. Kucherawy" , Scott Kitterman Subject: Re: [dmarc-ietf] -10 (was: Jim Fenton's review of -04) 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: Thu, 01 Jan 2015 21:02:29 -0000 On 2015-01-01, 12:50 , "Scott Kitterman" wrote: >Personally I prefer what you had for -09. I think it's clearer, but I'm >ok with either. I'm OK with the new wording, but would have liked to see the -09 statement about reporting temp errors carried over: > When otherwise appropriate due to DMARC policy, receivers MAY send >feedback reports regarding temporary errors. --Kurt From nobody Thu Jan 1 13:40:50 2015 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 397AC1A1ADF for ; Thu, 1 Jan 2015 13:40:49 -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 u5qv2ibE_mjy for ; Thu, 1 Jan 2015 13:40:48 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12101A03A9 for ; Thu, 1 Jan 2015 13:40:47 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id x13so5634494wgg.40 for ; Thu, 01 Jan 2015 13:40:46 -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=4Nff18ACkYWo9VjZJNmcZ7mSde3yN+lUNdLNC2Do7d8=; b=FxgkbMn3ZIroY5SygN0Eb6ZMfr4+fVLklgAaLZokd4gQbOvIpWt9+zj5qKArbdtGcc TYZusd3TXkNdWt7w0LidFPYPPpAdeUy20tjTYwAtm4Cnuy5umLAZuaeiz2XsGHgUd4G6 p+8o7BrKmw6DHM0B3ueZNyLZIXZhZbJ4fTayOqe7arjCQKrrs8zJy/Zdv8eAGXS0xS/m diqPryzkRyKnnw9Ygsz5pDkACbh7L8q09gVeAySdl328rL20oftNjrknoSUlWuryEjSf mRlijczI2PbDnrZD2z+qgfzFoTUM2kqFOyaIjfEAjQAMwMgvu5pPC5ETgILuEHWty/fK +/Fw== MIME-Version: 1.0 X-Received: by 10.180.94.37 with SMTP id cz5mr125315916wib.61.1420148446735; Thu, 01 Jan 2015 13:40:46 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 1 Jan 2015 13:40:46 -0800 (PST) In-Reply-To: References: Date: Thu, 1 Jan 2015 13:40:46 -0800 Message-ID: From: "Murray S. Kucherawy" To: Kurt Andersen Content-Type: multipart/alternative; boundary=f46d04426c2cb23375050b9e138a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/A7YuJ60Opohn5pwxJcBzASdd-OY Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] -10 (was: Jim Fenton's review of -04) 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: Thu, 01 Jan 2015 21:40:49 -0000 --f46d04426c2cb23375050b9e138a Content-Type: text/plain; charset=UTF-8 On Thu, Jan 1, 2015 at 1:02 PM, Kurt Andersen wrote: > > I'm OK with the new wording, but would have liked to see the -09 statement > about reporting temp errors carried over: > > > When otherwise appropriate due to DMARC policy, receivers MAY send > >feedback reports regarding temporary errors. Restored. -MSK --f46d04426c2cb23375050b9e138a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 1, 2015 at 1:02 PM, Kurt Andersen <kande= rsen@linkedin.com> wrote:

I'm OK with the new wording, but would have liked to see the -09 statem= ent
about reporting temp errors carried over:

> When otherwise appropriate due to DMARC policy, receivers MAY send
>feedback reports regarding temporary errors.

Restored= .

-MSK
--f46d04426c2cb23375050b9e138a-- From nobody Sun Jan 4 12:38:57 2015 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 E058C1A0231 for ; Sun, 4 Jan 2015 12:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 f_Pm1ovQNlNb for ; Sun, 4 Jan 2015 12:38:54 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196CE1A003A for ; Sun, 4 Jan 2015 12:38:53 -0800 (PST) Received: from splunge.local (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t04KcpSS011614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 4 Jan 2015 12:38:52 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1420403933; bh=aMV6iakmZl72ZioM++ah0O1GqiaIF2NsJVLUVbqtnkA=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pX8ViJa0KjOnff/9p54F/jXkyBUrRdP84dhhCRR3BUrJZcGL68k7tk2hJugQxQHxh JHkTq5iReCLP7Es+qrmRZm/hSFFoUAdBNX7kjMxYfnFpFZQkJz2C7nEA6/LtyansIP SeZK6GGhLZBHyyHRP9/kvzSQxvTDr7YR3PPBnL/A= Message-ID: <54A9A4DB.6080000@bluepopcorn.net> Date: Sun, 04 Jan 2015 12:38:51 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Scott Kitterman , dmarc@ietf.org References: <2397001.Fx3SqMl5ZI@scott-latitude-e6320> <3004337.MAocVZ5Co9@scott-latitude-e6320> In-Reply-To: <3004337.MAocVZ5Co9@scott-latitude-e6320> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_yTdI5Gs_fLV36FKbNQhBcv1GPs Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 04 Jan 2015 20:38:56 -0000 On 12/24/14 10:08 PM, Scott Kitterman wrote: > On Thursday, December 25, 2014 00:02:41 Murray S. Kucherawy wrote: >> On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman >> >> wrote: >>> Messages for which SPF and/or DKIM evaluation encounters a temporary >>> DNS error have not received a definitive result for steps 3 and/or 4 >>> >>> above. >>> >>> If the message has not passed the the DMARC mechanism check due to >>> an SPF or DKIM check that did not have a DNS error, receivers can >>> either >>> ignore DMARC for this message due to incomplete evaluation or they >>> can defer the message in the hope that the temporary error will be >>> resolved when the message is retried. Receivers MUST NOT apply DMARC >>> policy and reject or quarantine the message because the DMARC >>> evaluation is incomplete. When otherwise appropriate due to DMARC >>> policy, receivers MAY send feedback reports regarding temporary errors. >>> >>> Handling of messages for which SPF and/or DKIM evaluation encounters >>> a permanent DNS error is left to the discretion of the Mail Receiver. >>> >>> How's that? >> I think it pretty much says what's there, but is a lot more clear about >> it. I also think the second sentence is a bit convoluted, so I reworked it >> into this. Does it match what you're trying to say? >> >> Messages for which SPF and/or DKIM evaluation encounters >> a temporary DNS error have not received a definitive result for steps 3 >> and/or 4 above. When such an evaluation >> is done in conjunction with an aligned identifier, >> completion of the DMARC algorithm is not possible. >> In this case, receivers can either skip DMARC for this >> message due to incomplete evaluation, or they can >> arrange >> to defer handling of the message in the hope that the >> temporary error will be resolved when the message is >> retried. In any case, Receivers cannot apply DMARC >> policy and reject or quarantine the message because the >> DMARC evaluation is incomplete. When otherwise >> appropriate due to DMARC policy, receivers MAY send >> feedback reports regarding temporary errors. >> >> -MSK > I don't think it does. What I was trying to say is that if you already got an > aligned pass from one method, you're done. It doesn't matter if they other > one gets a DNS error, you already have a definitive result. I don't think your > text says that, but I may be wrong. It's a bit more complicated than that, unfortunately. While an aligned pass from one method does yield an overall DMARC "pass", depending on the setting of the "fo" flag, you might still need to send a failure report for the other method. If fo=1, should a report be sent for the temporary failure, or should the message be held to see if the failure clears? -Jim From nobody Sun Jan 4 12:49:33 2015 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 E58D81A0063 for ; Sun, 4 Jan 2015 12:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 zkYw62ZQ5_Vs for ; Sun, 4 Jan 2015 12:49:23 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DF361A000F for ; Sun, 4 Jan 2015 12:49:23 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A146FC40329; Sun, 4 Jan 2015 14:49:22 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1420404562; bh=CJ/JqNcxqQJqNeTv/BpCeBWM1wjmlviteebNr2PEC4E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pu4Ksk6mw1muAw3pE11UTvuOTkdDB7kgpO8BrWJi1mPZ3fhoF2W+jihvS8Obpv5dA pPukoqQ12H0FSRwOzcxjLp9MtfWPGc9nYNLMnjCRmmIGT/YUqp075OXL1FqmtzwG48 8UhfMYmK7x9uOOVz4fUE+4PjVJDM7nMIA9NwQFME= From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 04 Jan 2015 15:49:21 -0500 Message-ID: <1641711.lRDibUKfMd@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-43-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <54A9A4DB.6080000@bluepopcorn.net> References: <3004337.MAocVZ5Co9@scott-latitude-e6320> <54A9A4DB.6080000@bluepopcorn.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/YN4CJpG9CuCSmh1AASDgXibFuIk Subject: Re: [dmarc-ietf] Jim Fenton's review of -04 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, 04 Jan 2015 20:49:28 -0000 On Sunday, January 04, 2015 12:38:51 Jim Fenton wrote: > On 12/24/14 10:08 PM, Scott Kitterman wrote: > > On Thursday, December 25, 2014 00:02:41 Murray S. Kucherawy wrote: > >> On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman > >> > >> wrote: > >>> Messages for which SPF and/or DKIM evaluation encounters a temporary > >>> DNS error have not received a definitive result for steps 3 and/or 4 > >>> > >>> above. > >>> > >>> If the message has not passed the the DMARC mechanism check due to > >>> an SPF or DKIM check that did not have a DNS error, receivers can > >>> either > >>> ignore DMARC for this message due to incomplete evaluation or they > >>> can defer the message in the hope that the temporary error will be > >>> resolved when the message is retried. Receivers MUST NOT apply DMARC > >>> policy and reject or quarantine the message because the DMARC > >>> evaluation is incomplete. When otherwise appropriate due to DMARC > >>> policy, receivers MAY send feedback reports regarding temporary > >>> errors. > >>> > >>> Handling of messages for which SPF and/or DKIM evaluation encounters > >>> a permanent DNS error is left to the discretion of the Mail Receiver. > >>> > >>> How's that? > >> > >> I think it pretty much says what's there, but is a lot more clear about > >> it. I also think the second sentence is a bit convoluted, so I reworked > >> it > >> into this. Does it match what you're trying to say? > >> > >> Messages for which SPF and/or DKIM evaluation > >> encounters > >> > >> a temporary DNS error have not received a definitive result for steps 3 > >> and/or 4 above. When such an evaluation > >> > >> is done in conjunction with an aligned identifier, > >> completion of the DMARC algorithm is not possible. > >> In this case, receivers can either skip DMARC for > >> this > >> message due to incomplete evaluation, or they can > >> > >> arrange > >> > >> to defer handling of the message in the hope that the > >> temporary error will be resolved when the message is > >> retried. In any case, Receivers cannot apply DMARC > >> policy and reject or quarantine the message because > >> the > >> DMARC evaluation is incomplete. When otherwise > >> appropriate due to DMARC policy, receivers MAY send > >> feedback reports regarding temporary errors. > >> > >> -MSK > > > > I don't think it does. What I was trying to say is that if you already > > got an aligned pass from one method, you're done. It doesn't matter if > > they other one gets a DNS error, you already have a definitive result. I > > don't think your text says that, but I may be wrong. > > It's a bit more complicated than that, unfortunately. While an aligned > pass from one method does yield an overall DMARC "pass", depending on > the setting of the "fo" flag, you might still need to send a failure > report for the other method. If fo=1, should a report be sent for the > temporary failure, or should the message be held to see if the failure > clears? I think we covered that down thread from here. Scott K From nobody Mon Jan 5 13:43:15 2015 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 8EEC81A8AE5 for ; Mon, 5 Jan 2015 13:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 AEiccdZLP3IB for ; Mon, 5 Jan 2015 13:43:11 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B142F1A8AE4 for ; Mon, 5 Jan 2015 13:43:11 -0800 (PST) Received: from [IPv6:2001:470:1f05:bfe:8487:211c:c357:5a90] ([IPv6:2001:470:1f05:bfe:8487:211c:c357:5a90]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t05Lh9sH024713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 5 Jan 2015 13:43:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1420494190; bh=4M7AvOe84h3yXy3NKn2cx/rgScco6nsWdwwSydmO11I=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=VVe0rafTsrfp3FUOYyY8t0aBol7VhjpLS4mpuy9gBB699NFKz8kKBcQ6HFSNjjyQs c5fYLwUjrqFn/NSIH7zz2Xm0YwJEBHNTYN6Eyur9BEU1RCKB3y3btNTycK33Xtfxiw LvTW251wAdjtp6Yk3hKWexKmi5dS/mRZ7cMjKpBA= Message-ID: <54AB056C.2090101@bluepopcorn.net> Date: Mon, 05 Jan 2015 13:43:08 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "dmarc@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fRogXZnH2H9IEQyf_UXPx1_KLvE Subject: [dmarc-ietf] Comments on dmarc-base-09 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, 05 Jan 2015 21:43:13 -0000 I went back over my -04 comments while looking at -09, and the great majority have been resolved. There are still a few things that haven't been adequately addressed, as far as I can tell, nor resolved on-list.=20 I haven't thoroughly gone through the -09 draft, and don't think that would yield much new at this point. Here are the residual items. Apologies if I'm re-raising something that has been discussed, but I forgot about. Section numbers have been corrected for the -09 draft. Section 3, definition of Report Receiver: "...reports about the messages claiming to be from a third party." Comparing with the previous sentence, the third party referred to here seems to be another operator that is sending reports to the Report Receiver. Suggest substituting, "...reports about messages relating to another operator." Section 3.1/3.2, organization nit: It seems a little odd for the Overview and Authentication Mechanisms to be subsections of the Terminology and Definitions. Section 5.3, definition of fo: parameter: I had reported that there isn't any prohibition on specifying both 0 and 1, and I thought someone said that was fixed but I can't find it. More generally, I struggle to find any real utility for a colon-separated list of options here. Section 5.3, definition of pct: parameter: "However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered." This is strong normative language, but there is no procedure specified anywhere for how to identify a DMARC-generated report in order to apply this requirement. Consider the possibility that bad actors may try to craft messages to look like DMARC reports. Section 6.1, paragraph 3: "...the following verification steps are to be taken" It looks like this was changed in response to my earlier objection to a SHOULD here, but now we have language that isn't clear. Suggest "...the following verification steps MUST be taken" Section 6.3, paragraph 4, "The format for failure reports is defined in [AFRF]." This is redundant with the previous paragraph and can be delete= d. Section 6.2.1.1, "The filename is typically constructed..." Again, this is fuzzy normative language; it sounds like it's trying to say, "The filename MAY be constructed..." Section 6.3.1: "Operators implementing this specification also implement..." This needs a normative term, SHOULD or MUST. Not sure which one. Again, I think the SHOULD requirement on the Subject header field is likely to trick an implementer into depending on it, and you can't unless it's a MUST. The information is included in the report anywa= y. Not mentioned anywhere: Which SPF modes are considered to be a "pass" for purposes of DMARC? Presumably +, presumably not -, but it should say something about ? and ~ if it doesn't already. -Jim From nobody Mon Jan 5 14:11:26 2015 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 382201A8BBD for ; Mon, 5 Jan 2015 14:11:24 -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 Ta8ErvUZZZOc for ; Mon, 5 Jan 2015 14:11:20 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8D71A900A for ; Mon, 5 Jan 2015 14:11:19 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id p10so8716502wes.9 for ; Mon, 05 Jan 2015 14:11:17 -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=a2vln5TKr5hn49RCnuaDCWZBHwNtFDwMYDzHKhThGdo=; b=f1JnLNEOytNMvYY1m9hwkOXu+0zDtg18CCPxeIIjKcBnOiUEEn+KDP4JZ5MDJAsNLp 3p6gB7e4RZ4CeWkx0bUK3ny2Xj+Bi/9G5ppB4gsg3oYrw1V1Hdv+FTBDmaFvRCoCf/IP pQ2CCX0tRVfnU7RWBtygfb4+NfuTH7Njs0eDRQdMZbAp9Stl5V0RFvlGsI749bYF0stm iYJ60Zn2PqnsGX71VPIwOvpakAbQqHvClihk69alqbAb9xnRAs+wHwH5jslpWY6cWWpW TFObpg6FEcdFgzurn9eEWzpUelgVxYqhrDBuxQxYljIRutBSjXOJ3FUkBFqokc9ZTPdQ LYBg== MIME-Version: 1.0 X-Received: by 10.194.200.234 with SMTP id jv10mr185898944wjc.110.1420495877866; Mon, 05 Jan 2015 14:11:17 -0800 (PST) Received: by 10.27.204.198 with HTTP; Mon, 5 Jan 2015 14:11:17 -0800 (PST) In-Reply-To: <54AB056C.2090101@bluepopcorn.net> References: <54AB056C.2090101@bluepopcorn.net> Date: Mon, 5 Jan 2015 14:11:17 -0800 Message-ID: From: "Murray S. Kucherawy" To: Jim Fenton Content-Type: multipart/alternative; boundary=047d7bb70bb2348d08050beef899 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/RPYy00xCZGr0pNrQtR9rUhk_At4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Comments on dmarc-base-09 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, 05 Jan 2015 22:11:24 -0000 --047d7bb70bb2348d08050beef899 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 5, 2015 at 1:43 PM, Jim Fenton wrote: > I went back over my -04 comments while looking at -09, and the great > majority have been resolved. There are still a few things that haven't > been adequately addressed, as far as I can tell, nor resolved on-list. > I haven't thoroughly gone through the -09 draft, and don't think that > would yield much new at this point. > Unfortunately, -10 is now current per feedback received last week. I had expected that to be the last one, especially this close to the telechat. However: Section 3, definition of Report Receiver: "...reports about the messages > claiming to be from a third party." Comparing with the previous > sentence, the third party referred to here seems to be another operator > that is sending reports to the Report Receiver. Suggest substituting, > "...reports about messages relating to another operator." > Fixed, since it's minor. > Section 3.1/3.2, organization nit: It seems a little odd for the > Overview and Authentication Mechanisms to be subsections of the > Terminology and Definitions. > Actually I think this is more major than a nit, even though it's really the result of an unfortunate little XML error. This is the main reason I'm preparing a -11 now (sigh). Section 5.3, definition of fo: parameter: I had reported that there > isn't any prohibition on specifying both 0 and 1, and I thought someone > said that was fixed but I can't find it. More generally, I struggle to > find any real utility for a colon-separated list of options here. > I'm inclined to punt this to the working group to sort out if it decides this is a problem. It's too late in this document's lifecycle to be making possibly non-trivial syntax or semantic changes such as this. Section 5.3, definition of pct: parameter: "However, this MUST NOT be > applied to the DMARC-generated reports, all of which must be sent and > received unhindered." This is strong normative language, but there is no > procedure specified anywhere for how to identify a DMARC-generated > report in order to apply this requirement. Consider the possibility that > bad actors may try to craft messages to look like DMARC reports. > Same answer here. This is an ISE document recording current practice; it's OK for us to have gotten technical details wrong, and up to the working group to decide if and how to fix them. > Section 6.1, paragraph 3: "...the following verification steps are to be > taken" It looks like this was changed in response to my earlier > objection to a SHOULD here, but now we have language that isn't clear. > Suggest "...the following verification steps MUST be taken" > What's the normative difference between "are to be taken" and "MUST be taken"? In either case, if you don't take these steps, you're non-compliant. Either way, the risk is already described. > Section 6.3, paragraph 4, "The format for failure reports is defined in > [AFRF]." This is redundant with the previous paragraph and can be deleted. > Removed; redundant it is. > Section 6.2.1.1, "The filename is typically constructed..." Again, this > is fuzzy normative language; it sounds like it's trying to say, "The > filename MAY be constructed..." > This is intentionally not normative, and thus also something to be decided by the WG at this stage. > Section 6.3.1: "Operators implementing this specification also > implement..." This needs a normative term, SHOULD or MUST. Not sure > which one. Again, I think the SHOULD requirement on the Subject header > field is likely to trick an implementer into depending on it, and you > can't unless it's a MUST. The information is included in the report anyway. > I believe Pete, and probably others, would assert that the present language is normative. RFC2119 terms are not the only ways we have to say normative things. Not mentioned anywhere: Which SPF modes are considered to be a "pass" > for purposes of DMARC? Presumably +, presumably not -, but it should say > something about ? and ~ if it doesn't already. > Not only is that another late-stage technical issue to punt to the working group, but I also claim that's a layering violation. SPF simply reports a pass/fail/temperror/etc. It's not the purview of DMARC to ask what kind of "pass" it was any more than it is the purview of DMARC to ask which header fields or how much body was covered by an aligned DKIM signature. Neither SPF nor DKIM report those things. -MSK --047d7bb70bb2348d08050beef899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 5, 2015 at 1:43 PM, Jim Fenton <fenton@b= luepopcorn.net> wrote:
I went back over my -04 c= omments while looking at -09, and the great
majority have been resolved. There are still a few things that haven't<= br> been adequately addressed, as far as I can tell, nor resolved on-list.
I haven't thoroughly gone through the -09 draft, and don't think th= at
would yield much new at this point.

Unf= ortunately, -10 is now current per feedback received last week.=C2=A0 I had= expected that to be the last one, especially this close to the telechat.= =C2=A0 However:

Section 3, definition of Report Receiver: "...reports about the messag= es
claiming to be from a third party." Comparing with the previous
sentence, the third party referred to here seems to be another operator
that is sending reports to the Report Receiver. Suggest substituting,
"...reports about messages relating to another operator."

Fixed, since it's minor.
=C2= =A0
Section 3.1/3.2, organization nit: It seems a little odd for the
Overview and Authentication Mechanisms to be subsections of the
Terminology and Definitions.

Actually I= think this is more major than a nit, even though it's really the resul= t of an unfortunate little XML error.=C2=A0 This is the main reason I'm= preparing a -11 now (sigh).

Section 5.3, definition of fo: parameter: I had reported that there
isn't any prohibition on specifying both 0 and 1, and I thought someone=
said that was fixed but I can't find it. More generally, I struggle to<= br> find any real utility for a colon-separated list of options here.

I'm inclined to punt this to the working gro= up to sort out if it decides this is a problem.=C2=A0 It's too late in = this document's lifecycle to be making possibly non-trivial syntax or s= emantic changes such as this.

Section 5.3, definition of pct: parameter: "However, this MUST NOT be<= br> applied to the DMARC-generated reports, all of which must be sent and
received unhindered." This is strong normative language, but there is = no
procedure specified anywhere for how to identify a DMARC-generated
report in order to apply this requirement. Consider the possibility that bad actors may try to craft messages to look like DMARC reports.

Same answer here.=C2=A0 This is an ISE document r= ecording current practice; it's OK for us to have gotten technical deta= ils wrong, and up to the working group to decide if and how to fix them.=C2=A0
Section 6.1, paragraph 3: "...the following verification steps are to = be
taken"=C2=A0 It looks like this was changed in response to my earlier<= br> objection to a SHOULD here, but now we have language that isn't clear.<= br> Suggest "...the following verification steps MUST be taken"

What's the normative difference between = "are to be taken" and "MUST be taken"?=C2=A0 In either = case, if you don't take these steps, you're non-compliant.=C2=A0 Ei= ther way, the risk is already described.
=C2=A0
Section 6.3, paragraph 4, "The format for failure reports is defined i= n
[AFRF]."=C2=A0 This is redundant with the previous paragraph and can b= e deleted.

Removed; redundant it is.=C2=A0
Section 6.2.1.1, "The filename is typically constructed..." Again= , this
is fuzzy normative language; it sounds like it's trying to say, "T= he
filename MAY be constructed..."

Th= is is intentionally not normative, and thus also something to be decided by= the WG at this stage.
=C2=A0
Section 6.3.1: "Operators implementing this specification also
implement..."=C2=A0 This needs a normative term, SHOULD or MUST. Not s= ure
which one.=C2=A0 Again, I think the SHOULD requirement on the Subject heade= r
field is likely to trick an implementer into depending on it, and you
can't unless it's a MUST. The information is included in the report= anyway.

I believe Pete, and probably o= thers, would assert that the present language is normative.=C2=A0 RFC2119 t= erms are not the only ways we have to say normative things.

Not mentioned anywhere: Which SPF modes are considered to be a "pass&q= uot;
for purposes of DMARC? Presumably +, presumably not -, but it should say something about ? and ~ if it doesn't already.
Not only is that another late-stage technical issue to punt to = the working group, but I also claim that's a layering violation.=C2=A0 = SPF simply reports a pass/fail/temperror/etc.=C2=A0 It's not the purvie= w of DMARC to ask what kind of "pass" it was any more than it is = the purview of DMARC to ask which header fields or how much body was covere= d by an aligned DKIM signature. Neither SPF nor DKIM report those things.
-MSK
--047d7bb70bb2348d08050beef899-- From nobody Mon Jan 5 15:10:09 2015 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 E85301A0204 for ; Mon, 5 Jan 2015 15:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 n_hshvoiuREe for ; Mon, 5 Jan 2015 15:09:53 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C068F1A9064 for ; Mon, 5 Jan 2015 15:09:51 -0800 (PST) Received: from kitterman-optiplex-9020m.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C2DD0C402B7 for ; Mon, 5 Jan 2015 17:09:50 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1420499390; bh=EzDgs2M+HtVt66ZMSX/itdTQncbhxX8cOuRShUxgov0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gxoaqUKOhbs2PkmJYO60lTYYujwryefxBnrVCvlTNFOZBlsJW+aqjRcnQ0WiB4mPk yYIu8T5Hx2wnij3s8gpUN1bRIGojazxGjzoHFxocHK2ZW9roZd/f2I12HdIs2JFQbL OldFhwUajEtDLe5/x4k2M6Umg1XCmmuEABvTVO5w= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 05 Jan 2015 18:10:04 -0500 Message-ID: <1861555.X6X56CVSi3@kitterman-optiplex-9020m> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <54AB056C.2090101@bluepopcorn.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LtFiYv4iZcznS1uR5eE2djoUsDY Subject: Re: [dmarc-ietf] Comments on dmarc-base-09 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, 05 Jan 2015 23:10:04 -0000 On Monday, January 05, 2015 02:11:17 PM Murray S. Kucherawy wrote: > On Mon, Jan 5, 2015 at 1:43 PM, Jim Fenton wrote: ... > > Not mentioned anywhere: Which SPF modes are considered to be a "pass" > > for purposes of DMARC? Presumably +, presumably not -, but it should say > > something about ? and ~ if it doesn't already. > > Not only is that another late-stage technical issue to punt to the working > group, but I also claim that's a layering violation. SPF simply reports a > pass/fail/temperror/etc. It's not the purview of DMARC to ask what kind of > "pass" it was any more than it is the purview of DMARC to ask which header > fields or how much body was covered by an aligned DKIM signature. Neither > SPF nor DKIM report those things. Right, pass is pass. The more interesting question is what is fail. I think with the recent hand wringing over temporary DNS errors we can reasonably say that fail is not pass or temporary DNS error. I don't think the spec needs further changes in this regard. Scott K From nobody Mon Jan 5 18:19:26 2015 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 532F11A90C9 for ; Mon, 5 Jan 2015 18:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 HK6Ehp56yBt2 for ; Mon, 5 Jan 2015 18:19:23 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E797E1A037B for ; Mon, 5 Jan 2015 18:19:22 -0800 (PST) Received: (qmail 68953 invoked from network); 6 Jan 2015 02:19:21 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 6 Jan 2015 02:19:21 -0000 Date: 6 Jan 2015 02:18:59 -0000 Message-ID: <20150106021859.32330.qmail@ary.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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/n6-eLZ1LR4dpMzXqyUEpsGyC9xE Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Comments on dmarc-base-09 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, 06 Jan 2015 02:19:24 -0000 >Not mentioned anywhere: Which SPF modes are considered to be a "pass" >> for purposes of DMARC? Presumably +, presumably not -, but it should say >> something about ? and ~ if it doesn't already. > >Not only is that another late-stage technical issue to punt to the working >group, but I also claim that's a layering violation. RFC 7208 is quite clear about what constitutes an SPF pass. R's, John From nobody Tue Jan 6 10:21:30 2015 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 A0F5A1A1AD8 for ; Tue, 6 Jan 2015 10:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 3-co46pSJqPe for ; Tue, 6 Jan 2015 10:21:27 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E70E1A0406 for ; Tue, 6 Jan 2015 10:21:26 -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 t06ILKTw003623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 6 Jan 2015 10:21:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1420568482; bh=dmngLAXDc8ziggTjvondaHj6BauwVVb4+Y/Ovd9Nyuc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=W7VwEBqBfy/sGGrVQwf784PVxCzkhzmqlWEB28/phBLJAS7lYHLq2BV3/+CCnUiU8 3CgQkewQQ8oICsiNfbjnXCqLTmNUtFjSkW5PLgSgn/WGrvWCAoG7ghPaqbMMGQDafA wmQdtCutF3jq+kvAuZJcPtJpZcD+GOOXoJbGDQbI= Message-ID: <54AC279E.2040501@bluepopcorn.net> Date: Tue, 06 Jan 2015 10:21:18 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20150106021859.32330.qmail@ary.lan> In-Reply-To: <20150106021859.32330.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/P0-_-l9CT3CExw8pul1QpUKUoKA Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Comments on dmarc-base-09 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, 06 Jan 2015 18:21:28 -0000 On 1/5/15 6:18 PM, John Levine wrote: >> Not mentioned anywhere: Which SPF modes are considered to be a "pass" >>> for purposes of DMARC? Presumably +, presumably not -, but it should say >>> something about ? and ~ if it doesn't already. >> Not only is that another late-stage technical issue to punt to the working >> group, but I also claim that's a layering violation. > RFC 7208 is quite clear about what constitutes an SPF pass. Perhaps it should be referenced rather than RFC 4408 then. -Jim From nobody Tue Jan 6 10:25:13 2015 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 0CC301A1AFA for ; Tue, 6 Jan 2015 10:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 LizMkjXaTQ-k for ; Tue, 6 Jan 2015 10:25:06 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5911A1AF5 for ; Tue, 6 Jan 2015 10:25:05 -0800 (PST) Received: (qmail 14861 invoked from network); 6 Jan 2015 18:25:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3a0b.54ac2880.k1501; bh=boD6wkCOkLdcjCMnZVjGHzg2aMX3AXWNCFzPiciAT2g=; b=F/rQ8UIamIqVXc8/6u+/9P0llXdzGHd57PG5Ia04dbAYnmqb6oZLT2fK+l4bmU3BDYmJRc+QwFoqVbVim5LkqbkcllBvwyP0hTxZLGzzk3i7q+LOqm82HJqreWe6aQQnfzS+iI+g9KfPYNNDHy8r7Qno3Vr44aYATFsjqDmPVTDvX2wFOKmV81QZszsNVtgyEiUYLNhA1iVIAgeItD+fvzIFGKnX8A23mXv25kdvg98d9hlQII564zmN8sPNEe+2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3a0b.54ac2880.k1501; bh=boD6wkCOkLdcjCMnZVjGHzg2aMX3AXWNCFzPiciAT2g=; b=WjckUWdowHzrGwwqvGmdiQgKPX20Cw3uyvzBwyj3VXXOtlYUsyO9YExyxcOMZjZ/uAco81f5lXRGUFi6J+y97jwfXt2RFw1hdW4Ia+yz0R0RhBWeq7B+lcb177v99SXBNLhCqx8PSKm44ctDV3xXCDA7JEO+tN/sLhD6uDorGibgyYnqiLC/RGnTNQVZshL4YLnGb9rWLQFZwguc96vNCSOvus/Aq7jcCsb+RJ6G579mpJGjYDAUyTaQz7iUg8iN Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 06 Jan 2015 18:25:04 -0000 Date: 6 Jan 2015 13:25:05 -0500 Message-ID: From: "John R Levine" To: "Jim Fenton" In-Reply-To: <54AC279E.2040501@bluepopcorn.net> References: <20150106021859.32330.qmail@ary.lan> <54AC279E.2040501@bluepopcorn.net> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xWC1LATRDuRhmhyPo6ju-07G_WQ Cc: dmarc@ietf.org, Murray Kucherawy Subject: Re: [dmarc-ietf] Comments on dmarc-base-09 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, 06 Jan 2015 18:25:11 -0000 >> RFC 7208 is quite clear about what constitutes an SPF pass. > > Perhaps it should be referenced rather than RFC 4408 then. Right, 4408 is now obsolete. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Jan 6 11:42:09 2015 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 6321F1A1AA8 for ; Tue, 6 Jan 2015 11:42:07 -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 S5-TO1rs7uZA for ; Tue, 6 Jan 2015 11:42:06 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503211A1B45 for ; Tue, 6 Jan 2015 11:41:37 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id l18so4620575wgh.14 for ; Tue, 06 Jan 2015 11:41:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NbWJHAlCO9chmghUOm5QAEFSOoMh89M3864dNRDMT/k=; b=r2s2O0f+ibjFU4ePlvH1o4+WccQ9Y3/Oefe+ryU5nKNZ32TxcDnWmtPxaDswyDsFIJ liqwV5qOrao7W36B1eBySb1hbz3LRcGxFLhH/qu6lv4qgymDSOgtSFPRnEleK+eGMjOY Pp7G9DgfqCxglA3Pc3zci1eV0aX5ZVKZt18hp2qpjFRhQBciSUHdE1gWJ3D/GIPUPRa7 rNB7wXMSMJy73f7SVVZxcQMVhcmuv7GXOJ6KpnKELlNEtkzJJ5TDQ287e/eaCxDDMXv3 R5WoCKvk8P0HpriHwZzRZ6cFFCsIkuYoPA3b8hGJGpmh6Nf6pzqk5YeMB8t6cSfkYhgU lj5Q== MIME-Version: 1.0 X-Received: by 10.180.94.37 with SMTP id cz5mr9879455wib.61.1420573295854; Tue, 06 Jan 2015 11:41:35 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 6 Jan 2015 11:41:35 -0800 (PST) In-Reply-To: References: <20150106021859.32330.qmail@ary.lan> <54AC279E.2040501@bluepopcorn.net> Date: Tue, 6 Jan 2015 11:41:35 -0800 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=f46d04426c2cad4a6f050c00fec0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/RzCWnbtigc9zRP3Q-h9V4fs52kE Cc: Jim Fenton , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Comments on dmarc-base-09 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, 06 Jan 2015 19:42:07 -0000 --f46d04426c2cad4a6f050c00fec0 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 6, 2015 at 10:25 AM, John R Levine wrote: > RFC 7208 is quite clear about what constitutes an SPF pass. >>> >> >> Perhaps it should be referenced rather than RFC 4408 then. >> > > Right, 4408 is now obsolete. > Fixed in -11. -MSK --f46d04426c2cad4a6f050c00fec0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 6, 2015 at 10:25 AM, John R Levine <johnl@tau= gh.com> wrote:
RFC 7208 is quite clear about what constitutes an SPF pass.

Perhaps it should be referenced rather than RFC 4408 then.

 Right, 4408 is now obsolete.

Fixed in -= 11.

-MSK
--f46d04426c2cad4a6f050c00fec0-- From nobody Tue Jan 6 12:51:42 2015 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 9400C1A1BA3 for ; Tue, 6 Jan 2015 12:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 GHFETPcsaCFl for ; Tue, 6 Jan 2015 12:51:37 -0800 (PST) Received: from dkim.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 124351A1A91 for ; Tue, 6 Jan 2015 12:51:36 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=710; t=1420577487; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=gn+PO3p6fVXxlmoWqYCmRwfDLMA=; b=glKgYYjc8id7TanJkuWC 1pe7z3FXuE7JkkQKjV0TNQnt26ygw6TGbxh1Cajdo8hcPzHISZn8/eeD+8iBe2yV tkFNzES8ETOLin/jx/LW/odtuZv8Oj17olWZinQaOrgnlWFrqCh/JWdT8WUHGeny vEmaOcteasCmDNL2RrqvzdU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 06 Jan 2015 15:51:27 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2877533655.1.3396; Tue, 06 Jan 2015 15:51:27 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=710; t=1420577359; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=IKpHXcY EoGn4875RT30xTTwg0qLBC/27WkiQTHMShbE=; b=IVtW+glVdHhAEG2vW6Zz7e6 rU/4SAdMb7e0zmeIZ2U0JPWRopONTvPI52cZxs3uWqk3O1iNxMKS2dtq7djKf1My fLQjXefzrKK0WeD0hSzSMZI9bL+sTJZaxufwXncC+B6iEbtbomEE7zitGHaZbX96 7zwmWzvLXuBqokGZTXOw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 06 Jan 2015 15:49:19 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1469829580.9.6448; Tue, 06 Jan 2015 15:49:18 -0500 Message-ID: <54AC4A8E.3020101@isdg.net> Date: Tue, 06 Jan 2015 15:50:22 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: dmarc@ietf.org References: <20150106021859.32330.qmail@ary.lan> <54AC279E.2040501@bluepopcorn.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dhvU9fapnkl4a5I5I5Pcumc3s6g Subject: Re: [dmarc-ietf] Comments on dmarc-base-09 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, 06 Jan 2015 20:51:39 -0000 On 1/6/2015 1:25 PM, John R Levine wrote: >>> RFC 7208 is quite clear about what constitutes an SPF pass. >> >> Perhaps it should be referenced rather than RFC 4408 then. > > Right, 4408 is now obsolete. Not operationally. SPF PASS is what "Local Policy" implementation options has allowed for the last past 10 years. In our package implementation, an +ALL policy is acceptable by default (option is provided to continue testing additional filtering scripts). For the most part, we are looking for the obvious failure which is where the highest payoff is realized. All else pretty meaningless or not well defined how to best handle the anonymous, unsolicited +ALL policy checks. -- HLS From nobody Mon Jan 12 06:04:38 2015 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 488AB1A912B for ; Mon, 12 Jan 2015 06:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.512 X-Spam-Level: X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 uU15-2JdVlvP for ; Mon, 12 Jan 2015 06:04:31 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id C90191A9126 for ; Mon, 12 Jan 2015 06:04:31 -0800 (PST) Received: from [10.0.1.4] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 7A5F8CB46 for ; Mon, 12 Jan 2015 09:04:23 -0500 (EST) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4A9DE39D-8A9A-4C18-86E9-89034FE5E27E@eudaemon.net> Date: Mon, 12 Jan 2015 09:04:29 -0500 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [dmarc-ietf] update on 1st draft 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, 12 Jan 2015 14:04:33 -0000 Heyo all, The WG's 1st draft (documenting interoperability issues between DMARC = and indirect email flows plus possible ways to address them) should be = ready for WG-wide review come mid week. Due to the holidays this work was slow to get off the ground, but it's = shaping up nicely now. =3D- Tim From anne@encs.concordia.ca Fri Jan 16 16:10:59 2015 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 62D3E1A9079 for ; Fri, 16 Jan 2015 16:10:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 H4oyU2We0auL for ; Fri, 16 Jan 2015 16:10:57 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 91A811A9071 for ; Fri, 16 Jan 2015 16:10:57 -0800 (PST) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0H0Auio000956 for ; Fri, 16 Jan 2015 19:10:56 -0500 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0H0AuVJ006151 for ; Fri, 16 Jan 2015 19:10:56 -0500 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 16 Jan 2015 19:10:56 -0500 Message-ID: <6150.1421453456@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-16 19:10:56 EST Archived-At: Subject: [dmarc-ietf] SPF RFC 4408 vs 7208 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, 17 Jan 2015 00:29:06 -0000 On Jan 6, Murray S. Kucherawy confirmed fixing the reference for the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11"). However, -12 still has, in section "3.1. Identifier Alignment": For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] authenticates either the domain that appears in the RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom is null (in the case of Delivery Status Notifications). Actually, RFC 7208 states that: Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence if both are checked. ... and implies that if the first check passes, the second is unnecessary: If a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided. So the RFC5321.EHLO/HELO domain is checked not only if the RFC5321.MailFrom is null - in fact in cases where sites have followed the RFC 7208 recommendation, it will be checked first, at least by a "pure SPF" implementation. This means, first of all, that the -12 text above needs fixing. But also, I'm struggling with what it means for alignment. I can think of some real-life cases where only one of HELO or MAIL FROM aligns with RFC5322.From, even though both would "pass" in a pure SPF check. IMHO, Section "3.1.2. SPF-authenticated Identifiers" needs to be clarified to better take HELO into account. I'd like to see an approach similar to that for DKIM, where it is explicitly stated that: a single email can contain multiple DKIM signatures, and it is considered to be a DMARC "pass" if any DKIM signature is aligned and verifies. Similarly, I think that for SPF, it should be considered a pass if either the MAIL FROM or the HELO is aligned and results in a pass at the SPF level. But whether it is decided to take into account both HELO and MAIL FROM, or whether it is decided to ignore HELO (modulo its use to construct an artificial MAIL FROM if the latter is null), the text should IMHO make this clear one way or another, both in "3.1.2. SPF-authenticated Identifiers": In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce identifier alignment. ... and in "4.1. Authentication Mechanisms": o [SPF], which authenticates the domain found in an [SMTP] MAIL command when it is the authorized domain. In both cases, the text should specifically mention HELO, and whether to include or exclude a HELO SPF result, in view of HELO's prominence in RFC 7208. If it is decided to allow both HELO and MAIL FROM results to be passed back to DMARC, then in section "6.6.2. Determine Handling Policy", item 4 should be updated to reflect that as well. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From anne@encs.concordia.ca Fri Jan 16 16:26:44 2015 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 559A51A9083 for ; Fri, 16 Jan 2015 16:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 ED8_jgeTVqjp for ; Fri, 16 Jan 2015 16:26:43 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 208191A9068 for ; Fri, 16 Jan 2015 16:26:43 -0800 (PST) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0H0QgRA002058 for ; Fri, 16 Jan 2015 19:26:42 -0500 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0H0QfdN006463 for ; Fri, 16 Jan 2015 19:26:41 -0500 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 16 Jan 2015 19:26:41 -0500 Message-ID: <6462.1421454401@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-16 19:26:42 EST Archived-At: Subject: [dmarc-ietf] Flow of operations text in -12 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, 17 Jan 2015 00:29:26 -0000 In draft 12, Section "4.3 Flow Diagram", we have text which I think is somewhat contradicted by text in the later and more detailed "6.6. Mail Receiver Actions", in particular with respect to parallelizing some of the checks, and there's another small problem with the text as well. Quoting 4.3: 6. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain's DNS data (when identifiers are aligned; see below). ... but the "Author Domain" (based on RFC5322.From) is not necessarily the domain that will be queried by SPF and DKIM checks, and we won't know if identifiers are aligned until we look at the results of: 7. The results of these are passed to the DMARC module along with the Author's domain. The DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.) "6.6.2" shows clearly that the SPF check (with its DNS queries), the DKIM checks (with its DNS queries), and the DMARC policy determination (with its DNS queries) can be done in parallel, and their results combined when all have arrived, and I imagine that will turn out to be the best way to do it. So 4.2 could perhaps be modified: 6. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to DNS data. The results of these checks are passed back to the DMARC module. 7. Meanwhile, the DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.) Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Fri Jan 16 16:41:34 2015 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 9C0A41ACD6D for ; Fri, 16 Jan 2015 16:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 o2HQVzFVG47P for ; Fri, 16 Jan 2015 16:41:30 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDCA1ACD34 for ; Fri, 16 Jan 2015 16:41:30 -0800 (PST) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0H0fTaq003290 for ; Fri, 16 Jan 2015 19:41:29 -0500 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0H0fTcT006717 for ; Fri, 16 Jan 2015 19:41:29 -0500 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 16 Jan 2015 19:41:29 -0500 Message-ID: <6716.1421455289@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-16 19:41:29 EST Archived-At: Subject: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 17 Jan 2015 00:41:32 -0000 Having just spent several hours poring over this document (-12), I might as well send my additional minor observations. I suspect that some of you will consider these items trivial, but they gave me pause as I went back and forth through several sections of the text to make sure I understood correctly. So... In "6.6.2. Determine Handling Policy", items 3 and 4, it would be helpful to make it clear whether only "passed" checks are passed back from SPF and DKIM to DMARC modules, or only "pass/fail", or all results including temporary errors. In "6.6.3 Policy discovery", item 3, I think you mean that the OD must be looked up if AND ONLY IF the set is now empty. Otherwise, one does run the risk of ending up with several records, which item 5 implies is erroneous. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Fri Jan 16 20:08:43 2015 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 5C6F41B2A4D for ; Fri, 16 Jan 2015 20:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugpWcf8d5Og8 for ; Fri, 16 Jan 2015 20:08:37 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750A71B2A4C for ; Fri, 16 Jan 2015 20:08:37 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id l61so1546186wev.8 for ; Fri, 16 Jan 2015 20:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VOIaxp83nA7HBS7FaP+8T4UxkeQxUOjYB+qvCZulT8s=; b=xfabhJloWvsvizZCpd5ssOQsSXUx9U7kdTt3grKiCupE88ggau9z1MyBLUuarH9vRC 6I3+ld2yV3Rheu3qyLDsLL9K+zKy3hAcFyljFevUIlNwJDC+S+6EU7MYeplntQnciyJR DvUrjUVsDiCerejkOpm7hrUXQuai37YbCRfy9NcdVTvUa8MriP0wjxceKG/LfKHuLCXJ 3ORrRLIqV4Q65dMiYR9tHU5nFW7uTCcYMvvS6dTbBjTzuCLMM+Gm9s+q0AvgXbvgyD6H bIIZxt9qQTY+BS8iFy5ys0XajQ2f6saOHtBdqcf13avY+xFI7nngaH8hSPCU/9hTjVXd cvag== MIME-Version: 1.0 X-Received: by 10.180.95.4 with SMTP id dg4mr12257312wib.61.1421467716221; Fri, 16 Jan 2015 20:08:36 -0800 (PST) Received: by 10.27.204.198 with HTTP; Fri, 16 Jan 2015 20:08:36 -0800 (PST) In-Reply-To: <6716.1421455289@vindemiatrix.encs.concordia.ca> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> Date: Fri, 16 Jan 2015 20:08:36 -0800 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=f46d0444028e4900fc050cd13ec2 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 17 Jan 2015 04:08:41 -0000 --f46d0444028e4900fc050cd13ec2 Content-Type: text/plain; charset=UTF-8 Hello Anne, On Fri, Jan 16, 2015 at 4:41 PM, Anne Bennett wrote: > Having just spent several hours poring over this document > (-12), I might as well send my additional minor observations. > I suspect that some of you will consider these items trivial, > but they gave me pause as I went back and forth through several > sections of the text to make sure I understood correctly. So... > [...] > I think all of the points in your three messages are good input for a more solid specification, but the timing is unfortunate as we just got publication approval for -12 a week ago. Making more changes post-approval would probably not be a good idea, and by my reading none of them rise to the level of being urgent to correct. The plan for the DMARC working group is to consider, among other things, whether it wants to produce a new version of the base document on the Standards Track (because of its path to publication, -12 will be Informational). Your points here are ideal for consideration when the working group reaches that juncture. Would the co-chairs object to beginning to track these items using the WG's tracker? If and when we do decide to crack open the base document for a Proposed Standard revision, we'd already have an inventory of topics to consider. It would also help to keep the discussion on this list focused on active topics now that the base draft is "done". -MSK --f46d0444028e4900fc050cd13ec2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Anne,

On Fri, Jan 16, 2015 at 4:41 PM, Anne Bennett <an= ne@encs.concordia.ca> wrote:
, Anne Bennett References: <6716.1421455289@vindemiatrix.encs.concordia.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 17 Jan 2015 17:00:33 -0000 I have two concerns. It seems you "jumped the gun" to accept the RFC 4408 obsolete idea. Is 7208 backward compatible or not? Does DMARC require 7208 operations or 4408 operations? And is this -12 publication "worthy" of even considering for implementation? Or should we wait for the more "solid specification?" -- HLS On 1/16/2015 11:08 PM, Murray S. Kucherawy wrote: > Hello Anne, > > On Fri, Jan 16, 2015 at 4:41 PM, Anne Bennett > wrote: > > Having just spent several hours poring over this document > (-12), I might as well send my additional minor observations. > I suspect that some of you will consider these items trivial, > but they gave me pause as I went back and forth through several > sections of the text to make sure I understood correctly. So... > [...] > > > I think all of the points in your three messages are good input for a > more solid specification, but the timing is unfortunate as we just got > publication approval for -12 a week ago. Making more changes > post-approval would probably not be a good idea, and by my reading > none of them rise to the level of being urgent to correct. > > The plan for the DMARC working group is to consider, among other > things, whether it wants to produce a new version of the base document > on the Standards Track (because of its path to publication, -12 will > be Informational). Your points here are ideal for consideration when > the working group reaches that juncture. > > Would the co-chairs object to beginning to track these items using the > WG's tracker? If and when we do decide to crack open the base > document for a Proposed Standard revision, we'd already have an > inventory of topics to consider. It would also help to keep the > discussion on this list focused on active topics now that the base > draft is "done". > > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Mon Jan 19 06:30:26 2015 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 A9B141AD10A for ; Mon, 19 Jan 2015 06:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 bzWY0d-32ZMw for ; Mon, 19 Jan 2015 06:30:12 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id CB3E51B2A8D for ; Mon, 19 Jan 2015 06:30:12 -0800 (PST) Received: from [192.168.1.67] (208-104-143-220.brvd.dsl.dyn.comporium.net [208.104.143.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 9AC99CB46; Mon, 19 Jan 2015 09:30:03 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_01A80EFB-4309-4FDF-A381-B35BD41B8290" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Draegen In-Reply-To: Date: Mon, 19 Jan 2015 09:30:09 -0500 Message-Id: <3DEE5D4C-D33B-4190-BDEA-7E8DF240D305@eudaemon.net> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 19 Jan 2015 14:30:17 -0000 --Apple-Mail=_01A80EFB-4309-4FDF-A381-B35BD41B8290 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 16, 2015, at 11:08 PM, Murray S. Kucherawy = wrote: >=20 > Would the co-chairs object to beginning to track these items using the = WG's tracker? If and when we do decide to crack open the base document = for a Proposed Standard revision, we'd already have an inventory of = topics to consider. It would also help to keep the discussion on this = list focused on active topics now that the base draft is "done". No objection =E2=80=94 please do use the WG=E2=80=99s tracker for these = items. Anne=E2=80=99s thorough review will be picked up (and not = rediscovered!) if we=E2=80=99ve got an obvious place to start from. =3D- Tim --Apple-Mail=_01A80EFB-4309-4FDF-A381-B35BD41B8290 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jan 16, 2015, at 11:08 PM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

Would the co-chairs object to beginning to track = these items using the WG's tracker?  If and when we do decide to = crack open the base document for a Proposed Standard revision, we'd = already have an inventory of topics to consider.  It would also = help to keep the discussion on this list focused on active topics now = that the base draft is "done".

No objection =E2=80=94 please do use the = WG=E2=80=99s tracker for these items.  Anne=E2=80=99s thorough = review will be picked up (and not rediscovered!) if we=E2=80=99ve got an = obvious place to start from.

=3D- Tim

= --Apple-Mail=_01A80EFB-4309-4FDF-A381-B35BD41B8290-- From nobody Mon Jan 19 06:43:47 2015 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 9188F1B2A93 for ; Mon, 19 Jan 2015 06:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Z_9qjVcNu07k for ; Mon, 19 Jan 2015 06:43:43 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id EB8061ACE94 for ; Mon, 19 Jan 2015 06:43:42 -0800 (PST) Received: from [192.168.1.67] (208-104-143-220.brvd.dsl.dyn.comporium.net [208.104.143.220]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 516ACCB46; Mon, 19 Jan 2015 09:43:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Draegen In-Reply-To: <54BA9524.2050901@isdg.net> Date: Mon, 19 Jan 2015 09:43:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <04FE226F-8FF8-4D4F-B41F-EA6DC42744D1@eudaemon.net> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <54BA9524.2050901@isdg.net> To: Hector Santos X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 19 Jan 2015 14:43:44 -0000 > On Jan 17, 2015, at 12:00 PM, Hector Santos wrote: >=20 > I have two concerns. >=20 > It seems you "jumped the gun" to accept the RFC 4408 obsolete idea. Is = 7208 backward compatible or not? Does DMARC require 7208 operations or = 4408 operations? >=20 > And is this -12 publication "worthy" of even considering for = implementation? Or should we wait for the more "solid specification?" Hi Hector, if you review: https://www.rfc-editor.org/rfc/rfc7208.txt ..you'll see at the very top "Obsoletes: 4408". If there are = discrepancies between 4408 and 7208, it's best to file an errata = (erratum?): http://www.rfc-editor.org/how_to_report.html DMARC implementations are already in the wild and deployed. Input to = the existing specification will be largely based on working = implementations. You might have your own reasons for waiting for this = WG to review the DMARC base draft, but if you want to provide input = based on operational & implementation experience, it's probably best to = not wait. =3D- Tim From nobody Mon Jan 19 20:37:47 2015 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 D835E1ACEE3 for ; Mon, 19 Jan 2015 20:37:46 -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 EltRtw3u_JYS for ; Mon, 19 Jan 2015 20:37:45 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDF61ACE6D for ; Mon, 19 Jan 2015 20:37:45 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id em10so2145042wid.1 for ; Mon, 19 Jan 2015 20:37:44 -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=UpPN2TOvQemTNe5TxOnwhzscIa0Y20aedL+nAL3Q/Xc=; b=TNPoUuswr/ofsdeH2pJCHP9519T+/Kj4YS6/KhCm5c/FLRcSjapZVkRGMky3yrLNcX d020NA7NR/uPQ3qdfKegZNJhFhHotjX8fNZCbFNkaIeTWTs/isAtYt3BolaL3MigLr37 6SpE7fpnSAbimjCiEsrLA7l2BFRFOcUokKF4XW6Q4HJCFQJljJwEks4/VnSKLJxV7hOK EJyrD4/2v4TOYNBiHV9cUX+otAe4rzuyhsYDvM/NV6i0WIs5Maz4xkYzq8YqkMaR1xbY z8m89ERvpbahe9Yp/9nok8un3peIud0ymagYIhcWqGAxWJb+2pywBDyCn3WoxhWISt4N nOnQ== MIME-Version: 1.0 X-Received: by 10.180.76.133 with SMTP id k5mr18868779wiw.30.1421728664026; Mon, 19 Jan 2015 20:37:44 -0800 (PST) Received: by 10.27.204.198 with HTTP; Mon, 19 Jan 2015 20:37:43 -0800 (PST) In-Reply-To: <04FE226F-8FF8-4D4F-B41F-EA6DC42744D1@eudaemon.net> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <54BA9524.2050901@isdg.net> <04FE226F-8FF8-4D4F-B41F-EA6DC42744D1@eudaemon.net> Date: Mon, 19 Jan 2015 20:37:43 -0800 Message-ID: From: "Murray S. Kucherawy" To: Tim Draegen Content-Type: multipart/alternative; boundary=f46d0435c014fc84e4050d0dff2f Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett , Hector Santos Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 04:37:47 -0000 --f46d0435c014fc84e4050d0dff2f Content-Type: text/plain; charset=UTF-8 On Mon, Jan 19, 2015 at 6:43 AM, Tim Draegen wrote: > DMARC implementations are already in the wild and deployed. Input to the > existing specification will be largely based on working implementations. > You might have your own reasons for waiting for this WG to review the DMARC > base draft, but if you want to provide input based on operational & > implementation experience, it's probably best to not wait. Indeed, -12 represents what's been deployed, and that was always the intent of this ISE submission. One could thus conclude that it is solid enough for everyone that has already deployed it, and that's not exactly a small or obscure list. Still, as has been said before: If there's more work to be done on this document, the working group is chartered to generate a Standards Track version using this document as a starting point once its other deliverables have been completed. We can record issues we'd like to see addressed in the tracker if there are some, and, if and when the WG gets there, we'll be off to the races. -MSK --f46d0435c014fc84e4050d0dff2f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 19, 2015 at 6:43 AM, Tim Draegen <tim@eudaemon= .net> wrote:=C2=A0
DMARC implementations are already in the wild and deployed.=C2=A0 Input to = the existing specification will be largely based on working implementations= .=C2=A0 You might have your own reasons for waiting for this WG to review t= he DMARC base draft, but if you want to provide input based on operational = & implementation experience, it's probably best to not wait.

Indeed, -12 represents what's been deployed, = and that was always the intent of this ISE submission.=C2=A0 One could thus= conclude that it is solid enough for everyone that has already deployed it= , and that's not exactly a small or obscure list.

Sti= ll, as has been said before: If there's more work to be done on this do= cument, the working group is chartered to generate a Standards Track versio= n using this document as a starting point once its other deliverables have = been completed.=C2=A0 We can record issues we'd like to see addressed i= n the tracker if there are some, and, if and when the WG gets there, we'= ;ll be off to the races.

-MSK
=
--f46d0435c014fc84e4050d0dff2f-- From nobody Mon Jan 19 20:52:14 2015 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 308981ACF18 for ; Mon, 19 Jan 2015 20:52:13 -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 gu_6K4vojWrg for ; Mon, 19 Jan 2015 20:52:11 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F7E1ACEEF for ; Mon, 19 Jan 2015 20:52:11 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u56so34909775wes.2 for ; Mon, 19 Jan 2015 20:52:10 -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=uAeAcfkibmH3hwbyHfbZq3Fg4WiK2N9WWyW91PckAcY=; b=KgCKl60GXWrII9CLtwAmqNFHCkUhhExJ7t0TEJwF2VA1vpVBnLXa4ipWK+msQMt7jI nvsV1/SMmYCJerx+yyO3aKdSWkcphiZ2ciFe2pWsSEYq0lLd0t67BqSfG6Gohcg2b8cm cq4chPXD75OTOsaQRPdn/CGPiRhUXxspm76dwFzM7dLK/el1+YOabxq7z/RnN2l0Azvn X93AFyW02uztSnWktccEhmWm0twXjbbSLPi+7RKsJDVvlDN6iMCBhT7Acg0OXe10z9FR W97e7IGVpud/1dnE45KjL8LiJi5bDhlitF8sPBy8AdbqBPZnJpLfR9om2smybCx5ePxn MXAA== MIME-Version: 1.0 X-Received: by 10.180.189.161 with SMTP id gj1mr8688724wic.61.1421729530438; Mon, 19 Jan 2015 20:52:10 -0800 (PST) Received: by 10.27.204.198 with HTTP; Mon, 19 Jan 2015 20:52:10 -0800 (PST) In-Reply-To: <3DEE5D4C-D33B-4190-BDEA-7E8DF240D305@eudaemon.net> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <3DEE5D4C-D33B-4190-BDEA-7E8DF240D305@eudaemon.net> Date: Mon, 19 Jan 2015 20:52:10 -0800 Message-ID: From: "Murray S. Kucherawy" To: Tim Draegen Content-Type: multipart/alternative; boundary=001a11c23ee4a0ec78050d0e3309 Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 04:52:13 -0000 --001a11c23ee4a0ec78050d0e3309 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jan 19, 2015 at 6:30 AM, Tim Draegen wrote: > No objection =E2=80=94 please do use the WG=E2=80=99s tracker for these i= tems. Anne=E2=80=99s > thorough review will be picked up (and not rediscovered!) if we=E2=80=99v= e got an > obvious place to start from. > Done for Anne's points, and I'll do so for Jim Fenton's remaining ones as well. -MSK --001a11c23ee4a0ec78050d0e3309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 19, 2015 at 6:30 AM, Tim Draegen <tim@eudaemon= .net> wrote:
No objection =E2=80=94 please do us= e the WG=E2=80=99s tracker for these items.=C2=A0 Anne=E2=80=99s thorough r= eview will be picked up (and not rediscovered!) if we=E2=80=99ve got an obv= ious place to start from.

Done for Anne's points, and I&= #39;ll do so for Jim Fenton's remaining ones as well.

-MSK
--001a11c23ee4a0ec78050d0e3309-- From nobody Mon Jan 19 20:59:00 2015 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 B8EDC1ACEEF for ; Mon, 19 Jan 2015 20:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 8Dn6wlVMDY_b for ; Mon, 19 Jan 2015 20:48:28 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115AD1ACE6D for ; Mon, 19 Jan 2015 20:48:27 -0800 (PST) Received: from localhost ([::1]:57073 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDQjr-0004Gy-AA; Mon, 19 Jan 2015 20:48:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dmarc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: superuser@gmail.com X-Trac-Project: dmarc Date: Tue, 20 Jan 2015 04:48:27 -0000 X-URL: http://tools.ietf.org/dmarc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dmarc/trac/ticket/1 Message-ID: <059.ddf5b0214c75fac7df38165e0d3336dd@tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: superuser@gmail.com, dmarc@ietf.org X-SA-Exim-Mail-From: trac+dmarc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Mon, 19 Jan 2015 20:58:57 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] [dmarc] #1 (): SPF RFC 4408 vs 7208 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 04:48:30 -0000 #1: SPF RFC 4408 vs 7208 To: dmarc@ietf.org From: Anne Bennett Date: Fri, 16 Jan 2015 19:10:56 -0500 Subject: [dmarc-ietf] SPF RFC 4408 vs 7208 On Jan 6, Murray S. Kucherawy confirmed fixing the reference for the SPF RFC from the now-obsolete 4408 to 7208 ("Fixed in -11"). However, -12 still has, in section "3.1. Identifier Alignment": For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] authenticates either the domain that appears in the RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom is null (in the case of Delivery Status Notifications). Actually, RFC 7208 states that: Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence if both are checked. ... and implies that if the first check passes, the second is unnecessary: If a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided. So the RFC5321.EHLO/HELO domain is checked not only if the RFC5321.MailFrom is null - in fact in cases where sites have followed the RFC 7208 recommendation, it will be checked first, at least by a "pure SPF" implementation. This means, first of all, that the -12 text above needs fixing. But also, I'm struggling with what it means for alignment. I can think of some real-life cases where only one of HELO or MAIL FROM aligns with RFC5322.From, even though both would "pass" in a pure SPF check. IMHO, Section "3.1.2. SPF-authenticated Identifiers" needs to be clarified to better take HELO into account. I'd like to see an approach similar to that for DKIM, where it is explicitly stated that: a single email can contain multiple DKIM signatures, and it is considered to be a DMARC "pass" if any DKIM signature is aligned and verifies. Similarly, I think that for SPF, it should be considered a pass if either the MAIL FROM or the HELO is aligned and results in a pass at the SPF level. But whether it is decided to take into account both HELO and MAIL FROM, or whether it is decided to ignore HELO (modulo its use to construct an artificial MAIL FROM if the latter is null), the text should IMHO make this clear one way or another, both in "3.1.2. SPF-authenticated Identifiers": In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce identifier alignment. ... and in "4.1. Authentication Mechanisms": o [SPF], which authenticates the domain found in an [SMTP] MAIL command when it is the authorized domain. In both cases, the text should specifically mention HELO, and whether to include or exclude a HELO SPF result, in view of HELO's prominence in RFC 7208. If it is decided to allow both HELO and MAIL FROM results to be passed back to DMARC, then in section "6.6.2. Determine Handling Policy", item 4 should be updated to reflect that as well. -- -------------------------+------------------------------------------------- Reporter: | Owner: superuser@gmail.com | Status: new Type: defect | Milestone: Deliverable #3 (changes to DMARC Priority: major | base spec + DMARC Usage Guide Version: | Severity: - Keywords: | -------------------------+------------------------------------------------- Ticket URL: dmarc From nobody Mon Jan 19 20:59:02 2015 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 470211ACF58 for ; Mon, 19 Jan 2015 20:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 FZTi7n9-dobS for ; Mon, 19 Jan 2015 20:49:48 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22311ACF56 for ; Mon, 19 Jan 2015 20:49:48 -0800 (PST) Received: from localhost ([::1]:57102 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDQlA-00071u-Hz; Mon, 19 Jan 2015 20:49:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dmarc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: superuser@gmail.com X-Trac-Project: dmarc Date: Tue, 20 Jan 2015 04:49:48 -0000 X-URL: http://tools.ietf.org/dmarc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dmarc/trac/ticket/2 Message-ID: <059.4dd22a518ac1213662fc55a4400d3000@tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: superuser@gmail.com, dmarc@ietf.org X-SA-Exim-Mail-From: trac+dmarc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Mon, 19 Jan 2015 20:58:57 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] [dmarc] #2 (): Flow of operations text in dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 04:49:50 -0000 #2: Flow of operations text in dmarc-base To: dmarc@ietf.org From: Anne Bennett Date: Fri, 16 Jan 2015 19:26:41 -0500 Subject: [dmarc-ietf] Flow of operations text in -12 In draft 12, Section "4.3 Flow Diagram", we have text which I think is somewhat contradicted by text in the later and more detailed "6.6. Mail Receiver Actions", in particular with respect to parallelizing some of the checks, and there's another small problem with the text as well. Quoting 4.3: 6. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain's DNS data (when identifiers are aligned; see below). ... but the "Author Domain" (based on RFC5322.From) is not necessarily the domain that will be queried by SPF and DKIM checks, and we won't know if identifiers are aligned until we look at the results of: 7. The results of these are passed to the DMARC module along with the Author's domain. The DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.) "6.6.2" shows clearly that the SPF check (with its DNS queries), the DKIM checks (with its DNS queries), and the DMARC policy determination (with its DNS queries) can be done in parallel, and their results combined when all have arrived, and I imagine that will turn out to be the best way to do it. So 4.2 could perhaps be modified: 6. Recipient delivery service conducts SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to DNS data. The results of these checks are passed back to the DMARC module. 7. Meanwhile, the DMARC module attempts to retrieve a policy from the DNS for that domain. If none is found, the DMARC module determines the Organizational Domain and repeats the attempt to retrieve a policy from the DNS. (This is described in further detail in Section 6.6.3.) -- -------------------------+------------------------------------------------- Reporter: | Owner: superuser@gmail.com | Status: new Type: defect | Milestone: Deliverable #3 (changes to DMARC Priority: major | base spec + DMARC Usage Guide Version: | Severity: - Keywords: | -------------------------+------------------------------------------------- Ticket URL: dmarc From nobody Mon Jan 19 20:59:03 2015 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 723FA1ACF58 for ; Mon, 19 Jan 2015 20:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 eWnKKhyfZc_L for ; Mon, 19 Jan 2015 20:51:18 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5401ACF5A for ; Mon, 19 Jan 2015 20:51:17 -0800 (PST) Received: from localhost ([::1]:57175 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDQmb-0001iZ-Ep; Mon, 19 Jan 2015 20:51:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dmarc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: superuser@gmail.com X-Trac-Project: dmarc Date: Tue, 20 Jan 2015 04:51:17 -0000 X-URL: http://tools.ietf.org/dmarc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dmarc/trac/ticket/3 Message-ID: <059.05a81ea47247abada21539474281ac22@tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: superuser@gmail.com, dmarc@ietf.org X-SA-Exim-Mail-From: trac+dmarc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Mon, 19 Jan 2015 20:58:57 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] [dmarc] #3 (): Two tiny nits X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 04:51:19 -0000 #3: Two tiny nits To: dmarc@ietf.org From: Anne Bennett Date: Fri, 16 Jan 2015 19:41:29 -0500 Subject: [dmarc-ietf] ... and two more tiny nits, while I'm at it Having just spent several hours poring over this document (-12), I might as well send my additional minor observations. I suspect that some of you will consider these items trivial, but they gave me pause as I went back and forth through several sections of the text to make sure I understood correctly. So... In "6.6.2. Determine Handling Policy", items 3 and 4, it would be helpful to make it clear whether only "passed" checks are passed back from SPF and DKIM to DMARC modules, or only "pass/fail", or all results including temporary errors. In "6.6.3 Policy discovery", item 3, I think you mean that the OD must be looked up if AND ONLY IF the set is now empty. Otherwise, one does run the risk of ending up with several records, which item 5 implies is erroneous. -- -------------------------+------------------------------------------------- Reporter: | Owner: superuser@gmail.com | Status: new Type: defect | Milestone: Deliverable #3 (changes to DMARC Priority: major | base spec + DMARC Usage Guide Version: | Severity: - Keywords: | -------------------------+------------------------------------------------- Ticket URL: dmarc From nobody Mon Jan 19 20:59:05 2015 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 96D5B1ACE6D for ; Mon, 19 Jan 2015 20:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 RjCUG43BLngh for ; Mon, 19 Jan 2015 20:55:25 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74FEA1A909C for ; Mon, 19 Jan 2015 20:55:25 -0800 (PST) Received: from localhost ([::1]:57309 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDQqa-0002VM-Tk; Mon, 19 Jan 2015 20:55:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dmarc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: superuser@gmail.com X-Trac-Project: dmarc Date: Tue, 20 Jan 2015 04:55:24 -0000 X-URL: http://tools.ietf.org/dmarc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dmarc/trac/ticket/4 Message-ID: <059.7abf789cf716e5a5f6cd8d58dbcc07ab@tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: superuser@gmail.com, dmarc@ietf.org X-SA-Exim-Mail-From: trac+dmarc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Mon, 19 Jan 2015 20:58:57 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] [dmarc] #4 (): Definition of "fo" parameter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 04:55:26 -0000 #4: Definition of "fo" parameter Message-ID: <54AB056C.2090101@bluepopcorn.net> Date: Mon, 05 Jan 2015 13:43:08 -0800 From: Jim Fenton To: "dmarc@ietf.org" Subject: [dmarc-ietf] Comments on dmarc-base-09 [...] Section 5.3, definition of fo: parameter: I had reported that there isn't any prohibition on specifying both 0 and 1, and I thought someone said that was fixed but I can't find it. More generally, I struggle to find any real utility for a colon-separated list of options here. [...] -- -------------------------+------------------------------------------------- Reporter: | Owner: superuser@gmail.com | Status: new Type: defect | Milestone: Deliverable #3 (changes to DMARC Priority: major | base spec + DMARC Usage Guide Version: | Severity: - Keywords: | -------------------------+------------------------------------------------- Ticket URL: dmarc From nobody Mon Jan 19 20:59:06 2015 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 0A2181ACF58 for ; Mon, 19 Jan 2015 20:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 0au7XG6KyKSW for ; Mon, 19 Jan 2015 20:56:30 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEAE11ACF60 for ; Mon, 19 Jan 2015 20:56:29 -0800 (PST) Received: from localhost ([::1]:57353 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDQrd-0002hT-L5; Mon, 19 Jan 2015 20:56:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dmarc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: superuser@gmail.com X-Trac-Project: dmarc Date: Tue, 20 Jan 2015 04:56:29 -0000 X-URL: http://tools.ietf.org/dmarc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dmarc/trac/ticket/5 Message-ID: <059.792e6f445bd9d990e5f1739d829d3611@tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: superuser@gmail.com, dmarc@ietf.org X-SA-Exim-Mail-From: trac+dmarc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Mon, 19 Jan 2015 20:58:57 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] [dmarc] #5 (): Definition of "pct" parameter X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 04:56:32 -0000 #5: Definition of "pct" parameter Message-ID: <54AB056C.2090101@bluepopcorn.net> Date: Mon, 05 Jan 2015 13:43:08 -0800 From: Jim Fenton To: "dmarc@ietf.org" Subject: [dmarc-ietf] Comments on dmarc-base-09 [...] Section 5.3, definition of pct: parameter: "However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered." This is strong normative language, but there is no procedure specified anywhere for how to identify a DMARC-generated report in order to apply this requirement. Consider the possibility that bad actors may try to craft messages to look like DMARC reports. [...] -- -------------------------+------------------------------------------------- Reporter: | Owner: superuser@gmail.com | Status: new Type: defect | Milestone: Deliverable #3 (changes to DMARC Priority: major | base spec + DMARC Usage Guide Version: | Severity: - Keywords: | -------------------------+------------------------------------------------- Ticket URL: dmarc From nobody Mon Jan 19 20:59:07 2015 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 430751ACF58 for ; Mon, 19 Jan 2015 20:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 u6oTs_G06HuY for ; Mon, 19 Jan 2015 20:57:40 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DD631A909C for ; Mon, 19 Jan 2015 20:57:40 -0800 (PST) Received: from localhost ([::1]:57384 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YDQsl-0002s6-SC; Mon, 19 Jan 2015 20:57:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dmarc issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: superuser@gmail.com X-Trac-Project: dmarc Date: Tue, 20 Jan 2015 04:57:39 -0000 X-URL: http://tools.ietf.org/dmarc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dmarc/trac/ticket/6 Message-ID: <059.9152b8457eff65296fde90daa7e684a7@tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: superuser@gmail.com, dmarc@ietf.org X-SA-Exim-Mail-From: trac+dmarc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Mon, 19 Jan 2015 20:58:57 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] [dmarc] #6 (): Fuzzy normative language around filenames X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2015 04:57:41 -0000 #6: Fuzzy normative language around filenames Message-ID: <54AB056C.2090101@bluepopcorn.net> Date: Mon, 05 Jan 2015 13:43:08 -0800 From: Jim Fenton To: "dmarc@ietf.org" Subject: [dmarc-ietf] Comments on dmarc-base-09 [...] Section 6.2.1.1, "The filename is typically constructed..." Again, this is fuzzy normative language; it sounds like it's trying to say, "The filename MAY be constructed..." [...] -- -------------------------+------------------------------------------------- Reporter: | Owner: superuser@gmail.com | Status: new Type: defect | Milestone: Deliverable #3 (changes to DMARC Priority: major | base spec + DMARC Usage Guide Version: | Severity: - Keywords: | -------------------------+------------------------------------------------- Ticket URL: dmarc From nobody Tue Jan 20 12:22:45 2015 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 193081B2B69 for ; Tue, 20 Jan 2015 12:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 N9CvEn-wAnqr for ; Tue, 20 Jan 2015 12:22:40 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9CC1B2B68 for ; Tue, 20 Jan 2015 12:22:39 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 6EB4F563C4C for ; Tue, 20 Jan 2015 14:22:39 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5662DA027F for ; Tue, 20 Jan 2015 14:22:39 -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 H2cVs7tgTq2y for ; Tue, 20 Jan 2015 14:22:39 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 128B5A02A9 for ; Tue, 20 Jan 2015 14:22:39 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 128B5A02A9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421785359; bh=GGjLSwBDayRrXw94AuUhj1dGJSnol9fXRzPpjjPyQSY=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=gkQYUBjSZ29KAf4Medz3FhsXnf0Icnbta4OS+Uv+pkxQ5PV5a/pVCjyN717ojBY8Y 6ztfYQRyDTyl0jEUHDBueSBp2Ko++eYxFJ+2/AFN+Pz6Rjj1tQYgxdiCcpaVuZrQQi wcAEG92ttnvqsFUUbgWtjHYXLbPM4tNjaan9h1yc= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id EEF12A028F for ; Tue, 20 Jan 2015 14:22:38 -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 GpYAkOeVZd08 for ; Tue, 20 Jan 2015 14:22:38 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id CD0E5A027F for ; Tue, 20 Jan 2015 14:22:38 -0600 (CST) Date: Tue, 20 Jan 2015 14:22:38 -0600 (CST) From: Franck Martin To: dmarc Message-ID: <1544808300.42070.1421785358575.JavaMail.zimbra@peachymango.org> In-Reply-To: <188571312.41640.1421784230252.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-dmarc-interoperability-00.txt Thread-Index: lGgF29jLK4UomIaM8cm1FY8P9AI0zw== Archived-At: Subject: [dmarc-ietf] New Version Notification for draft-dmarc-interoperability-00.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: Tue, 20 Jan 2015 20:22:42 -0000 FYI I'm still a bit new on the IETF processes, so apologies if I stepped outside normal tracks... --------------------- A new version of I-D, draft-dmarc-interoperability-00.txt has been successfully submitted by Franck Martin and posted to the IETF repository. Name: draft-dmarc-interoperability Revision: 00 Title: Interoperability Issues Between DMARC and Indirect Email Flows Document date: 2015-01-19 Group: Individual Submission Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-dmarc-interoperability-00.txt Status: https://datatracker.ietf.org/doc/draft-dmarc-interoperability/ Htmlized: http://tools.ietf.org/html/draft-dmarc-interoperability-00 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages originate from third party sources, are modified in transit, or are forwarded enroute to their final destination. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. From nobody Tue Jan 20 13:44:23 2015 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 027941A0026 for ; Tue, 20 Jan 2015 13:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 iOTlZ_aEzD6y for ; Tue, 20 Jan 2015 13:44:18 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 33BC41A0022 for ; Tue, 20 Jan 2015 13:44:18 -0800 (PST) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0KLiG0c009930 for ; Tue, 20 Jan 2015 16:44:16 -0500 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0KLiGEg009330 for ; Tue, 20 Jan 2015 16:44:16 -0500 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: DMARC list In-reply-to: Your message of Fri, 16 Jan 2015 20:08:36 PST References: <6716.1421455289@vindemiatrix.encs.concordia.ca> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Tue, 20 Jan 2015 16:44:16 -0500 Message-ID: <9329.1421790256@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-20 16:44:16 EST Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 21:44:21 -0000 Hi, Murray. MK> I think all of the points in your three messages are good input for a more MK> solid specification, but the timing is unfortunate as we just got MK> publication approval for -12 a week ago. I apologize for my inadvertently poor timing; I was catapulted into all this last week when my parent domain (also my Organizational Domain) published an SPF record and a DKIM record, and we became concerned that they might implement DMARC, which could have a very negative impact on our mail services unless we take action quickly and become prepared to publish our own DMARC record. Thus, my sudden plunge into all these RFCs and this draft. :-/ MK> Making more changes post-approval MK> would probably not be a good idea, and by my reading none of them rise to MK> the level of being urgent to correct. That's certainly not my call to make; I can only give you a point of view from a fairly small site (about 10K users), where we're not looking to implement any of these mechanisms from scratch (we'll use software someone else wrote, mostly), but we *do* need to understand the implications of our (or our OD's) publishing DNS records for SPF, DKIM, and/or DMARC. Since, as pointed out by Tim Draegen, "DMARC implementations are already in the wild and deployed", one would expect to be able to determine what those implementations do, based on this spec. Sadly this hasn't been possible (so far) for me and my colleague Michael Jack Assels, despite our being two fairly smart cookies, with nearly a half-century of e-mail experience between us. I want to emphasize that I think that the documents in question (at least this draft and RFC7208 - I've barely skimmed RFC6376 on DKIM yet) individually are well written, but trying to understand them in context together is proving to be quite a challenge, and the lack of clarity on the HELO issue is the biggest part of the problem. We're now resorting to running tests to see how the biggest gorilla in this jungle (Google) handles all this. We've just completed an initial set of tests with SPF records only (no DMARC), which show that Google uses the MAIL FROM identity but seems to ignore the HELO identity even in the absence of DMARC, much to our surprise given RFC7208. We haven't yet run our with-DMARC tests, though I suspect that if Google doesn't look at HELO in a "pure SPF" environment, it probably won't use it in the context of DMARC either. If indeed it is the case that (at least in the context of DMARC) the HELO identity is not normally used, I would hope that introducing a small clarification to that effect could be done without significantly impeding the progress of this draft towards publication. Mind you, I don't know that the publication constraints are, so perhaps my hope is utterly in vain! But on the off-chance that it's not impossible to clarify this now, and assuming that my growing suspicion that HELO is ignored is correct, then I would propose: In section "3.1. Identifier Alignment": < For example, [DKIM] authenticates the domain that affixed a < signature to the message, while [SPF] authenticates either < the domain that appears in the RFC5321.MailFrom portion of < [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom < is null (in the case of Delivery Status Notifications). > For example, [DKIM] authenticates the domain that affixed a > signature to the message, while [SPF] can authenticate either > the domain that appears in the RFC5321.MailFrom portion of > [SMTP], or the RFC5321.EHLO/HELO domain, or both. In section "3.1.2. SPF-authenticated Identifiers": < In relaxed mode, the [SPF]-authenticated domain and < RFC5322.From domain must have the same Organizational Domain. < In strict mode, only an exact DNS domain match is considered < to produce identifier alignment. > In relaxed mode, the [SPF]-authenticated domain and > RFC5322.From domain must have the same Organizational Domain. > In strict mode, only an exact DNS domain match is considered > to produce identifier alignment. > > Note that the HELO identity is not used in the context of > DMARC (except when required to "fake" an otherwise null > reverse-path), even though a "pure SPF" implementation > according to [SPF] would check the HELO domain. In "4.1. Authentication Mechanisms": < o [SPF], which authenticates the domain found in an < [SMTP] MAIL command when it is the authorized domain. > o [SPF], which authenticates the domain found in an > [SMTP] MAIL command, or the domain found in the > [SMTP] HELO/EHLO command if the MAIL command has > a null path. Note that in contradiction to [SPF], > in the context of DMARC, the HELO identity is not > checked (except in the case of a null path). Even if it turns out to be impossible to make the above changes before publication, I'd be grateful to the people on this list for confirming (or disconfirming!) my understanding that HELO is not used in the context of DMARC (modulo the null path case). Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Tue Jan 20 14:14:38 2015 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 A348C1A003B for ; Tue, 20 Jan 2015 14:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 hZef6fagvmlT for ; Tue, 20 Jan 2015 14:14:33 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2A1A0006 for ; Tue, 20 Jan 2015 14:14:33 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id D5C7F563D58; Tue, 20 Jan 2015 16:14:32 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id CEB9E601DE; Tue, 20 Jan 2015 16:14:32 -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 akv3tPoNOdLJ; Tue, 20 Jan 2015 16:14:32 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A39A6601E8; Tue, 20 Jan 2015 16:14:32 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com A39A6601E8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421792072; bh=+pOsmgiWFYid8lXVkViLkGHWbfndT1jJFaNuNiBDeQw=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=a+bEJaAq7I161e4JZWeatTkhxaFwgGqzvlcfBO0/AemvqLsr5GO7f/HPLnSS6mhzD 5pG5acw5kqMG60zV6fhH56W7B7WgtFGoGgJ6g9OBi38FMUUQSin50f6MGdHzW4e+Hr NHLP2dAj8lzwTyOn6DsCCs/R2cx5A5M5ysCis0Qs= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 8B692601DE; Tue, 20 Jan 2015 16:14:32 -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 oSkwD9sQY8N2; Tue, 20 Jan 2015 16:14:32 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 6DD17601B6; Tue, 20 Jan 2015 16:14:32 -0600 (CST) Date: Tue, 20 Jan 2015 16:14:32 -0600 (CST) From: Franck Martin To: Anne Bennett Message-ID: <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <9329.1421790256@vindemiatrix.encs.concordia.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: ... and two more tiny nits, while I'm at it Thread-Index: 1wF75BofdqLK1pbX6z0s/qI2XUq1zA== Archived-At: Cc: DMARC list Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 22:14:35 -0000 ----- Original Message ----- > From: "Anne Bennett" > To: "DMARC list" > Sent: Tuesday, January 20, 2015 1:44:16 PM > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > Hi, Murray. > > MK> I think all of the points in your three messages are good input for a > more > MK> solid specification, but the timing is unfortunate as we just got > MK> publication approval for -12 a week ago. > > I apologize for my inadvertently poor timing; I was catapulted > into all this last week when my parent domain (also my > Organizational Domain) published an SPF record and a DKIM > record, and we became concerned that they might implement DMARC, > which could have a very negative impact on our mail services > unless we take action quickly and become prepared to publish > our own DMARC record. Thus, my sudden plunge into all these > RFCs and this draft. :-/ > > MK> Making more changes post-approval > MK> would probably not be a good idea, and by my reading none of them rise to > MK> the level of being urgent to correct. > > That's certainly not my call to make; I can only give you > a point of view from a fairly small site (about 10K users), > where we're not looking to implement any of these mechanisms > from scratch (we'll use software someone else wrote, mostly), > but we *do* need to understand the implications of our (or > our OD's) publishing DNS records for SPF, DKIM, and/or DMARC. > > Since, as pointed out by Tim Draegen, "DMARC implementations are > already in the wild and deployed", one would expect to be able > to determine what those implementations do, based on this spec. > Sadly this hasn't been possible (so far) for me and my colleague > Michael Jack Assels, despite our being two fairly smart cookies, > with nearly a half-century of e-mail experience between us. > > I want to emphasize that I think that the documents in question > (at least this draft and RFC7208 - I've barely skimmed RFC6376 > on DKIM yet) individually are well written, but trying to > understand them in context together is proving to be quite > a challenge, and the lack of clarity on the HELO issue is > the biggest part of the problem. > > > We're now resorting to running tests to see how the biggest > gorilla in this jungle (Google) handles all this. We've just > completed an initial set of tests with SPF records only (no > DMARC), which show that Google uses the MAIL FROM identity but > seems to ignore the HELO identity even in the absence of DMARC, > much to our surprise given RFC7208. > > We haven't yet run our with-DMARC tests, though I suspect that > if Google doesn't look at HELO in a "pure SPF" environment, it > probably won't use it in the context of DMARC either. > > > If indeed it is the case that (at least in the context of > DMARC) the HELO identity is not normally used, I would hope > that introducing a small clarification to that effect could > be done without significantly impeding the progress of this > draft towards publication. Mind you, I don't know that the > publication constraints are, so perhaps my hope is utterly > in vain! > > But on the off-chance that it's not impossible to clarify > this now, and assuming that my growing suspicion that HELO is > ignored is correct, then I would propose: > Your confusion on HELO is may be related to the fact that the HELO string is only used when the MAIL-FROM: is empty? There is some text here: http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 The HELO string is not evaluated all the time, it is more like a fall back. Also I have trouble to understand why you may be affected by your OD? What is the relation between your domain and your OD? I suspect this is concordia.ca? If you look at the public suffix list, google has put a separation at blogspot.com level, so that each hosting domain, can be organizationally separated. https://publicsuffix.org/list/effective_tld_names.dat I would suggest you publish a DMARC record in monitoring mode (p=none) so that you get reports (and no impact) and better understand your email infrastructure and what needs to be done. From nobody Tue Jan 20 14:29:19 2015 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 3F8721A005E for ; Tue, 20 Jan 2015 14:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 4rzDQnPD7ywB for ; Tue, 20 Jan 2015 14:29:12 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95D101A0053 for ; Tue, 20 Jan 2015 14:29:12 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 92718C40265; Tue, 20 Jan 2015 16:31:44 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421793104; bh=8qT+fE0MVV7Z/ODq9t/70ia74SHeJy6o+Gf6A8gpSs0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LYV/y4MG6t+Db2GeF+qAdkjbEREi50fXlNLG0bfH4xbMvDCPlPEKGUq0adYoMJ1Rb Zv9MYZAEJ7ZajsbEsYnSO/ct0BhLqWPuC0hBEJeLV51tT6O6Z//oS0pF0N6Dg3Ut99 FwfvzXe27ly9Ukx8miQ469OnQPRDhe+RETqu/7VQ= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 20 Jan 2015 17:29:10 -0500 Message-ID: <1997519.eG4sQ0KdZQ@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 22:29:16 -0000 On Tuesday, January 20, 2015 16:14:32 Franck Martin wrote: > ----- Original Message ----- > > > From: "Anne Bennett" > > To: "DMARC list" > > Sent: Tuesday, January 20, 2015 1:44:16 PM > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > > > > Hi, Murray. > > > > MK> I think all of the points in your three messages are good input for a > > more > > MK> solid specification, but the timing is unfortunate as we just got > > MK> publication approval for -12 a week ago. > > > > I apologize for my inadvertently poor timing; I was catapulted > > into all this last week when my parent domain (also my > > Organizational Domain) published an SPF record and a DKIM > > record, and we became concerned that they might implement DMARC, > > which could have a very negative impact on our mail services > > unless we take action quickly and become prepared to publish > > our own DMARC record. Thus, my sudden plunge into all these > > RFCs and this draft. :-/ > > > > MK> Making more changes post-approval > > MK> would probably not be a good idea, and by my reading none of them rise > > to MK> the level of being urgent to correct. > > > > That's certainly not my call to make; I can only give you > > a point of view from a fairly small site (about 10K users), > > where we're not looking to implement any of these mechanisms > > from scratch (we'll use software someone else wrote, mostly), > > but we *do* need to understand the implications of our (or > > our OD's) publishing DNS records for SPF, DKIM, and/or DMARC. > > > > Since, as pointed out by Tim Draegen, "DMARC implementations are > > already in the wild and deployed", one would expect to be able > > to determine what those implementations do, based on this spec. > > Sadly this hasn't been possible (so far) for me and my colleague > > Michael Jack Assels, despite our being two fairly smart cookies, > > with nearly a half-century of e-mail experience between us. > > > > I want to emphasize that I think that the documents in question > > (at least this draft and RFC7208 - I've barely skimmed RFC6376 > > on DKIM yet) individually are well written, but trying to > > understand them in context together is proving to be quite > > a challenge, and the lack of clarity on the HELO issue is > > the biggest part of the problem. > > > > > > We're now resorting to running tests to see how the biggest > > gorilla in this jungle (Google) handles all this. We've just > > completed an initial set of tests with SPF records only (no > > DMARC), which show that Google uses the MAIL FROM identity but > > seems to ignore the HELO identity even in the absence of DMARC, > > much to our surprise given RFC7208. > > > > We haven't yet run our with-DMARC tests, though I suspect that > > if Google doesn't look at HELO in a "pure SPF" environment, it > > probably won't use it in the context of DMARC either. > > > > > > If indeed it is the case that (at least in the context of > > DMARC) the HELO identity is not normally used, I would hope > > that introducing a small clarification to that effect could > > be done without significantly impeding the progress of this > > draft towards publication. Mind you, I don't know that the > > publication constraints are, so perhaps my hope is utterly > > in vain! > > > > But on the off-chance that it's not impossible to clarify > > this now, and assuming that my growing suspicion that HELO is > > > ignored is correct, then I would propose: > Your confusion on HELO is may be related to the fact that the HELO string is > only used when the MAIL-FROM: is empty? The confusion is that many people think that HELO is only used when Mail From is empty. It's been recommended as a stand alone test in both RFC 4408 and that's not changed in RFC 7208. It's just more obvious now. You do use postmaster@$HELO when Mail From is empty, which is relevant to DMARC use of SPF results. You can also use HELO on it's own, which is not. SPF pass on the HELO identity isn't useful as an accept criteria. SPF fail on the HELO identity can, however, be useful as a reject criteria. Scott K From nobody Tue Jan 20 14:34:33 2015 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 4DFAA1A005C for ; Tue, 20 Jan 2015 14:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-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 FENOBDlfpusk for ; Tue, 20 Jan 2015 14:34:30 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 070161A0056 for ; Tue, 20 Jan 2015 14:34:30 -0800 (PST) Received: from grover.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id A14BC811C0; Tue, 20 Jan 2015 14:34:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1421793269; bh=t6oztzUNdJDl2K74iO0Pa9ROwrdBPertz+/yiPkhyLU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=gfO0H4E3/eUMmyUxxS5ucJSQ+4YAPyeple7ltXJeuRKVPykfTVeFjag2G/w6MzrAd sWMmbyF1RLge3b87YLRAiu6/FLSFPunMrX+JrvAvbtLXrrsA8WbAEdudT7RRhH9hlF qB1wKHKv9VpwHpSvoXdzPSEaDBnzE4oSVz3n23yE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Laura Atkins In-Reply-To: <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> Date: Tue, 20 Jan 2015 14:34:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8D02E23B-AF11-4D01-8E3A-3CC8B0EF5B32@wordtothewise.com> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <9329.1421790256@vindemiatrix.encs.concordia.ca> <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> To: Franck Martin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: DMARC list Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 22:34:31 -0000 On Jan 20, 2015, at 2:14 PM, Franck Martin = wrote: >=20 >> But on the off-chance that it's not impossible to clarify >> this now, and assuming that my growing suspicion that HELO is >> ignored is correct, then I would propose: >>=20 >=20 > Your confusion on HELO is may be related to the fact that the HELO = string is only used when the MAIL-FROM: is empty? >=20 > There is some text here: > http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 >=20 > The HELO string is not evaluated all the time, it is more like a fall = back. 7208 actually recommends that the HELO string be evaluated every time.=20= http://trac.tools.ietf.org/html/rfc7208#section-2.3 "2.3. The "HELO" Identity It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the . Checking "HELO" promotes consistency of results and can reduce DNS resource usage." laura=20 --=20 Laura Atkins Word to the Wise "The Deliverability Experts!" Direct: 650 678-3454 Fax: 650 249-1909 @wise_laura Delivery blog: From nobody Tue Jan 20 14:38:50 2015 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 71CBB1A005C for ; Tue, 20 Jan 2015 14:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Fjic15vb6hC9 for ; Tue, 20 Jan 2015 14:38:44 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id A8A4D1A0056 for ; Tue, 20 Jan 2015 14:38:44 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 40B15563D76; Tue, 20 Jan 2015 16:38:44 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 316B2A0294; Tue, 20 Jan 2015 16:38:44 -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 mLdf4YxP69Kv; Tue, 20 Jan 2015 16:38:44 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id DF45AA03E1; Tue, 20 Jan 2015 16:38:43 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com DF45AA03E1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421793523; bh=aXqArq2RcPoPrEXTHrrBHDJd8qks+csDy0HPvuCa+jU=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=TWs3kPgSnkaW7bfeGfFbiN0SNk5dUrAv43Z0OOeDuYwdXFLncwvFsK6Mris+vpmAQ xDdO8p/jQwNi9KGue5RGQudBE2C8p0JT4TzzA/gMjXndUabeliV2RVExDjGGjYjDYJ mVjMyZUFJQfIoO9E7NPg0UiqZBsKnJB9OXAU0n58= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BFE9DA0377; Tue, 20 Jan 2015 16:38:43 -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 TTUtaCXYpb21; Tue, 20 Jan 2015 16:38:43 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id A4AD0A0294; Tue, 20 Jan 2015 16:38:43 -0600 (CST) Date: Tue, 20 Jan 2015 16:38:43 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <1295180662.46088.1421793523542.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> <1997519.eG4sQ0KdZQ@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: ... and two more tiny nits, while I'm at it Thread-Index: CVYu/4vLI3NHHbQO3aTaS8GOr56xkw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 22:38:47 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Tuesday, January 20, 2015 2:29:10 PM > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > On Tuesday, January 20, 2015 16:14:32 Franck Martin wrote: > > ----- Original Message ----- > > > > > From: "Anne Bennett" > > > To: "DMARC list" > > > Sent: Tuesday, January 20, 2015 1:44:16 PM > > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > > > > > > > Hi, Murray. > > > > > > MK> I think all of the points in your three messages are good input for a > > > more > > > MK> solid specification, but the timing is unfortunate as we just got > > > MK> publication approval for -12 a week ago. > > > > > > I apologize for my inadvertently poor timing; I was catapulted > > > into all this last week when my parent domain (also my > > > Organizational Domain) published an SPF record and a DKIM > > > record, and we became concerned that they might implement DMARC, > > > which could have a very negative impact on our mail services > > > unless we take action quickly and become prepared to publish > > > our own DMARC record. Thus, my sudden plunge into all these > > > RFCs and this draft. :-/ > > > > > > MK> Making more changes post-approval > > > MK> would probably not be a good idea, and by my reading none of them > > > rise > > > to MK> the level of being urgent to correct. > > > > > > That's certainly not my call to make; I can only give you > > > a point of view from a fairly small site (about 10K users), > > > where we're not looking to implement any of these mechanisms > > > from scratch (we'll use software someone else wrote, mostly), > > > but we *do* need to understand the implications of our (or > > > our OD's) publishing DNS records for SPF, DKIM, and/or DMARC. > > > > > > Since, as pointed out by Tim Draegen, "DMARC implementations are > > > already in the wild and deployed", one would expect to be able > > > to determine what those implementations do, based on this spec. > > > Sadly this hasn't been possible (so far) for me and my colleague > > > Michael Jack Assels, despite our being two fairly smart cookies, > > > with nearly a half-century of e-mail experience between us. > > > > > > I want to emphasize that I think that the documents in question > > > (at least this draft and RFC7208 - I've barely skimmed RFC6376 > > > on DKIM yet) individually are well written, but trying to > > > understand them in context together is proving to be quite > > > a challenge, and the lack of clarity on the HELO issue is > > > the biggest part of the problem. > > > > > > > > > We're now resorting to running tests to see how the biggest > > > gorilla in this jungle (Google) handles all this. We've just > > > completed an initial set of tests with SPF records only (no > > > DMARC), which show that Google uses the MAIL FROM identity but > > > seems to ignore the HELO identity even in the absence of DMARC, > > > much to our surprise given RFC7208. > > > > > > We haven't yet run our with-DMARC tests, though I suspect that > > > if Google doesn't look at HELO in a "pure SPF" environment, it > > > probably won't use it in the context of DMARC either. > > > > > > > > > If indeed it is the case that (at least in the context of > > > DMARC) the HELO identity is not normally used, I would hope > > > that introducing a small clarification to that effect could > > > be done without significantly impeding the progress of this > > > draft towards publication. Mind you, I don't know that the > > > publication constraints are, so perhaps my hope is utterly > > > in vain! > > > > > > But on the off-chance that it's not impossible to clarify > > > this now, and assuming that my growing suspicion that HELO is > > > > > ignored is correct, then I would propose: > > Your confusion on HELO is may be related to the fact that the HELO string > > is > > only used when the MAIL-FROM: is empty? > > The confusion is that many people think that HELO is only used when Mail From > is empty. It's been recommended as a stand alone test in both RFC 4408 and > that's not changed in RFC 7208. It's just more obvious now. > > You do use postmaster@$HELO when Mail From is empty, which is relevant to > DMARC use of SPF results. > > You can also use HELO on it's own, which is not. SPF pass on the HELO > identity isn't useful as an accept criteria. SPF fail on the HELO identity > can, however, be useful as a reject criteria. > > Yes, RFC7208 says evaluate both in parallel, but the result of an spf=pass/fail is highly constrained on the success or failure of the MAIL FROM spf test. I mean, it seems quite rare to find an SPF record on the HELO string but not one the MAIL FROM string From nobody Tue Jan 20 14:46:45 2015 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 83F091A006C for ; Tue, 20 Jan 2015 14:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 c5o9dHo_UtUL for ; Tue, 20 Jan 2015 14:46:41 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2EFF1A006D for ; Tue, 20 Jan 2015 14:46:41 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B3723C40265; Tue, 20 Jan 2015 16:49:13 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421794153; bh=lzfJZyrrs1xtbFPZueeEiOfg62n91pJbcGM/rciN0c4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=X4mV8WmkWVDh0NPG11xBqPG90+6SeWLAm77dnbxyCnzz3EwnvgjKDU1WnYB5av3/q oc9vEl7Gl8F8Ej1t4QcWdbcihggAME81GEpWn/Ejlo034fVOZtWViu1pL13Wrzin+2 9ssIKWRVImpm0gxQHPJvqxDVSFnWEBYA3sLmSlbw= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 20 Jan 2015 17:46:39 -0500 Message-ID: <4391673.47kOljF4j1@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <8D02E23B-AF11-4D01-8E3A-3CC8B0EF5B32@wordtothewise.com> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> <8D02E23B-AF11-4D01-8E3A-3CC8B0EF5B32@wordtothewise.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 22:46:43 -0000 On Tuesday, January 20, 2015 14:34:22 Laura Atkins wrote: > On Jan 20, 2015, at 2:14 PM, Franck Martin wrote: > >> But on the off-chance that it's not impossible to clarify > >> this now, and assuming that my growing suspicion that HELO is > > > >> ignored is correct, then I would propose: > > Your confusion on HELO is may be related to the fact that the HELO string > > is only used when the MAIL-FROM: is empty? > > > > There is some text here: > > http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 > > > > The HELO string is not evaluated all the time, it is more like a fall > > back. > > 7208 actually recommends that the HELO string be evaluated every time. > http://trac.tools.ietf.org/html/rfc7208#section-2.3 > > "2.3. The "HELO" Identity > > > It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" > identity but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > . Checking "HELO" promotes consistency of results and can > reduce DNS resource usage." > > laura Approximately the same text existed in RFC 4408 2.1: > It is RECOMMENDED that SPF clients not only check the "MAIL FROM" > identity, but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > . HELO results are unrelated to DMARC. Scott K From nobody Tue Jan 20 14:49:07 2015 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 0F1EE1A0065 for ; Tue, 20 Jan 2015 14:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 R2Hfn9d8qCUv for ; Tue, 20 Jan 2015 14:49:04 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBE61A005C for ; Tue, 20 Jan 2015 14:49:03 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A076EC40265; Tue, 20 Jan 2015 16:51:35 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421794295; bh=F3bie35uv1Dg9ik1HU91a/ETGbzXrf+OSb71nqgmq8Q=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Hc/LsLK45s5EfqWpXGqRYmtRb8ml5jVMqAE6NdkLfDra5Wn5aL6fG8UHUEoH4jP9p K97KebmQw519cj0iuCAgyNTrFEQY0weRhFJ6Zrkewl+5AB6vYHIE8D6uL4OC2ylOKm s9hcKszTEjJRuTE+n4PDnwZw8IuUEgDYGHzCz0hg= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 20 Jan 2015 17:49:01 -0500 Message-ID: <14221361.tb6bO3xpOi@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1295180662.46088.1421793523542.JavaMail.zimbra@peachymango.org> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <1295180662.46088.1421793523542.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 22:49:06 -0000 On Tuesday, January 20, 2015 16:38:43 Franck Martin wrote: > ----- Original Message ----- > > > From: "Scott Kitterman" > > To: dmarc@ietf.org > > Sent: Tuesday, January 20, 2015 2:29:10 PM > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > > On Tuesday, January 20, 2015 16:14:32 Franck Martin wrote: > > > ----- Original Message ----- > > > > > > > From: "Anne Bennett" > > > > To: "DMARC list" > > > > Sent: Tuesday, January 20, 2015 1:44:16 PM > > > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > > > > > > > > > > Hi, Murray. > > > > > > > > MK> I think all of the points in your three messages are good input > > > > for a > > > > more > > > > MK> solid specification, but the timing is unfortunate as we just got > > > > MK> publication approval for -12 a week ago. > > > > > > > > I apologize for my inadvertently poor timing; I was catapulted > > > > into all this last week when my parent domain (also my > > > > Organizational Domain) published an SPF record and a DKIM > > > > record, and we became concerned that they might implement DMARC, > > > > which could have a very negative impact on our mail services > > > > unless we take action quickly and become prepared to publish > > > > our own DMARC record. Thus, my sudden plunge into all these > > > > RFCs and this draft. :-/ > > > > > > > > MK> Making more changes post-approval > > > > MK> would probably not be a good idea, and by my reading none of them > > > > rise > > > > to MK> the level of being urgent to correct. > > > > > > > > That's certainly not my call to make; I can only give you > > > > a point of view from a fairly small site (about 10K users), > > > > where we're not looking to implement any of these mechanisms > > > > from scratch (we'll use software someone else wrote, mostly), > > > > but we *do* need to understand the implications of our (or > > > > our OD's) publishing DNS records for SPF, DKIM, and/or DMARC. > > > > > > > > Since, as pointed out by Tim Draegen, "DMARC implementations are > > > > already in the wild and deployed", one would expect to be able > > > > to determine what those implementations do, based on this spec. > > > > Sadly this hasn't been possible (so far) for me and my colleague > > > > Michael Jack Assels, despite our being two fairly smart cookies, > > > > with nearly a half-century of e-mail experience between us. > > > > > > > > I want to emphasize that I think that the documents in question > > > > (at least this draft and RFC7208 - I've barely skimmed RFC6376 > > > > on DKIM yet) individually are well written, but trying to > > > > understand them in context together is proving to be quite > > > > a challenge, and the lack of clarity on the HELO issue is > > > > the biggest part of the problem. > > > > > > > > > > > > We're now resorting to running tests to see how the biggest > > > > gorilla in this jungle (Google) handles all this. We've just > > > > completed an initial set of tests with SPF records only (no > > > > DMARC), which show that Google uses the MAIL FROM identity but > > > > seems to ignore the HELO identity even in the absence of DMARC, > > > > much to our surprise given RFC7208. > > > > > > > > We haven't yet run our with-DMARC tests, though I suspect that > > > > if Google doesn't look at HELO in a "pure SPF" environment, it > > > > probably won't use it in the context of DMARC either. > > > > > > > > > > > > If indeed it is the case that (at least in the context of > > > > DMARC) the HELO identity is not normally used, I would hope > > > > that introducing a small clarification to that effect could > > > > be done without significantly impeding the progress of this > > > > draft towards publication. Mind you, I don't know that the > > > > publication constraints are, so perhaps my hope is utterly > > > > in vain! > > > > > > > > But on the off-chance that it's not impossible to clarify > > > > this now, and assuming that my growing suspicion that HELO is > > > > > > > ignored is correct, then I would propose: > > > Your confusion on HELO is may be related to the fact that the HELO > > > string > > > is > > > only used when the MAIL-FROM: is empty? > > > > The confusion is that many people think that HELO is only used when Mail > > From is empty. It's been recommended as a stand alone test in both RFC > > 4408 and that's not changed in RFC 7208. It's just more obvious now. > > > > You do use postmaster@$HELO when Mail From is empty, which is relevant to > > DMARC use of SPF results. > > > > You can also use HELO on it's own, which is not. SPF pass on the HELO > > identity isn't useful as an accept criteria. SPF fail on the HELO > > identity > > can, however, be useful as a reject criteria. > > Yes, RFC7208 says evaluate both in parallel, but the result of an > spf=pass/fail is highly constrained on the success or failure of the MAIL > FROM spf test. > > I mean, it seems quite rare to find an SPF record on the HELO string but not > one the MAIL FROM string Last time I had stats, it was about 10% as common as Mail From oriented records. Much less common, but I wouldn't say rare. When done this way, there isn't a singe "SPF" result, there are two: SPF/Mail From and SPF/HELO. Only SPF/Mail From is relevant to DMARC. In the case of the message having a null Mail From, you can still get two SPF results, they will just be the same. Scott K From nobody Tue Jan 20 14:54:28 2015 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 7ECDA1A0067 for ; Tue, 20 Jan 2015 14:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 AAQacWmWVwdF for ; Tue, 20 Jan 2015 14:54:24 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 15F381A0071 for ; Tue, 20 Jan 2015 14:54:24 -0800 (PST) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0KMsMjY000969 for ; Tue, 20 Jan 2015 17:54:23 -0500 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0KMsMWA010391 for ; Tue, 20 Jan 2015 17:54:22 -0500 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Tue, 20 Jan 2015 16:38:43 CST References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> <1997519.eG4sQ0KdZQ@scott-latitude-e6320> <1295180662.46088.1421793523542.JavaMail.zimbra@peachymango.org> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Tue, 20 Jan 2015 17:54:22 -0500 Message-ID: <10390.1421794462@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-20 17:54:23 EST Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 22:54:26 -0000 Franck Martin writes: > Yes, RFC7208 says evaluate both in parallel, but the result > of an spf=pass/fail is highly constrained on the success or > failure of the MAIL FROM spf test. Actually, it recommends checking the HELO identity first, because if you get a definite result from that, you may not have to evaluate the MAIL FROM identity at all. > I mean, it seems quite rare to find an SPF record on the > HELO string but not one the MAIL FROM string I have no stats on how rare it is, but I can show you an example for one of my home domains: # host -t txt quill.porcupine.ca quill.porcupine.ca descriptive text "v=spf1 +a -all" # host -t txt porcupine.ca porcupine.ca descriptive text "v=spf1 +mx ?all" ... that is, if anyone tries to HELO as host "quill" and isn't coming from my IP address, you can reject that mail out of hand as a fake ("-all"). However, if the envelope sender is in my domain, then if it came from my MX, it's almost certainly good (lower its spam score), but if not, perhaps someone is forwarding their mail, and I don't want their final receiving ISP to drop my message, which is why "?all" in that case. (And yes, forwarded bounce mail originally from my mailer will fail the "MAIL FROM constructed from HELO" test, but I think I mostly avoid backscatter, so that's not too serious.) Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Tue Jan 20 14:56:19 2015 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 B1BBB1A006E for ; Tue, 20 Jan 2015 14:56:18 -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, 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 ySXvMR7UY6Fi for ; Tue, 20 Jan 2015 14:56:16 -0800 (PST) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0088.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360D11A0065 for ; Tue, 20 Jan 2015 14:56:16 -0800 (PST) Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) by BY2SR01MB609.namsdf01.sdf.exchangelabs.com (10.255.93.168) with Microsoft SMTP Server (TLS) id 15.1.75.5; Tue, 20 Jan 2015 22:55:58 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.11.34]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.11.34]) with mapi id 15.01.0075.002; Tue, 20 Jan 2015 22:55:58 +0000 From: Terry Zink To: DMARC list Thread-Topic: [dmarc-ietf] ... and two more tiny nits, while I'm at it Thread-Index: AQHQNP6A2+ZbNkLdFUic0heIpBnuIpzJmHsAgAAEHHA= Date: Tue, 20 Jan 2015 22:55:58 +0000 Message-ID: References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <9329.1421790256@vindemiatrix.encs.concordia.ca> <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> <8D02E23B-AF11-4D01-8E3A-3CC8B0EF5B32@wordtothewise.com> In-Reply-To: <8D02E23B-AF11-4D01-8E3A-3CC8B0EF5B32@wordtothewise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2SR01MB609; authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY2SR01MB609; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(51704005)(54606007)(87936001)(2656002)(46102003)(93886004)(97736003)(19580395003)(101416001)(92566002)(106356001)(2950100001)(76176999)(106116001)(50986999)(54356999)(33656002)(105586002)(86362001)(2900100001)(62966003)(77156002)(107886001)(15975445007)(102836002)(64706001)(450100001)(110136001)(54206007)(68736005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2SR01MB609; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2015 22:55:58.1334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2SR01MB609 Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 22:56:18 -0000 >7208 actually recommends that the HELO string be evaluated every time.=20 > http://trac.tools.ietf.org/html/rfc7208#section-2.3 They do say to check it both times but I don't agree with the rationale pro= vided. Expanding on the excerpt that Laura provided: 2.3. The "HELO" Identity It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the . Checking "HELO" promotes consistency of results and can reduce DNS resource usage. =20 [tzink] How does this reduce DNS resource usage? Aren't we now checking two= domains instead of one? If a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided. [tzink] Disagree here, especially the case of shared hosting environment li= ke Office 365. Customers relay spam through us and sometimes that spam will= fail SPF checks. Yet, if you checked the SPF record on the HELO string (e.= g., na01-bn1-obe.outbound.protection.outlook.com), that would pass an SPF c= heck every time whereas the @paypal.com in the MAIL FROM would fail SPF. Se= ems like you can only be sure you can trust the HELO when you are sure the = sender locks down the outbound mail infrastructure, and that is not the cas= e everywhere. Additionally, since SPF records published for "HELO" identities refer to a single host, when available, they are a very reliable source of host authorization status. Checking "HELO" before "MAIL FROM" is the RECOMMENDED sequence if both are checked. [tzink] They are for a single host but not necessarily for a single organiz= ation or even a series of organizations with the same set of policies. It s= eems like this RFC does not have a mult-tenant hosted environment in mind, = and that is becoming more common. -- Terry > 7208 actually recommends that the HELO string be evaluated every time.=20 > http://trac.tools.ietf.org/html/rfc7208#section-2.3 > > "2.3. The "HELO" Identity >=20 > > It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" > identity but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > . Checking "HELO" promotes consistency of results and can > reduce DNS resource usage." > > laura=20 > > --=20 > Laura Atkins > Word to the Wise "The Deliverability Experts!" > Direct: 650 678-3454 Fax: 650 249-1909 > @wise_laura > Delivery blog: From nobody Tue Jan 20 14:58:00 2015 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 876E91A0075 for ; Tue, 20 Jan 2015 14:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 PQesfB94or8e for ; Tue, 20 Jan 2015 14:57:57 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2091A006E for ; Tue, 20 Jan 2015 14:57:57 -0800 (PST) Received: (qmail 69495 invoked from network); 20 Jan 2015 22:57:56 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jan 2015 22:57:56 -0000 Date: 20 Jan 2015 22:57:34 -0000 Message-ID: <20150120225734.1523.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <4391673.47kOljF4j1@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 22:57:58 -0000 >HELO results are unrelated to DMARC. Is that still true when the bounce address is empty? It's fairly common to have an NDR with an empty bounce address and From: MAILER-DAEMON@flaky.example Assuming it's not DKIM signed (most NDRs aren't) what's a DMARC user supposed to do? R's, John From nobody Tue Jan 20 15:40:45 2015 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 A04A01A008F for ; Tue, 20 Jan 2015 15:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NS4hJ4noVDbV for ; Tue, 20 Jan 2015 15:40:41 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEE21A0081 for ; Tue, 20 Jan 2015 15:40:41 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id DD9F2563D9A; Tue, 20 Jan 2015 17:40:40 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BF5FEA02AB; Tue, 20 Jan 2015 17:40:40 -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 irMqbjmqOR0m; Tue, 20 Jan 2015 17:40:40 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7676EA03C2; Tue, 20 Jan 2015 17:40:40 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 7676EA03C2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421797240; bh=n/miEAHa2wNkWRSKOtP9fk+DlEmVXqT8gJ/nbCWpNYI=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=kjH7r37FvXIbx+zUvjc1yW8RJmvkJ6NoKDI072/2t1oN4buJ6a6rzK37cEEDF5in4 MO/28+ZTGV3wQYUxU0xLpH3jbAe5E61AoMCxcpM4cQIKhv7C6q2ZZPr7qTvDByWxYb y2okFcfR8yleSXo0AyV62XKcEKIw69LqIGjcQkso= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4D102A02F9; Tue, 20 Jan 2015 17:40:40 -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 Lnc7GSGwtIZ0; Tue, 20 Jan 2015 17:40:40 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 15B63A02AB; Tue, 20 Jan 2015 17:40:40 -0600 (CST) Date: Tue, 20 Jan 2015 17:40:39 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <5468593.48012.1421797239927.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <1295180662.46088.1421793523542.JavaMail.zimbra@peachymango.org> <14221361.tb6bO3xpOi@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: ... and two more tiny nits, while I'm at it Thread-Index: 1ywdRB0GIZEshldNo4GewdaXeyhHaw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 23:40:42 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Tuesday, January 20, 2015 2:49:01 PM > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > Last time I had stats, it was about 10% as common as Mail From oriented > records. Much less common, but I wouldn't say rare. When done this way, > there isn't a singe "SPF" result, there are two: SPF/Mail From and SPF/HELO. > Only SPF/Mail From is relevant to DMARC. Why do you say that? DMARC takes the result from SPF (pass/fail/...) and the string that SPF used for this result be it mail from or helo, to check for alignment. Did I miss something? From nobody Tue Jan 20 15:43:48 2015 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 B63C41A00A7 for ; Tue, 20 Jan 2015 15:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7j7X3KrrvOFI for ; Tue, 20 Jan 2015 15:43:45 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id ADFA41A0097 for ; Tue, 20 Jan 2015 15:43:45 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 4F992563D9A; Tue, 20 Jan 2015 17:43:45 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3EBC3600D8; Tue, 20 Jan 2015 17:43:45 -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 LSgo30ri59zM; Tue, 20 Jan 2015 17:43:45 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 083C8601DE; Tue, 20 Jan 2015 17:43:45 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 083C8601DE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421797425; bh=4/0nyojWOW8e497y5eq0Pfk8UuN/J2gdVjI/+5Hiia8=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=GjpM/umQz7LvpNKdaGPQdchVD4xXmAbO6ZGogUvM57ImpHgOXSLSStaP6fx1+qvm/ ev7gW5BIolIWxX+PGr1bwypWw5jWHugPYznGWKr93jmiWc3ULkQ9h9Dvr5A7VZZBYp bDhcZxZnIVMPPIAMrx4jw84xqwHFweyOhRMmANF8= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id DD796601B6; Tue, 20 Jan 2015 17:43:44 -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 pC6OPyaE78My; Tue, 20 Jan 2015 17:43:44 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id BDF0A600D8; Tue, 20 Jan 2015 17:43:44 -0600 (CST) Date: Tue, 20 Jan 2015 17:43:44 -0600 (CST) From: Franck Martin To: John Levine Message-ID: <1109361778.48035.1421797424676.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150120225734.1523.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: ... and two more tiny nits, while I'm at it Thread-Index: w42j9WfbKyH+/3wTKqCkdBsCWHng3w== Archived-At: Cc: dmarc@ietf.org, sklist@kitterman.com Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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, 20 Jan 2015 23:43:46 -0000 ----- Original Message ----- > From: "John Levine" > To: dmarc@ietf.org > Cc: sklist@kitterman.com > Sent: Tuesday, January 20, 2015 2:57:34 PM > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > >HELO results are unrelated to DMARC. > > Is that still true when the bounce address is empty? It's fairly common > to have an NDR with an empty bounce address and > > From: MAILER-DAEMON@flaky.example > > Assuming it's not DKIM signed (most NDRs aren't) what's a DMARC user > supposed to do? > The same as a non DMARC user should do... From nobody Tue Jan 20 17:22:33 2015 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 E2C781A00FE for ; Tue, 20 Jan 2015 17:22:30 -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 dt3P5qLr1lEf for ; Tue, 20 Jan 2015 17:22:28 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA081A00FA for ; Tue, 20 Jan 2015 17:22:28 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u56so41341660wes.2 for ; Tue, 20 Jan 2015 17:22:27 -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=KYKurM9CuDOBlHwz3xhQsCS2sqzgoavNasQedWdyKmY=; b=nbPInu8CVDGO9EBKDqEzAPRYpujP8ry+yYl/XkBIEqNdzALMbKaOywCzOH4CAnvE6L pk6mu/AMOcT7WB9CbXN1yd3NyIKa/slsmrpuioi8WdNuLlS3/YuYeNU83PMCHyB1fW2l LN96EWbm9MpZ3qSFQxwZvp+bksRLlkfCoOy2kjao9AavlWFG2Ko2xyCRHW1RNe5L+pZD z1HifjCENGY4bh2zp4DCW8rpi2oGygBbvrFF3xQmfFbTLNzw3oQRXNNYkiwt5lLbIPkk WTcGENoUsfLPL/7Y+od+dfcJ7fN5T2xU/EHkBwku0WHwI9o0CXOqo3RrOw35hMckBK4P txOw== MIME-Version: 1.0 X-Received: by 10.180.95.4 with SMTP id dg4mr51126608wib.61.1421803347095; Tue, 20 Jan 2015 17:22:27 -0800 (PST) Received: by 10.27.204.198 with HTTP; Tue, 20 Jan 2015 17:22:27 -0800 (PST) In-Reply-To: <9329.1421790256@vindemiatrix.encs.concordia.ca> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <9329.1421790256@vindemiatrix.encs.concordia.ca> Date: Tue, 20 Jan 2015 17:22:27 -0800 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=f46d0444028e71b6c1050d1f6387 Archived-At: Cc: DMARC list Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 01:22:31 -0000 --f46d0444028e71b6c1050d1f6387 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 20, 2015 at 1:44 PM, Anne Bennett wrote: > I apologize for my inadvertently poor timing; I was catapulted > into all this last week when my parent domain (also my > Organizational Domain) published an SPF record and a DKIM > record, and we became concerned that they might implement DMARC, > which could have a very negative impact on our mail services > unless we take action quickly and become prepared to publish > our own DMARC record. Thus, my sudden plunge into all these > RFCs and this draft. :-/ > Well, shoot. Timing notwithstanding, I also apologize if I came across as dismissing your use case as unimportant. I thought you were merely providing reviews as an interested party, not actually addressing a production problem. Since, as pointed out by Tim Draegen, "DMARC implementations are > already in the wild and deployed", one would expect to be able > to determine what those implementations do, based on this spec. > Sadly this hasn't been possible (so far) for me and my colleague > Michael Jack Assels, despite our being two fairly smart cookies, > with nearly a half-century of e-mail experience between us. > I can't speak for most of the operators you're probably dealing with, many of whom have their own implementations. I can say that OpenDMARC consumes the Authentication-Results field, or the Received-SPF field if the former isn't there, but it prefers a result based on MAIL FROM over one based on HELO if both are present. But it will use both. I'm pretty sure Gmail people are on, or at least following, this list; hopefully someone there will comment. I want to emphasize that I think that the documents in question > (at least this draft and RFC7208 - I've barely skimmed RFC6376 > on DKIM yet) individually are well written, but trying to > understand them in context together is proving to be quite > a challenge, and the lack of clarity on the HELO issue is > the biggest part of the problem. > This is certainly useful feedback to the WG. In addition to considering it as a topic for a Proposed Standard version of the DMARC specification, there might be a need to explore some kind of interim statement about what's supposed to happen here (if necessary). > But on the off-chance that it's not impossible to clarify > this now, and assuming that my growing suspicion that HELO is > ignored is correct, then I would propose: > > [...] > Do people concur with this change, or something close to it? -MSK --f46d0444028e71b6c1050d1f6387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 20, 2015 at 1:44 PM, Anne Bennett <anne@= encs.concordia.ca> wrote:
I apologize for my ina= dvertently poor timing; I was catapulted
into all this last week when my parent domain (also my
Organizational Domain) published an SPF record and a DKIM
record, and we became concerned that they might implement DMARC,
which could have a very negative impact on our mail services
unless we take action quickly and become prepared to publish
our own DMARC record.=C2=A0 Thus, my sudden plunge into all these
RFCs and this draft.=C2=A0 :-/

Well, sh= oot.=C2=A0 Timing notwithstanding, I also apologize if I came across as dis= missing your use case as unimportant.=C2=A0 I thought you were merely provi= ding reviews as an interested party, not actually addressing a production p= roblem.

Since, as pointed out by Tim Draegen, "DMARC implementations are
already in the wild and deployed", one would expect to be able
to determine what those implementations do, based on this spec.
Sadly this hasn't been possible (so far) for me and my colleague
Michael Jack Assels, despite our being two fairly smart cookies,
with nearly a half-century of e-mail experience between us.

I can't speak for most of the operators you're= probably dealing with, many of whom have their own implementations.
I can say that OpenDMARC consumes the Authentication-Results fi= eld, or the Received-SPF field if the former isn't there, but it prefer= s a result based on MAIL FROM over one based on HELO if both are present.= =C2=A0 But it will use both.

I'm pretty su= re Gmail people are on, or at least following, this list; hopefully someone= there will comment.

I want to emphasize that I think that the documents in question
(at least this draft and RFC7208 - I've barely skimmed RFC6376
on DKIM yet) individually are well written, but trying to
understand them in context together is proving to be quite
a challenge, and the lack of clarity on the HELO issue is
the biggest part of the problem.

This i= s certainly useful feedback to the WG.=C2=A0 In addition to considering it = as a topic for a Proposed Standard version of the DMARC specification, ther= e might be a need to explore some kind of interim statement about what'= s supposed to happen here (if necessary).
=C2=A0
But on the off-chance that it's not impossible to clar= ify
this now, and assuming that my growing suspicion that HELO is
ignored is correct, then I would propose:

[...]
=C2=A0
Do people concur with this chan= ge, or something close to it?

-MSK
<= /div> --f46d0444028e71b6c1050d1f6387-- From nobody Tue Jan 20 18:15:29 2015 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 CB8DA1A0149 for ; Tue, 20 Jan 2015 18:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 C5Gv7YNZfm8K for ; Tue, 20 Jan 2015 18:15:21 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EE41A0145 for ; Tue, 20 Jan 2015 18:15:20 -0800 (PST) Received: (qmail 96268 invoked from network); 21 Jan 2015 02:15:19 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 21 Jan 2015 02:15:19 -0000 Date: 21 Jan 2015 02:14:57 -0000 Message-ID: <20150121021457.1947.qmail@ary.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 Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 02:15:22 -0000 >Do people concur with this change, or something close to it? I'm OK with it, but to the meta-question, I realize the practical issues involved with yanking something out of the production queue, but in this case I wonder if that's not the right thing to do. There's no great hurry in getting the DMARC document published, since nothing currently depends on it, and if reasonable people are finding holes in it that make it hard to write interoperable code, I'd rather fix the holes than add lengthy errata or recycle later. R's, John From nobody Tue Jan 20 19:57:21 2015 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 96F801A0278 for ; Tue, 20 Jan 2015 19:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 OAeaOVpwQrTY for ; Tue, 20 Jan 2015 19:57:13 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE121A02BE for ; Tue, 20 Jan 2015 19:57:00 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 9E2441C38D2; Wed, 21 Jan 2015 12:56:58 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 866041A2D18; Wed, 21 Jan 2015 12:56:58 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20150121021457.1947.qmail@ary.lan> References: <20150121021457.1947.qmail@ary.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 21 Jan 2015 12:56:58 +0900 Message-ID: <87r3uovl9x.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 03:57:17 -0000 John Levine writes: > There's no great hurry in getting the DMARC document published, since > nothing currently depends on it, and if reasonable people are finding > holes in it that make it hard to write interoperable code, I'd rather > fix the holes than add lengthy errata or recycle later. *If* the existing code bases are interoperable, then it makes sense to postpone publication to fix the spec to conform to actual practice (which is its purpose, after all). Is it worth the effort/editor time to compose and discuss better language and the calendar time to wait for confirmation from implementors? From nobody Tue Jan 20 20:59:30 2015 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 3BD821A0354 for ; Tue, 20 Jan 2015 20:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 GV7W6llYsHxo for ; Tue, 20 Jan 2015 20:59:04 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD561A034C for ; Tue, 20 Jan 2015 20:59:04 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B3438C401D1; Tue, 20 Jan 2015 23:01:39 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421816499; bh=3bXtUzR4JAJSj2ra/D2SwHUecVSbF1RyJTVOYXHeBaY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UWw4JUCgUrRv/R5MJSTnM8Z6HRfCMFQKStNqaGZ8UH7QHAO4SiYHhPJrtFsPyOWGU A9jQKdOvYDBdy9ADiDjIxnEt8aLXRO40ThcsXa9elagNxJcRlz2vqhZKZ3M2fmO7iN GRAGrh6/2l3gQ+4JrEfevdWvvRDThdnoTDIkdBYc= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 20 Jan 2015 23:59:02 -0500 Message-ID: <3462827.Qs4xraX6ou@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <8D02E23B-AF11-4D01-8E3A-3CC8B0EF5B32@wordtothewise.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 04:59:08 -0000 On Tuesday, January 20, 2015 22:55:58 Terry Zink wrote: > >7208 actually recommends that the HELO string be evaluated every time. > > > > http://trac.tools.ietf.org/html/rfc7208#section-2.3 > > They do say to check it both times but I don't agree with the rationale > provided. Expanding on the excerpt that Laura provided: > > 2.3. The "HELO" Identity > > It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" > identity but also separately check the "HELO" identity by applying > the check_host() function (Section 4) to the "HELO" identity as the > . Checking "HELO" promotes consistency of results and can > reduce DNS resource usage. > > [tzink] How does this reduce DNS resource usage? Aren't we now checking two > domains instead of one? Note: This point was actively discussed during the SPFbis working group. HELO records are virtually always very simple: zero or one additional DNS lookup. If you get a fail result and choose to reject as a result, you never have to even retrieve the Mail From record, let alone do all the lookups triggered by the terms in the record. This is for SPF on it's own and not particularly relevant if you want to feed SPF results into DMARC. > If a conclusive determination about the > message can be made based on a check of "HELO", then the use of DNS > resources to process the typically more complex "MAIL FROM" can be > avoided. > > [tzink] Disagree here, especially the case of shared hosting environment > like Office 365. Customers relay spam through us and sometimes that spam > will fail SPF checks. Yet, if you checked the SPF record on the HELO string > (e.g., na01-bn1-obe.outbound.protection.outlook.com), that would pass an > SPF check every time whereas the @paypal.com in the MAIL FROM would fail > SPF. Seems like you can only be sure you can trust the HELO when you are > sure the sender locks down the outbound mail infrastructure, and that is > not the case everywhere. Agree. The only definitive result you can get from SPF HELO checks is reject. It'll never tell you something is good. > Additionally, since SPF records published for "HELO" > identities refer to a single host, when available, they are a very > reliable source of host authorization status. Checking "HELO" before > "MAIL FROM" is the RECOMMENDED sequence if both are checked. > > [tzink] They are for a single host but not necessarily for a single > organization or even a series of organizations with the same set of > policies. It seems like this RFC does not have a mult-tenant hosted > environment in mind, and that is becoming more common. It doesn't matter. The HELO name is (should be) particular to that host so it works regardless. Recall that for SPF there's no notion of alignment so there's no requirement that the HELO name have anything to do with any other identity in the message. To read RFC 7208 as intended, you have to forget DMARC exists. It was written to stand alone. It's up to DMARC to explain how it wants to be built on top of SPF. Scott K > -- Terry > > > 7208 actually recommends that the HELO string be evaluated every time. > > http://trac.tools.ietf.org/html/rfc7208#section-2.3 > > > > "2.3. The "HELO" Identity > > > > It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" > > identity but also separately check the "HELO" identity by applying > > the check_host() function (Section 4) to the "HELO" identity as the > > > > . Checking "HELO" promotes consistency of results and can > > reduce DNS resource usage." > > > > laura > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jan 20 21:00:11 2015 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 231871A0362 for ; Tue, 20 Jan 2015 21:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 TMJhaTxJg8ln for ; Tue, 20 Jan 2015 21:00:00 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDAE1A0360 for ; Tue, 20 Jan 2015 21:00:00 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8109EC401D1; Tue, 20 Jan 2015 23:02:35 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421816555; bh=RpNJSe/KnQlvu+0paR3gnbec2IirB4gpAeAr2Eetiwk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YJoTyvlZRjSDcj8xTUt1kY+7EtBx3eOAuJdzBnshQ2moYHfaaIOlFvXP0/HMgNTJO CZUWhyEO68Px8fK+LuJoceOpnXiciYCcCX5RY5tDlz3wDcScQNUqNweU7yXxA+7NCv dhxSlQmuj59pO2mAIWimPbZbaEB3KzXlXbOkn7wE= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 20 Jan 2015 23:59:58 -0500 Message-ID: <2977931.VXq1lVS3OR@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20150120225734.1523.qmail@ary.lan> References: <20150120225734.1523.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 05:00:03 -0000 On Tuesday, January 20, 2015 22:57:34 John Levine wrote: > >HELO results are unrelated to DMARC. > > Is that still true when the bounce address is empty? It's fairly common > to have an NDR with an empty bounce address and > > From: MAILER-DAEMON@flaky.example > > Assuming it's not DKIM signed (most NDRs aren't) what's a DMARC user > supposed to do? Subtle point, but that's not a HELO result, that's a Mail From result evaluated using a synthetic Mail From based on HELO. Scott K From nobody Tue Jan 20 21:02:41 2015 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 7BF8C1A0354 for ; Tue, 20 Jan 2015 21:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 9Xf3wJVcLwNX for ; Tue, 20 Jan 2015 21:02:27 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC67A1A034C for ; Tue, 20 Jan 2015 21:02:27 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 170DAC401D1; Tue, 20 Jan 2015 23:05:03 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421816703; bh=eedelixF1EiuSFelDnkry05jOlCQyvpp0fFU0NI7LO0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=pyWXAadG6cy4SUjD5oJW+LQL+cFgJoUQkiq2dQIl0sUMEYfz3HfFUzBKLPUDdZH6w opneY0CdDqH0FSVwdSzZfbnXt8f4mx1A6OqLf1owgCvYRiwxA4K1t2sU4sFB9VNIaf lFkl/M47alsUGPWytGxqQL2rlcMc6TsaExiO6RHA= From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 21 Jan 2015 00:02:26 -0500 Message-ID: <2311563.S4yK7lBgP6@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5468593.48012.1421797239927.JavaMail.zimbra@peachymango.org> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <5468593.48012.1421797239927.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 05:02:33 -0000 On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote: > ----- Original Message ----- > > > From: "Scott Kitterman" > > To: dmarc@ietf.org > > Sent: Tuesday, January 20, 2015 2:49:01 PM > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > > > > > > > > Last time I had stats, it was about 10% as common as Mail From oriented > > records. Much less common, but I wouldn't say rare. When done this way, > > there isn't a singe "SPF" result, there are two: SPF/Mail From and > > SPF/HELO. Only SPF/Mail From is relevant to DMARC. > > Why do you say that? > > DMARC takes the result from SPF (pass/fail/...) and the string that SPF used > for this result be it mail from or helo, to check for alignment. > > Did I miss something? DMARC takes the SPF result and the Mail From as an input (which in the case of a null Mail From is a synthetic Mail From built using HELO, but that's just a coincidence). SPF isn't just a result (pass, fail, etc), it also has a domain and a related identity. Scott K From nobody Tue Jan 20 21:31:52 2015 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 8ABC51A0367 for ; Tue, 20 Jan 2015 21:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 2JfHedT-mPho for ; Tue, 20 Jan 2015 21:31:47 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id EC4A71A0354 for ; Tue, 20 Jan 2015 21:31:46 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 6690C563E60; Tue, 20 Jan 2015 23:31:46 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 57F2C601B4; Tue, 20 Jan 2015 23:31:46 -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 5GyAfR-lX0ZU; Tue, 20 Jan 2015 23:31:46 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id EE622601DE; Tue, 20 Jan 2015 23:31:45 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com EE622601DE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421818306; bh=12/CJcNssrs9+k3Vf6RyV+8hc5UOm0hOpMPJfDeliC0=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=R+fGmzoyEm8F5zFSvxEDENExXBHhLM3Z+/jrwdhvM3vfb+jAUwk/Hztfr8s+zwQBn 7E/gCw2mFmWYdYnuALZunPVaw/HaSHq9QnHKlq1rDbQZlYenp8xF7FLpI7cFpadmH6 QYYMEcLDD4CK5kmBCNB+AHMhUrXsZeV3aLJ4Gcn4= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id CD29E601B6; Tue, 20 Jan 2015 23:31:45 -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 Qx-CcuO4KRGz; Tue, 20 Jan 2015 23:31:45 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id B338F601B4; Tue, 20 Jan 2015 23:31:45 -0600 (CST) Date: Tue, 20 Jan 2015 23:31:45 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <947960233.51510.1421818305383.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <5468593.48012.1421797239927.JavaMail.zimbra@peachymango.org> <2311563.S4yK7lBgP6@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: ... and two more tiny nits, while I'm at it Thread-Index: Ugtc6qVC5i7UiTzvXNMZulCd0Vs5yQ== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 05:31:49 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Tuesday, January 20, 2015 9:02:26 PM > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote: > > ----- Original Message ----- > > > > > From: "Scott Kitterman" > > > To: dmarc@ietf.org > > > Sent: Tuesday, January 20, 2015 2:49:01 PM > > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > > > > > > > > > > > > > > Last time I had stats, it was about 10% as common as Mail From oriented > > > records. Much less common, but I wouldn't say rare. When done this way, > > > there isn't a singe "SPF" result, there are two: SPF/Mail From and > > > SPF/HELO. Only SPF/Mail From is relevant to DMARC. > > > > Why do you say that? > > > > DMARC takes the result from SPF (pass/fail/...) and the string that SPF > > used > > for this result be it mail from or helo, to check for alignment. > > > > Did I miss something? > > DMARC takes the SPF result and the Mail From as an input (which in the case > of > a null Mail From is a synthetic Mail From built using HELO, but that's just a > coincidence). SPF isn't just a result (pass, fail, etc), it also has a > domain > and a related identity. > If I recall the SPF spec, it specifies a MAIL FROM which is not the RFC5321.mailfrom, but a mix of RFC5321.mailfrom and RFC5321.helo based on which one was used to get the SPF result. The original SPF spec is quite confusing on that, at least for me. On senderid, I think they call this field mfrom to avoid confusion. It seems weird that the SPF results would depend more on the HELO than the RFC5321.mailfrom because if spammer.com put a SPF then mailfrom: security@example.com helo spammer.com would seem quite problematic.... From nobody Tue Jan 20 21:37:21 2015 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 D7EAE1A0362 for ; Tue, 20 Jan 2015 21:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MJw-voFg5r3s for ; Tue, 20 Jan 2015 21:37:17 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E841A0270 for ; Tue, 20 Jan 2015 21:37:16 -0800 (PST) Received: from [192.168.111.105] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5E9A8C401D1; Tue, 20 Jan 2015 23:39:52 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421818792; bh=/gQ/s7K0U5Rtzl9tCj8SS4uEYRCrUy7GV3rzP2xz+4g=; h=In-Reply-To:References:Subject:From:Date:To:From; b=PbzR+Yak9jFin+Pw5phcjiT7ozl7v/PF44Qt50W9pnxokG7dCCgHuJUI+6hyRp4V3 9dD/Bspcd+zlrK4AXwdvSABNuTnbfUk7jFu3C+x811hIwRjNDz7EdAVfz86jCIqnJV h4olU6P5zWSSE/b11Jb+Zz/cUsr8TZffUAHngn1E= User-Agent: K-9 Mail for Android In-Reply-To: <947960233.51510.1421818305383.JavaMail.zimbra@peachymango.org> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <5468593.48012.1421797239927.JavaMail.zimbra@peachymango.org> <2311563.S4yK7lBgP6@scott-latitude-e6320> <947960233.51510.1421818305383.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Wed, 21 Jan 2015 00:36:57 -0500 To: dmarc@ietf.org Message-ID: <70BCE1E2-B6CD-4988-9403-75F87D36FA05@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 05:37:19 -0000 On January 21, 2015 12:31:45 AM EST, Franck Martin wrote: > >----- Original Message ----- >> From: "Scott Kitterman" >> To: dmarc@ietf.org >> Sent: Tuesday, January 20, 2015 9:02:26 PM >> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it >> >> On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote: >> > ----- Original Message ----- >> > >> > > From: "Scott Kitterman" >> > > To: dmarc@ietf.org >> > > Sent: Tuesday, January 20, 2015 2:49:01 PM >> > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm >at it >> > > >> > > >> > > >> > > >> > > Last time I had stats, it was about 10% as common as Mail From >oriented >> > > records. Much less common, but I wouldn't say rare. When done >this way, >> > > there isn't a singe "SPF" result, there are two: SPF/Mail From >and >> > > SPF/HELO. Only SPF/Mail From is relevant to DMARC. >> > >> > Why do you say that? >> > >> > DMARC takes the result from SPF (pass/fail/...) and the string that >SPF >> > used >> > for this result be it mail from or helo, to check for alignment. >> > >> > Did I miss something? >> >> DMARC takes the SPF result and the Mail From as an input (which in >the case >> of >> a null Mail From is a synthetic Mail From built using HELO, but >that's just a >> coincidence). SPF isn't just a result (pass, fail, etc), it also has >a >> domain >> and a related identity. >> > >If I recall the SPF spec, it specifies a MAIL FROM which is not the >RFC5321.mailfrom, but a mix of RFC5321.mailfrom and RFC5321.helo based >on which one was used to get the SPF result. > >The original SPF spec is quite confusing on that, at least for me. On >senderid, I think they call this field mfrom to avoid confusion. > >It seems weird that the SPF results would depend more on the HELO than >the RFC5321.mailfrom because if spammer.com put a SPF then > >mailfrom: security@example.com >helo spammer.com > >would seem quite problematic.... Which is precisely why I said HELO pass doesn't mean anything. HELO is really for rejection on fail. Scott K From nobody Wed Jan 21 07:50:38 2015 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 D7B931A1AF9 for ; Wed, 21 Jan 2015 07:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 toBUAs1q7-sN for ; Wed, 21 Jan 2015 07:50:24 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id A9FC11A1A6F for ; Wed, 21 Jan 2015 07:50:09 -0800 (PST) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0LFo8cg029396; Wed, 21 Jan 2015 10:50:08 -0500 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0LFo8Av010997; Wed, 21 Jan 2015 10:50:08 -0500 Message-Id: <201501211550.t0LFo8Av010997@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: Franck Martin From: Michael Jack Assels In-reply-to: <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <9329.1421790256@vindemiatrix.encs.concordia.ca> <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> Comments: In-reply-to Franck Martin message dated "Tue, 20 Jan 2015 16:14:32 -0600." Date: Wed, 21 Jan 2015 10:50:08 -0500 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-21 10:50:08 EST Archived-At: Cc: DMARC list Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 15:50:33 -0000 On Tue, 20 Jan 2015 16:14:32 CST, Franck Martin wrote: > [...] > Your confusion on HELO is may be related to the fact that the > HELO string is only used when the MAIL-FROM: is empty? > > There is some text here: > http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 > > The HELO string is not evaluated all the time, it is more like > a fall back. It's already been pointed out that http://trac.tools.ietf.org/html/rfc7208#section-2.3 RECOMMENDs checking the HELO string first; hence our confusion. It'a not difficult to imagine a HELO string that passes SPF but doesn't align with the RFC5322.From with a MAIL FROM domain that passes SPF *and* aligns, while the DKIM-Signature validates but doesn't align. An implementation of DMARC that follows the SPF recommendation will, as I understand it, produce [SPF:fail, DKIM:fail], despite the existence of an SPF-valid MAIL FROM domain that aligns with the RFC5322.From domain. It seems to be the consensus that this would be wrong, and that existing DMARC implementations don't behave that way. That's fine by me, but it needs to be said out loud that DMARC implementations MUST NOT (SHOULD NOT?) follow rfc7208#section-2.3's recommendation. > Also I have trouble to understand why you may be affected by > your OD? What is the relation between your domain and your OD? > I suspect this is concordia.ca? Yes, it's Concordia.ca. Some details: Concordia.ca is Concordia University, while encs.concordia.ca is just the Faculty of Engineering and Computer Science at Concordia, so it's appropriate that concordia.ca is the OD. They've delegated encs.concordia.ca to us, and we (ENCS staff) manage it ourselves, with minimal interaction. > If you look at the public suffix list, google has put a > separation at blogspot.com level, so that each hosting domain, > can be organizationally separated. > > https://publicsuffix.org/list/effective_tld_names.dat Are you saying that any owner of a registered domain can arrange to the suffix list on request, thereby allowing next-level subdomains to be elevated to ODs? If that's right, I'd certainly be keen on suggesting to our concordia.ca colleagues that they do us that favour. > I would suggest you publish a DMARC record in monitoring mode > (p=none) so that you get reports (and no impact) and better > understand your email infrastructure and what needs to be done. We'll certainly publish a DMARC record with p=none. Thanks, MJA From nobody Wed Jan 21 11:13:04 2015 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 6FE081A701F for ; Wed, 21 Jan 2015 11:12:57 -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 1EjcsMGT3kCb for ; Wed, 21 Jan 2015 11:12:53 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2AC1A6FF2 for ; Wed, 21 Jan 2015 11:12:52 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id z12so7957069wgg.3 for ; Wed, 21 Jan 2015 11:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LNWN8X28lDpCxXVRpfRcGZwmfx7WoYtBmqL3n9DBCKs=; b=wf31HycU1KI9pj7wmBW77lxBuN9yyJeVnmYjAmFBRjbEzY5PdzbzrTn7TaRkiN7ELM wBJKZMG3jnsKl5cYsZr7bS5uiTpZeco1djhoACZcFFdOVoGRtFitXkGg5GIPTE7Volzl eIRGfKNcYBydP+qymDB6nfH6AyjwPM+jc1ULRwkpQiw/4GBBFIS2QFVJVS//WeUCUw+i pabpH+bUO5h8gjEZislBhoTq9ifMhKCdlF/jcWdEH6WoAHLTkg5fyKM+9BMgkNLZ4Dzp Z++fTiGyE2JEeza9+z4txTkBU3RmNHmC7pnGIlnGsEmfPH+LWkXAI8plBnY2hjt3o6uh BGog== MIME-Version: 1.0 X-Received: by 10.180.95.4 with SMTP id dg4mr58867989wib.61.1421867571622; Wed, 21 Jan 2015 11:12:51 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 21 Jan 2015 11:12:51 -0800 (PST) In-Reply-To: <20150121021457.1947.qmail@ary.lan> References: <20150121021457.1947.qmail@ary.lan> Date: Wed, 21 Jan 2015 11:12:51 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d0444028e8638b8050d2e5739 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 19:12:58 -0000 --f46d0444028e8638b8050d2e5739 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 20, 2015 at 6:14 PM, John Levine wrote: > >Do people concur with this change, or something close to it? > > I'm OK with it, but to the meta-question, I realize the practical > issues involved with yanking something out of the production queue, > but in this case I wonder if that's not the right thing to do. > > There's no great hurry in getting the DMARC document published, since > nothing currently depends on it, and if reasonable people are finding > holes in it that make it hard to write interoperable code, I'd rather > fix the holes than add lengthy errata or recycle later. > I am asking the IESG and the ISE what the process is for making such adjustments now. Mainly my resistance to further change comes from the fact that we've done last calls of varying kinds on this document more times than I can count. It really is time to put the non-IETF version to bed and hand it off, even with its weaknesses, and let the standards process take it from there. There's a working group already chartered to do exactly that; in fact, that was one of the premises of creating that working group. -MSK --f46d0444028e8638b8050d2e5739 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jan 20, 2015 at 6:14 PM, John Levine <johnl@taugh.c= om> wrote:
>Do people concur with this change= , or something close to it?

I'm OK with it, but to the meta-question, I realize the practical
issues involved with yanking something out of the production queue,
but in this case I wonder if that's not the right thing to do.

There's no great hurry in getting the DMARC document published, since nothing currently depends on it, and if reasonable people are finding
holes in it that make it hard to write interoperable code, I'd rather fix the holes than add lengthy errata or recycle later.

I am asking the IESG and the ISE what the process is for m= aking such adjustments now.

Mainly my resistance to further change c= omes from the fact that we've done last calls of varying kinds on this = document more times than I can count.=C2=A0 It really is time to put the no= n-IETF version to bed and hand it off, even with its weaknesses, and let th= e standards process take it from there.=C2=A0 There's a working group a= lready chartered to do exactly that; in fact, that was one of the premises = of creating that working group.

-MSK
--f46d0444028e8638b8050d2e5739-- From nobody Wed Jan 21 11:18:51 2015 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 1F0C31A8549 for ; Wed, 21 Jan 2015 11:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 05ivU1mCI8KM for ; Wed, 21 Jan 2015 11:18:45 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7641B1A86E8 for ; Wed, 21 Jan 2015 11:18:25 -0800 (PST) Received: (qmail 88386 invoked from network); 21 Jan 2015 19:18:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15941.54bffb80.k1501; bh=FDzqkhGIDGRtaHjtG3nxptUUevQbYx9Mu0nV5VoZXRw=; b=p615PrVJaiSPd6DudyxN1Rea3wIwPn4p7zSnFyam2Q6Me2q7sslwTHpY3tAkLXQuDpenQag25H3V2Yk7uuW6VRIGFYjzTD5VYx4i/6Zvq3W/iIkMSwBcMNq7byxJoLuQfNugjn4gepCCgPOPUh7wLS9EOoJVc+gUL6/RCsyBco+MkpLcNZxkl1FsAIOfelfIXhyBROvqTRsqxjvOKxm+3cp2aLpJmh6QtUMdbmK9ibK3l+dx3hoERMiuPBucPW+g DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15941.54bffb80.k1501; bh=FDzqkhGIDGRtaHjtG3nxptUUevQbYx9Mu0nV5VoZXRw=; b=vfCsI8O8x0+OYaYarvn5EiHmEkTBsbylQv3I4SetrPlsKDKGWXmtnIy/6Fu+2KnDrHpfqHkYWwoHql3ZRy9zDaBjk+Bg4WZRL1vUzJ5FSy0Yu2n3urfnMlOI2xzBUlUBnpZfpYI6qAlUKeLOjSAsIvlmt+kzoNN/f4G/j57yFjYgL2+T4AXu5x17FwjESWeBgcbXSSPQEL82RhE17WM+TWSnvsA/099FBOWvj1WTveB6xFt/sV02DUcfv3xaHi+L Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 21 Jan 2015 19:18:24 -0000 Date: 21 Jan 2015 14:18:23 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150121021457.1947.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 19:18:46 -0000 > It really is time to put the non-IETF version to bed and hand it off, even > with its weaknesses, and let the standards process take it from there. > There's a working group already chartered to do exactly that; in fact, that > was one of the premises of creating that working group. I was under the impression that the reason this version's going through the ISE is that the DMARC group isn't willing to hand change control to the IETF. If they are willing, it makes no sense to do it outside of a WG. I sympathize with your concern about the length of the process, and the lack of timely review, but DMARC is unusually complex for a mail thing, the implementations have all been from different drafts (did anyone ever do reporting by http?) and it's not surprising that there are still places where the code doesn't match the text, or two versions of code do different things. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Jan 21 11:33:50 2015 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 677931A8722 for ; Wed, 21 Jan 2015 11:33:44 -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 n0a3MH2Gc5DE for ; Wed, 21 Jan 2015 11:33:42 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACA6B1A871E for ; Wed, 21 Jan 2015 11:33:41 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w62so18535962wes.7 for ; Wed, 21 Jan 2015 11:33:40 -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=4Q041YA5LmTrVm8dXT02KkMWTGAdSPDl1DYzslI8fEU=; b=a8qNjNiAVNH3UelLJGVNqIqjtUfCm3IeloxmLrjSKp94ogfI4eMUCBbAry50pTvXc9 MpGOfKFLcQLQo84AsNDMVGs5l7hr/2reMYdpim9Nu/jMSgXiZ6ZqlE3PfMNVX3rhiB3p F1GtfkjXDmj5h9DMDWGoEaLx8ld3MnJNuR0Q4byZrAzqT6bAGD9zeTB3It4+VrTlf4vA h0dXqAW33Gf6SpCI7gpRgmQuuVAhUF14i2S27zt1fOPQYf/MxnA1hAX0em/+GY/aOcKQ aXkFGjM95ftDmqCwQeIxYHZHfIdoiFQc6I6nvMjFj3t8ngMMS9a+OJchYSzvWbflvfiu oL0A== MIME-Version: 1.0 X-Received: by 10.194.142.174 with SMTP id rx14mr29122013wjb.110.1421868820447; Wed, 21 Jan 2015 11:33:40 -0800 (PST) Received: by 10.27.204.198 with HTTP; Wed, 21 Jan 2015 11:33:40 -0800 (PST) In-Reply-To: References: <20150121021457.1947.qmail@ary.lan> Date: Wed, 21 Jan 2015 11:33:40 -0800 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=089e01176ee3f5c8bc050d2ea1da Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 19:33:44 -0000 --089e01176ee3f5c8bc050d2ea1da Content-Type: text/plain; charset=UTF-8 On Wed, Jan 21, 2015 at 11:18 AM, John R Levine wrote: > I was under the impression that the reason this version's going through > the ISE is that the DMARC group isn't willing to hand change control to the > IETF. If they are willing, it makes no sense to do it outside of a WG. > It's a little late to re-hash the path by which we got here now, I think, and it was a rancorous debate. The agreement we have with the IESG is to do it via the path we're now on. Likewise, I was under the impression that publishing something through the ISE is deliberately restricted to Informational status specifically because what the document specifies might have flaws as it hasn't been subjected to any kind of IETF Review. I would agree with you if it were on the Standards Track, but it isn't. The idea of a process for ensuring that all implementations are based on -12 (or -13) and thus any two versions of the code do the same thing sounds dreadfully open-ended. I'd really like to have the goal posts sit still for a while. -MSK --089e01176ee3f5c8bc050d2ea1da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 21, 2015 at 11:18 AM, John R Levine <johnl@tau= gh.com> wrote:
I was under the impression that t= he reason this version's going through the ISE is that the DMARC group = isn't willing to hand change control to the IETF.=C2=A0 If they are wil= ling, it makes no sense to do it outside of a WG.

=
It's a little late to re-hash the path by which we got here = now, I think, and it was a rancorous debate.=C2=A0 The agreement we have wi= th the IESG is to do it via the path we're now on.

Li= kewise, I was under the impression that publishing something through the IS= E is deliberately restricted to Informational status specifically because w= hat the document specifies might have flaws as it hasn't been subjected= to any kind of IETF Review.=C2=A0 I would agree with you if it were on the= Standards Track, but it isn't.

The idea of a process= for ensuring that all implementations are based on -12 (or -13) and thus a= ny two versions of the code do the same thing sounds dreadfully open-ended.= =C2=A0 I'd really like to have the goal posts sit still for a while.
-MSK
--089e01176ee3f5c8bc050d2ea1da-- From nobody Wed Jan 21 12:43:23 2015 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 53D4E1A87D1 for ; Wed, 21 Jan 2015 12:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.78 X-Spam-Level: X-Spam-Status: No, score=-98.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, MANGLED_EMAIL=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 U7ZgUUglnn0Y for ; Wed, 21 Jan 2015 12:43:19 -0800 (PST) Received: from mail.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 84F3B1A87A7 for ; Wed, 21 Jan 2015 12:43:19 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3258; t=1421872991; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=zWrs9oNZpuN9lzO0u/nK+nXlEFg=; b=v7NOOz6QSEW6b/8lq6Eu whKy5NKUbTOS4GFFMY2OFiBxZ32hcS5AfpFeB9wMrdLsNTM/ATIiqptR/FHNtx/V +lIYt91/mvvm8ZBNOsfE8GYMwM+UGJoBQ60D5Xy0JC0N9Ho7vYmgkuBPcxSWJTrd G5LTb3gzUJ3W5kdE4+rLb3U= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 21 Jan 2015 15:43:11 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4173021899.1255.3560; Wed, 21 Jan 2015 15:43:10 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3258; t=1421872900; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Emx/eoF 6N80WuwqTJIXmpG5QZmTRTgJOUtfOCNqxSXc=; b=Uyr949IqfyKWnD4jb4omA8a zFh5c5AzNXe5f6pmjlPhODEMdT4MMf4w9Hk30TYXhmP0UW3o2pMkYPrEVsvj+FZE roUMBYVPRdThL1D7iy0TTkhs1zO5m2TcSewYYLLwYxp5fFZF/UUFSEOIZkOvzCPU 4rhIhBOAA+jb2jolvq2s= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 21 Jan 2015 15:41:40 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2765369893.9.9380; Wed, 21 Jan 2015 15:41:38 -0500 Message-ID: <54C00F5D.1080704@isdg.net> Date: Wed, 21 Jan 2015 15:43:09 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Jack Assels , Franck Martin References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <9329.1421790256@vindemiatrix.encs.concordia.ca> <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> <201501211550.t0LFo8Av010997@shadrach.encs.concordia.ca> In-Reply-To: <201501211550.t0LFo8Av010997@shadrach.encs.concordia.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: DMARC list Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 20:43:22 -0000 On 1/21/2015 10:50 AM, Michael Jack Assels wrote: > On Tue, 20 Jan 2015 16:14:32 CST, > Franck Martin wrote: > >> [...] >> Your confusion on HELO is may be related to the fact that the >> HELO string is only used when the MAIL-FROM: is empty? >> >> There is some text here: >> http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 >> >> The HELO string is not evaluated all the time, it is more like >> a fall back. > > It's already been pointed out that > http://trac.tools.ietf.org/html/rfc7208#section-2.3 > RECOMMENDs checking the HELO string first; hence our confusion. Implementators should know this would be a high DNS waste and overhead suggestion. The optimized approach is to delay any DNS query applications and first capture the SMTP process field parameters to determine what augmented DNS applications apply, what needs be queried and calculated. For example, SMTP has offered guidance in this area for delaying the reverse-path (MAIL FROM) processing until the forward-path (RCPT TO) is known: SMTP Section 3.3 Mail Transactions ..... Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. HELO/EHLO has historically been known to be incorrect for many reasons. At best, the receiver can perform a field syntax check including a required bracketed IP Domain literal check to make sure it matches the connection IP address before doing anything else and allowing the next SMTP state to continue. The reality is that SMTP receivers are not going to know the DMARC status of an incoming anonymous client until the DATA payload is received. It doesn't need DMARC information for SPF -ALL rejection policies. SPF -ALL policy SHOULD be processed immediately before DATA. But I think DMARC wants you further delay SPF processing until DATA payload is received (for reporting reasons I suppose). Since it can be potentially high overhead of getting a payload with no DMARC information, SPF receivers may not wait until DATA is received to process SPF. Incidentally, SENDER-ID [1] resolve this DATA overhead potential issue with the SUBMITTER optimization [2] where the PRA (Purported Responsible Address) [3] was passed to the MAIL FROM state: MAIL FROM: SUBMITTER=pra This tells the SPF processor that the pra DOMAIN is the lookup domain. DMARC can borrow from such ideas to pass the 5322 Author Domain (DMARC domain), and better yet even pass the policy as well to help optimized the receiver: MAIL FROM:[ DMARC=author-domain[ DMARC.P=reject]] This DMARC ESMTP idea would probably only work if there is a TRUST that the that payload is DKIM signed correctly using the problem 5322.From address. -- HLS [1] https://tools.ietf.org/html/rfc4406 [2] https://tools.ietf.org/html/rfc4405 [3] https://tools.ietf.org/html/rfc4407 From nobody Wed Jan 21 13:18:46 2015 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 BDA341A8891 for ; Wed, 21 Jan 2015 13:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.78 X-Spam-Level: X-Spam-Status: No, score=-98.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, MANGLED_EMAIL=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Wqj-c75oUURF for ; Wed, 21 Jan 2015 13:18:44 -0800 (PST) Received: from mail.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 724841A888A for ; Wed, 21 Jan 2015 13:18:17 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2125; t=1421875091; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=dnSWsD7tV+JXGSd05YVEt5PlzF8=; b=ZgFUlygd88101I3ujbhy Kg6u9qHFSp5kxIB8VBvyyYemMubrn0psFt9uua/SvUU4E4AhMdorn6mEA4iZeY0S tH1AlaF6RWa9q04/nF9jfjR5HUpHlBwynU5pWu7+Lsewftig0xtosKR30Eb5fOfG cfZ+SmhBHF9BA5z5ae3oY7s= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 21 Jan 2015 16:18:11 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4175122063.1255.3916; Wed, 21 Jan 2015 16:18:10 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2125; t=1421874998; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kng7h5D 4DTpKPsQcA8Tc1GfMxToKPd2a6ouWtzqWX/8=; b=c7YAtWQp+vJBX2Yq/8vrYmu xRtWz0ZF1jKq0GQEJCZjXSd+3fxtDOlVQCLugWsZYPYPQr6NTCRS9ONGspCjVPzt xotK5u9lUdhmlcIhj+oW9wWCe2C/PRqNEt7hk0HmfghL5qRvuaTcLQUR1u+PpGU9 wdWfc0IWTcC6ORR2hrQ0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 21 Jan 2015 16:16:38 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2767467955.9.9896; Wed, 21 Jan 2015 16:16:36 -0500 Message-ID: <54C0178B.4050905@isdg.net> Date: Wed, 21 Jan 2015 16:18:03 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Anne Bennett , dmarc@ietf.org References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <512967569.45322.1421792072188.JavaMail.zimbra@peachymango.org> <1997519.eG4sQ0KdZQ@scott-latitude-e6320> <1295180662.46088.1421793523542.JavaMail.zimbra@peachymango.org> <10390.1421794462@vindemiatrix.encs.concordia.ca> In-Reply-To: <10390.1421794462@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 21:18:44 -0000 On 1/20/2015 5:54 PM, Anne Bennett wrote: > > Franck Martin writes: > >> Yes, RFC7208 says evaluate both in parallel, but the result >> of an spf=pass/fail is highly constrained on the success or >> failure of the MAIL FROM spf test. > > Actually, it recommends checking the HELO identity first, > because if you get a definite result from that, you may not > have to evaluate the MAIL FROM identity at all. However, in practice, optimized receivers will wait for a valid local RCPT TO (Forward-path) address before exerting any potentially, high overhead, wasteful DNS application queries. For remote RCPT TO address, this generally requires authentication/authorization to relay mail. Under the SUBMIT protocol, HELO/EHLO can be enforced. Our package does not enforce it (it was relaxed) for PORT 587 operations because AUTH is required anyway and in the SOHO market, with NATs around, it was not always possible to put a proper machine client host name for the EHLO/HELO field or the Domain IP Literal was incorrect (did not match the connection ip). But for public port 25 operations, there is a high payoff to wait. We realized a 60% savings in DNS lookups because 60% of the RCPT TO were invalid! SMTP RFC5321 even provides insight into using delay strategies: SMTP Section 3.3 Mail Transactions ..... Despite the apparent scope of this requirement, there are circumstances in which the acceptability of the reverse-path may not be determined until one or more forward-paths (in RCPT commands) can be examined. In those cases, the server MAY reasonably accept the reverse-path (with a 250 reply) and then report problems after the forward-paths are received and examined. Normally, failures produce 550 or 553 replies. Overall, all specs are just guidelines. You don't have to follow them exactly where it doesn't make sense. A RECOMMEND is functionally equivalent to a SHOULD, it is not a MUST. As long as the end result is the same, we should be generally ok so we are basically talking about optimization concepts. -- HLS From nobody Wed Jan 21 14:01:58 2015 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 752851A005A for ; Wed, 21 Jan 2015 14:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 0QRrN0O9j07g for ; Wed, 21 Jan 2015 14:01:55 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id EE9931A0016 for ; Wed, 21 Jan 2015 14:01:54 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 872BC563D52; Wed, 21 Jan 2015 16:01:54 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 764C0A03BD; Wed, 21 Jan 2015 16:01:54 -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 Zvt64s4CVVrB; Wed, 21 Jan 2015 16:01:54 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id ED93AA0285; Wed, 21 Jan 2015 16:01:53 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com ED93AA0285 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421877714; bh=vFUXvLXFBc2FsoXh4esIm3hkJEqKBorNNKWThCYYvxM=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=TrW0XQiGKVy/57gRT3nqFlvj+7Z710z7YGlO+9F68nQObNjhEG7cZ0WFOzlr3UUTR J1tPLip4N0vv4Av9NHN1jXbAc6sAKExn+7+0waueG6Njtfympg30c4b4gWliZYzWSL JzvxEuvNviisb9vHhpjtMsCpMKL4iQ3DCsCbYZI8= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C43B9A0289; Wed, 21 Jan 2015 16:01:53 -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 8LG_zI-fVhlB; Wed, 21 Jan 2015 16:01:53 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 7E2F6A0285; Wed, 21 Jan 2015 16:01:53 -0600 (CST) Date: Wed, 21 Jan 2015 16:01:53 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <1347257699.70903.1421877713064.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <5468593.48012.1421797239927.JavaMail.zimbra@peachymango.org> <2311563.S4yK7lBgP6@scott-latitude-e6320> <947960233.51510.1421818305383.JavaMail.zimbra@peachymango.org> <70BCE1E2-B6CD-4988-9403-75F87D36FA05@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: ... and two more tiny nits, while I'm at it Thread-Index: w3kijxESW6dvbn48ICbxf6g29BFMjw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 22:01:57 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Tuesday, January 20, 2015 9:36:57 PM > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > > On January 21, 2015 12:31:45 AM EST, Franck Martin > wrote: > > > >----- Original Message ----- > >> From: "Scott Kitterman" > >> To: dmarc@ietf.org > >> Sent: Tuesday, January 20, 2015 9:02:26 PM > >> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it > >> > >> On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote: > >> > ----- Original Message ----- > >> > > >> > > From: "Scott Kitterman" > >> > > To: dmarc@ietf.org > >> > > Sent: Tuesday, January 20, 2015 2:49:01 PM > >> > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm > >at it > >> > > > >> > > > >> > > > >> > > > >> > > Last time I had stats, it was about 10% as common as Mail From > >oriented > >> > > records. Much less common, but I wouldn't say rare. When done > >this way, > >> > > there isn't a singe "SPF" result, there are two: SPF/Mail From > >and > >> > > SPF/HELO. Only SPF/Mail From is relevant to DMARC. > >> > > >> > Why do you say that? > >> > > >> > DMARC takes the result from SPF (pass/fail/...) and the string that > >SPF > >> > used > >> > for this result be it mail from or helo, to check for alignment. > >> > > >> > Did I miss something? > >> > >> DMARC takes the SPF result and the Mail From as an input (which in > >the case > >> of > >> a null Mail From is a synthetic Mail From built using HELO, but > >that's just a > >> coincidence). SPF isn't just a result (pass, fail, etc), it also has > >a > >> domain > >> and a related identity. > >> > > > >If I recall the SPF spec, it specifies a MAIL FROM which is not the > >RFC5321.mailfrom, but a mix of RFC5321.mailfrom and RFC5321.helo based > >on which one was used to get the SPF result. > > > >The original SPF spec is quite confusing on that, at least for me. On > >senderid, I think they call this field mfrom to avoid confusion. > > > >It seems weird that the SPF results would depend more on the HELO than > >the RFC5321.mailfrom because if spammer.com put a SPF then > > > >mailfrom: security@example.com > >helo spammer.com > > > >would seem quite problematic.... > > Which is precisely why I said HELO pass doesn't mean anything. HELO is really > for rejection on fail. > >From http://www.openspf.org/Implementations Mail::SPF has passed the test suites http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm "Note: In the case of an empty MAIL FROM SMTP transaction parameter (MAIL FROM:<>), you should perform a check with the helo scope instead." I think we are going in circles here. The SPF spec is not clear or there is a disconnect with what's out there, or both... From nobody Wed Jan 21 14:20:51 2015 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 238741A0393 for ; Wed, 21 Jan 2015 14:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 daQDk5GnKQuN for ; Wed, 21 Jan 2015 14:20:44 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id C6E6D1A0047 for ; Wed, 21 Jan 2015 14:20:43 -0800 (PST) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0LMKhVh030664 for ; Wed, 21 Jan 2015 17:20:43 -0500 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0LMKggC018641 for ; Wed, 21 Jan 2015 17:20:43 -0500 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: DMARC list In-reply-to: Your message of Tue, 20 Jan 2015 17:22:27 PST References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <9329.1421790256@vindemiatrix.encs.concordia.ca> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Wed, 21 Jan 2015 17:20:42 -0500 Message-ID: <18640.1421878842@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-21 17:20:43 EST Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Wed, 21 Jan 2015 22:20:46 -0000 Scott Kitterman writes: > DMARC takes the SPF result and the Mail From as an input > (which in the case of a null Mail From is a synthetic Mail From > built using HELO, but that's just a coincidence). SPF isn't > just a result (pass, fail, etc), it also has a domain and a > related identity. ... in other words, aside from its presence in the null return path case, the HELO identity is *not* used by DMARC. Murray S. Kucherawy writes: > I can say that OpenDMARC consumes the Authentication-Results field, or the > Received-SPF field if the former isn't there, but it prefers a result based > on MAIL FROM over one based on HELO if both are present. But it will use > both. ... in other words, a HELO identity *can* be used by DMARC. Either I'm misunderstanding both of you, or the implementations differ on this point. :-( Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Wed Jan 21 16:23:34 2015 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 C26B71A1A90 for ; Wed, 21 Jan 2015 16:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 2DtTGPpfFNXm for ; Wed, 21 Jan 2015 16:23:31 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4331A1A88 for ; Wed, 21 Jan 2015 16:23:31 -0800 (PST) Received: from [10.184.226.145] (6.sub-70-208-129.myvzw.com [70.208.129.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 76E26C403F1; Wed, 21 Jan 2015 18:26:15 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421886375; bh=GSmq9wi7OXVE24VCpFqSWB78kX06Qq7OiZ0hkINO728=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Yw1C78mvNWXB201n9WSn7/baL4tfBf9C3JGlxlmHDJmNU0P+WsHAeGBfS/dJhwg5m UyxobD1X+CB93+DtD4K3P9h+lr6yA9l/mtox7DOIrybfO8zXTEuSqD0P5//7coiDBW JDNsbuQFgJvU5bNExK64CxSdfa9jV2uPgMk0VwOw= User-Agent: K-9 Mail for Android In-Reply-To: <18640.1421878842@vindemiatrix.encs.concordia.ca> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <9329.1421790256@vindemiatrix.encs.concordia.ca> <18640.1421878842@vindemiatrix.encs.concordia.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Wed, 21 Jan 2015 19:21:06 -0500 To: DMARC list Message-ID: <9A84E250-DB82-4042-B09F-E5C98F74A4EF@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 00:23:32 -0000 On January 21, 2015 5:20:42 PM EST, Anne Bennett wrote: > >Scott Kitterman writes: > >> DMARC takes the SPF result and the Mail From as an input >> (which in the case of a null Mail From is a synthetic Mail From >> built using HELO, but that's just a coincidence). SPF isn't >> just a result (pass, fail, etc), it also has a domain and a >> related identity. > >... in other words, aside from its presence in the null return >path case, the HELO identity is *not* used by DMARC. > > >Murray S. Kucherawy writes: > >> I can say that OpenDMARC consumes the Authentication-Results field, >or the >> Received-SPF field if the former isn't there, but it prefers a result >based >> on MAIL FROM over one based on HELO if both are present. But it will >use >> both. > >... in other words, a HELO identity *can* be used by DMARC. > > >Either I'm misunderstanding both of you, or the implementations differ >on this point. :-( They differ, but I think it's mostly a theoretical difference. Scott K From nobody Wed Jan 21 16:23:45 2015 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 9D74C1A1B2B for ; Wed, 21 Jan 2015 16:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 geFKGG3n0Emw for ; Wed, 21 Jan 2015 16:23:40 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1016F1A1AAC for ; Wed, 21 Jan 2015 16:23:40 -0800 (PST) Received: from [10.184.226.145] (6.sub-70-208-129.myvzw.com [70.208.129.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 87FCFC403F1; Wed, 21 Jan 2015 18:26:24 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421886385; bh=BRD9Apu+bjA9TtEBLZ9dKRtQpMyn75qsvWWCk2BNOY8=; h=In-Reply-To:References:Subject:From:Date:To:From; b=KbiLavyYc1D6LLPlN3Kx5LRY/bSfw12HM454xVudK3ZPOSLO6wH+/ljw2+ddLu+rI 1P2vTyCuiFadx3l2RemKU29q9fb3Lep3O8Oa8/K0ZVumBAUC4c/+UCARaBKPyp4SIF oOTVy0ESx1NbA5ynIN3U84DR9KnXLaOXb9f1yhMU= User-Agent: K-9 Mail for Android In-Reply-To: <1347257699.70903.1421877713064.JavaMail.zimbra@peachymango.org> References: <6716.1421455289@vindemiatrix.encs.concordia.ca> <5468593.48012.1421797239927.JavaMail.zimbra@peachymango.org> <2311563.S4yK7lBgP6@scott-latitude-e6320> <947960233.51510.1421818305383.JavaMail.zimbra@peachymango.org> <70BCE1E2-B6CD-4988-9403-75F87D36FA05@kitterman.com> <1347257699.70903.1421877713064.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Wed, 21 Jan 2015 19:19:44 -0500 To: dmarc@ietf.org Message-ID: Archived-At: Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 00:23:42 -0000 On January 21, 2015 5:01:53 PM EST, Franck Martin wrote: > > > > >----- Original Message ----- >> From: "Scott Kitterman" >> To: dmarc@ietf.org >> Sent: Tuesday, January 20, 2015 9:36:57 PM >> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at it >> >> On January 21, 2015 12:31:45 AM EST, Franck Martin > >> wrote: >> > >> >----- Original Message ----- >> >> From: "Scott Kitterman" >> >> To: dmarc@ietf.org >> >> Sent: Tuesday, January 20, 2015 9:02:26 PM >> >> Subject: Re: [dmarc-ietf] ... and two more tiny nits, while I'm at >it >> >> >> >> On Tuesday, January 20, 2015 17:40:39 Franck Martin wrote: >> >> > ----- Original Message ----- >> >> > >> >> > > From: "Scott Kitterman" >> >> > > To: dmarc@ietf.org >> >> > > Sent: Tuesday, January 20, 2015 2:49:01 PM >> >> > > Subject: Re: [dmarc-ietf] ... and two more tiny nits, while >I'm >> >at it >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > Last time I had stats, it was about 10% as common as Mail From >> >oriented >> >> > > records. Much less common, but I wouldn't say rare. When >done >> >this way, >> >> > > there isn't a singe "SPF" result, there are two: SPF/Mail From >> >and >> >> > > SPF/HELO. Only SPF/Mail From is relevant to DMARC. >> >> > >> >> > Why do you say that? >> >> > >> >> > DMARC takes the result from SPF (pass/fail/...) and the string >that >> >SPF >> >> > used >> >> > for this result be it mail from or helo, to check for alignment. >> >> > >> >> > Did I miss something? >> >> >> >> DMARC takes the SPF result and the Mail From as an input (which in >> >the case >> >> of >> >> a null Mail From is a synthetic Mail From built using HELO, but >> >that's just a >> >> coincidence). SPF isn't just a result (pass, fail, etc), it also >has >> >a >> >> domain >> >> and a related identity. >> >> >> > >> >If I recall the SPF spec, it specifies a MAIL FROM which is not the >> >RFC5321.mailfrom, but a mix of RFC5321.mailfrom and RFC5321.helo >based >> >on which one was used to get the SPF result. >> > >> >The original SPF spec is quite confusing on that, at least for me. >On >> >senderid, I think they call this field mfrom to avoid confusion. >> > >> >It seems weird that the SPF results would depend more on the HELO >than >> >the RFC5321.mailfrom because if spammer.com put a SPF then >> > >> >mailfrom: security@example.com >> >helo spammer.com >> > >> >would seem quite problematic.... >> >> Which is precisely why I said HELO pass doesn't mean anything. HELO >is really >> for rejection on fail. >> >>From http://www.openspf.org/Implementations Mail::SPF has passed the >test suites > >http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm >"Note: In the case of an empty MAIL FROM SMTP transaction parameter >(MAIL FROM:<>), you should perform a check with the helo scope >instead." > >I think we are going in circles here. > >The SPF spec is not clear or there is a disconnect with what's out >there, or both... By design, SPF doesn't go very far into what receivers should do. Unlike DMARC, it actively avoids specifying receiver policy. It's not clear what to do because what to do is outside the scope of the specification. Scott K From nobody Thu Jan 22 10:27:45 2015 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 26A2A1ACEF6 for ; Thu, 22 Jan 2015 10:27:44 -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 XqVqo1c3f97x for ; Thu, 22 Jan 2015 10:27:42 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027F91ACEB1 for ; Thu, 22 Jan 2015 10:27:42 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id bs8so42088179wib.0 for ; Thu, 22 Jan 2015 10:27:40 -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=fnJsZySfnGM96xlvwhbBE0qlyHUIJTld3pIKs5w6R+8=; b=lBQcfN9C8GIxjwjT4RpYT81EjeJGDj3gT3JofjJmqP8IZ27givUJNEx2AN0t20Hozv DpcAjQleiod7++SszfcKCniBvT1FjZmTNAL7HA6DlNZSdOSgHwAUrdh8ydZnAbhTN9pe LddNR5+JJiD1ym48JkF84KwKu5lLW76H6EP8+qnm1UaCCaqU20D5ElkrOV7NrT4OCSvk vBRbtR7dAl8iRgn+SP0eLGNBYseicZ36vQDPUDM2lb0HOFEGbMMACyEYWuCpFXSLB4fB 7+kjL1oL/lyD+Q4SipO+ncUWkma2NLwk10Bbjq2xYkVg650MDuVKtyjAEUkfvCec6Ifu 36ZQ== MIME-Version: 1.0 X-Received: by 10.180.218.39 with SMTP id pd7mr7819621wic.21.1421951260769; Thu, 22 Jan 2015 10:27:40 -0800 (PST) Received: by 10.27.204.198 with HTTP; Thu, 22 Jan 2015 10:27:40 -0800 (PST) In-Reply-To: References: <20150121021457.1947.qmail@ary.lan> Date: Thu, 22 Jan 2015 10:27:40 -0800 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a1134cd58c944fc050d41d3e7 Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 18:27:44 -0000 --001a1134cd58c944fc050d41d3e7 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy wrote: > I am asking the IESG and the ISE what the process is for making such > adjustments now. > > Mainly my resistance to further change comes from the fact that we've done > last calls of varying kinds on this document more times than I can count. > It really is time to put the non-IETF version to bed and hand it off, even > with its weaknesses, and let the standards process take it from there. > There's a working group already chartered to do exactly that; in fact, that > was one of the premises of creating that working group. > I've consulted with the Area Director sponsoring the document's conflict review, and the ISE. Both of them agree that we will only make changes approved by the ISE and only during AUTH48 at this point, and those will be limited to correcting serious problems that would prevent current DMARC implementations from interacting properly. Anything else can be left to the DMARC working group on its standards track deliverable. An argument can be made that this proposed change qualifies under that definition, so please review it and comment as to whether it satisfies the defect identified, or whether the change is necessary at all. I will assume "yes" unless I hear otherwise. Again, the diff is here: http://www.blackops.org/~msk/dmarc/diff.html -MSK --001a1134cd58c944fc050d41d3e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy <= superuser@gmail.com> wrote:
<= div dir=3D"ltr">I am asking the IESG and the ISE what the process is for ma= king such adjustments now.

Mainly my resistance to further change comes from the fac= t that we've done last calls of varying kinds on this document more tim= es than I can count.=C2=A0 It really is time to put the non-IETF version to= bed and hand it off, even with its weaknesses, and let the standards proce= ss take it from there.=C2=A0 There's a working group already chartered = to do exactly that; in fact, that was one of the premises of creating that = working group.
I've consulted with the Area Director sponsoring the docum= ent's conflict review, and the ISE.=C2=A0 Both of them agree that we wi= ll only make changes approved by the ISE and only during AUTH48 at this poi= nt, and those will be limited to correcting serious problems that would pre= vent current DMARC implementations from interacting properly.=C2=A0 Anythin= g else can be left to the DMARC working group on its standards track delive= rable.

An argument can be made that this proposed change = qualifies under that definition, so please review it and comment as to whet= her it satisfies the defect identified, or whether the change is necessary = at all.=C2=A0 I will assume "yes" unless I hear otherwise.=C2=A0 = Again, the diff is here:

http://www.blackops.org/~msk/dmarc/diff.html

-MSK<= br>

--001a1134cd58c944fc050d41d3e7-- From nobody Thu Jan 22 10:48:12 2015 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 7D5EF1B29B0 for ; Thu, 22 Jan 2015 10:48:10 -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, 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 vBxBvdu3c4-g for ; Thu, 22 Jan 2015 10:48:06 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id A74DB1AD369 for ; Thu, 22 Jan 2015 10:48:06 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 15CA6563F8F; Thu, 22 Jan 2015 12:48:06 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0C04AA03C8; Thu, 22 Jan 2015 12:48:06 -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 VTTOvKx4Srjv; Thu, 22 Jan 2015 12:48:05 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 91FC3A03DF; Thu, 22 Jan 2015 12:48:05 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 91FC3A03DF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421952485; bh=/7G4YZUUrN2MRGG1B6SaALI5f58d5UdvtbDtv6sqAhU=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=rsGYs4fvUAK9deZ/Id72wDiu51hKYTfHx8U3cr4TULuvZ4i7fmM56LrgsA/+LIsCX AVd0hJDIL/wgvwgFypPnoyZPdbYZ3etHnjiqhkbO6UjDNjAqk6PxfAsaVTObbm3Rn+ vV6Y2vdVHRkXnGR1DLs3T4ke/eD5RaRaaZGo4SE0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 80B9CA03C8; Thu, 22 Jan 2015 12:48:05 -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 RWK0PbbgDOXQ; Thu, 22 Jan 2015 12:48:05 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 56D6BA03E7; Thu, 22 Jan 2015 12:48:05 -0600 (CST) Date: Thu, 22 Jan 2015 12:48:03 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150121021457.1947.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_92118_357630589.1421952483626" X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: PwMyvcQlUEbf6VwmyL0JjYiw0yCJ0Q== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 18:48:10 -0000 ------=_Part_92118_357630589.1421952483626 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 10:27:40 AM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < superuser@gmail.com > > wrote: > > I am asking the IESG and the ISE what the process is for making such > > adjustments now. > > > Mainly my resistance to further change comes from the fact that we've done > > last calls of varying kinds on this document more times than I can count. > > It > > really is time to put the non-IETF version to bed and hand it off, even > > with > > its weaknesses, and let the standards process take it from there. There's a > > working group already chartered to do exactly that; in fact, that was one > > of > > the premises of creating that working group. > > I've consulted with the Area Director sponsoring the document's conflict > review, and the ISE. Both of them agree that we will only make changes > approved by the ISE and only during AUTH48 at this point, and those will be > limited to correcting serious problems that would prevent current DMARC > implementations from interacting properly. Anything else can be left to the > DMARC working group on its standards track deliverable. > An argument can be made that this proposed change qualifies under that > definition, so please review it and comment as to whether it satisfies the > defect identified, or whether the change is necessary at all. I will assume > "yes" unless I hear otherwise. Again, the diff is here: > http://www.blackops.org/~msk/dmarc/diff.html Hold on... What is the decision matrix of SPF? SPF uses two strings, the RFC5321.mailfrom and the RFC5321.helo. Each string may or may not have an SPF record. What gives the spf status? ------=_Part_92118_357630589.1421952483626 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: dmarc@ietf.org
Sent: Thursday, Januar= y 22, 2015 10:27:40 AM
Subject: Re: [dmarc-ietf] questions on the= spec, was ... and two more tiny nits, while I'm at it

On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy <su= peruser@gmail.com> wrote:
I am asking the IESG and the ISE what the process is for maki= ng such adjustments now.

Mainly my resistance to further change comes from the fact = that we've done last calls of varying kinds on this document more times tha= n I can count.  It really is time to put the non-IETF version to bed a= nd hand it off, even with its weaknesses, and let the standards process tak= e it from there.  There's a working group already chartered to do exac= tly that; in fact, that was one of the premises of creating that working gr= oup.

I've consu= lted with the Area Director sponsoring the document's conflict review, and = the ISE.  Both of them agree that we will only make changes approved b= y the ISE and only during AUTH48 at this point, and those will be limited t= o correcting serious problems that would prevent current DMARC implementati= ons from interacting properly.  Anything else can be left to the DMARC= working group on its standards track deliverable.

=
An argument can be made that this proposed change qualifies under that= definition, so please review it and comment as to whether it satisfies the= defect identified, or whether the change is necessary at all.  I will= assume "yes" unless I hear otherwise.  Again, the diff is here:

http://www.blackops.org/~msk/dmarc/diff.html

<= /div>
Hold on...
What is the decision matrix of SPF?

SPF uses two strings, the RFC5321.mailfrom and the RFC5321.helo. Each str= ing may or may not have an SPF record. What gives the spf status?
= ------=_Part_92118_357630589.1421952483626-- From nobody Thu Jan 22 12:01:14 2015 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 BCD231A86EC for ; Thu, 22 Jan 2015 12:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 zNd4jV4jDOxC for ; Thu, 22 Jan 2015 12:01:10 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6521B2A53 for ; Thu, 22 Jan 2015 12:01:00 -0800 (PST) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0MK0weI028326 for ; Thu, 22 Jan 2015 15:00:58 -0500 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0MK0wl0020115 for ; Thu, 22 Jan 2015 15:00:58 -0500 Message-Id: <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: dmarc@ietf.org From: Michael Jack Assels In-reply-to: <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> References: <20150121021457.1947.qmail@ary.lan> <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> Comments: In-reply-to Franck Martin message dated "Thu, 22 Jan 2015 12:48:03 -0600." Date: Thu, 22 Jan 2015 15:00:58 -0500 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-22 15:00:58 EST Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 20:01:12 -0000 On Thu, 22 Jan 2015 12:48:03 CST, Franck Martin wrote: > ----- Original Message ----- > > > From: "Murray S. Kucherawy" > > To: dmarc@ietf.org > > Sent: Thursday, January 22, 2015 10:27:40 AM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < superuser@gmail.com > > > wrote: > > > > I am asking the IESG and the ISE what the process is for > > > making such adjustments now. > > > > > > Mainly my resistance to further change comes from the fact > > > that we've done last calls of varying kinds on this > > > document more times than I can count. It really is time to > > > put the non-IETF version to bed and hand it off, even with > > > its weaknesses, and let the standards process take it from > > > there. There's a working group already chartered to do > > > exactly that; in fact, that was one of the premises of > > > creating that working group. > > > > I've consulted with the Area Director sponsoring the > > document's conflict review, and the ISE. Both of them agree > > that we will only make changes approved by the ISE and only > > during AUTH48 at this point, and those will be limited to > > correcting serious problems that would prevent current DMARC > > implementations from interacting properly. Anything else can > > be left to the DMARC working group on its standards track > > deliverable. > > > An argument can be made that this proposed change qualifies > > under that definition, so please review it and comment as to > > whether it satisfies the defect identified, or whether the > > change is necessary at all. I will assume "yes" unless I hear > > otherwise. Again, the diff is here: > > > http://www.blackops.org/~msk/dmarc/diff.html > > Hold on... > > What is the decision matrix of SPF? > > SPF uses two strings, the RFC5321.mailfrom and the > RFC5321.helo. Each string may or may not have an SPF record. > What gives the spf status? As I read RFC7208, it doesn't explicitly provide a decision matrix, but it does clearly recommend in section 2.3, that [i]f a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided." Section 2.4 provides that "SPF verifiers MUST check the [RFC5321.mailfrom] identity if a [RFC5321.helo] check either has not been performed or has not reached a definitive policy" I can't think of a way to read that that doesn't imply that a "pass" or a "fail" on the basis of an SPF record for the RFC5321.helo indentity (if such a record exists) is the spf result; otherwise, the result is based on the RFC5321.mailfrom identity. I believe that this is not what DMARC implementations actually do, and that the proposed change to the draft correctly points out the difference and makes it clear what DMARC does, so if I had a vote, I'd vote "yes" to the change. MJA From nobody Thu Jan 22 12:26:40 2015 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 4FFF11B2A14 for ; Thu, 22 Jan 2015 12:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Y7NSyM_Pzods for ; Thu, 22 Jan 2015 12:26:34 -0800 (PST) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91ED71A86EA for ; Thu, 22 Jan 2015 12:26:34 -0800 (PST) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Thu, 22 Jan 2015 15:26:32 -0500 From: "MH Michael Hammer (5304)" To: "Murray S. Kucherawy" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: AQHQNSAiQ6lhQZMJYU29fjeM2niJOZzLRhGAgAGFtQD//804gA== Date: Thu, 22 Jan 2015 20:26:31 +0000 Message-ID: References: <20150121021457.1947.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.204] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CE39F90A45FF0C49A1EA229FC9899B0525F73A62USCLES544agnaam_" MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 20:26:38 -0000 --_000_CE39F90A45FF0C49A1EA229FC9899B0525F73A62USCLES544agnaam_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIHJldmlld2VkIHRoZSBkaWZmIGJldHdlZW4gLTEyIGFuZCAtMTMgYW5kIEnigJltIGNv bWZvcnRhYmxlIHdpdGggdGhlIGNoYW5nZXMuDQoNCk1pa2UNCg0KRnJvbTogZG1hcmMgW21haWx0 bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTXVycmF5IFMuIEt1Y2hlcmF3 eQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjIsIDIwMTUgMToyOCBQTQ0KVG86IGRtYXJjQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIHF1ZXN0aW9ucyBvbiB0aGUgc3BlYywg d2FzIC4uLiBhbmQgdHdvIG1vcmUgdGlueSBuaXRzLCB3aGlsZSBJJ20gYXQgaXQNCg0KT24gV2Vk LCBKYW4gMjEsIDIwMTUgYXQgMTE6MTIgQU0sIE11cnJheSBTLiBLdWNoZXJhd3kgPHN1cGVydXNl ckBnbWFpbC5jb208bWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb20+PiB3cm90ZToNCkkgYW0gYXNr aW5nIHRoZSBJRVNHIGFuZCB0aGUgSVNFIHdoYXQgdGhlIHByb2Nlc3MgaXMgZm9yIG1ha2luZyBz dWNoIGFkanVzdG1lbnRzIG5vdy4NCg0KTWFpbmx5IG15IHJlc2lzdGFuY2UgdG8gZnVydGhlciBj aGFuZ2UgY29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IHdlJ3ZlIGRvbmUgbGFzdCBjYWxscyBvZiB2 YXJ5aW5nIGtpbmRzIG9uIHRoaXMgZG9jdW1lbnQgbW9yZSB0aW1lcyB0aGFuIEkgY2FuIGNvdW50 LiAgSXQgcmVhbGx5IGlzIHRpbWUgdG8gcHV0IHRoZSBub24tSUVURiB2ZXJzaW9uIHRvIGJlZCBh bmQgaGFuZCBpdCBvZmYsIGV2ZW4gd2l0aCBpdHMgd2Vha25lc3NlcywgYW5kIGxldCB0aGUgc3Rh bmRhcmRzIHByb2Nlc3MgdGFrZSBpdCBmcm9tIHRoZXJlLiAgVGhlcmUncyBhIHdvcmtpbmcgZ3Jv dXAgYWxyZWFkeSBjaGFydGVyZWQgdG8gZG8gZXhhY3RseSB0aGF0OyBpbiBmYWN0LCB0aGF0IHdh cyBvbmUgb2YgdGhlIHByZW1pc2VzIG9mIGNyZWF0aW5nIHRoYXQgd29ya2luZyBncm91cC4NCg0K SSd2ZSBjb25zdWx0ZWQgd2l0aCB0aGUgQXJlYSBEaXJlY3RvciBzcG9uc29yaW5nIHRoZSBkb2N1 bWVudCdzIGNvbmZsaWN0IHJldmlldywgYW5kIHRoZSBJU0UuICBCb3RoIG9mIHRoZW0gYWdyZWUg dGhhdCB3ZSB3aWxsIG9ubHkgbWFrZSBjaGFuZ2VzIGFwcHJvdmVkIGJ5IHRoZSBJU0UgYW5kIG9u bHkgZHVyaW5nIEFVVEg0OCBhdCB0aGlzIHBvaW50LCBhbmQgdGhvc2Ugd2lsbCBiZSBsaW1pdGVk IHRvIGNvcnJlY3Rpbmcgc2VyaW91cyBwcm9ibGVtcyB0aGF0IHdvdWxkIHByZXZlbnQgY3VycmVu dCBETUFSQyBpbXBsZW1lbnRhdGlvbnMgZnJvbSBpbnRlcmFjdGluZyBwcm9wZXJseS4gIEFueXRo aW5nIGVsc2UgY2FuIGJlIGxlZnQgdG8gdGhlIERNQVJDIHdvcmtpbmcgZ3JvdXAgb24gaXRzIHN0 YW5kYXJkcyB0cmFjayBkZWxpdmVyYWJsZS4NCkFuIGFyZ3VtZW50IGNhbiBiZSBtYWRlIHRoYXQg dGhpcyBwcm9wb3NlZCBjaGFuZ2UgcXVhbGlmaWVzIHVuZGVyIHRoYXQgZGVmaW5pdGlvbiwgc28g cGxlYXNlIHJldmlldyBpdCBhbmQgY29tbWVudCBhcyB0byB3aGV0aGVyIGl0IHNhdGlzZmllcyB0 aGUgZGVmZWN0IGlkZW50aWZpZWQsIG9yIHdoZXRoZXIgdGhlIGNoYW5nZSBpcyBuZWNlc3Nhcnkg YXQgYWxsLiAgSSB3aWxsIGFzc3VtZSAieWVzIiB1bmxlc3MgSSBoZWFyIG90aGVyd2lzZS4gIEFn YWluLCB0aGUgZGlmZiBpcyBoZXJlOg0KDQpodHRwOi8vd3d3LmJsYWNrb3BzLm9yZy9+bXNrL2Rt YXJjL2RpZmYuaHRtbA0KDQotTVNLDQoNCg== --_000_CE39F90A45FF0C49A1EA229FC9899B0525F73A62USCLES544agnaam_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmXZlIHJldmlld2Vk IHRoZSBkaWZmIGJldHdlZW4gLTEyIGFuZCAtMTMgYW5kIEnigJltIGNvbWZvcnRhYmxlIHdpdGgg dGhlIGNoYW5nZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IGRtYXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+TXVycmF5IFMuIEt1Y2hlcmF3eTxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSmFudWFyeSAyMiwgMjAxNSAxOjI4IFBNPGJyPg0KPGI+VG86PC9iPiBkbWFyY0Bp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZdIHF1ZXN0aW9ucyBv biB0aGUgc3BlYywgd2FzIC4uLiBhbmQgdHdvIG1vcmUgdGlueSBuaXRzLCB3aGlsZSBJJ20gYXQg aXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gV2VkLCBKYW4gMjEsIDIwMTUgYXQgMTE6MTIgQU0sIE11cnJheSBTLiBLdWNoZXJhd3kgJmx0 OzxhIGhyZWY9Im1haWx0bzpzdXBlcnVzZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3Vw ZXJ1c2VyQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gYXNraW5n IHRoZSBJRVNHIGFuZCB0aGUgSVNFIHdoYXQgdGhlIHByb2Nlc3MgaXMgZm9yIG1ha2luZyBzdWNo IGFkanVzdG1lbnRzIG5vdy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk1haW5seSBteSByZXNpc3RhbmNlIHRvIGZ1cnRoZXIg Y2hhbmdlIGNvbWVzIGZyb20gdGhlIGZhY3QgdGhhdCB3ZSd2ZSBkb25lIGxhc3QgY2FsbHMgb2Yg dmFyeWluZyBraW5kcyBvbiB0aGlzIGRvY3VtZW50IG1vcmUgdGltZXMgdGhhbiBJIGNhbiBjb3Vu dC4mbmJzcDsgSXQgcmVhbGx5IGlzIHRpbWUgdG8gcHV0IHRoZSBub24tSUVURiB2ZXJzaW9uIHRv IGJlZCBhbmQgaGFuZCBpdCBvZmYsIGV2ZW4gd2l0aCBpdHMgd2Vha25lc3NlcywgYW5kIGxldCB0 aGUNCiBzdGFuZGFyZHMgcHJvY2VzcyB0YWtlIGl0IGZyb20gdGhlcmUuJm5ic3A7IFRoZXJlJ3Mg YSB3b3JraW5nIGdyb3VwIGFscmVhZHkgY2hhcnRlcmVkIHRvIGRvIGV4YWN0bHkgdGhhdDsgaW4g ZmFjdCwgdGhhdCB3YXMgb25lIG9mIHRoZSBwcmVtaXNlcyBvZiBjcmVhdGluZyB0aGF0IHdvcmtp bmcgZ3JvdXAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SSd2ZSBjb25zdWx0ZWQgd2l0aCB0aGUgQXJlYSBEaXJlY3RvciBz cG9uc29yaW5nIHRoZSBkb2N1bWVudCdzIGNvbmZsaWN0IHJldmlldywgYW5kIHRoZSBJU0UuJm5i c3A7IEJvdGggb2YgdGhlbSBhZ3JlZSB0aGF0IHdlIHdpbGwgb25seSBtYWtlIGNoYW5nZXMgYXBw cm92ZWQgYnkgdGhlIElTRSBhbmQgb25seSBkdXJpbmcgQVVUSDQ4IGF0IHRoaXMgcG9pbnQsIGFu ZA0KIHRob3NlIHdpbGwgYmUgbGltaXRlZCB0byBjb3JyZWN0aW5nIHNlcmlvdXMgcHJvYmxlbXMg dGhhdCB3b3VsZCBwcmV2ZW50IGN1cnJlbnQgRE1BUkMgaW1wbGVtZW50YXRpb25zIGZyb20gaW50 ZXJhY3RpbmcgcHJvcGVybHkuJm5ic3A7IEFueXRoaW5nIGVsc2UgY2FuIGJlIGxlZnQgdG8gdGhl IERNQVJDIHdvcmtpbmcgZ3JvdXAgb24gaXRzIHN0YW5kYXJkcyB0cmFjayBkZWxpdmVyYWJsZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuIGFy Z3VtZW50IGNhbiBiZSBtYWRlIHRoYXQgdGhpcyBwcm9wb3NlZCBjaGFuZ2UgcXVhbGlmaWVzIHVu ZGVyIHRoYXQgZGVmaW5pdGlvbiwgc28gcGxlYXNlIHJldmlldyBpdCBhbmQgY29tbWVudCBhcyB0 byB3aGV0aGVyIGl0IHNhdGlzZmllcyB0aGUgZGVmZWN0IGlkZW50aWZpZWQsIG9yIHdoZXRoZXIg dGhlIGNoYW5nZSBpcyBuZWNlc3NhcnkgYXQgYWxsLiZuYnNwOyBJIHdpbGwgYXNzdW1lICZxdW90 O3llcyZxdW90OyB1bmxlc3MNCiBJIGhlYXIgb3RoZXJ3aXNlLiZuYnNwOyBBZ2FpbiwgdGhlIGRp ZmYgaXMgaGVyZTo8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmJsYWNrb3BzLm9yZy9+ bXNrL2RtYXJjL2RpZmYuaHRtbCI+aHR0cDovL3d3dy5ibGFja29wcy5vcmcvfm1zay9kbWFyYy9k aWZmLmh0bWw8L2E+PGJyPg0KPGJyPg0KLU1TSzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CE39F90A45FF0C49A1EA229FC9899B0525F73A62USCLES544agnaam_-- From nobody Thu Jan 22 12:47:06 2015 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 704AE1A876B for ; Thu, 22 Jan 2015 12:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 F-di-M8n6FUz for ; Thu, 22 Jan 2015 12:47:01 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id A435F1A8760 for ; Thu, 22 Jan 2015 12:47:01 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 66F0E563C99; Thu, 22 Jan 2015 14:47:00 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4B88FA040B; Thu, 22 Jan 2015 14:47:00 -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 ohpgOsT69QFr; Thu, 22 Jan 2015 14:47:00 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E2D5EA040E; Thu, 22 Jan 2015 14:46:59 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com E2D5EA040E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421959620; bh=SsAr2EsMDOuj2zcPv+PLH0GvX4RZL1+dn5CuvMMNxFs=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=JV8caa35IHaMMqUeJQKeNmi0Qr7GQ91IZbMmfB058ioasejobPdC1RNPz1WfpjQkd NqNYh6YYsHDCxe4hverM7JoCJlR/+ISkZcrPsF2/0g2JLHoGY5kovw0JnQqnjW0Qtu yiRFV8uraRyaOsBj9gi9m6PXbQ0562iRB3ScAB5w= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D4E01A040B; Thu, 22 Jan 2015 14:46:59 -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 53j6E_AoUp65; Thu, 22 Jan 2015 14:46:59 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 9B808A0406; Thu, 22 Jan 2015 14:46:59 -0600 (CST) Date: Thu, 22 Jan 2015 14:46:59 -0600 (CST) From: Franck Martin To: Michael Jack Assels Message-ID: <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150121021457.1947.qmail@ary.lan> <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: GdjgSdm2s7lB8t02GkwoztPP0V7Uvg== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 20:47:04 -0000 ----- Original Message ----- > From: "Michael Jack Assels" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 12:00:58 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > On Thu, 22 Jan 2015 12:48:03 CST, > Franck Martin wrote: > > > ----- Original Message ----- > > > > > From: "Murray S. Kucherawy" > > > To: dmarc@ietf.org > > > Sent: Thursday, January 22, 2015 10:27:40 AM > > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > > > tiny nits, while I'm at it > > > > > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < > > > superuser@gmail.com > > > > wrote: > > > > > > I am asking the IESG and the ISE what the process is for > > > > making such adjustments now. > > > > > > > > > Mainly my resistance to further change comes from the fact > > > > that we've done last calls of varying kinds on this > > > > document more times than I can count. It really is time to > > > > put the non-IETF version to bed and hand it off, even with > > > > its weaknesses, and let the standards process take it from > > > > there. There's a working group already chartered to do > > > > exactly that; in fact, that was one of the premises of > > > > creating that working group. > > > > > > > I've consulted with the Area Director sponsoring the > > > document's conflict review, and the ISE. Both of them agree > > > that we will only make changes approved by the ISE and only > > > during AUTH48 at this point, and those will be limited to > > > correcting serious problems that would prevent current DMARC > > > implementations from interacting properly. Anything else can > > > be left to the DMARC working group on its standards track > > > deliverable. > > > > > An argument can be made that this proposed change qualifies > > > under that definition, so please review it and comment as to > > > whether it satisfies the defect identified, or whether the > > > change is necessary at all. I will assume "yes" unless I hear > > > otherwise. Again, the diff is here: > > > > > http://www.blackops.org/~msk/dmarc/diff.html > > > > Hold on... > > > > What is the decision matrix of SPF? > > > > SPF uses two strings, the RFC5321.mailfrom and the > > RFC5321.helo. Each string may or may not have an SPF record. > > What gives the spf status? > > As I read RFC7208, it doesn't explicitly provide a decision > matrix, but it does clearly recommend in section 2.3, that > [i]f a conclusive determination about the message can be made > based on a check of "HELO", then the use of DNS resources to > process the typically more complex "MAIL FROM" can be avoided." > > Section 2.4 provides that "SPF verifiers MUST check the > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either > has not been performed or has not reached a definitive policy" > > I can't think of a way to read that that doesn't imply that > a "pass" or a "fail" on the basis of an SPF record for the > RFC5321.helo indentity (if such a record exists) is the spf > result; otherwise, the result is based on the RFC5321.mailfrom > identity. > > I believe that this is not what DMARC implementations actually > do, and that the proposed change to the draft correctly points > out the difference and makes it clear what DMARC does, so if > I had a vote, I'd vote "yes" to the change. > Ok, but a specific well known implementation does not seem to do that: >From http://www.openspf.org/Implementations Mail::SPF has passed the test suites http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm "Note: In the case of an empty MAIL FROM SMTP transaction parameter (MAIL FROM:<>), you should perform a check with the helo scope instead." an RFC to reach standard status needs to represent what is out there, I'd like to see more code before I form an opinion. From nobody Thu Jan 22 13:20:47 2015 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 7BB421B2A47 for ; Thu, 22 Jan 2015 13:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 glUjJbF0duxP for ; Thu, 22 Jan 2015 13:20:38 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id E3B091A87CD for ; Thu, 22 Jan 2015 13:20:36 -0800 (PST) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0MLKZxN010783 for ; Thu, 22 Jan 2015 16:20:35 -0500 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0MLKZWt020710 for ; Thu, 22 Jan 2015 16:20:35 -0500 Message-Id: <201501222120.t0MLKZWt020710@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: dmarc@ietf.org From: Michael Jack Assels In-reply-to: <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> References: <20150121021457.1947.qmail@ary.lan> <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> Comments: In-reply-to Franck Martin message dated "Thu, 22 Jan 2015 14:46:59 -0600." Date: Thu, 22 Jan 2015 16:20:35 -0500 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-22 16:20:35 EST Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 21:20:45 -0000 On Thu, 22 Jan 2015 14:46:59 CST, Franck Martin wrote: > ----- Original Message ----- > > From: "Michael Jack Assels" > > To: dmarc@ietf.org > > Sent: Thursday, January 22, 2015 12:00:58 PM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > > > On Thu, 22 Jan 2015 12:48:03 CST, > > Franck Martin wrote: > > > > > [....] > > > > > > Hold on... > > > > > > What is the decision matrix of SPF? > > > > > > SPF uses two strings, the RFC5321.mailfrom and the > > > RFC5321.helo. Each string may or may not have an SPF record. > > > What gives the spf status? > > > > As I read RFC7208, it doesn't explicitly provide a decision > > matrix, but it does clearly recommend in section 2.3, that > > [i]f a conclusive determination about the message can be made > > based on a check of "HELO", then the use of DNS resources to > > process the typically more complex "MAIL FROM" can be avoided." > > > > Section 2.4 provides that "SPF verifiers MUST check the > > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either > > has not been performed or has not reached a definitive policy" > > > > I can't think of a way to read that that doesn't imply that > > a "pass" or a "fail" on the basis of an SPF record for the > > RFC5321.helo indentity (if such a record exists) is the spf > > result; otherwise, the result is based on the RFC5321.mailfrom > > identity. > > > > I believe that this is not what DMARC implementations actually > > do, and that the proposed change to the draft correctly points > > out the difference and makes it clear what DMARC does, so if > > I had a vote, I'd vote "yes" to the change. > > > > Ok, but a specific well known implementation does not seem to > do that: From http://www.openspf.org/Implementations Mail::SPF > has passed the test suites > > http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm > "Note: In the case of an empty MAIL FROM SMTP transaction > parameter (MAIL FROM:<>), you should perform a check with the > helo scope instead." This is what the proposed change says, isn't it? > an RFC to reach standard status needs to represent what is out > there, I'd like to see more code before I form an opinion. I think we've crossed wires here. I unreservedly agree that RFC7208 does NOT represent what all DMARC implementations do, and it may not even represent what all SPF implementations do. Perhaps RFC7208 needs correction, but given what it says now, and given that DMARC has an obvious dependency on SPF, it's important that DMARC's standard should say "contrary to what RFC7208 recommends, DMARC normally SPF-checks HELO only when MAIL FROM is <>". I don't think we're disagreeing about what DMARC does, or even about what SPF usually does, despite what RFC7208 says. MJA From nobody Thu Jan 22 14:29:22 2015 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 1C38C1A885A for ; Thu, 22 Jan 2015 14:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, 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 N-C87pKaRmc4 for ; Thu, 22 Jan 2015 14:29:14 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8E21A8856 for ; Thu, 22 Jan 2015 14:29:13 -0800 (PST) Received: from [10.173.75.215] (187.sub-70-208-151.myvzw.com [70.208.151.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 455DDC40029; Thu, 22 Jan 2015 16:32:09 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421965929; bh=+b/+ul3nZzI+XtHgCT4EyInJbmBAtWZJx345vxECiNo=; h=In-Reply-To:References:Subject:From:Date:To:From; b=EEeUvp146xCVYr9eqEXHJY7bo7CnZmyj4+Ks4jUmmjCxvYfzIH56n9jIdChEJHWkQ SIh7NZ29QUa3RDSXHjamVonKeUYIaGfPNz108Fogw2lmBQayTPFBgRobSAe7CCEmqa p4VyrkOcVc29Nl8TpvtrNs/rsVq9LVvhmiszXvak= User-Agent: K-9 Mail for Android In-Reply-To: <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> References: <20150121021457.1947.qmail@ary.lan> <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 22 Jan 2015 17:18:56 -0500 To: dmarc@ietf.org Message-ID: <9690B8A4-36FF-4509-B413-D84AA1DB79CF@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 22:29:16 -0000 On January 22, 2015 3:46:59 PM EST, Franck Martin wrote: > > > > >----- Original Message ----- >> From: "Michael Jack Assels" >> To: dmarc@ietf.org >> Sent: Thursday, January 22, 2015 12:00:58 PM >> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more >tiny nits, while I'm at it >> >> On Thu, 22 Jan 2015 12:48:03 CST, >> Franck Martin wrote: >> >> > ----- Original Message ----- >> > >> > > From: "Murray S. Kucherawy" >> > > To: dmarc@ietf.org >> > > Sent: Thursday, January 22, 2015 10:27:40 AM >> > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two >more >> > > tiny nits, while I'm at it >> > >> > > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < >> > > superuser@gmail.com > >> > > wrote: >> > >> > > > I am asking the IESG and the ISE what the process is for >> > > > making such adjustments now. >> > > >> > >> > > > Mainly my resistance to further change comes from the fact >> > > > that we've done last calls of varying kinds on this >> > > > document more times than I can count. It really is time to >> > > > put the non-IETF version to bed and hand it off, even with >> > > > its weaknesses, and let the standards process take it from >> > > > there. There's a working group already chartered to do >> > > > exactly that; in fact, that was one of the premises of >> > > > creating that working group. >> > > >> >> > > I've consulted with the Area Director sponsoring the >> > > document's conflict review, and the ISE. Both of them agree >> > > that we will only make changes approved by the ISE and only >> > > during AUTH48 at this point, and those will be limited to >> > > correcting serious problems that would prevent current DMARC >> > > implementations from interacting properly. Anything else can >> > > be left to the DMARC working group on its standards track >> > > deliverable. >> > >> > > An argument can be made that this proposed change qualifies >> > > under that definition, so please review it and comment as to >> > > whether it satisfies the defect identified, or whether the >> > > change is necessary at all. I will assume "yes" unless I hear >> > > otherwise. Again, the diff is here: >> > >> > > http://www.blackops.org/~msk/dmarc/diff.html >> > >> > Hold on... >> > >> > What is the decision matrix of SPF? >> > >> > SPF uses two strings, the RFC5321.mailfrom and the >> > RFC5321.helo. Each string may or may not have an SPF record. >> > What gives the spf status? >> >> As I read RFC7208, it doesn't explicitly provide a decision >> matrix, but it does clearly recommend in section 2.3, that >> [i]f a conclusive determination about the message can be made >> based on a check of "HELO", then the use of DNS resources to >> process the typically more complex "MAIL FROM" can be avoided." >> >> Section 2.4 provides that "SPF verifiers MUST check the >> [RFC5321.mailfrom] identity if a [RFC5321.helo] check either >> has not been performed or has not reached a definitive policy" >> >> I can't think of a way to read that that doesn't imply that >> a "pass" or a "fail" on the basis of an SPF record for the >> RFC5321.helo indentity (if such a record exists) is the spf >> result; otherwise, the result is based on the RFC5321.mailfrom >> identity. >> >> I believe that this is not what DMARC implementations actually >> do, and that the proposed change to the draft correctly points >> out the difference and makes it clear what DMARC does, so if >> I had a vote, I'd vote "yes" to the change. >> > >Ok, but a specific well known implementation does not seem to do that: >>From http://www.openspf.org/Implementations Mail::SPF has passed the >test suites > >http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm >"Note: In the case of an empty MAIL FROM SMTP transaction parameter >(MAIL FROM:<>), you should perform a check with the helo scope >instead." > >an RFC to reach standard status needs to represent what is out there, >I'd like to see more code before I form an opinion. Mail::SPF is a library that can be called by various applications. It's not an application which is where such logic would be implemented. You're quoting one library author's recommendations to application developers, not an actual implementation detail. Note:also not yet updated for RFC 7208. Also, DMARC isn't standards track. DMARC leverages the Mail From identity, so I don't see how independent HELO checks can be relevant. Scott K From nobody Thu Jan 22 14:47:51 2015 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 9969D1A07BD for ; Thu, 22 Jan 2015 14:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 n8PaomiX9fwb for ; Thu, 22 Jan 2015 14:47:44 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id E9A991A006D for ; Thu, 22 Jan 2015 14:47:43 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 7292E564009; Thu, 22 Jan 2015 16:47:43 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6C2A660268; Thu, 22 Jan 2015 16:47:43 -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 LTqO9dfY4mgG; Thu, 22 Jan 2015 16:47:43 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3F73F60274; Thu, 22 Jan 2015 16:47:43 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 3F73F60274 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421966863; bh=IzjACVO74+bglDqC0fqdc1MyQduhickNAcOMzs+K3TM=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=cpwmrWnIVHbO0g+gpM8rjGpZioBdAU1EM49xJBU7lv9AbR0yTxWRTC0c8hIrdoIs2 nLe2KB2KuCPf2Oqppaja+ZKvnf3Nvz/T5YviKBZ5FEaGH1dHlqDesPnpI39XJs9m9X 43TsKElcqe7hDbOJ7yB1xN+LDILUXOEEZ/bt/Xv0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 29A9D60271; Thu, 22 Jan 2015 16:47:43 -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 vAcdXyg1sDNW; Thu, 22 Jan 2015 16:47:43 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 123CB60268; Thu, 22 Jan 2015 16:47:43 -0600 (CST) Date: Thu, 22 Jan 2015 16:47:42 -0600 (CST) From: Franck Martin To: Michael Jack Assels Message-ID: <1658626091.99464.1421966862810.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> <201501222120.t0MLKZWt020710@shadrach.encs.concordia.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: H6YofNZxxoBGuyVo1ezZBtxfiBDrsw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 22:47:48 -0000 ----- Original Message ----- > From: "Michael Jack Assels" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 1:20:35 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > On Thu, 22 Jan 2015 14:46:59 CST, > Franck Martin wrote: > > > ----- Original Message ----- > > > From: "Michael Jack Assels" > > > To: dmarc@ietf.org > > > Sent: Thursday, January 22, 2015 12:00:58 PM > > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > > > tiny nits, while I'm at it > > > > > > On Thu, 22 Jan 2015 12:48:03 CST, > > > Franck Martin wrote: > > > > > > > [....] > > > > > > > > Hold on... > > > > > > > > What is the decision matrix of SPF? > > > > > > > > SPF uses two strings, the RFC5321.mailfrom and the > > > > RFC5321.helo. Each string may or may not have an SPF record. > > > > What gives the spf status? > > > > > > As I read RFC7208, it doesn't explicitly provide a decision > > > matrix, but it does clearly recommend in section 2.3, that > > > [i]f a conclusive determination about the message can be made > > > based on a check of "HELO", then the use of DNS resources to > > > process the typically more complex "MAIL FROM" can be avoided." > > > > > > Section 2.4 provides that "SPF verifiers MUST check the > > > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either > > > has not been performed or has not reached a definitive policy" > > > > > > I can't think of a way to read that that doesn't imply that > > > a "pass" or a "fail" on the basis of an SPF record for the > > > RFC5321.helo indentity (if such a record exists) is the spf > > > result; otherwise, the result is based on the RFC5321.mailfrom > > > identity. > > > > > > I believe that this is not what DMARC implementations actually > > > do, and that the proposed change to the draft correctly points > > > out the difference and makes it clear what DMARC does, so if > > > I had a vote, I'd vote "yes" to the change. > > > > > > > Ok, but a specific well known implementation does not seem to > > do that: From http://www.openspf.org/Implementations Mail::SPF > > has passed the test suites > > > > http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm > > "Note: In the case of an empty MAIL FROM SMTP transaction > > parameter (MAIL FROM:<>), you should perform a check with the > > helo scope instead." > > This is what the proposed change says, isn't it? > > > an RFC to reach standard status needs to represent what is out > > there, I'd like to see more code before I form an opinion. > > I think we've crossed wires here. I unreservedly agree that > RFC7208 does NOT represent what all DMARC implementations do, > and it may not even represent what all SPF implementations do. > Perhaps RFC7208 needs correction, but given what it says now, > and given that DMARC has an obvious dependency on SPF, it's > important that DMARC's standard should say "contrary to what > RFC7208 recommends, DMARC normally SPF-checks HELO only when > MAIL FROM is <>". > > I don't think we're disagreeing about what DMARC does, or even > about what SPF usually does, despite what RFC7208 says. > Yes, this is my point, seems to me RFC7208 needs an errata... than DMARC... but I'm ok with the proposed language, I just think DMARC should avoid to fix problems with lower protocols... If you read the previous RFC: http://trac.tools.ietf.org/html/rfc4408 section 2.2 [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in RFC 2821). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the localpart "postmaster" and the "HELO" identity (which may or may not have been checked separately before). SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the . so the MAIL FROM entity contains postmaster@helo if the RFC5321.mailfrom is empty... Now in this document, it says to do the check_host on mail from and helo separately, it says the check_host function will return a result, and that result is deterministic, I see the code. However I reread quickly the spec, it does not say how you would merge both results to a single one: Did SPF passes or not? For instance, RFC7001 expects one result. http://tools.ietf.org/html/rfc7001#section-2.6.2 RFC7208 was written to make the text of the document more suitable for a "Standard" track. The charter was to not modify the protocol. So RFC7208 is not addressing this issue either. From nobody Thu Jan 22 15:09:02 2015 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 E9A0A1A88E5 for ; Thu, 22 Jan 2015 15:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 W32WaJRQRRhH for ; Thu, 22 Jan 2015 15:08:56 -0800 (PST) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 84A801A88C1 for ; Thu, 22 Jan 2015 15:08:56 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3kSzn265xpz5Mhdj; Fri, 23 Jan 2015 00:08:54 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3kSzn24Hk3z1L8cG; Fri, 23 Jan 2015 00:08:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 60392123480; Fri, 23 Jan 2015 00:08:54 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0T0pmwMeV4eN; Fri, 23 Jan 2015 00:08:51 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id B5065123437; Fri, 23 Jan 2015 00:08:51 +0100 (CET) Message-ID: <54C18303.7070208@sonnection.nl> Date: Fri, 23 Jan 2015 00:08:51 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Franck Martin , Michael Jack Assels References: <20150121021457.1947.qmail@ary.lan> <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> In-Reply-To: <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1421968134; bh=gELOTUvOH0e0vSd+tC7lIrHbnDUkPlAPUJ77PRyedq8=; h=Message-ID:Date:From:To:Subject:From; b=RB36URw7I67MImv1O7DUAW4nVGsG++geAgcsbrR55ddgGQbD+zx+KiBhU68N2w0O+ 4ehUuvfWTh0JxlUig2gvFK/LllVQ4J66WDTBI6in/+vFxBeLVcaCPLp0GfiHo7FqGz vIrxOTHkDV2tXkRGnl/LRVi6gUJzHlx7XYroZLP4= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3kSzn265xpz5Mhdj Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 23:09:00 -0000 On 01/22/2015 09:46 PM, Franck Martin wrote: > > > > ----- Original Message ----- >> From: "Michael Jack Assels" >> To: dmarc@ietf.org >> Sent: Thursday, January 22, 2015 12:00:58 PM >> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it >> >> On Thu, 22 Jan 2015 12:48:03 CST, >> Franck Martin wrote: >> >>> ----- Original Message ----- >>> >>>> From: "Murray S. Kucherawy" >>>> To: dmarc@ietf.org >>>> Sent: Thursday, January 22, 2015 10:27:40 AM >>>> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more >>>> tiny nits, while I'm at it >>>> On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < >>>> superuser@gmail.com > >>>> wrote: >>>>> I am asking the IESG and the ISE what the process is for >>>>> making such adjustments now. >>>>> Mainly my resistance to further change comes from the fact >>>>> that we've done last calls of varying kinds on this >>>>> document more times than I can count. It really is time to >>>>> put the non-IETF version to bed and hand it off, even with >>>>> its weaknesses, and let the standards process take it from >>>>> there. There's a working group already chartered to do >>>>> exactly that; in fact, that was one of the premises of >>>>> creating that working group. >>>> I've consulted with the Area Director sponsoring the >>>> document's conflict review, and the ISE. Both of them agree >>>> that we will only make changes approved by the ISE and only >>>> during AUTH48 at this point, and those will be limited to >>>> correcting serious problems that would prevent current DMARC >>>> implementations from interacting properly. Anything else can >>>> be left to the DMARC working group on its standards track >>>> deliverable. >>>> An argument can be made that this proposed change qualifies >>>> under that definition, so please review it and comment as to >>>> whether it satisfies the defect identified, or whether the >>>> change is necessary at all. I will assume "yes" unless I hear >>>> otherwise. Again, the diff is here: >>>> http://www.blackops.org/~msk/dmarc/diff.html >>> Hold on... >>> >>> What is the decision matrix of SPF? >>> >>> SPF uses two strings, the RFC5321.mailfrom and the >>> RFC5321.helo. Each string may or may not have an SPF record. >>> What gives the spf status? >> As I read RFC7208, it doesn't explicitly provide a decision >> matrix, but it does clearly recommend in section 2.3, that >> [i]f a conclusive determination about the message can be made >> based on a check of "HELO", then the use of DNS resources to >> process the typically more complex "MAIL FROM" can be avoided." >> >> Section 2.4 provides that "SPF verifiers MUST check the >> [RFC5321.mailfrom] identity if a [RFC5321.helo] check either >> has not been performed or has not reached a definitive policy" >> >> I can't think of a way to read that that doesn't imply that >> a "pass" or a "fail" on the basis of an SPF record for the >> RFC5321.helo indentity (if such a record exists) is the spf >> result; otherwise, the result is based on the RFC5321.mailfrom >> identity. >> >> I believe that this is not what DMARC implementations actually >> do, and that the proposed change to the draft correctly points >> out the difference and makes it clear what DMARC does, so if >> I had a vote, I'd vote "yes" to the change. >> > Ok, but a specific well known implementation does not seem to do that: > >From http://www.openspf.org/Implementations Mail::SPF has passed the test suites > > http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm > "Note: In the case of an empty MAIL FROM SMTP transaction parameter (MAIL FROM:<>), you should perform a check with the helo scope instead." > > an RFC to reach standard status needs to represent what is out there, the current draft is heading for Informational status, not standard status. Having said that I fully agree with: > I'd like to see more code before I form an opinion. as from an interoperability point of view it is important to know what the various implementations of the current implementors do exactly with SPF re. the point raised by Anne (SPF use of RFC5321.MailFrom vs. RFC5321.EHLO/HELO). As for the 'SPF part of DMARC only an 'SPF pass' counts it must be crystal clear how an 'SPF pass' is reached. Therefore, if (repeat: if) all current implementations of DMARC only use the RFC5321.MailFrom, I'd suggest to use RFC2119 terminology here, like: -13 text: Note that the RFC5321.HELO identity is not typically used in the context of DMARC (except when required to "fake" an otherwise null reverse-path), even though a "pure SPF" implementation according to [SPF] would check that identifier. Suggested text: If RFC5321.MailFrom identity is present and not null, the RFC5321.HELO identity MUST NOT be used in the context of DMARC, even though a "pure SPF" implementation according to [SPF] would check that identifier. /rolf From nobody Thu Jan 22 15:18:06 2015 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 255151A8913 for ; Thu, 22 Jan 2015 15:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 cERuC7DBuGxP for ; Thu, 22 Jan 2015 15:17:56 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3EC1A8912 for ; Thu, 22 Jan 2015 15:17:55 -0800 (PST) Received: (qmail 72994 invoked from network); 22 Jan 2015 23:17:54 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 22 Jan 2015 23:17:54 -0000 Date: 22 Jan 2015 23:17:28 -0000 Message-ID: <20150122231728.780.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <9690B8A4-36FF-4509-B413-D84AA1DB79CF@kitterman.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 23:17:59 -0000 >DMARC leverages the Mail From identity, so I don't see how independent HELO checks can be relevant. If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable interpretation is that you check the HELO identity, and if you get a "definitive policy" result, you're done and return that to the caller. So a message comes from host mail.provider.com with From: bob@customer.com. The recipient host does an SPF check on mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF domain isn't aligned so it ignores it, and DMARC says it's unaligned, even though an SPF check of customer.com might have passed. I can't say whether this is a bug in 7208 or a fundamental flaw in DMARC, but something is clearly wrong and this does not match what running code does. As things are written now, I don't see any way to demand that SPF look at the MAIL FROM if it likes the HELO. Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL FROM check first and only do the HELO check otherwise. This may match some running code, I haven't looked. Fix 2: change 7208 to say that SPF can return multiple results. Ugh. R's, John From nobody Thu Jan 22 15:24:34 2015 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 426A21A8917 for ; Thu, 22 Jan 2015 15:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 f2s2xEh42QHy for ; Thu, 22 Jan 2015 15:24:30 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34341A8915 for ; Thu, 22 Jan 2015 15:24:29 -0800 (PST) Received: from [10.173.75.215] (187.sub-70-208-151.myvzw.com [70.208.151.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 42CCAC403F1; Thu, 22 Jan 2015 17:27:26 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421969246; bh=l6ITlaeEfrRiR1Ww0NF5awMaXlpX1e+FQoEV2JruzTw=; h=In-Reply-To:References:Subject:From:Date:To:From; b=UXU1pPeyE5ouBQRFm2ogZbBD0wy/WDNFT2v9OQiWuzyrpdltZrmZ46AzDhiUWf8eB /sQ01iYbuHd3OiZWe5oAUfL9C+43b4NgXLBzVQhd+z26477nyMisIWloCfUpV12871 aipLBGjGkHiGmosWcdSAnpdeXPeltSHN4AGZUflI= User-Agent: K-9 Mail for Android In-Reply-To: <1658626091.99464.1421966862810.JavaMail.zimbra@peachymango.org> References: <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> <201501222120.t0MLKZWt020710@shadrach.encs.concordia.ca> <1658626091.99464.1421966862810.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 22 Jan 2015 18:24:21 -0500 To: dmarc@ietf.org Message-ID: Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 23:24:32 -0000 On January 22, 2015 5:47:42 PM EST, Franck Martin wrote: > > > > >----- Original Message ----- >> From: "Michael Jack Assels" >> To: dmarc@ietf.org >> Sent: Thursday, January 22, 2015 1:20:35 PM >> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more >tiny nits, while I'm at it >> >> On Thu, 22 Jan 2015 14:46:59 CST, >> Franck Martin wrote: >> >> > ----- Original Message ----- >> > > From: "Michael Jack Assels" >> > > To: dmarc@ietf.org >> > > Sent: Thursday, January 22, 2015 12:00:58 PM >> > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two >more >> > > tiny nits, while I'm at it >> > > >> > > On Thu, 22 Jan 2015 12:48:03 CST, >> > > Franck Martin wrote: >> > > >> > > > [....] >> > > > >> > > > Hold on... >> > > > >> > > > What is the decision matrix of SPF? >> > > > >> > > > SPF uses two strings, the RFC5321.mailfrom and the >> > > > RFC5321.helo. Each string may or may not have an SPF record. >> > > > What gives the spf status? >> > > >> > > As I read RFC7208, it doesn't explicitly provide a decision >> > > matrix, but it does clearly recommend in section 2.3, that >> > > [i]f a conclusive determination about the message can be made >> > > based on a check of "HELO", then the use of DNS resources to >> > > process the typically more complex "MAIL FROM" can be avoided." >> > > >> > > Section 2.4 provides that "SPF verifiers MUST check the >> > > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either >> > > has not been performed or has not reached a definitive policy" >> > > >> > > I can't think of a way to read that that doesn't imply that >> > > a "pass" or a "fail" on the basis of an SPF record for the >> > > RFC5321.helo indentity (if such a record exists) is the spf >> > > result; otherwise, the result is based on the RFC5321.mailfrom >> > > identity. >> > > >> > > I believe that this is not what DMARC implementations actually >> > > do, and that the proposed change to the draft correctly points >> > > out the difference and makes it clear what DMARC does, so if >> > > I had a vote, I'd vote "yes" to the change. >> > > >> > >> > Ok, but a specific well known implementation does not seem to >> > do that: From http://www.openspf.org/Implementations Mail::SPF >> > has passed the test suites >> > >> > http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm >> > "Note: In the case of an empty MAIL FROM SMTP transaction >> > parameter (MAIL FROM:<>), you should perform a check with the >> > helo scope instead." >> >> This is what the proposed change says, isn't it? >> >> > an RFC to reach standard status needs to represent what is out >> > there, I'd like to see more code before I form an opinion. >> >> I think we've crossed wires here. I unreservedly agree that >> RFC7208 does NOT represent what all DMARC implementations do, >> and it may not even represent what all SPF implementations do. >> Perhaps RFC7208 needs correction, but given what it says now, >> and given that DMARC has an obvious dependency on SPF, it's >> important that DMARC's standard should say "contrary to what >> RFC7208 recommends, DMARC normally SPF-checks HELO only when >> MAIL FROM is <>". >> >> I don't think we're disagreeing about what DMARC does, or even >> about what SPF usually does, despite what RFC7208 says. >> > >Yes, this is my point, seems to me RFC7208 needs an errata... than >DMARC... but I'm ok with the proposed language, I just think DMARC >should avoid to fix problems with lower protocols... > > >If you read the previous RFC: >http://trac.tools.ietf.org/html/rfc4408 section 2.2 > > [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in > RFC 2821). In this case, there is no explicit sender mailbox, and > such a message can be assumed to be a notification message from the > mail system itself. When the reverse-path is null, this document > defines the "MAIL FROM" identity to be the mailbox composed of the > localpart "postmaster" and the "HELO" identity (which may or may not > have been checked separately before). > > SPF clients MUST check the "MAIL FROM" identity. SPF clients check > the "MAIL FROM" identity by applying the check_host() function to the > "MAIL FROM" identity as the . > >so the MAIL FROM entity contains postmaster@helo if the >RFC5321.mailfrom is empty... > >Now in this document, it says to do the check_host on mail from and >helo separately, it says the check_host function will return a result, >and that result is deterministic, I see the code. However I reread >quickly the spec, it does not say how you would merge both results to a >single one: Did SPF passes or not? For instance, RFC7001 expects one >result. http://tools.ietf.org/html/rfc7001#section-2.6.2 > >RFC7208 was written to make the text of the document more suitable for >a "Standard" track. The charter was to not modify the protocol. So >RFC7208 is not addressing this issue either. Sigh. RFC 7208 doesn't say the HELO result determines anything. It says IF (I say again IF) a decision has been reached about message disposition based on the HELO result, there is no requirement to go ahead and do a pointless Mail From check. Avoiding a check that has been determined to be pointless is the only change in this area in RFC 7208. This is much ado about nothing and really, really irrelevant to DMARC. Scott K P.S. No erratum needed From nobody Thu Jan 22 15:31:45 2015 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 02EC51A8924 for ; Thu, 22 Jan 2015 15:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 HKNiSk0y5D1d for ; Thu, 22 Jan 2015 15:31:41 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C141A002A for ; Thu, 22 Jan 2015 15:31:41 -0800 (PST) Received: from [10.173.75.215] (187.sub-70-208-151.myvzw.com [70.208.151.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5F4D0C403F1; Thu, 22 Jan 2015 17:34:37 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421969677; bh=A+IC5MDhswbzqbbC9DrpW/72HGC4pqZV+Tg9yf8TBPc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Gsmd+Qmsx2KBLFb9rT2bC1R2LTw0jzO4BZ6c/FovpjGZwidQGvWH34ATsVxuMdXqL cvmwHsuGrjf3D/dsxCuGFqdlh9zdnzdnAuv6pquXfsSZJjFa3qmZpwgFQxeqoaH4g7 gtUoLBCO6QduUCZrUrenoJShgKhIMk32mTaBlzFE= User-Agent: K-9 Mail for Android In-Reply-To: <20150122231728.780.qmail@ary.lan> References: <20150122231728.780.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 22 Jan 2015 18:30:59 -0500 To: dmarc@ietf.org Message-ID: <6368691B-0343-4D5E-A21A-7BFEF20BCD2D@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 23:31:44 -0000 On January 22, 2015 6:17:28 PM EST, John Levine wrote: >>DMARC leverages the Mail From identity, so I don't see how independent >HELO checks can be relevant. > >If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable >interpretation is that you check the HELO identity, and if you get a >"definitive policy" result, you're done and return that to the caller. > >So a message comes from host mail.provider.com with From: >bob@customer.com. The recipient host does an SPF check on >mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF >domain isn't aligned so it ignores it, and DMARC says it's unaligned, >even though an SPF check of customer.com might have passed. > >I can't say whether this is a bug in 7208 or a fundamental flaw in >DMARC, but something is clearly wrong and this does not match what >running code does. As things are written now, I don't see any way to >demand that SPF look at the MAIL FROM if it likes the HELO. > >Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL >FROM check first and only do the HELO check otherwise. This may match >some running code, I haven't looked. > >Fix 2: change 7208 to say that SPF can return multiple results. Ugh. 4408 and 7208 both suggest multiple calls to check_host() each with a single result. If I were configuring and SPF verifier to provide an input to DMARC processing, then I would probably configure it not to reject based on SPF fail. Then the problem doesn't arise. This really is a non-issue. Scott K From nobody Thu Jan 22 15:36:03 2015 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 CAFC31A8949 for ; Thu, 22 Jan 2015 15:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 LFdv3g_T0kIX for ; Thu, 22 Jan 2015 15:36:00 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798DE1A1A3A for ; Thu, 22 Jan 2015 15:36:00 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so45524876wiv.0 for ; Thu, 22 Jan 2015 15:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=jhYLWOPQBj9HJxyNMmTnjdxFEoNxdbEedACkOubfzUk=; b=Z2L/NuF0OcCyjNmFPe1Ecr3eFkr8BEjktnJCogYtvrasuTENj8PUe1zrYLZE3BGVA8 YYubnYFqVBRqUnkxFMyo38Iye4mF3VUxW+6fGm/7B2PF6NvI54csadDMNsEgVY6dw7CO cX5f/0Ute2s6KVSYCzcv2ucerCpb1ACK+q2Hg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jhYLWOPQBj9HJxyNMmTnjdxFEoNxdbEedACkOubfzUk=; b=fN8sghNH89RnB6t6EzoS0iHUEZjpIBBzmAqY8xnfn7zgRlwKWSZTn1Q5+tjkEe7Gy2 59ne4mstGRr+iha4k10gppLacvHFcbDcY86IujvpRVijOCEUmbd6+/q+I+NtRud0mN2H vm9WK0Db3rclokpIyriaHPRdLwpz/Z0eupcBdpC+3jnXzMoCIiSA8gQ3+b9igGS9euOW r09RrAChtbJ780deLeKRO6OyGIVilvNKxyYze8n8NdfFmy7T+1aBPLsmuzijAnmRf83s qm7187OUxgo3cQwVL3k3536biiAP/9hAv76f3zucx2y+Bb82kC2SkjlCXF0VcrGHZxIL b8cg== X-Gm-Message-State: ALoCoQkYR3wHO0Xqo4G37TYTs8RRRbiVHbBUchpr9TDg0IuRLWufo9HDN365ol/SW6NMcqEUmBXU MIME-Version: 1.0 X-Received: by 10.181.12.112 with SMTP id ep16mr73687541wid.38.1421969759267; Thu, 22 Jan 2015 15:35:59 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.41.161 with HTTP; Thu, 22 Jan 2015 15:35:59 -0800 (PST) In-Reply-To: <6368691B-0343-4D5E-A21A-7BFEF20BCD2D@kitterman.com> References: <20150122231728.780.qmail@ary.lan> <6368691B-0343-4D5E-A21A-7BFEF20BCD2D@kitterman.com> Date: Thu, 22 Jan 2015 15:35:59 -0800 X-Google-Sender-Auth: SdH3ZJnBH8FPz2p7sGaYmvfA0Fg Message-ID: From: Kurt Andersen To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043891db6206b7050d4622e6 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 23:36:02 -0000 --f46d043891db6206b7050d4622e6 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman wrote: > If I were configuring and SPF verifier to provide an input to DMARC > processing, then I would probably configure it not to reject based on SPF > fail. Then the problem doesn't arise. > > This really is a non-issue. > Are you suggesting that the DMARC spec should say that people SHOULD configure (some would say usurp) SPF in such a way? I seem to recall some contentious discussions about such usurpation during SPFbis (though I could be conflating arguments from another context). --Kurt --f46d043891db6206b7050d4622e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --f46d043891db6206b7050d4622e6-- From nobody Thu Jan 22 15:57:39 2015 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 45CAE1A8A49 for ; Thu, 22 Jan 2015 15:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 lvJ9tPY5KtUN for ; Thu, 22 Jan 2015 15:57:33 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 48BFA1A8A5A for ; Thu, 22 Jan 2015 15:57:33 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id E00CC564017; Thu, 22 Jan 2015 17:57:32 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id CF864A03E8; Thu, 22 Jan 2015 17:57:32 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYCZHZgqi1z8; Thu, 22 Jan 2015 17:57:32 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7C9F0A040E; Thu, 22 Jan 2015 17:57:32 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 7C9F0A040E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421971052; bh=bQuNZq9AQdB9K6RzANJCj7sQgsOWXb4ZAzKUCUsq1/c=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=p5QNyptK5SYNl+QWIokaG8RbIKjVvBep1JNNqIB9oxRxU9P5DSkfG7rmJs799N2Q3 JXXZIFG4+zzQfXIsqR3xJLek8LBJK/sMnCQNDAsgKwHe0BrxPuAxZjp0OEBiKX8ASE GVuGVmcGgRb7PIvkG82jjbYeCo2z/qFIEXoIvejw= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 62DF0A0406; Thu, 22 Jan 2015 17:57:32 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BK8T60hFoVFp; Thu, 22 Jan 2015 17:57:32 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 32C4BA03E8; Thu, 22 Jan 2015 17:57:32 -0600 (CST) Date: Thu, 22 Jan 2015 17:57:32 -0600 (CST) From: Franck Martin To: R E Sonneveld Message-ID: <701580818.100954.1421971052000.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> <54C18303.7070208@sonnection.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: YnW22BYS7d/WE/2K+kDzk9QSaN47kA== Archived-At: Cc: dmarc@ietf.org, Michael Jack Assels Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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: Thu, 22 Jan 2015 23:57:36 -0000 ----- Original Message ----- > From: "Rolf E. Sonneveld" > To: "Franck Martin" , "Michael Jack Assels" > Cc: dmarc@ietf.org > Sent: Thursday, January 22, 2015 3:08:51 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > On 01/22/2015 09:46 PM, Franck Martin wrote: > > > > > > > > ----- Original Message ----- > >> From: "Michael Jack Assels" > >> To: dmarc@ietf.org > >> Sent: Thursday, January 22, 2015 12:00:58 PM > >> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > >> nits, while I'm at it > >> > >> On Thu, 22 Jan 2015 12:48:03 CST, > >> Franck Martin wrote: > >> > >>> ----- Original Message ----- > >>> > >>>> From: "Murray S. Kucherawy" > >>>> To: dmarc@ietf.org > >>>> Sent: Thursday, January 22, 2015 10:27:40 AM > >>>> Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > >>>> tiny nits, while I'm at it > >>>> On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < > >>>> superuser@gmail.com > > >>>> wrote: > >>>>> I am asking the IESG and the ISE what the process is for > >>>>> making such adjustments now. > >>>>> Mainly my resistance to further change comes from the fact > >>>>> that we've done last calls of varying kinds on this > >>>>> document more times than I can count. It really is time to > >>>>> put the non-IETF version to bed and hand it off, even with > >>>>> its weaknesses, and let the standards process take it from > >>>>> there. There's a working group already chartered to do > >>>>> exactly that; in fact, that was one of the premises of > >>>>> creating that working group. > >>>> I've consulted with the Area Director sponsoring the > >>>> document's conflict review, and the ISE. Both of them agree > >>>> that we will only make changes approved by the ISE and only > >>>> during AUTH48 at this point, and those will be limited to > >>>> correcting serious problems that would prevent current DMARC > >>>> implementations from interacting properly. Anything else can > >>>> be left to the DMARC working group on its standards track > >>>> deliverable. > >>>> An argument can be made that this proposed change qualifies > >>>> under that definition, so please review it and comment as to > >>>> whether it satisfies the defect identified, or whether the > >>>> change is necessary at all. I will assume "yes" unless I hear > >>>> otherwise. Again, the diff is here: > >>>> http://www.blackops.org/~msk/dmarc/diff.html > >>> Hold on... > >>> > >>> What is the decision matrix of SPF? > >>> > >>> SPF uses two strings, the RFC5321.mailfrom and the > >>> RFC5321.helo. Each string may or may not have an SPF record. > >>> What gives the spf status? > >> As I read RFC7208, it doesn't explicitly provide a decision > >> matrix, but it does clearly recommend in section 2.3, that > >> [i]f a conclusive determination about the message can be made > >> based on a check of "HELO", then the use of DNS resources to > >> process the typically more complex "MAIL FROM" can be avoided." > >> > >> Section 2.4 provides that "SPF verifiers MUST check the > >> [RFC5321.mailfrom] identity if a [RFC5321.helo] check either > >> has not been performed or has not reached a definitive policy" > >> > >> I can't think of a way to read that that doesn't imply that > >> a "pass" or a "fail" on the basis of an SPF record for the > >> RFC5321.helo indentity (if such a record exists) is the spf > >> result; otherwise, the result is based on the RFC5321.mailfrom > >> identity. > >> > >> I believe that this is not what DMARC implementations actually > >> do, and that the proposed change to the draft correctly points > >> out the difference and makes it clear what DMARC does, so if > >> I had a vote, I'd vote "yes" to the change. > >> > > Ok, but a specific well known implementation does not seem to do that: > > >From http://www.openspf.org/Implementations Mail::SPF has passed the test > > >suites > > > > http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm > > "Note: In the case of an empty MAIL FROM SMTP transaction parameter (MAIL > > FROM:<>), you should perform a check with the helo scope instead." > > > > an RFC to reach standard status needs to represent what is out there, > > the current draft is heading for Informational status, not standard > status. Having said that I fully agree with: > > > I'd like to see more code before I form an opinion. > > as from an interoperability point of view it is important to know what > the various implementations of the current implementors do exactly with > SPF re. the point raised by Anne (SPF use of RFC5321.MailFrom vs. > RFC5321.EHLO/HELO). > > As for the 'SPF part of DMARC only an 'SPF pass' counts it must be > crystal clear how an 'SPF pass' is reached. Therefore, if (repeat: if) > all current implementations of DMARC only use the RFC5321.MailFrom, I'd > suggest to use RFC2119 terminology here, like: > > -13 text: > > Note that the RFC5321.HELO identity is not typically used in the > context of DMARC (except when required to "fake" an > otherwise null > reverse-path), even though a "pure SPF" implementation > according to > [SPF] would check that identifier. > > Suggested text: > > If RFC5321.MailFrom identity is present and not null, the RFC5321.HELO > identity MUST NOT be used in the > context of DMARC, even though a "pure SPF" implementation > according to > [SPF] would check that identifier. > No, no... :P if you send a bounce, and usually some MTAs have trouble to sign the bounce they generate (not anymore true with postfix but a bit tricky to setup), then the only way to recover the message is to ensure there is an SPF aligned on the string presented by HELO. So basically, I would say DMARC takes only the result of the check_host for the MAIL FROM entity which contains the postmaster@helo if the RFC5321.mailfrom is empty. Murray, I think the elegant way in DMARC to refer to RFC7208 is this. "DMARC uses only the result of the check_host() applied on the MAIL FROM entity as defined by RFC7208. The MAIL FROM entity is the one used for alignment checking.". If I recall the operational test created by Tim, were checking these cases: http://dmarc-qa.com/ (2.1) We all ran these tests during inter-op for conformance. From nobody Thu Jan 22 16:13:53 2015 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 A7BB51B2A66 for ; Thu, 22 Jan 2015 16:13:51 -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, 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 n5U9aCAkszs3 for ; Thu, 22 Jan 2015 16:13:48 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09811B2A67 for ; Thu, 22 Jan 2015 16:13:48 -0800 (PST) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.81.4; Fri, 23 Jan 2015 00:13:46 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.108]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.108]) with mapi id 15.01.0081.000; Fri, 23 Jan 2015 00:13:46 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: AQHQNp861CtzZwWVHkurC9sto0VSHJzM1Fzw Date: Fri, 23 Jan 2015 00:13:46 +0000 Message-ID: References: <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> <54C18303.7070208@sonnection.nl> <701580818.100954.1421971052000.JavaMail.zimbra@peachymango.org> In-Reply-To: <701580818.100954.1421971052000.JavaMail.zimbra@peachymango.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.160.117] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(199003)(189002)(76176999)(54356999)(93886004)(101416001)(50986999)(54606007)(92566002)(64706001)(97736003)(66066001)(87936001)(105586002)(2656002)(106116001)(19580405001)(19580395003)(46102003)(2501002)(33656002)(54206007)(2900100001)(86362001)(15975445007)(102836002)(2351001)(107886001)(2950100001)(106356001)(68736005)(77156002)(62966003)(110136001)(450100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2015 00:13:46.2482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 00:13:51 -0000 The way it works in Office 365 is this: 1. When checking SPF, use the domain in the 5321.MailFrom. If it is empty, = use the domain in the HELO/EHLO. 2. Use the domain extracted from (1) when doing the DMARC alignment check f= or SPF. We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never found t= his to be a problem. I don't know how it works in Hotmail (although I should) but it is moving o= ver to the Office 365 infrastructure over the next several months anyhow so= it will be the same. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Franck Martin Sent: Thursday, January 22, 2015 3:58 PM To: R E Sonneveld Cc: dmarc@ietf.org; Michael Jack Assels Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny = nits, while I'm at it if you send a bounce, and usually some MTAs have trouble to sign the bounce= they generate (not anymore true with postfix but a bit tricky to setup), t= hen the only way to recover the message is to ensure there is an SPF aligne= d on the string presented by HELO. So basically, I would say DMARC takes only the result of the check_host for= the MAIL FROM entity which contains the postmaster@helo if the RFC5321.mai= lfrom is empty. Murray, I think the elegant way in DMARC to refer to RFC7208 is this. "DMARC uses only the result of the check_host() applied on the MAIL FROM en= tity as defined by RFC7208. The MAIL FROM entity is the one used for alignm= ent checking.". If I recall the operational test created by Tim, were checking these cases:= http://dmarc-qa.com/ (2.1) We all ran these tests during inter-op for conformance. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Jan 22 16:49:30 2015 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 C5FA41B2A6E for ; Thu, 22 Jan 2015 16:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 uopra-yzSJ3g for ; Thu, 22 Jan 2015 16:49:27 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBD71B2A66 for ; Thu, 22 Jan 2015 16:49:27 -0800 (PST) Received: from [10.173.75.215] (187.sub-70-208-151.myvzw.com [70.208.151.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7657FC40472; Thu, 22 Jan 2015 18:52:24 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421974344; bh=wL9F9eN+gmoTUq8Htnj1pbamRvMRj0QORjNiKr5mEb8=; h=In-Reply-To:References:Subject:From:Date:To:From; b=eHNIyQemVyrRDPQZgbBtxouI5pcehefyLuEHI7L3uaO2o+egexph8H7p0oc7dUHVw Zft5sA+f4sFo0ZYhoOZR97btpCUb/BhZZsicc5nuVaMdV1qYF6h2E8QrNSsNjtDxSo /jmILVeOy0FsR9m7CSS1HECC8VyiCWpQ0D6Oa8mY= User-Agent: K-9 Mail for Android In-Reply-To: References: <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> <54C18303.7070208@sonnection.nl> <701580818.100954.1421971052000.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 22 Jan 2015 19:45:38 -0500 To: "dmarc@ietf.org" Message-ID: <2B62AD47-EEF1-42AC-9B0F-8AB495BF22D6@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 00:49:29 -0000 On January 22, 2015 7:13:46 PM EST, Terry Zink wrote: >The way it works in Office 365 is this: > >1. When checking SPF, use the domain in the 5321.MailFrom. If it is >empty, use the domain in the HELO/EHLO. >2. Use the domain extracted from (1) when doing the DMARC alignment >check for SPF. > >We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never >found this to be a problem. > >I don't know how it works in Hotmail (although I should) but it is >moving over to the Office 365 infrastructure over the next several >months anyhow so it will be the same. > >-- Terry > >-----Original Message----- >From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Franck Martin >Sent: Thursday, January 22, 2015 3:58 PM >To: R E Sonneveld >Cc: dmarc@ietf.org; Michael Jack Assels >Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more >tiny nits, while I'm at it >if you send a bounce, and usually some MTAs have trouble to sign the >bounce they generate (not anymore true with postfix but a bit tricky to >setup), then the only way to recover the message is to ensure there is >an SPF aligned on the string presented by HELO. > >So basically, I would say DMARC takes only the result of the check_host >for the MAIL FROM entity which contains the postmaster@helo if the >RFC5321.mailfrom is empty. > >Murray, I think the elegant way in DMARC to refer to RFC7208 is this. > >"DMARC uses only the result of the check_host() applied on the MAIL >FROM entity as defined by RFC7208. The MAIL FROM entity is the one used >for alignment checking.". > >If I recall the operational test created by Tim, were checking these >cases: http://dmarc-qa.com/ (2.1) > >We all ran these tests during inter-op for conformance. > >_______________________________________________ >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 This is a perfectly reasonable way to do it. Spamassassin checks both independently (using Mail::SPF) and applies the results to two different SA tests. There's more than one way to do it (Meng Wong is a Perl programmer). Scott K From nobody Thu Jan 22 17:03:39 2015 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 1DDC81A1A5E for ; Thu, 22 Jan 2015 17:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ZQ2y2TQj100B for ; Thu, 22 Jan 2015 17:03:36 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012FA1A1A4A for ; Thu, 22 Jan 2015 17:03:36 -0800 (PST) Received: from [10.173.75.215] (187.sub-70-208-151.myvzw.com [70.208.151.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 168E4C40472; Thu, 22 Jan 2015 19:06:33 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421975193; bh=UcOSkrUbWDADEHfkNqEYhAvtJs4OYaGXN/KwisXQxEI=; h=In-Reply-To:References:Subject:From:Date:To:From; b=wG3XAO9hZ9eA8ivLhrIC/OysRN340P/aqhIR5A8GI5jQAToV2+TyQ93b4aYmLojnY PfFnYmHenAp6hi5U5b002B/hZ9aAezWv/4b5rIzyocjlsQ9uZAmM+VsXzZgJ/cP8jj fFVdnbqRxe01S1t6r+PqpG8SVFBgRN2pO2RT7GSI= User-Agent: K-9 Mail for Android In-Reply-To: References: <20150122231728.780.qmail@ary.lan> <6368691B-0343-4D5E-A21A-7BFEF20BCD2D@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 22 Jan 2015 20:03:28 -0500 To: "dmarc@ietf.org" Message-ID: <58A5D269-F368-49F8-9819-656DA8EA6359@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 01:03:37 -0000 On January 22, 2015 6:35:59 PM EST, Kurt Andersen wrote: >On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman >wrote: > >> If I were configuring and SPF verifier to provide an input to DMARC >> processing, then I would probably configure it not to reject based on >SPF >> fail. Then the problem doesn't arise. >> >> This really is a non-issue. >> > > >Are you suggesting that the DMARC spec should say that people SHOULD >configure (some would say usurp) SPF in such a way? I seem to recall >some >contentious discussions about such usurpation during SPFbis (though I >could >be conflating arguments from another context). Of course. Section 6.7 discusses this in general terms. If you want to only use SPF as an input to DMARC, then it wouldn't make sense to set up your system to reject mail just based on SPF. Specifying receiver policy was somewhat contentious in SPFbis. In the end, RFC7208 specifies almost, if not, exactly the same amount of receiver policy as did RFC4408 (almost none). Scott K From nobody Thu Jan 22 17:50:33 2015 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 E40061B2B72 for ; Thu, 22 Jan 2015 17:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 GjPnyOpe1ngb for ; Thu, 22 Jan 2015 17:50:30 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1101B2B25 for ; Thu, 22 Jan 2015 17:50:30 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PHMKWKM4B4000E33@mauve.mrochek.com> for dmarc@ietf.org; Thu, 22 Jan 2015 17:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1421977528; bh=v+6OC3bhSlkcO9ZDk59Zu43cNjCW5TFgEpuHnOA+LZc=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=GzhgSlTHDpvusjfRkopddMQa25seCB9QQWctznrLMC7/6GOlPNs0Y7HK6ZHeJBhbm M6JCQ7s41mgf2VGVfdSXgRoPM+8ztKtHJ5wugDhbTZ7tr6oapPx9uyHmFuWmeGT5YT yk5C/0j3hLJkHVRDs+FudOeliMgKIrH59smjIUnE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PHMFFWQPXC000052@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 22 Jan 2015 17:45:23 -0800 (PST) From: ned+dmarc@mrochek.com Message-id: <01PHMKWI6KSC000052@mauve.mrochek.com> Date: Thu, 22 Jan 2015 17:41:46 -0800 (PST) In-reply-to: "Your message dated Thu, 22 Jan 2015 23:17:28 +0000" <20150122231728.780.qmail@ary.lan> References: <9690B8A4-36FF-4509-B413-D84AA1DB79CF@kitterman.com> <20150122231728.780.qmail@ary.lan> To: John Levine Archived-At: Cc: dmarc@ietf.org, sklist@kitterman.com Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 01:50:32 -0000 > >DMARC leverages the Mail From identity, so I don't see how independent HELO checks can be relevant. > If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable > interpretation is that you check the HELO identity, and if you get a > "definitive policy" result, you're done and return that to the caller. > So a message comes from host mail.provider.com with From: > bob@customer.com. The recipient host does an SPF check on > mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF > domain isn't aligned so it ignores it, and DMARC says it's unaligned, > even though an SPF check of customer.com might have passed. > I can't say whether this is a bug in 7208 or a fundamental flaw in > DMARC, but something is clearly wrong and this does not match what > running code does. As things are written now, I don't see any way to > demand that SPF look at the MAIL FROM if it likes the HELO. > Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL > FROM check first and only do the HELO check otherwise. This may match > some running code, I haven't looked. > Fix 2: change 7208 to say that SPF can return multiple results. Ugh. Filing an erratum for purposes of documenting the issue is fine, but since this is a substantive change to the protocol it far exceeds the scope of what approval of an erratum is allowed to do. As such, I believe the best outcome you can get here would be "held for document update". Ned From nobody Thu Jan 22 17:59:48 2015 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 C873B1A1A91 for ; Thu, 22 Jan 2015 17:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 iNU5XqIanmNG for ; Thu, 22 Jan 2015 17:59:44 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E2D1A1A7B for ; Thu, 22 Jan 2015 17:59:43 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id l15so37676171wiw.4 for ; Thu, 22 Jan 2015 17:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=waqNATm6Gs1d/QdbMb2HmVBjf6EPB+4RavibD/U9EDM=; b=TGiDxy0G9x0Z4Yl/u8e0kyqRP3A+XeRDlwT3FAJY5F+ncmmwuaroS3GDQsdC8mfRiS 4/ddbEmVHVsm+cIys/7jlcf08u5zVMn1Q65sh7q/cP8MrFCPBUyL1MkhzyxZR5M0QHUg oejUOK6qcV55w5bwwIVK61oJBfg2ChKSWd6iE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=waqNATm6Gs1d/QdbMb2HmVBjf6EPB+4RavibD/U9EDM=; b=GEBvWT4bgEJpLM/cUG6Ojd5tNabd2JxIaYuzYmCdU6AHiTijAbjumcVqMp6CamESPl NrTNUEkkUoo1Os9MUPmYuuKv7NcXSYMgO7iGaFRCHgiGUZj1FFppOe8skszcTXzpUBsd rx1IV3DkpqsE3dnEd/xUk85OcwJUPGIkikV4I4vFR5LQ4WsN07vCz8fYI37FRc3S/WE7 RFr6HSWg6wzFWhbN/VFMIoC0tc3Dka4Q/6fOnfezrfiS5jPzVwRF3GC8TCZdmqOXsnq4 gMGZqYZifW24XNiYSnTaz14ka3OZRfTtm0kIlU5NQYdka/+gopUwBjlYEsmeN5kchXiD auVA== X-Gm-Message-State: ALoCoQnn6fAS489tONLyrQs3l4HSwqBOs82ZDjIVH09ObOMK2aZGpFrEBEMi/3+lb+FmJUfQQjph MIME-Version: 1.0 X-Received: by 10.194.81.104 with SMTP id z8mr8783254wjx.45.1421978382729; Thu, 22 Jan 2015 17:59:42 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.41.161 with HTTP; Thu, 22 Jan 2015 17:59:42 -0800 (PST) In-Reply-To: <58A5D269-F368-49F8-9819-656DA8EA6359@kitterman.com> References: <20150122231728.780.qmail@ary.lan> <6368691B-0343-4D5E-A21A-7BFEF20BCD2D@kitterman.com> <58A5D269-F368-49F8-9819-656DA8EA6359@kitterman.com> Date: Thu, 22 Jan 2015 17:59:42 -0800 X-Google-Sender-Auth: 8pHgjaG51Fk4X-yyutHsVpJ8rww Message-ID: From: Kurt Andersen To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bf0c58e619f77050d48242f Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 01:59:46 -0000 --047d7bf0c58e619f77050d48242f Content-Type: text/plain; charset=UTF-8 On Thu, Jan 22, 2015 at 5:03 PM, Scott Kitterman wrote: > On January 22, 2015 6:35:59 PM EST, Kurt Andersen > wrote: > >On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman > >wrote: > > > >> If I were configuring and SPF verifier to provide an input to DMARC > >> processing, then I would probably configure it not to reject based on > >> SPF fail. Then the problem doesn't arise. > > > > > >Are you suggesting that the DMARC spec should say that people SHOULD > >configure (some would say usurp) SPF in such a way? I seem to recall > >some > >contentious discussions about such usurpation during SPFbis (though I > >could > >be conflating arguments from another context). > > Of course. Section 6.7 discusses this in general terms. If you want to > only use SPF as an input to DMARC, then it wouldn't make sense to set up > your system to reject mail just based on SPF. > > Specifying receiver policy was somewhat contentious in SPFbis. In the > end, RFC7208 specifies almost, if not, exactly the same amount of receiver > policy as did RFC4408 (almost none). > I think that the crux of the issue is this: 1) The DMARC spec was written with 4408 as context. That remains true today, except that in the meantime 7208 was finalized (thanks to SPFbis) and Murray was seeking to keep up with the times by following the "7208 obsoletes 4408" statement. 2) The key problem is that 7208 changes the checking precedence. Here's what the two specs actually say: 4408, section 2.2: "SPF clients MUST check the "MAIL FROM" identity." 7208, section 2.4: "SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check either has not been performed or has not reached a definitive policy. . ." My recommendation is to take -12 and amend it to change the SPF reference back to 4408 and let the WG wrestle through how to handle the change that was introduced in 7208. --Kurt --047d7bf0c58e619f77050d48242f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 22, 2015 at 5:03 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
On January 22, 2015 6:35:59 PM EST, Kurt Ande= rsen <kboth@drkurt.com> wrote= :
>On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman <sklist@kitterman.com>
>wrote:
>
>> If I were configuring and SPF verifier to provide an input to DMAR= C
>> processing, then I would probably configure it not to reject based= on
>> SPF fail.=C2=A0 Then the problem doesn't arise.
>
>
>Are you suggesting that the DMARC spec should say that people SHOULD >configure (some would say usurp) SPF in such a way? I seem to recall >some
>contentious discussions about such usurpation during SPFbis (though I >could
>be conflating arguments from another context).

Of course. Section 6.7 discusses this in general terms. If you = want to only use SPF as an input to DMARC, then it wouldn't make sense = to set up your system to reject mail just based on SPF.

Specifying receiver policy was somewhat contentious in SPFbis.=C2=A0 In the= end, RFC7208 specifies almost, if not, exactly the same amount of receiver= policy as did RFC4408 (almost none).

I think that the crux of the issue is this= :
1) The DMARC spec was written with 4408 as context. That re= mains true today, except that in the meantime 7208 was finalized (thanks to= SPFbis) and Murray was seeking to keep up with the times by following the = "7208 obsoletes 4408" statement.
2) The key problem= is that 7208 changes the checking precedence.=C2=A0 Here's what the tw= o specs actually say:
4408, section 2.2: "SPF clients MU= ST check the "MAIL FROM" identity."
7208, sect= ion 2.4: "SPF verifiers MUST check the "MAIL FROM" identity = if a "HELO" check either has not been performed or has not reached a definitive policy. . = ."

My recommendation is to take -12 and amend it to = change the SPF reference back to 4408 and let the WG wrestle through how to= handle the change that was introduced in 7208.

--Kurt
--047d7bf0c58e619f77050d48242f-- From nobody Thu Jan 22 18:16:35 2015 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 C25AC1A1A96 for ; Thu, 22 Jan 2015 18:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 fBEEJccdG-Xp for ; Thu, 22 Jan 2015 18:16:32 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id F179B1A00CD for ; Thu, 22 Jan 2015 18:16:31 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 83B50564056; Thu, 22 Jan 2015 20:16:31 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 6CFB7A03D0; Thu, 22 Jan 2015 20:16:31 -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 oNzwjWFi9nzy; Thu, 22 Jan 2015 20:16:31 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id F0508A0406; Thu, 22 Jan 2015 20:16:30 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com F0508A0406 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421979391; bh=fUQuN8Vd+nDnf/Y+EbGAF0GNd9xJXhX4Sv3Ly4zIB/M=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Czt4gsQiNzX5fI4GDsKDKShArBDJYPTIVgu7UvChwyb9/EWUtd7vp1bLT3DlbMFDK Z41cvuU+1wKYze3UTt3/fH4nC9TQrqPDEmdWnqV0F53mGGGPSPOIRxM8Uvdkd6bQGX wU5LpNo8o62ILGL0/penB+KeGHLMgU7sTKy4BQtI= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BCD3EA0404; Thu, 22 Jan 2015 20:16:30 -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 kFewg1HUKEXT; Thu, 22 Jan 2015 20:16:30 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 5F1BEA03D0; Thu, 22 Jan 2015 20:16:30 -0600 (CST) Date: Thu, 22 Jan 2015 20:16:30 -0600 (CST) From: Franck Martin To: ned+dmarc@mrochek.com Message-ID: <1643454857.101996.1421979390163.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <9690B8A4-36FF-4509-B413-D84AA1DB79CF@kitterman.com> <20150122231728.780.qmail@ary.lan> <01PHMKWI6KSC000052@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: tuVFRlKo1892HL8AniIW3arr9Vvh6A== Archived-At: Cc: sklist@kitterman.com, dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 02:16:34 -0000 ----- Original Message ----- > From: ned+dmarc@mrochek.com > To: "John Levine" > Cc: dmarc@ietf.org, sklist@kitterman.com > Sent: Thursday, January 22, 2015 5:41:46 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > > >DMARC leverages the Mail From identity, so I don't see how independent > > >HELO checks can be relevant. > > > If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable > > interpretation is that you check the HELO identity, and if you get a > > "definitive policy" result, you're done and return that to the caller. > > > So a message comes from host mail.provider.com with From: > > bob@customer.com. The recipient host does an SPF check on > > mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF > > domain isn't aligned so it ignores it, and DMARC says it's unaligned, > > even though an SPF check of customer.com might have passed. > > > I can't say whether this is a bug in 7208 or a fundamental flaw in > > DMARC, but something is clearly wrong and this does not match what > > running code does. As things are written now, I don't see any way to > > demand that SPF look at the MAIL FROM if it likes the HELO. > > > Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL > > FROM check first and only do the HELO check otherwise. This may match > > some running code, I haven't looked. > > > Fix 2: change 7208 to say that SPF can return multiple results. Ugh. > > Filing an erratum for purposes of documenting the issue is fine, but since > this > is a substantive change to the protocol it far exceeds the scope of what > approval of an erratum is allowed to do. As such, I believe the best outcome > you can get here would be "held for document update". > I tried to understand Scott, and I think this is what is missing in RFC7208. Each check_host() is meant to be done as soon as you have the data to do it. So after the HELO phase in SMTP RFC5321, you do check_host(HELO identity, IP). You get a result and apply the SPF policy (and disconnect if policy says so) after the mail from phase, you do check_host(MAIL FROM identity, IP). You get a result and apply the SPF policy (and disconnect if policy says so) This makes sense then, except when SPF policy on both check_host is not -all The difficulty then comes when you do these check_host() later in the RFC5321 transaction, as you have to emulate, this serialization. And then there is still some uncertainty on what to do when both SPF records exist and do not have -all both (or when receivers consider -all as ~all) I think RFC7208 confused more this serialization, that was implicit in RFC4408, like the elephant in the room. :P To come back to operational matters, I think SPF implementations just do check_host(MAIL FROM identity, IP) as Terry pointed out, this is why I suggest DMARC spec could just say that: "DMARC uses only the MAIL FROM identity and results of the check_host() of the MAIL FROM identity as defined in RFC7208)" And we will fix RFC7208 later to match operational deployments, but this ought to be recorded somewhere. (add reporting to emails, and you get plenty new questions about standardizations :P) From nobody Thu Jan 22 18:22:03 2015 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 523B61B2B82 for ; Thu, 22 Jan 2015 18:21:58 -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, 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 SWH5meIHKw2G for ; Thu, 22 Jan 2015 18:21:56 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 0D26F1B2B7C for ; Thu, 22 Jan 2015 18:21:56 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 9E4BF56404C; Thu, 22 Jan 2015 20:21:55 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 82061A0404; Thu, 22 Jan 2015 20:21:55 -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 B7-GNySHUzRT; Thu, 22 Jan 2015 20:21:55 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4A1E6A03D0; Thu, 22 Jan 2015 20:21:55 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 4A1E6A03D0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421979715; bh=IIv3nAP0842wJIkBCIIEAFyXtv59XoxBPi1pG6+Hxk8=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=cndiKWL2MrN9+WK1SyqCGpYBSC489FOVMaFak1nEky3unC4At0SK+J/MSzpqrpKAM uJIh8DM1WGvHZVXDYyHVxcUl9yYTrbyrmT6jrj4ftvchP5u39uQkbWpnGAjCtehJV5 FjAu1YGmaIoctE7cvavWpEvmQbN/njKDv+Hsy1kc= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 31F5FA0404; Thu, 22 Jan 2015 20:21:55 -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 02Vg_YPpDHNB; Thu, 22 Jan 2015 20:21:55 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 01264A03D0; Thu, 22 Jan 2015 20:21:54 -0600 (CST) Date: Thu, 22 Jan 2015 20:21:54 -0600 (CST) From: Franck Martin To: Kurt Andersen Message-ID: <895890793.102039.1421979714901.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150122231728.780.qmail@ary.lan> <6368691B-0343-4D5E-A21A-7BFEF20BCD2D@kitterman.com> <58A5D269-F368-49F8-9819-656DA8EA6359@kitterman.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_102038_1749523531.1421979714900" X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: SVZ4yJ7vibNpwOzribIaU5c+t1zVQQ== Archived-At: Cc: dmarc@ietf.org, Scott Kitterman Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 02:21:58 -0000 ------=_Part_102038_1749523531.1421979714900 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Kurt Andersen" > To: "Scott Kitterman" > Cc: dmarc@ietf.org > Sent: Thursday, January 22, 2015 5:59:42 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > On Thu, Jan 22, 2015 at 5:03 PM, Scott Kitterman < sklist@kitterman.com > > wrote: > > On January 22, 2015 6:35:59 PM EST, Kurt Andersen < kboth@drkurt.com > > > wrote: > > > >On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman < sklist@kitterman.com > > > > >wrote: > > > > > > > >> If I were configuring and SPF verifier to provide an input to DMARC > > > >> processing, then I would probably configure it not to reject based on > > > >> SPF fail. Then the problem doesn't arise. > > > > > > > > > > > >Are you suggesting that the DMARC spec should say that people SHOULD > > > >configure (some would say usurp) SPF in such a way? I seem to recall > > > >some > > > >contentious discussions about such usurpation during SPFbis (though I > > > >could > > > >be conflating arguments from another context). > > > Of course. Section 6.7 discusses this in general terms. If you want to only > > use SPF as an input to DMARC, then it wouldn't make sense to set up your > > system to reject mail just based on SPF. > > > Specifying receiver policy was somewhat contentious in SPFbis. In the end, > > RFC7208 specifies almost, if not, exactly the same amount of receiver > > policy > > as did RFC4408 (almost none). > > I think that the crux of the issue is this: > 1) The DMARC spec was written with 4408 as context. That remains true today, > except that in the meantime 7208 was finalized (thanks to SPFbis) and Murray > was seeking to keep up with the times by following the "7208 obsoletes 4408" > statement. > 2) The key problem is that 7208 changes the checking precedence. Here's what > the two specs actually say: > 4408, section 2.2: "SPF clients MUST check the "MAIL FROM" identity." > 7208, section 2.4: "SPF verifiers MUST check the "MAIL FROM" identity if a > "HELO" check either has not been performed or has not reached a definitive > policy. . ." I think this text in 7208 is wrong, if you consider the serialization for the checks implicit in 4408, it should have been written: "SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check either has not been performed or has not reached a definitive fail result that led to the application of the -all policy. . ." But I think the fix is a bit more complex to be elegant. ------=_Part_102038_1749523531.1421979714900 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Kurt Andersen" <kboth@drkurt.com= >
To: "Scott Kitterman" <sklist@kitterman.com>
Cc:= dmarc@ietf.org
Sent: Thursday, January 22, 2015 5:59:42 PMSubject: Re: [dmarc-ietf] questions on the spec, was ... and two m= ore tiny nits, while I'm at it

On Thu, J= an 22, 2015 at 5:03 PM, Scott Kitterman <sklist@kitterman.com> wrote:
On January 22, 2015 6:35:59 PM EST, Kurt Andersen <kboth@drkurt.com> wrote:
>On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman <sklist@kitterman.com>
>wrote:
>
>> If I were configuring and SPF verifier to provide an input to DMAR= C
>> processing, then I would probably configure it not to reject based= on
>> SPF fail.  Then the problem doesn't arise.
>
>
>Are you suggesting that the DMARC spec should say that people SHOULD >configure (some would say usurp) SPF in such a way? I seem to recall >some
>contentious discussions about such usurpation during SPFbis (though I >could
>be conflating arguments from another context).

Of co= urse. Section 6.7 discusses this in general terms. If you want to only use = SPF as an input to DMARC, then it wouldn't make sense to set up your system= to reject mail just based on SPF.

Specifying receiver policy was somewhat contentious in SPFbis.  In the= end, RFC7208 specifies almost, if not, exactly the same amount of receiver= policy as did RFC4408 (almost none).

I= think that the crux of the issue is this:
1) The DMARC spec = was written with 4408 as context. That remains true today, except that in t= he meantime 7208 was finalized (thanks to SPFbis) and Murray was seeking to= keep up with the times by following the "7208 obsoletes 4408" statement.
2) The key problem is that 7208 changes the checking precedenc= e.  Here's what the two specs actually say:
4408, sectio= n 2.2: "SPF clients MUST check the "MAIL FROM" identity."
720= 8, section 2.4: "SPF verifiers MUST check the "MAIL FROM" identity if a "HE= LO" check either has not been performed or has not reached a definitive policy. . = ."
I think this text in 7208 i= s wrong, if you consider the serialization for the checks implicit in 4408,= it should have been written:
"SPF verifiers MUST check the "= MAIL FROM" identity if a "HELO" check either has not been performed or has = not reached a definitive fail result that led to the application of the -al= l policy. . ."

But I think the fix is a bit more c= omplex to be elegant.
------=_Part_102038_1749523531.1421979714900-- From nobody Thu Jan 22 18:24:29 2015 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 251671B2B88 for ; Thu, 22 Jan 2015 18:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 tVCnGknsyCqQ for ; Thu, 22 Jan 2015 18:24:26 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235C71B2B98 for ; Thu, 22 Jan 2015 18:24:12 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DCBE7C40472; Thu, 22 Jan 2015 20:27:09 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421980030; bh=pnJ+IBUlW3RJOSvJ4bDVTc1hXPt4ZTOJ+r/7mf7iGN0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=O3pg7y2XdkGWtK5Xe0UwSrlQd9U6agIOHNW3Y2DUO9bzePQbd46pWgGH+QvtTc+bs uURAsOxJPO4QVYYrLAiCyDp2TS+Vl6K7Gu0CI7c6ApGZg6c+z87UZG+uXbrFcNnR2Q W719/mEum+w3sz55N+ppY0TEREMrcu9lWNUBDI48= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 22 Jan 2015 21:24:09 -0500 Message-ID: <3480148.AXP8cLrsrV@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <01PHMKWI6KSC000052@mauve.mrochek.com> References: <9690B8A4-36FF-4509-B413-D84AA1DB79CF@kitterman.com> <20150122231728.780.qmail@ary.lan> <01PHMKWI6KSC000052@mauve.mrochek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 02:24:28 -0000 On Thursday, January 22, 2015 17:41:46 Ned Freed wrote: > > >DMARC leverages the Mail From identity, so I don't see how independent > > >HELO checks can be relevant.> > > If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable > > interpretation is that you check the HELO identity, and if you get a > > "definitive policy" result, you're done and return that to the caller. > > > > So a message comes from host mail.provider.com with From: > > bob@customer.com. The recipient host does an SPF check on > > mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF > > domain isn't aligned so it ignores it, and DMARC says it's unaligned, > > even though an SPF check of customer.com might have passed. > > > > I can't say whether this is a bug in 7208 or a fundamental flaw in > > DMARC, but something is clearly wrong and this does not match what > > running code does. As things are written now, I don't see any way to > > demand that SPF look at the MAIL FROM if it likes the HELO. > > > > Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL > > FROM check first and only do the HELO check otherwise. This may match > > some running code, I haven't looked. > > > > Fix 2: change 7208 to say that SPF can return multiple results. Ugh. > > Filing an erratum for purposes of documenting the issue is fine, but since > this is a substantive change to the protocol it far exceeds the scope of > what approval of an erratum is allowed to do. As such, I believe the best > outcome you can get here would be "held for document update". Please don't. There's no error to document. Order was explicitly discussed during SPFbis and is not there by accident. Just because someone working on an unrelated ISE draft thinks it should have been different doesn't create an error. Scott K From nobody Thu Jan 22 18:25:54 2015 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 C8C811B2B9C for ; Thu, 22 Jan 2015 18:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 k_xeVGJpYFbD for ; Thu, 22 Jan 2015 18:25:51 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CDFE1B2B9A for ; Thu, 22 Jan 2015 18:25:51 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 40420C40472; Thu, 22 Jan 2015 20:28:49 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421980129; bh=i1iRsWGyd1aiwTJhI1RyU0XWT3reJDvDo1/U4FqS2jU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ub2VM7Uh4jYICKsnb/UR4vWVEk/LnQmvsBXOOann8VBT/dWnOSAHQoP7/oGRJMLUL eDIgnQNjY6V+/5s4BubYa0acYbOQg/SFbndBcjmLS+HZTwq/w+qVwH8L29eSBiNuEd Zdn6eFvUgXtPayrAIZAi2XAcPwxJCTpq1ZOLk8kI= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 22 Jan 2015 21:25:49 -0500 Message-ID: <2401367.z7SfuPmqJh@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20150122231728.780.qmail@ary.lan> <58A5D269-F368-49F8-9819-656DA8EA6359@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 02:25:53 -0000 On Thursday, January 22, 2015 17:59:42 Kurt Andersen wrote: > On Thu, Jan 22, 2015 at 5:03 PM, Scott Kitterman > > wrote: > > On January 22, 2015 6:35:59 PM EST, Kurt Andersen > > > > wrote: > > >On Thu, Jan 22, 2015 at 3:30 PM, Scott Kitterman > > > > > >wrote: > > >> If I were configuring and SPF verifier to provide an input to DMARC > > >> processing, then I would probably configure it not to reject based on > > >> SPF fail. Then the problem doesn't arise. > > > > > >Are you suggesting that the DMARC spec should say that people SHOULD > > >configure (some would say usurp) SPF in such a way? I seem to recall > > >some > > >contentious discussions about such usurpation during SPFbis (though I > > >could > > >be conflating arguments from another context). > > > > Of course. Section 6.7 discusses this in general terms. If you want to > > only use SPF as an input to DMARC, then it wouldn't make sense to set up > > your system to reject mail just based on SPF. > > > > Specifying receiver policy was somewhat contentious in SPFbis. In the > > end, RFC7208 specifies almost, if not, exactly the same amount of receiver > > policy as did RFC4408 (almost none). > > I think that the crux of the issue is this: > 1) The DMARC spec was written with 4408 as context. That remains true > today, except that in the meantime 7208 was finalized (thanks to SPFbis) > and Murray was seeking to keep up with the times by following the "7208 > obsoletes 4408" statement. > 2) The key problem is that 7208 changes the checking precedence. Here's > what the two specs actually say: > 4408, section 2.2: "SPF clients MUST check the "MAIL FROM" identity." > 7208, section 2.4: "SPF verifiers MUST check the "MAIL FROM" identity if a > "HELO" check either has not been performed or has not reached a definitive > policy. . ." > > My recommendation is to take -12 and amend it to change the SPF reference > back to 4408 and let the WG wrestle through how to handle the change that > was introduced in 7208. If you've already rejected the message (e.g. HELO check reached a definitive result) the DMARC doesn't care. There's no relevant change between 4408 and 7208. Scott K From nobody Thu Jan 22 18:36:36 2015 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 AE6C21A8917 for ; Thu, 22 Jan 2015 18:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 JA6oJDDrGfk1 for ; Thu, 22 Jan 2015 18:36:34 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1F991A00E1 for ; Thu, 22 Jan 2015 18:36:33 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D912EC40472; Thu, 22 Jan 2015 20:39:31 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421980771; bh=ZGg1fsMlRHj2+nAa1XTkkeLJuUrVSLyzgWys5JeZVbg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OxYHG2dOPL6kTvLZEZr/TIYaAjVSKuIUTVcC5rEyjQkgQPLkWlTuMG0VYxgXdVtEG i5UhpQy0inMg0GdDTFgfB53t7/0rp+P7PI9/+PUb1f1UyDFzlFiLniBzAYzy9VQAP+ bBTyLeJAPzo6B43Wyep/LOuE6D6ZqL1Wd0f1cIdw= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 22 Jan 2015 21:36:31 -0500 Message-ID: <1817175.t1FDUTCr1f@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1643454857.101996.1421979390163.JavaMail.zimbra@peachymango.org> References: <9690B8A4-36FF-4509-B413-D84AA1DB79CF@kitterman.com> <1643454857.101996.1421979390163.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 02:36:35 -0000 On Thursday, January 22, 2015 20:16:30 Franck Martin wrote: > ----- Original Message ----- > > > From: ned+dmarc@mrochek.com > > To: "John Levine" > > Cc: dmarc@ietf.org, sklist@kitterman.com > > Sent: Thursday, January 22, 2015 5:41:46 PM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > > nits, while I'm at it> > > > >DMARC leverages the Mail From identity, so I don't see how independent > > > >HELO checks can be relevant. > > > > > > If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable > > > interpretation is that you check the HELO identity, and if you get a > > > "definitive policy" result, you're done and return that to the caller. > > > > > > So a message comes from host mail.provider.com with From: > > > bob@customer.com. The recipient host does an SPF check on > > > mail.provider.com, it passes, so SPF is done. DMARC sees that the SPF > > > domain isn't aligned so it ignores it, and DMARC says it's unaligned, > > > even though an SPF check of customer.com might have passed. > > > > > > I can't say whether this is a bug in 7208 or a fundamental flaw in > > > DMARC, but something is clearly wrong and this does not match what > > > running code does. As things are written now, I don't see any way to > > > demand that SPF look at the MAIL FROM if it likes the HELO. > > > > > > Fix 1: file an erratum on 7208 to say to switch the order, do the MAIL > > > FROM check first and only do the HELO check otherwise. This may match > > > some running code, I haven't looked. > > > > > > Fix 2: change 7208 to say that SPF can return multiple results. Ugh. > > > > Filing an erratum for purposes of documenting the issue is fine, but since > > this > > is a substantive change to the protocol it far exceeds the scope of what > > approval of an erratum is allowed to do. As such, I believe the best > > outcome you can get here would be "held for document update". > > I tried to understand Scott, and I think this is what is missing in RFC7208. > > Each check_host() is meant to be done as soon as you have the data to do it. > > So after the HELO phase in SMTP RFC5321, you do check_host(HELO identity, > IP). You get a result and apply the SPF policy (and disconnect if policy > says so) after the mail from phase, you do check_host(MAIL FROM identity, > IP). You get a result and apply the SPF policy (and disconnect if policy > says so) > > This makes sense then, except when SPF policy on both check_host is not -all > > The difficulty then comes when you do these check_host() later in the > RFC5321 transaction, as you have to emulate, this serialization. And then > there is still some uncertainty on what to do when both SPF records exist > and do not have -all both (or when receivers consider -all as ~all) There is no uncertainty. What you do it apply local policy. End of story. The only tricky part is you have to decide what local policy is. This is not new. > I think RFC7208 confused more this serialization, that was implicit in > RFC4408, like the elephant in the room. :P > > To come back to operational matters, I think SPF implementations just do > check_host(MAIL FROM identity, IP) as Terry pointed out, this is why I > suggest DMARC spec could just say that: "DMARC uses only the MAIL FROM > identity and results of the check_host() of the MAIL FROM identity as > defined in RFC7208)" > > And we will fix RFC7208 later to match operational deployments, but this > ought to be recorded somewhere. > > (add reporting to emails, and you get plenty new questions about > standardizations :P) What the code I've written and distributed does is check HELO and if there's not a reject (definitive result) store the helo result and then check Mail From (using the synthetic postmaster@HELO if needed). If the message is not rejected/deferred then the appropriate result header (SPF Received or auth- res) is added for both results. There is a configuration option to only check HELO if Mail From is null, but it's not the default. By default, Postfix (which is what I'm writing for) delays all such checks until rcpt to, so no. There's absolutely no need to do check_host() as soon as you have the information. IIRC I first wrote that code in about 2007 based on RFC 4408. The only way it didn't do explicitly what 4408 required was that it didn't both doing a Mail >From check that would have been pointless since the message was already going to be rejected. We fixed that bug in the spec in RFC 7208 during SPFbis. I really think this is making a mountain out of the tiniest of molehills. Recall: The almost complete lack of receiver policy specification in RFC 4408 (and RFC 7208) is not an oversight. It was a deliberate design choice. Scott K From nobody Thu Jan 22 19:03:58 2015 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 CA6641A00F6 for ; Thu, 22 Jan 2015 19:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 x5SJ9aOcHLBr for ; Thu, 22 Jan 2015 19:03:56 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847331A00BF for ; Thu, 22 Jan 2015 19:03:56 -0800 (PST) Received: (qmail 96630 invoked from network); 23 Jan 2015 03:03:54 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jan 2015 03:03:54 -0000 Date: 23 Jan 2015 03:03:28 -0000 Message-ID: <20150123030328.46355.qmail@ary.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 Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 03:03:57 -0000 >RFC 7208 doesn't say the HELO result determines anything. It says IF (I say again IF) a decision >has been reached about message disposition based on the HELO result, there is no requirement to go >ahead and do a pointless Mail From check. While that is certainly one plausible interpretation of the 7208 language, it says "definitive policy result", a phrase that's not defined anywhere, which may or may not involve a decision about mail disposition. A "pass" result certainly strikes me as a definitive policy result. >Avoiding a check that has been determined to be pointless is the only change in this area in RFC 7208. Indeed, and that turns out to be a lot more incompatible than was appreciated at the time. R's, John From nobody Thu Jan 22 19:17:04 2015 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 8DCE31A00ED for ; Thu, 22 Jan 2015 19:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 XkL9xOT0Ms1C for ; Thu, 22 Jan 2015 19:17:01 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5607E1A0033 for ; Thu, 22 Jan 2015 19:17:01 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CA91BC40472; Thu, 22 Jan 2015 21:19:59 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421983199; bh=08ImT7fzdCwoU+i6LaJKOKpzQNZE84LDK9Dl1W32Tv4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eghPUiF+HKycIuUjBnoICoLRWPKUV8bO+oIqaSLnDGzHnquDOstmbVX9euUBArWRr wrerkLQkqpTxeJJSkvYoQPxA5KYqrlHFaZQRxPOZRIhm1dCO4/62DQd4LSQfJnOOYF tOqmf9GbcDuzKC1Zkx+2Q0QjpWDWvvtkv+gU8myo= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 22 Jan 2015 22:16:58 -0500 Message-ID: <11755350.x5lsV1TBXT@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20150123030328.46355.qmail@ary.lan> References: <20150123030328.46355.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 03:17:02 -0000 On Friday, January 23, 2015 03:03:28 John Levine wrote: > >RFC 7208 doesn't say the HELO result determines anything. It says IF (I say > >again IF) a decision has been reached about message disposition based on > >the HELO result, there is no requirement to go ahead and do a pointless > >Mail From check. > > While that is certainly one plausible interpretation of the 7208 > language, it says "definitive policy result", a phrase that's not > defined anywhere, which may or may not involve a decision about mail > disposition. A "pass" result certainly strikes me as a definitive > policy result. Pass is an SPF result. I probably should have added the word local in front of policy when I wrote that. What I wrote above isn't just a random interpretation, it's what I meant when I wrote it and what we discussed in the working group. > >Avoiding a check that has been determined to be pointless is the only > >change in this area in RFC 7208. > Indeed, and that turns out to be a lot more incompatible than was > appreciated at the time. I'm up to accepting that there's some ambiguity in the language, but I don't see any actual incompatibility assuming the ambiguity is resolved appropriately. If one changes "definitive policy result" to "definitive local policy result" or "definitive receiver policy result" then I think there's no ambiguity. I'm still a bit boggled that anyone is confused about this, but obviously they are. Scott K From nobody Thu Jan 22 20:05:20 2015 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 3E4AE1A0126 for ; Thu, 22 Jan 2015 20:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=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 xniNPVBCs0v1 for ; Thu, 22 Jan 2015 20:05:01 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id F02221A00E9 for ; Thu, 22 Jan 2015 20:05:00 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 84DBC56409B; Thu, 22 Jan 2015 22:05:00 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7F08AA03E8; Thu, 22 Jan 2015 22:05:00 -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 IKcD49e4plkO; Thu, 22 Jan 2015 22:05:00 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 2FB26A03E1; Thu, 22 Jan 2015 22:05:00 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 2FB26A03E1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421985900; bh=KJbvdA/EQ0TNj/aXA4wjxsdypN6k9WJAAX0RW6pT/os=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Fq/gQxdzKejwaqZeHy68JeY2Qp2AFMOXTNyP8rowTGptEwAE2mvTqrAzPabSVPcuk XkAB/9/Cs80SWkTkbxiZH1CsTZ1emFOdXjMlfhBcZYY2ra1+KURs6iSexL5hU7fYh6 heOlz5OR40ixIxKTm7x4wqFVNINyhvI7EppwbtEc= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0715BA03E8; Thu, 22 Jan 2015 22:05:00 -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 O8KT_PgS0l5X; Thu, 22 Jan 2015 22:04:59 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id BA6C0A03E1; Thu, 22 Jan 2015 22:04:59 -0600 (CST) Date: Thu, 22 Jan 2015 22:04:59 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <1231537268.102648.1421985899640.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150123030328.46355.qmail@ary.lan> <11755350.x5lsV1TBXT@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: XBF1wZbG7npM71cZdk6VfaaYdQR9TA== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 04:05:02 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 7:16:58 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > On Friday, January 23, 2015 03:03:28 John Levine wrote: > > >RFC 7208 doesn't say the HELO result determines anything. It says IF (I > > >say > > > >Avoiding a check that has been determined to be pointless is the only > > >change in this area in RFC 7208. > > Indeed, and that turns out to be a lot more incompatible than was > > appreciated at the time. > > I'm up to accepting that there's some ambiguity in the language, but I don't > see any actual incompatibility assuming the ambiguity is resolved > appropriately. > > If one changes "definitive policy result" to "definitive local policy result" > or > "definitive receiver policy result" then I think there's no ambiguity. > > I'm still a bit boggled that anyone is confused about this, but obviously > they > are. > To try to explain the confusion... Well, DKIM is easy, DKIM is valid or is not (I'm excluding temp failures due to DNS etc..). The DKIM spec tells what the dkim result MUST be, and then the receiver do whatever with this result. With SPF, the spf=pass/fail result (as shown in the authentication-result header) is not depending on the sender policy as expressed in the SPF record, but at whatever the receiver policy is... Usually, a SPEC will tell the receiver what it SHOULD do to define the spf= status, but instead it seems RFC7208 says put whatever result you feel like... Therefore different implementations will produce different results. I could have an implementation that checks HELO only and check MAILFROM and ignore the last result to put in the SPF result and that would be in accordance to RFC7208. I could have an implementation that checks HELO and MAILFROM, where an helo pass is better than a MAILFROM fail or softfail, to put SPF=pass as result and that would be still in accordance with RFC7208. or I'm mistaken? From nobody Thu Jan 22 20:41:43 2015 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 CA2EA1A01D5 for ; Thu, 22 Jan 2015 20:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, 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 M1pSDrtsfSfr for ; Thu, 22 Jan 2015 20:41:41 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636B71A0187 for ; Thu, 22 Jan 2015 20:41:41 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7DDCFC40472; Thu, 22 Jan 2015 22:44:40 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421988280; bh=NjlGZAP/ThW7DNeEipnDrtW3U49CkIOnN1roBGwmEJI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UkzrH1hEAOu7SAoy3ltsecKj0IjEMWzICaGY92Ydgv7ENi9NWZaWMVsKzOUqCaqg8 4CIA0sKc41AZPW5ZyjONaOmf+ETmQ/R6VCTFQ3H37C2FKu0cYGKX4meEfA2rOTY61P cp0YeqdtniQPZ+NX+wYXMwm7toD/QZ/1p0u/28dM= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 22 Jan 2015 23:41:39 -0500 Message-ID: <2397344.PpySU5inne@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1231537268.102648.1421985899640.JavaMail.zimbra@peachymango.org> References: <20150123030328.46355.qmail@ary.lan> <1231537268.102648.1421985899640.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 04:41:43 -0000 On Thursday, January 22, 2015 22:04:59 Franck Martin wrote: > ----- Original Message ----- > > > From: "Scott Kitterman" > > To: dmarc@ietf.org > > Sent: Thursday, January 22, 2015 7:16:58 PM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > > nits, while I'm at it> > > On Friday, January 23, 2015 03:03:28 John Levine wrote: > > > >RFC 7208 doesn't say the HELO result determines anything. It says IF (I > > > >say > > > > > > > >Avoiding a check that has been determined to be pointless is the only > > > >change in this area in RFC 7208. > > > > > > Indeed, and that turns out to be a lot more incompatible than was > > > appreciated at the time. > > > > I'm up to accepting that there's some ambiguity in the language, but I > > don't see any actual incompatibility assuming the ambiguity is resolved > > appropriately. > > > > If one changes "definitive policy result" to "definitive local policy > > result" or > > "definitive receiver policy result" then I think there's no ambiguity. > > > > I'm still a bit boggled that anyone is confused about this, but obviously > > they > > are. > > To try to explain the confusion... > > Well, DKIM is easy, DKIM is valid or is not (I'm excluding temp failures due > to DNS etc..). The DKIM spec tells what the dkim result MUST be, and then > the receiver do whatever with this result. > > With SPF, the spf=pass/fail result (as shown in the authentication-result > header) is not depending on the sender policy as expressed in the SPF > record, but at whatever the receiver policy is... No. An SPF result is the deterministic. It's a combination of domain, identity, and result. This is always true and always consistent. Where the variation is in what the receiver decides to do. This is exactly the same as DKIM. I think the confusion is that people think SPF does more because of the name and because at one time (pre-RFC) it did. In hind sight, we'd have been much better off to keep the original name: Sender Permitted From. > Usually, a SPEC will tell the receiver what it SHOULD do to define the spf= > status, but instead it seems RFC7208 says put whatever result you feel > like... Therefore different implementations will produce different results. > > I could have an implementation that checks HELO only and check MAILFROM and > ignore the last result to put in the SPF result and that would be in > accordance to RFC7208. I could have an implementation that checks HELO and > MAILFROM, where an helo pass is better than a MAILFROM fail or softfail, to > put SPF=pass as result and that would be still in accordance with RFC7208. > > or I'm mistaken? I think your mistake to insist that there be one and only one defined way to deal with SPF results from both HELO and Mail From and there isn't. Since RFC 7208 doesn't attempt (except in one special case) to dictate to receivers, it's not at all surprising the you fail to find direction on what to do as a receiver. Scott K From nobody Thu Jan 22 20:56:45 2015 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 C4B241A01F4 for ; Thu, 22 Jan 2015 20:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 OhwglVXjIOpN for ; Thu, 22 Jan 2015 20:56:42 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCD11A0199 for ; Thu, 22 Jan 2015 20:56:42 -0800 (PST) Received: from [192.168.111.105] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id ECC27C40472; Thu, 22 Jan 2015 22:59:41 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421989182; bh=0Uj+IiI6I2qXS3WpHbJr24vFyFT4cR37Og+yfcwh/ek=; h=In-Reply-To:References:Subject:From:Date:To:From; b=NL1aug2HZBLHEdiTtqtp/sFzpWmyl/uQKtfLMET6w+uT7Uy3sILwR9ibLJQeC6Ef3 3MEcELn7hC3TkfaTJeOYgukymYv9sKQHBhlpUnY0rI7KjPavNNv3AZgBMccMSnA1Zm stkyZGZTohz02ZUxF/6Z5C3nK+hSQWIprxbMP9O0= User-Agent: K-9 Mail for Android In-Reply-To: References: <20150121021457.1947.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 22 Jan 2015 19:54:18 -0500 To: "dmarc@ietf.org" Message-ID: <1A73E1BA-8A00-4244-8C07-095B2EBFCA12@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 04:56:43 -0000 On January 22, 2015 1:27:40 PM EST, "Murray S. Kucherawy" wrote: >On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy > >wrote: > >> I am asking the IESG and the ISE what the process is for making such >> adjustments now. >> >> Mainly my resistance to further change comes from the fact that we've >done >> last calls of varying kinds on this document more times than I can >count. >> It really is time to put the non-IETF version to bed and hand it off, >even >> with its weaknesses, and let the standards process take it from >there. >> There's a working group already chartered to do exactly that; in >fact, that >> was one of the premises of creating that working group. >> > >I've consulted with the Area Director sponsoring the document's >conflict >review, and the ISE. Both of them agree that we will only make changes >approved by the ISE and only during AUTH48 at this point, and those >will be >limited to correcting serious problems that would prevent current DMARC >implementations from interacting properly. Anything else can be left >to >the DMARC working group on its standards track deliverable. > >An argument can be made that this proposed change qualifies under that >definition, so please review it and comment as to whether it satisfies >the >defect identified, or whether the change is necessary at all. I will >assume "yes" unless I hear otherwise. Again, the diff is here: > >http://www.blackops.org/~msk/dmarc/diff.html I think what's in the diff is correct and a good clarification. I'm not sure the problem it fixes qualifies as serious, although the longer this thread goes on, the more I lean in that direction. Scott K From nobody Thu Jan 22 20:56:53 2015 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 A02781A026C for ; Thu, 22 Jan 2015 20:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 JcubhRCAiiCs for ; Thu, 22 Jan 2015 20:56:45 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7E01A01F4 for ; Thu, 22 Jan 2015 20:56:45 -0800 (PST) Received: from [192.168.111.105] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5D740C40472; Thu, 22 Jan 2015 22:59:44 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421989184; bh=Wnwz6jVNCARv+w2MvL1xXgPwAp2FXRHCbVRi3GdrBIs=; h=In-Reply-To:References:Subject:From:Date:To:From; b=so3B/quc9i+w2Z8BfwFspURXO6Og6LaoTa0uvsHlqlICkwhq3Fdgcfn8kqwXIqAAC 3asX1KwKRNAR1Kh/5rAfsD+eVjejYgCOcY1vqAyeFx5iY0MP8a4t0ZIor016dX+aLL JnFydhhwNUpTDH1oHsfw6yjIK2bIMu2hpoIDs4+U= User-Agent: K-9 Mail for Android In-Reply-To: <201501222120.t0MLKZWt020710@shadrach.encs.concordia.ca> References: <20150121021457.1947.qmail@ary.lan> <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> <201501222120.t0MLKZWt020710@shadrach.encs.concordia.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 22 Jan 2015 17:21:50 -0500 To: dmarc@ietf.org Message-ID: Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 04:56:46 -0000 On January 22, 2015 4:20:35 PM EST, Michael Jack Assels wrote: >On Thu, 22 Jan 2015 14:46:59 CST, >Franck Martin wrote: > >> ----- Original Message ----- >> > From: "Michael Jack Assels" >> > To: dmarc@ietf.org >> > Sent: Thursday, January 22, 2015 12:00:58 PM >> > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two >more tiny nits, while I'm at it >> > >> > On Thu, 22 Jan 2015 12:48:03 CST, >> > Franck Martin wrote: >> > >> > > [....] >> > > >> > > Hold on... >> > > >> > > What is the decision matrix of SPF? >> > > >> > > SPF uses two strings, the RFC5321.mailfrom and the >> > > RFC5321.helo. Each string may or may not have an SPF record. >> > > What gives the spf status? >> > >> > As I read RFC7208, it doesn't explicitly provide a decision >> > matrix, but it does clearly recommend in section 2.3, that >> > [i]f a conclusive determination about the message can be made >> > based on a check of "HELO", then the use of DNS resources to >> > process the typically more complex "MAIL FROM" can be avoided." >> > >> > Section 2.4 provides that "SPF verifiers MUST check the >> > [RFC5321.mailfrom] identity if a [RFC5321.helo] check either >> > has not been performed or has not reached a definitive policy" >> > >> > I can't think of a way to read that that doesn't imply that >> > a "pass" or a "fail" on the basis of an SPF record for the >> > RFC5321.helo indentity (if such a record exists) is the spf >> > result; otherwise, the result is based on the RFC5321.mailfrom >> > identity. >> > >> > I believe that this is not what DMARC implementations actually >> > do, and that the proposed change to the draft correctly points >> > out the difference and makes it clear what DMARC does, so if >> > I had a vote, I'd vote "yes" to the change. >> > >> >> Ok, but a specific well known implementation does not seem to >> do that: From http://www.openspf.org/Implementations Mail::SPF >> has passed the test suites >> >> http://search.cpan.org/dist/Mail-SPF/lib/Mail/SPF/Request.pm >> "Note: In the case of an empty MAIL FROM SMTP transaction >> parameter (MAIL FROM:<>), you should perform a check with the >> helo scope instead." > >This is what the proposed change says, isn't it? > >> an RFC to reach standard status needs to represent what is out >> there, I'd like to see more code before I form an opinion. > >I think we've crossed wires here. I unreservedly agree that >RFC7208 does NOT represent what all DMARC implementations do, >and it may not even represent what all SPF implementations do. >Perhaps RFC7208 needs correction, but given what it says now, >and given that DMARC has an obvious dependency on SPF, it's >important that DMARC's standard should say "contrary to what >RFC7208 recommends, DMARC normally SPF-checks HELO only when >MAIL FROM is <>". > >I don't think we're disagreeing about what DMARC does, or even >about what SPF usually does, despite what RFC7208 says. I think that's close. DMARC doesn't do SPF, it uses SPF results. Nothing contrary to RFC 7208 (or 4408). Scott K From nobody Thu Jan 22 21:53:06 2015 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 6AF2A1A1A25 for ; Thu, 22 Jan 2015 21:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 HsrIv0O0_lR4 for ; Thu, 22 Jan 2015 21:53:00 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id E6F261A0167 for ; Thu, 22 Jan 2015 21:52:59 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 70FF6564066; Thu, 22 Jan 2015 23:52:59 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 6274EA03E7; Thu, 22 Jan 2015 23:52:59 -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 fXIfLbD2xa3l; Thu, 22 Jan 2015 23:52:59 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0F9E4A03EF; Thu, 22 Jan 2015 23:52:59 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 0F9E4A03EF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1421992379; bh=W6+RQ25XAOPLs2IlauFIIrUMyYyX20dOT6KGnL1LU70=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=kk0UdfxyhSfZs63nV45PcagfgBgdmGwIb4XpStZ6M3VcXMp0VetB4wxkECTpOrVRa REDJV/AwH+beXOw6mhAOUNZaaKZjT5szWL/UP2bnmVUtJHf5koRE8V1EkadcYJjRYh sla6dOk7VsFbO70l/RSQgXAEPEV7h/jhNl/Nr02g= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D9B4DA03E8; Thu, 22 Jan 2015 23:52:58 -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 9t5M0hIiCX-0; Thu, 22 Jan 2015 23:52:58 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id B5457A03E7; Thu, 22 Jan 2015 23:52:58 -0600 (CST) Date: Thu, 22 Jan 2015 23:52:58 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <1254031113.103166.1421992378094.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150123030328.46355.qmail@ary.lan> <1231537268.102648.1421985899640.JavaMail.zimbra@peachymango.org> <2397344.PpySU5inne@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: AB1f7OkPlY5ddNLxF189Jp5KMg4qxA== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 05:53:02 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 8:41:39 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > On Thursday, January 22, 2015 22:04:59 Franck Martin wrote: > > ----- Original Message ----- > > > > > From: "Scott Kitterman" > > > To: dmarc@ietf.org > > > Sent: Thursday, January 22, 2015 7:16:58 PM > > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > > > tiny > > > nits, while I'm at it> > > > On Friday, January 23, 2015 03:03:28 John Levine wrote: > > > > >RFC 7208 doesn't say the HELO result determines anything. It says IF > > > > >(I > > > > >say > > > > > > > > > >Avoiding a check that has been determined to be pointless is the only > > > > >change in this area in RFC 7208. > > > > > > > > Indeed, and that turns out to be a lot more incompatible than was > > > > appreciated at the time. > > > > > > I'm up to accepting that there's some ambiguity in the language, but I > > > don't see any actual incompatibility assuming the ambiguity is resolved > > > appropriately. > > > > > > If one changes "definitive policy result" to "definitive local policy > > > result" or > > > "definitive receiver policy result" then I think there's no ambiguity. > > > > > > I'm still a bit boggled that anyone is confused about this, but obviously > > > they > > > are. > > > > To try to explain the confusion... > > > > Well, DKIM is easy, DKIM is valid or is not (I'm excluding temp failures > > due > > to DNS etc..). The DKIM spec tells what the dkim result MUST be, and then > > the receiver do whatever with this result. > > > > With SPF, the spf=pass/fail result (as shown in the authentication-result > > header) is not depending on the sender policy as expressed in the SPF > > record, but at whatever the receiver policy is... > > No. An SPF result is the deterministic. It's a combination of domain, > identity, and result. This is always true and always consistent. > > Where the variation is in what the receiver decides to do. This is exactly > the same as DKIM. I think the confusion is that people think SPF does more > because of the name and because at one time (pre-RFC) it did. In hind sight, > we'd have been much better off to keep the original name: Sender Permitted > From. I know the receiver can do whatever of the result, and anyhow the receiver, its rules. but I'm sorry I don't read anywhere in RFC7208 where f() is defined. spfresult in (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(HELO identity, IP), check_host(MAIL FROM identity,IP)) it may be clear to you, but it is certainly not for me. Would you please define f()? (note calling MAIL FROM a combination of RFC5321.mailfrom and postmaster@RFC5321.helo does not help clarity either). From nobody Thu Jan 22 22:15:06 2015 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 9361A1A1A8E for ; Thu, 22 Jan 2015 22:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 UmgE8UwxkZzO for ; Thu, 22 Jan 2015 22:15:00 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2753F1A024C for ; Thu, 22 Jan 2015 22:15:00 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3C608C40472; Fri, 23 Jan 2015 00:17:59 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1421993879; bh=F52xusvMN+WnThmlFhZbt1GhIu7/kYmQ0G1gFf3JKB4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=q3P+TPoSdL+TaqHVarfAvOHGgYYkNKrzf4/On21Zej9q0l+3nvz/VEV5TiFGeuatb shh3rM4+ihB9RNF8yA3Jlqcs9wmwHe9OemcU2dNGiT+Wm0bXBSFiH7YYdUIYgMiv8S SXm471G3Uv37dKyAc5hRSrVh+H5ThjahZQ5bhIhc= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 23 Jan 2015 01:14:56 -0500 Message-ID: <4325594.AqqyWs0xax@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1254031113.103166.1421992378094.JavaMail.zimbra@peachymango.org> References: <20150123030328.46355.qmail@ary.lan> <1254031113.103166.1421992378094.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 06:15:04 -0000 On Thursday, January 22, 2015 23:52:58 Franck Martin wrote: > ----- Original Message ----- > > > From: "Scott Kitterman" > > To: dmarc@ietf.org > > Sent: Thursday, January 22, 2015 8:41:39 PM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > > nits, while I'm at it> > > On Thursday, January 22, 2015 22:04:59 Franck Martin wrote: > > > ----- Original Message ----- > > > > > > > From: "Scott Kitterman" > > > > To: dmarc@ietf.org > > > > Sent: Thursday, January 22, 2015 7:16:58 PM > > > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > > > > tiny > > > > nits, while I'm at it> > > > > > > > > On Friday, January 23, 2015 03:03:28 John Levine wrote: > > > > > >RFC 7208 doesn't say the HELO result determines anything. It says > > > > > >IF > > > > > >(I > > > > > >say > > > > > > > > > > > >Avoiding a check that has been determined to be pointless is the > > > > > >only > > > > > >change in this area in RFC 7208. > > > > > > > > > > Indeed, and that turns out to be a lot more incompatible than was > > > > > appreciated at the time. > > > > > > > > I'm up to accepting that there's some ambiguity in the language, but I > > > > don't see any actual incompatibility assuming the ambiguity is > > > > resolved > > > > appropriately. > > > > > > > > If one changes "definitive policy result" to "definitive local policy > > > > result" or > > > > "definitive receiver policy result" then I think there's no ambiguity. > > > > > > > > I'm still a bit boggled that anyone is confused about this, but > > > > obviously > > > > they > > > > are. > > > > > > To try to explain the confusion... > > > > > > Well, DKIM is easy, DKIM is valid or is not (I'm excluding temp failures > > > due > > > to DNS etc..). The DKIM spec tells what the dkim result MUST be, and > > > then > > > the receiver do whatever with this result. > > > > > > With SPF, the spf=pass/fail result (as shown in the > > > authentication-result > > > header) is not depending on the sender policy as expressed in the SPF > > > record, but at whatever the receiver policy is... > > > > No. An SPF result is the deterministic. It's a combination of domain, > > identity, and result. This is always true and always consistent. > > > > Where the variation is in what the receiver decides to do. This is > > exactly > > the same as DKIM. I think the confusion is that people think SPF does > > more > > because of the name and because at one time (pre-RFC) it did. In hind > > sight, we'd have been much better off to keep the original name: Sender > > Permitted From. > > I know the receiver can do whatever of the result, and anyhow the receiver, > its rules. > > but I'm sorry I don't read anywhere in RFC7208 where f() is defined. > > spfresult in > (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(HELO identity, > IP), check_host(MAIL FROM identity,IP)) > > it may be clear to you, but it is certainly not for me. Would you please > define f()? > > (note calling MAIL FROM a combination of RFC5321.mailfrom and > postmaster@RFC5321.helo does not help clarity either). Probably not, but I don't know how else to have dealt with it. f() doesn't exist. SPF's check_host() has inputs and an output. If you call it twice then you have two outputs to decide how to aggregate. The way I've done it typically is something like (let's leave SPF check whitelisting out of the equation to keep it relatively simple): spfresult.helo in (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(HELO identity, IP) Apply local policy: if spfresult.helo == fail, neutral, softfail, permerror then reject if spfresult.helo == temperror then defer else no definitive result if no definitive result: If Mail From == "" then Mail From = postmaster@HELO identity spfresult.mailfrom in (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(Mail From identity, IP) Apply local policy: if spfresult.mailfrom == fail, permerror then reject if spfresult.mailfrom == temperror then defer else no definitive result If no definitive result, add Received SPF or A-R header fields for both checks and complete the SPF check (the messsage may still end up rejected, deferred, spamfoldered, dropped, or accepted based on other checks - I wouldn't recommend accepting just on SPF). The follow-on processing might include DMARC, but it's unrelated. Scott K Note: This is roughly the default processing the SPF policy server I wrote for postfix. There's lots of ways to do this and most of them wouldn't be wrong. From nobody Fri Jan 23 09:04:14 2015 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 4686B1A1B06 for ; Fri, 23 Jan 2015 09:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 1Rc-d6dLRZzC for ; Fri, 23 Jan 2015 09:03:56 -0800 (PST) Received: from dkim.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 485A71A1AD0 for ; Fri, 23 Jan 2015 09:03:56 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3097; t=1422032634; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=3xc+dltWXAKkCEfswF5IyT9ohYs=; b=IDu8Y7yjmiKiCln7B2Fz 1bA8bn/izn2cjIIuqk2E2rjCPat7proze3I4hGKpmkU6485oOhCSCQA+dFQfp+HC vgjQUD1EnoaOWt5GHSjh2iMStryOEa0M/iC/QqcOwUFgv8g/0MRboNTTfeNmqOHF jQpzkGOiMzR5DiYK5i4jVOI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 23 Jan 2015 12:03:54 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 37696760.5786.5772; Fri, 23 Jan 2015 12:03:54 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3097; t=1422032538; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RmF+Pa4 4PgVQ/JkVBHY5A/C5HOikHpOVuIbESUm8YPs=; b=Df+HooIfyXN1DSHDDZUPqv4 RHQ+wjVP4VWZLh1/i83LrlsSe8W4rMwh9zfHJy4AVzjoeiiWkMuHe2By3khnPmiQ 3/5yuAGZBiiT/KSRih+miLfypKmMwwYlKVJcRumPtx4FCHFXTVPJHqhQN7ppgktU KLvNaUc8eqGAnBtO3AL4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 23 Jan 2015 12:02:18 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2925008830.9.8628; Fri, 23 Jan 2015 12:02:17 -0500 Message-ID: <54C27EFA.7000502@isdg.net> Date: Fri, 23 Jan 2015 12:03:54 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kurt Andersen , Scott Kitterman , "Murray S. Kucherawy" References: <20150122231728.780.qmail@ary.lan> <6368691B-0343-4D5E-A21A-7BFEF20BCD2D@kitterman.com> <58A5D269-F368-49F8-9819-656DA8EA6359@kitterman.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] DMARC SPF support for both RFC7208 and RFC 4408 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, 23 Jan 2015 17:04:11 -0000 On 1/22/2015 8:59 PM, Kurt Andersen wrote: > > I think that the crux of the issue is this: > 1) The DMARC spec was written with 4408 as context. That remains true > today, except that in the meantime 7208 was finalized (thanks to > SPFbis) and Murray was seeking to keep up with the times by following > the "7208 obsoletes 4408" statement. > 2) The key problem is that 7208 changes the checking precedence. > Here's what the two specs actually say: > 4408, section 2.2: "SPF clients MUST check the "MAIL FROM" identity." > 7208, section 2.4: "SPF verifiers MUST check the "MAIL FROM" identity > if a "HELO" check either has not been performed or has not reached a > definitive policy. . ." > > My recommendation is to take -12 and amend it to change the SPF > reference back to 4408 and let the WG wrestle through how to handle > the change that was introduced in 7208. > > --Kurt +0.8 I believe this -12 rev "jumped the gun" to presume 4408 is obsolete when its not in practice and probably won't be for a very long time. I understand the IETF idea that 7208 updates 4408 but there are differences besides the HELO issue and the reality would be there may be both type of SPF receivers and that includes support for 5322.Authentication-Result (AUTH-RES) in 7208, and 4408 which only supports 5322.Received-SPF. 7208 was suppose to be compatible to both possible consumers of these 5322 reporting headers. So if DMARC requires AUTH-RES, then it should reference 7208 for this key reason and it should also continue to reference 4408 to provide design semantics regarding adding DMARC support existing 4408 only systems with the official SPF reporting trace header. Its possible for DMARC implementations to add support for detecting both reporting headers. That would be an "informational" type of design semantics that should be in this document, if not already, i.e, future DMARC implementations need to understand that current software SPF modules SPF may not be 7208 ready and will A) change it if they can, and/or b) add support for SPF 4408 Received-SPF results. For new developers, starting with this Informational version of DMARC, there is a mix of inconsistencies. And until the official IETF standard track "solid spec" version is done, this IETF-produced informational doc will be the "pseudo" standard to work with. So it should be ready for the "solid spec." Finally, just look at its ADSP references, with semantics, direct or indirect, regarding ADSP, it should probably be removed at this point. The informational doc should be as clean and clear as possible about what is expected to come and that includes support for 3rd party Policy augmented protocol extensions. One last thing, it should also add some Migration considerations such as: - SPF 4408 to SPF 7208, - ADSP to DMARC, - Other future software enhancement "Get Ready" considerations. For future implementations that do not use the open source libraries, the "OpenDMarc" or any other 3rd party package, this would be a big item. -- HLS From nobody Fri Jan 23 10:07:30 2015 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 85F0A1ACD5E for ; Fri, 23 Jan 2015 10:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 3K18HQJyZtOz for ; Fri, 23 Jan 2015 10:07:25 -0800 (PST) Received: from news.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0D47B1ACD39 for ; Fri, 23 Jan 2015 10:06:51 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1007; t=1422036399; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=gWGkOsvVkohrjAIYvBYCCzB9MsQ=; b=bLSOCTMjFlikVuw+Csy5 RSPVsPXh82vriZIIPHPzaK1owRsic7VcedpfW8gmMxElaTPABsxzksys6GWTRudl GnYBzhV5utIqEogIzWnkaPCgwh8iZcTmNOGZgK1zaVpCyYrNH5NdUG2g9T4DAfzJ MKBbozeDIsY+kSrCX52ey5I= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 23 Jan 2015 13:06:39 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 41461953.5786.5332; Fri, 23 Jan 2015 13:06:39 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1007; t=1422036307; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gfNZF7E SiWM7WpaGpLRoSOWmlns6MlO2eyPfgQlE8Fw=; b=I9VmwmiuQyAY0Ndmf6V7Ltn PX2O0TYkcLn91fb5yVA1OA/SJsEe1LqW9vin9zUzsTZ1FlHgqiQAjAA06dwWDo3M sxSPdHy0WgM5Ny1Xb/Q5QsowQOmsU/AJaBQkg+qCl3BdqvQ1UE8glY+06HgYkJ1E jVJHaOtOBgVKUN6jt/V4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 23 Jan 2015 13:05:07 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2928777658.9.5376; Fri, 23 Jan 2015 13:05:06 -0500 Message-ID: <54C28DB3.8000507@isdg.net> Date: Fri, 23 Jan 2015 13:06:43 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Terry Zink , "dmarc@ietf.org" References: <955371379.92119.1421952483633.JavaMail.zimbra@peachymango.org> <201501222000.t0MK0wl0020115@shadrach.encs.concordia.ca> <1751041912.95797.1421959619345.JavaMail.zimbra@peachymango.org> <54C18303.7070208@sonnection.nl> <701580818.100954.1421971052000.JavaMail.zimbra@peachymango.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 18:07:27 -0000 On 1/22/2015 7:13 PM, Terry Zink wrote: > The way it works in Office 365 is this: > > 1. When checking SPF, use the domain in the 5321.MailFrom. If it is empty, use the domain in the HELO/EHLO. > 2. Use the domain extracted from (1) when doing the DMARC alignment check for SPF. > > We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never found this to be a problem. > SPF Software that also supports: RFC4405 SUBMITTER SMTP Service Extension RFC4406 Sender ID: Authenticating E-Mail RFC4407 Purported Responsible Address (PRA) will also look at the PRA for SPF calculations. Enable the SMTP Extension 4405 and watch many of the sessions using the SUBMITTER field in MAIL FROM: MAIL FROM: SUBMITTER=pra > I don't know how it works in Hotmail (although I should) but it is moving over to the Office 365 infrastructure over the next several months anyhow so it will be the same. > Its good to know that Microsoft is single sourcing it. -- HLS From nobody Fri Jan 23 10:37:18 2015 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 731FA1A86FF for ; Fri, 23 Jan 2015 10:36:56 -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, 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 U6FxBt2KIdM1 for ; Fri, 23 Jan 2015 10:36:54 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3536D1A871D for ; Fri, 23 Jan 2015 10:36:48 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id BC7D356418C; Fri, 23 Jan 2015 12:36:47 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B7C57A0308; Fri, 23 Jan 2015 12:36:47 -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 HZwNlmpIH7Bk; Fri, 23 Jan 2015 12:36:47 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 237E8A03CE; Fri, 23 Jan 2015 12:36:46 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 237E8A03CE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1422038207; bh=vLLatD+Ki460I+USxZiW7436HHbo1A+HDDMEwuIstWc=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=N6pE8g8p8pYvfrqWW+UZuL5N2LpgdgrfR9UzeBhePwyvnyVyD2Q8+0KMSNoqi11tm ulTRmpPyWpPO9h2m8eneEUQDHZUb69En0VIWlq7EQBeeMbTOEsHf5ltZTdlkqsstNG yzsyHNHSLVSrHng+sNEhnf8zexOFKTk0SWR6S0t0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0B2EBA0395; Fri, 23 Jan 2015 12:36:46 -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 uuz0XzP7g-z6; Fri, 23 Jan 2015 12:36:45 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id D664DA0308; Fri, 23 Jan 2015 12:36:45 -0600 (CST) Date: Fri, 23 Jan 2015 12:36:45 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <8464504.115519.1422038205376.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150121021457.1947.qmail@ary.lan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_115518_351632264.1422038205375" X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: xVbbJNqA2eHJsu53McicwdjRedFGgQ== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 18:36:56 -0000 ------=_Part_115518_351632264.1422038205375 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 10:27:40 AM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < superuser@gmail.com > > wrote: > > I am asking the IESG and the ISE what the process is for making such > > adjustments now. > > > Mainly my resistance to further change comes from the fact that we've done > > last calls of varying kinds on this document more times than I can count. > > It > > really is time to put the non-IETF version to bed and hand it off, even > > with > > its weaknesses, and let the standards process take it from there. There's a > > working group already chartered to do exactly that; in fact, that was one > > of > > the premises of creating that working group. > > I've consulted with the Area Director sponsoring the document's conflict > review, and the ISE. Both of them agree that we will only make changes > approved by the ISE and only during AUTH48 at this point, and those will be > limited to correcting serious problems that would prevent current DMARC > implementations from interacting properly. Anything else can be left to the > DMARC working group on its standards track deliverable. > An argument can be made that this proposed change qualifies under that > definition, so please review it and comment as to whether it satisfies the > defect identified, or whether the change is necessary at all. I will assume > "yes" unless I hear otherwise. Again, the diff is here: > http://www.blackops.org/~msk/dmarc/diff.html So after the whole discussion, I don't think in 4.1 we can say "in contradiction of SPF". DMARC is defining a "local policy" for SPF, which is valid. People implementting DMARC must ensure their SPF implementation follow also this local policy. I would cite Terry's email where his SPF follows what DMARC expects, and where Scott said it is a valid implementation of SPF, and Scott implementation of SPF, which is valid too. I would also cite Tim's conformance tests, that matches operational deployment. So to be pedantic, suggested text: [SPF], which authenticates the HELO identity and the MAIL FROM identity: the domain found in an [SMTP] MAIL command, or the domain found in the HELO/EHLO command if the MAIL command has a null path. Note that in the context of DMARC, this later identity is only used. ------=_Part_115518_351632264.1422038205375 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable



=
From: "Murray S. Kucherawy" <superuser@gmail.com>To: dmarc@ietf.org
Sent: Thursday, January 22, 2015 10:2= 7:40 AM
Subject: Re: [dmarc-ietf] questions on the spec, was ... = and two more tiny nits, while I'm at it

= On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy <= ;superuser@gmail.c= om> wrote:
I= am asking the IESG and the ISE what the process is for making such adjustm= ents now.
Mainly my resistance to further change comes from the fact that we've done= last calls of varying kinds on this document more times than I can count.&= nbsp; It really is time to put the non-IETF version to bed and hand it off,= even with its weaknesses, and let the standards process take it from there= .  There's a working group already chartered to do exactly that; in fa= ct, that was one of the premises of creating that working group.
<= /div>

I've consulted with the A= rea Director sponsoring the document's conflict review, and the ISE.  = Both of them agree that we will only make changes approved by the ISE and o= nly during AUTH48 at this point, and those will be limited to correcting se= rious problems that would prevent current DMARC implementations from intera= cting properly.  Anything else can be left to the DMARC working group = on its standards track deliverable.

An argumen= t can be made that this proposed change qualifies under that definition, so= please review it and comment as to whether it satisfies the defect identif= ied, or whether the change is necessary at all.  I will assume "yes" u= nless I hear otherwise.  Again, the diff is here:

ht= tp://www.blackops.org/~msk/dmarc/diff.html
<= /blockquote>
So after the whole discussion, I don't think in 4.1 we can= say "in contradiction of SPF". DMARC is defining a "local policy" for SPF,= which is valid. People implementting DMARC must ensure their SPF implement= ation follow also this local policy.

I would cite= Terry's email where his SPF follows what DMARC expects, and where Scott sa= id it is a valid implementation of SPF, and Scott implementation of SPF, wh= ich is valid too. I would also cite Tim's conformance tests, that matches o= perational deployment.

So to be pedantic, sugg= ested text:
[SPF], which authenticates the HELO identity and = the MAIL FROM identity: the domain found in an [SMTP] MAIL
comman= d, or the domain found in the HELO/EHLO command if the MAIL
comma= nd has a null path. Note that in    
the context of DMARC= , this later identity is only used.
------=_Part_115518_351632264.1422038205375-- From nobody Fri Jan 23 10:45:19 2015 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 69A9F1A1B1E for ; Fri, 23 Jan 2015 10:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 UlOJVoLX7qoy for ; Fri, 23 Jan 2015 10:45:04 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 187361A1AD2 for ; Fri, 23 Jan 2015 10:45:04 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id BE68E564159; Fri, 23 Jan 2015 12:45:03 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id AC406A03D0; Fri, 23 Jan 2015 12:45:03 -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 Y928GhDypQWh; Fri, 23 Jan 2015 12:45:03 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 769B3A03CE; Fri, 23 Jan 2015 12:45:03 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 769B3A03CE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1422038703; bh=JrHjhi9rjx/IkfNURmxLjaFah9kUYPumRTq2rDMOcgA=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Mzq0QXBFWL7I4Tg4BSSuUZZ95qYXXEyo5W33R8gEG8snSEfV4WrK4bVLDW8Boo4Pz IDnW79aRtaA9A+Z3/Z4Ze0sr0yiiiVNCnYWaMlALr8Pfu/s7COExZRKz0834UV60OE bVX49t5nPK6e5OMhd2GMk7WS20bvzA9E4/bB4unc= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4EA5DA03D5; Fri, 23 Jan 2015 12:45:03 -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 TIknmpNpke6Y; Fri, 23 Jan 2015 12:45:03 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 0C9ABA03CE; Fri, 23 Jan 2015 12:45:03 -0600 (CST) Date: Fri, 23 Jan 2015 12:45:02 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <1787558876.115795.1422038702849.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150123030328.46355.qmail@ary.lan> <1254031113.103166.1421992378094.JavaMail.zimbra@peachymango.org> <4325594.AqqyWs0xax@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: vU3VvNWK5K6IR1mcS7lUuPWChq3x5g== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 18:45:05 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Thursday, January 22, 2015 10:14:56 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > On Thursday, January 22, 2015 23:52:58 Franck Martin wrote: > > ----- Original Message ----- > > > > > > I know the receiver can do whatever of the result, and anyhow the receiver, > > its rules. > > > > but I'm sorry I don't read anywhere in RFC7208 where f() is defined. > > > > spfresult in > > (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(HELO identity, > > IP), check_host(MAIL FROM identity,IP)) > > > > it may be clear to you, but it is certainly not for me. Would you please > > define f()? > > > > (note calling MAIL FROM a combination of RFC5321.mailfrom and > > postmaster@RFC5321.helo does not help clarity either). > > Probably not, but I don't know how else to have dealt with it. First thanks, for describing in details your implementation. Very useful. > > f() doesn't exist. SPF's check_host() has inputs and an output. If you call > it twice then you have two outputs to decide how to aggregate. > Yes this is where the point is, RFC7208 does not define how to aggregate the results. This is the part which is not clear in the spec, and should be clearly spelled out, me thinks. From nobody Fri Jan 23 12:07:19 2015 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 E6DD31A1AF2 for ; Fri, 23 Jan 2015 12:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 gilk8pwqOaL4 for ; Fri, 23 Jan 2015 12:06:59 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 762541A1ADF for ; Fri, 23 Jan 2015 12:06:59 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 185AFC403F1; Fri, 23 Jan 2015 14:10:06 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1422043806; bh=UU1mC666JyB8jp07p7C5sd8TvVLYiOz4YT7fTshXdds=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iApeohQRRkttjldnfz+69IePJP+Avdj6Vy+6afHqQJNRGPL6eJ+ICs8R1CuQXFPkw BGTfw2DALLWWIVbBXMUXljJh0nolMaQgAiCM8dRIDvGejxH1gosQT7MeKzb9jNm3jT J1k55jNcjmfHRYI1IhZHkozPeHiJnaB7BiFhP9+4= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 23 Jan 2015 15:06:56 -0500 Message-ID: <3199028.vBhhPjPtdX@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <54C28DB3.8000507@isdg.net> References: <54C28DB3.8000507@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 20:07:01 -0000 On Friday, January 23, 2015 13:06:43 Hector Santos wrote: > On 1/22/2015 7:13 PM, Terry Zink wrote: > > The way it works in Office 365 is this: > > > > 1. When checking SPF, use the domain in the 5321.MailFrom. If it is empty, > > use the domain in the HELO/EHLO. 2. Use the domain extracted from (1) > > when doing the DMARC alignment check for SPF. > > > > We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never found > > this to be a problem. > SPF Software that also supports: > > RFC4405 SUBMITTER SMTP Service Extension > RFC4406 Sender ID: Authenticating E-Mail > RFC4407 Purported Responsible Address (PRA) > > will also look at the PRA for SPF calculations. Enable the SMTP > Extension 4405 and watch many of the sessions using the SUBMITTER > field in MAIL FROM: > > MAIL FROM: SUBMITTER=pra Hector, As you know, those are Sender ID, not SPF. Scott K From nobody Fri Jan 23 12:30:49 2015 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 82A951A1BE3 for ; Fri, 23 Jan 2015 12:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 YugsY40pZ6En for ; Fri, 23 Jan 2015 12:30:28 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019071A1BE0 for ; Fri, 23 Jan 2015 12:30:23 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0F937C403F1; Fri, 23 Jan 2015 14:33:31 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1422045211; bh=R8SLdUcbR7SmxiFQLSybZCWqbEECa7CeqGbGLVZxuyY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PJFQcu2yJZ2tOzxj5NAF8EcQe6+9cNF8y5VgUOZwPhjDudDY+sfe7CAa+zyK5H8+B 4edsI2+kS54wiot2KBrNeiVK2TXIe59aYT1eDStowi/3tRzjYtYdapWASPgVrJPEdZ Y6uHxFsv+V93TW2c17vaYel1DPgC3Q6cNXUzl8O0= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 23 Jan 2015 15:30:22 -0500 Message-ID: <7078275.DjGRhGCaG6@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1787558876.115795.1422038702849.JavaMail.zimbra@peachymango.org> References: <20150123030328.46355.qmail@ary.lan> <1787558876.115795.1422038702849.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 20:30:29 -0000 On Friday, January 23, 2015 12:45:02 Franck Martin wrote: > ----- Original Message ----- > > > From: "Scott Kitterman" > > To: dmarc@ietf.org > > Sent: Thursday, January 22, 2015 10:14:56 PM > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > > nits, while I'm at it> > > On Thursday, January 22, 2015 23:52:58 Franck Martin wrote: > > > ----- Original Message ----- > > > > > > > > > I know the receiver can do whatever of the result, and anyhow the > > > receiver, > > > its rules. > > > > > > but I'm sorry I don't read anywhere in RFC7208 where f() is defined. > > > > > > spfresult in > > > (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(HELO > > > identity, > > > IP), check_host(MAIL FROM identity,IP)) > > > > > > it may be clear to you, but it is certainly not for me. Would you please > > > define f()? > > > > > > (note calling MAIL FROM a combination of RFC5321.mailfrom and > > > postmaster@RFC5321.helo does not help clarity either). > > > > Probably not, but I don't know how else to have dealt with it. > > First thanks, for describing in details your implementation. Very useful. > > > f() doesn't exist. SPF's check_host() has inputs and an output. If you > > call it twice then you have two outputs to decide how to aggregate. > > Yes this is where the point is, RFC7208 does not define how to aggregate the > results. This is the part which is not clear in the spec, and should be > clearly spelled out, me thinks. I guess that's where we'll have to disagree. I don't know what RFC 7208 could have said beyond "How to aggregate SPF HELO and SPF Mail From checks is a matter of local policy". That doesn't really help much. Personally, I don't think they can be successfully aggregated into a single SPF result since they are about different things. Scott K From nobody Fri Jan 23 14:09:18 2015 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 EA19D1A87BE for ; Fri, 23 Jan 2015 14:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 rLQr-kdeyqz5 for ; Fri, 23 Jan 2015 14:08:44 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id D720D1A87D1 for ; Fri, 23 Jan 2015 14:08:27 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 4CE62564157; Fri, 23 Jan 2015 16:08:27 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 36D8FA03D4; Fri, 23 Jan 2015 16:08:27 -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 hxBpwdfZruE8; Fri, 23 Jan 2015 16:08:27 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D1AE6A0278; Fri, 23 Jan 2015 16:08:26 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com D1AE6A0278 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1422050906; bh=d38Dx4TLQkmY4HsFYQXDqA5NaoCKYUYoyFIsdYNXwn8=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=PxeY58PbRLI3okPJqtE0CWPmYysfmAbTCvLPaBe4pUJpg1QiW1PegpcRT5Y7aiWBn VzPXPkqcphyjekBHobpLrxoOgxOlunGf5l6ai8c3FNH+ARX5YQf5M2fmxwcHzLrVdd IWae4Q1ItUvLrPAPGQ/yxjPPxz56MS5tXPkq17Gg= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9D6A2A03D4; Fri, 23 Jan 2015 16:08:26 -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 2OOO06NtI_p0; Fri, 23 Jan 2015 16:08:26 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 78D97A0278; Fri, 23 Jan 2015 16:08:26 -0600 (CST) Date: Fri, 23 Jan 2015 16:08:26 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <875853947.122724.1422050906189.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150123030328.46355.qmail@ary.lan> <1787558876.115795.1422038702849.JavaMail.zimbra@peachymango.org> <7078275.DjGRhGCaG6@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: A6T3wJyhrcd+Z/OftzTkzrn80g7akQ== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 22:08:52 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Friday, January 23, 2015 12:30:22 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > On Friday, January 23, 2015 12:45:02 Franck Martin wrote: > > ----- Original Message ----- > > > > > From: "Scott Kitterman" > > > To: dmarc@ietf.org > > > Sent: Thursday, January 22, 2015 10:14:56 PM > > > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more > > > tiny > > > nits, while I'm at it> > > > On Thursday, January 22, 2015 23:52:58 Franck Martin wrote: > > > > ----- Original Message ----- > > > > > > > > > > > > I know the receiver can do whatever of the result, and anyhow the > > > > receiver, > > > > its rules. > > > > > > > > but I'm sorry I don't read anywhere in RFC7208 where f() is defined. > > > > > > > > spfresult in > > > > (pass,fail,softfail,permfail,tmpfail,none,...)=f(check_host(HELO > > > > identity, > > > > IP), check_host(MAIL FROM identity,IP)) > > > > > > > > it may be clear to you, but it is certainly not for me. Would you > > > > please > > > > define f()? > > > > > > > > (note calling MAIL FROM a combination of RFC5321.mailfrom and > > > > postmaster@RFC5321.helo does not help clarity either). > > > > > > Probably not, but I don't know how else to have dealt with it. > > > > First thanks, for describing in details your implementation. Very useful. > > > > > f() doesn't exist. SPF's check_host() has inputs and an output. If you > > > call it twice then you have two outputs to decide how to aggregate. > > > > Yes this is where the point is, RFC7208 does not define how to aggregate > > the > > results. This is the part which is not clear in the spec, and should be > > clearly spelled out, me thinks. > > I guess that's where we'll have to disagree. I don't know what RFC 7208 > could > have said beyond "How to aggregate SPF HELO and SPF Mail From checks is a > matter of local policy". That doesn't really help much. Personally, I don't > think they can be successfully aggregated into a single SPF result since they > are about different things. > No, no, we don't disagree, I did not express myself correctly. I would like to see this text you just wrote in the spec may be something like: "Aggregating SPF HELO and SPF Mail From checks is a matter of local policy. This document does not defines a single result nor how to get one, but defines a result for each check." From nobody Fri Jan 23 14:54:44 2015 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 54A691A00A8 for ; Fri, 23 Jan 2015 14:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -82.002 X-Spam-Level: X-Spam-Status: No, score=-82.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLACK=20, USER_IN_WHITELIST=-100] 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 8Isb7nMKY8jP for ; Fri, 23 Jan 2015 14:54:39 -0800 (PST) Received: from ntbbs.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 730281A8AEA for ; Fri, 23 Jan 2015 14:54:38 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4796; t=1422053675; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Q2f7PQ95mj13JN3Sh1h000rCTKs=; b=e1ZI/U50zJZGHGIfmqYC vL+BuvH/cgOr+gtFj4XMST2GQwlnpGL/J2ro2pOWLiunsnjQipwbI29jh+s1lWow 9hDbX78YNYUiY8+KwNGTMaxh6v33pgkLSypkVH1bLolLMUnR4TKvhso0JvCXe1NY LRAZoxSxoSf3cEFRCwdOOUw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 23 Jan 2015 17:54:35 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 58737317.5786.4444; Fri, 23 Jan 2015 17:54:34 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4796; t=1422053578; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=bGk+33V A5UqLdFyb9nrFeO2pWS9GM3oj8L3XvupSQmE=; b=kYbEgitohVKjeO2koxkdRXM zNoPAOcUEzSS4XDVuZFbc08VVxmiPEVj6pRTt8kMvJpi33Ee2IXGH1Q27xPpUxY4 8tPrSyvhYGjQszvmEDf/w3STkcuB+6aiL6TKQweMT6bGqF+AC3cNFkanJQX3iIgC PW5N9T6YQBW0PWny3Vfs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 23 Jan 2015 17:52:58 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2946048455.9.5960; Fri, 23 Jan 2015 17:52:57 -0500 Message-ID: <54C2D12A.2090501@isdg.net> Date: Fri, 23 Jan 2015 17:54:34 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Scott Kitterman , dmarc@ietf.org References: <54C28DB3.8000507@isdg.net> <3199028.vBhhPjPtdX@scott-latitude-e6320> In-Reply-To: <3199028.vBhhPjPtdX@scott-latitude-e6320> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 23 Jan 2015 22:54:43 -0000 On 1/23/2015 3:06 PM, Scott Kitterman wrote: > On Friday, January 23, 2015 13:06:43 Hector Santos wrote: >> On 1/22/2015 7:13 PM, Terry Zink wrote: >>> The way it works in Office 365 is this: >>> >>> 1. When checking SPF, use the domain in the 5321.MailFrom. If it is empty, >>> use the domain in the HELO/EHLO. 2. Use the domain extracted from (1) >>> when doing the DMARC alignment check for SPF. >>> >>> We don't check both 5321.MailFrom AND HELO/EHLO for SPF. I've never found >>> this to be a problem. >> SPF Software that also supports: >> >> RFC4405 SUBMITTER SMTP Service Extension >> RFC4406 Sender ID: Authenticating E-Mail >> RFC4407 Purported Responsible Address (PRA) >> >> will also look at the PRA for SPF calculations. Enable the SMTP >> Extension 4405 and watch many of the sessions using the SUBMITTER >> field in MAIL FROM: >> >> MAIL FROM: SUBMITTER=pra > > Hector, > > As you know, those are Sender ID, not SPF. > Correct, but as pointed out during SPFBIS, the integration of all the protocols is possible as it is with our package. When the PRA is passed via the MAIL FROM SUBMITTER field, this could override or may be used in conjunction with 5321.MAIL FROM. Grant it, we are probably the only SMTP package that supports SUBMITTER at the server side so it may not mean much to you, but the fact remains, if you turn on the SMTP extension, you will get a high rate of clients that issue the MAIL FROM SUBMITTER=pra field. You choose to not consider this high possibility of SUBMITTER SPF sessions during SPFBIS. It may be a consideration for DMARC Informational doc. Just a quick view of todays SMTP trace logs, here is one of many SMTP sessions with the SUBMITTER field. ************************************************************************** Wildcat! ESMTP Server v7.0.454.4 SMTP log started at Fri, 23 Jan 2015 01:19:19 Connection Time: 20150123 01:19:19 cid: 0000169A tid: 0000159C SSL-Enabled=YES No-Quit-Cancel=OFF Receiver-Bin=ON Client IP: 216.98.142.131:59607 (mx131.gbm22.com) Host IP: 208.247.131.9:25 01:19:19.824 S: 220-winserver.com Wildcat! ESMTP Server v7.0.454.4 ready 01:19:19.824 S: 220-************** WARNING: FOR AUTHORIZED USE ONLY! ********************** 01:19:19.825 S: 220-* THIS SYSTEM DO NOT AUTHORIZE THE USE OF ITS PROPRIETARY COMPUTERS * 01:19:19.825 S: 220-* AND COMPUTER NETWORKS TO ACCEPT, TRANSMIT, OR DISTRIBUTE UNSOLICITED * 01:19:19.825 S: 220-* BULK E-MAIL SENT FROM THE INTERNET. THIS SYSTEM WILL RESTRICT ACCESS * 01:19:19.825 S: 220-* TO CAN-SPAM (US S. 877) COMPLIANT CLIENTS ONLY. * 01:19:19.825 S: 220 ************************************************************************ 01:19:20.039 C: EHLO mx131.gbm22.com 01:19:20.041 S: 250-winserver.com, Hello mx131.gbm22.com, pleased to meet you. 01:19:20.041 S: 250-SIZE 10240000 01:19:20.041 S: 250-8BITMIME 01:19:20.041 S: 250-SUBMITTER 01:19:20.041 S: 250-ETRN 01:19:20.041 S: 250-AUTH CRAM-MD5 DIGEST-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1 01:19:20.041 S: 250-AUTH=LOGIN 01:19:20.041 S: 250-HELP 01:19:20.041 S: 250 STARTTLS 01:19:20.294 C: MAIL FROM: BODY=7BIT SUBMITTER=support@gbresponder.com 01:19:20.295 S: 250 ... Sender validation pending. Continue. 01:19:20.401 C: RCPT TO: 01:19:20.402 S: 550 User not a member of domain: 01:19:20.511 C: QUIT 01:19:20.511 S: 221 closing connection 01:19:20.511 ** Completed. Elapsed Time: 1124 msecs First, for our receiver, note the delayed Sender validation was pending (SPF checking, among other envelope parameters filter checks) until RCPT TO is known. Next, note what the SPF and DMARC records at: gbresponder.com "v=spf1 a mx a:gbresponder.com ip4:71.6.179.3 ip4:71.6.179.0/24 ip4:167.88.9.128/26 -all" _dmarc.gbresponder.com "v=DMARC1; p=none; rf=afrf; rua=mailto:dmarc@gbresponder.com" The client domain name mx131.gbm22.com has no record and there was a short delay. Just to illustrate that these are still high overhead items. Our package will still support SUBMITTER until I have a reason not to. I don't think its a big thing because most of the time, the domains all align up. I am not making a case for submitter, just to point that there are still operations out there using it, especially at the client side. The package with such a client COULD also be supporting the server side of submitter SPF processing as well. A case can be made that the SUBMITTER=PRA is the same as the 5322.From field, its possible to explore this as a way to determine the DMARC policy before the DATA overhead is transferred. -- HLS From nobody Fri Jan 23 15:27:54 2015 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 36A8D1A065C for ; Fri, 23 Jan 2015 15:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 iuICErZl_D1Z for ; Fri, 23 Jan 2015 15:27:48 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2A51A006D for ; Fri, 23 Jan 2015 15:27:48 -0800 (PST) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0NNRltQ007825 for ; Fri, 23 Jan 2015 18:27:47 -0500 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0NNRk2B008590 for ; Fri, 23 Jan 2015 18:27:47 -0500 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 23 Jan 2015 18:27:46 -0500 Message-ID: <8589.1422055666@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-23 18:27:47 EST Archived-At: Subject: [dmarc-ietf] the painful issue of SPF HELO 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, 23 Jan 2015 23:27:52 -0000 I seem to have wandered into a bit of a minefield. :-/ Obviously I like Murray's proposed changes, since they're based on mine :-), but I see that he has added "typically" in a couple of places... and I begin to understand why it's necessary to waffle somewhat. ** What is interoperability in this context? ** Interestingly, Murray explains that changes "will be limited to correcting serious problems that would prevent current DMARC implementations from interacting properly". If I may be a bit pedantic for a moment, it doesn't look as though DMARC implementations interact (with each other) at all. Rather, as mail receivers, they "interact" with values published in the DNS by mail senders. In that light, one could argue that a problem which prevents a sending domain from predicting what "pass/fail/none" result a DMARC-compliant receiver will assign to its messages, is a problem which "prevents proper interaction". Unfortunately, since this effort is one to document what's out there now, and since (it's slowly becoming clear to me) not all DMARC implementations produce the same evaluation results, it's impossible to define the DMARC mechanism unambiguously. Murray would like the "goal posts [to] sit still for a while", but I think the goal posts are behaving more like waves than like particles! ** A technical problem: how many results from SPF? ** [SPF] defines a test which is recommended to be applied to two separate identifiers (HELO and MAIL FROM), where the receiver can consider the results of each test independently. (However, I can publish only one SPF record for a name - that is, I cannot say "my policy is *this* if the name is used for HELO, but my policy is *that* if it is used in MAIL FROM". But that's not a topic for this list.) Along comes DMARC, which expects to receive *one* result from "the SPF test", but there are *two* possible SPF tests. Scott takes the position that this doesn't much matter, and for all I know he may be right in practice, but from the point of view of the poor sod trying to figure out what will happen when she publishes SPF and DMARC records, it sure makes life difficult. I doubt we're going to be able to do much better than the proposed "-13" (or something very similar) with respect to HELO, but at least it raises the issue instead of leaving people like me perplexed, and it admits that there's more than one way a DMARC implementation could choose to use (or ignore!) the two SPF results. ** A "political" issue: how is receiver policy determined? ** Scott points out, with respect to the SPF RFCs, that the results of each SPF check are unambiguous, that "The almost complete lack of receiver policy specification in RFC 4408 (and RFC 7208) is not an oversight. It was a deliberate design choice", and that "[Franck's] mistake [is] to insist that there be one and only one defined way to deal with SPF results from both HELO and Mail From and there isn't". All of this is fair enough and true, but some of it is tautological: the receiver can do as it pleases, and no one can stuff an unwanted e-mail message down someone else's throat. I suspect I can choose to refuse all mail on Tuesdays if I want to, so certainly I can do whatever I wish with SPF results. I think that discussion about who determines the receiver's policy misses the point. The current draft even states that "Final disposition of a message is always a matter of local policy". The point, IMHO, is that when I publish DMARC and SPF and DKIM records, I should be able to reliably predict whether a given message will result in a DMARC pass, fail, or none, quite regardless of what the receiver will choose to do based on that result. It looks as though that won't happen in this go-round, no matter what. :-( ** 4408 vs 7208 - does it matter? ** Hector points out that SPF implementations using the "obsoleted" RFC 4408 will be around for some time, and expresses the concern (if I understand him correctly) that if DMARC references the newer 7208, there may be an implication that the 5322.Authentication-Result header will be expected to be present so DMARC can "consume" it. But there's no mention of the use of these headers in the current draft (except, in passing, "Original-Authentication-Results"). The draft mentions using the *results* of the SPF and DKIM tests, but not how they are obtained, and I think that may be the right approach. Or, Hector, are you concerned that DMARC implementations will be expected to *provide* one or both those headers, and if so, that this should be explicitly stated? ** The word "contradiction" ** Murray proposed this text for 4.1, based on my suggestion: [SPF], which authenticates the domain found in an [SMTP] MAIL command, or the domain found in the HELO/EHLO command if the MAIL command has a null path. Note that in contradiction to [SPF], in the context of DMARC, this latter identity is typically only used in the case of a MAIL null path. Franck objects to the word "contradiction", and suggests: [SPF], which authenticates the HELO identity and the MAIL FROM identity: the domain found in an [SMTP] MAIL command, or the domain found in the HELO/EHLO command if the MAIL command has a null path. Note that in the context of DMARC, this later identity is only used. Hmm. How about this: [SPF], which authenticates: - the domain found in an [SMTP] HELO or EHLO command (the "HELO result"), and/or - the domain found in an [SMTP] MAIL command, or the domain found in the HELO/EHLO command if the MAIL command has a null path (the "MAIL FROM" result). It is not specified whether DMARC uses the "HELO result" or the "MAIL FROM result"; implementations differ. It certainly exposes the ugly truth. ;-) But speaking of ugly truths, the document already allows for differences; in section 6.7 we have: -12> DMARC-compliant Mail Receivers typically disregard any mail handling -12> directive discovered as part of an authentication mechanism (e.g., -12> ADSP, SPF) where a DMARC record is also discovered that specifies a -12> policy other than "none". Deviating from this practice introduces -12> inconsistency among DMARC operators in terms of handling of the -12> message. However, such deviation is not proscribed. ** A tiny rant ** Necessary as this flexibility is if this document is to be finished any time soon, it causes problems for a person trying to create SPF and DMARC records in a way that will not cause more problems than it solves! While it's tempting to stay away from this stuff until it all settles down, that's becoming more difficult, and not only because my parent domain at work might be poised to publish a DMARC record which could interfere with my domain's outgoing mail. Even at home, a few months ago, Gmail started tagging my outgoing mail as spam, and when I tried to troubleshoot this, their "why is this spam" web page essentially insisted that I publish an SPF record before going any further! (end of rant) It's only fair to admit that despite my frustration, I'm grateful for all the work being done on these issues, both to combat spam, and to document what on earth is going on. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Fri Jan 23 16:06:28 2015 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 D95501A8914 for ; Fri, 23 Jan 2015 16:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 mr2ENF-86-s1 for ; Fri, 23 Jan 2015 16:06:21 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1AC1A0053 for ; Fri, 23 Jan 2015 16:06:15 -0800 (PST) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0O06DAM011931 for ; Fri, 23 Jan 2015 19:06:13 -0500 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0O06CmR029998 for ; Fri, 23 Jan 2015 19:06:12 -0500 Message-Id: <201501240006.t0O06CmR029998@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "dmarc@ietf.org" From: Michael Jack Assels In-reply-to: References: <20150121021457.1947.qmail@ary.lan> Comments: In-reply-to "Murray S. Kucherawy" message dated "Thu, 22 Jan 2015 10:27:40 -0800." Date: Fri, 23 Jan 2015 19:06:12 -0500 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-23 19:06:13 EST Archived-At: Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 24 Jan 2015 00:06:24 -0000 What seems like ages ago, on Thu, 22 Jan 2015 10:27:40 PST, "Murray S. Kucherawy" wrote: > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy > wrote: > > > I am asking the IESG and the ISE what the process is for making such > > adjustments now. > > > > Mainly my resistance to further change comes from the fact that we've done > > last calls of varying kinds on this document more times than I can count. > > It really is time to put the non-IETF version to bed and hand it off, even > > with its weaknesses, and let the standards process take it from there. > > There's a working group already chartered to do exactly that; in fact, that > > was one of the premises of creating that working group. > > > > I've consulted with the Area Director sponsoring the document's conflict > review, and the ISE. Both of them agree that we will only make changes > approved by the ISE and only during AUTH48 at this point, and those will be > limited to correcting serious problems that would prevent current DMARC > implementations from interacting properly. Anything else can be left to > the DMARC working group on its standards track deliverable. > > An argument can be made that this proposed change qualifies under that > definition, so please review it and comment as to whether it satisfies the > defect identified, or whether the change is necessary at all. I will > assume "yes" unless I hear otherwise. Again, the diff is here: > > http://www.blackops.org/~msk/dmarc/diff.html That sound to me like a call for thumbs up or thumbs down. I'd personally like to change the infelicitous word "contradiction" to "contrast", but rather than argue about changes, I think any remaining argument should be simply about making the change as proposed by Murray or not making any change at all. I've paid attention to all the points raised, and I still think -13 is better than -12. I don't think the floor is open for -14. MJA From nobody Fri Jan 23 16:14:16 2015 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 A4C341A008C for ; Fri, 23 Jan 2015 16:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.001 X-Spam-Level: X-Spam-Status: No, score=-4.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 jpfKp2ROAHP4 for ; Fri, 23 Jan 2015 16:14:13 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id AC2971A002A for ; Fri, 23 Jan 2015 16:14:13 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 1042B563F1E; Fri, 23 Jan 2015 18:14:13 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 022B660275; Fri, 23 Jan 2015 18:14:13 -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 4iQzX4gIv3yl; Fri, 23 Jan 2015 18:14:12 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id CAB296027A; Fri, 23 Jan 2015 18:14:12 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com CAB296027A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1422058452; bh=oEvetdWw/Qi9UU2/cES/6L0aq4VT4ORFt8346vne/4s=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=U1jQkOkJmGILl1fRz7ApleC+A4QRmvnepkWLOqSGAcR4n0Zemxi5OtGQw7+PZBgqr iNUI4gKyeiuHnTfXBskZ0fFPMZv2/R/YTItm3kNQecblwm3sfRZhNDVXx9qKTPAhdy f5UUZIKMv1rjYR+9avHsFpnPfYBtH9oDN6GxpMuw= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id ACDCF60279; Fri, 23 Jan 2015 18:14:12 -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 Fx6cOGRPoNMs; Fri, 23 Jan 2015 18:14:12 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 8DAC860275; Fri, 23 Jan 2015 18:14:12 -0600 (CST) Date: Fri, 23 Jan 2015 18:14:12 -0600 (CST) From: Franck Martin To: Anne Bennett Message-ID: <1374787805.125075.1422058452307.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <8589.1422055666@vindemiatrix.encs.concordia.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: the painful issue of SPF HELO Thread-Index: VWLWGBx027qPcVKuEB4O6jHgWoCN9g== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 24 Jan 2015 00:14:15 -0000 ----- Original Message ----- > From: "Anne Bennett" > To: dmarc@ietf.org > Sent: Friday, January 23, 2015 3:27:46 PM > Subject: [dmarc-ietf] the painful issue of SPF HELO > > > > Murray proposed this text for 4.1, based on my suggestion: > > [SPF], which authenticates the domain found in an [SMTP] > MAIL command, or the domain found in the HELO/EHLO command if > the MAIL command has a null path. Note that in contradiction > to [SPF], in the context of DMARC, this latter identity is > typically only used in the case of a MAIL null path. > > Franck objects to the word "contradiction", and suggests: > > [SPF], which authenticates the HELO identity and the MAIL > FROM identity: the domain found in an [SMTP] MAIL command, > or the domain found in the HELO/EHLO command if the MAIL > command has a null path. Note that in the context of DMARC, > this later identity is only used. > > Hmm. How about this: > > [SPF], which authenticates: > - the domain found in an [SMTP] HELO or EHLO command > (the "HELO result"), and/or > - the domain found in an [SMTP] MAIL command, or the domain > found in the HELO/EHLO command if the MAIL command has a > null path (the "MAIL FROM" result). > It is not specified whether DMARC uses the "HELO result" > or the "MAIL FROM result"; implementations differ. > Your text is clearer but replace the last sentence by: DMARC uses the MAIL FROM result. If you look Terri's, my implementation, which is used at least by another large ISP, and Tim's conformance tests, that were used for much code out there. Then I can say DMARC uses the MAIL from result today. I cannot speak for everyone, but this is what I feel is true out there. I have not seen any evidence that DMARC uses the HELO result, so your implementation differ is conjecture. > It certainly exposes the ugly truth. ;-) > > But speaking of ugly truths, the document already allows for > differences; in section 6.7 we have: > > -12> DMARC-compliant Mail Receivers typically disregard any mail handling > -12> directive discovered as part of an authentication mechanism (e.g., > -12> ADSP, SPF) where a DMARC record is also discovered that specifies a > -12> policy other than "none". Deviating from this practice introduces > -12> inconsistency among DMARC operators in terms of handling of the > -12> message. However, such deviation is not proscribed. > This was mainly added in the case of people that follow -all to the letter and reject emails on sight. > > ** A tiny rant ** > > Necessary as this flexibility is if this document is to be > finished any time soon, it causes problems for a person trying > to create SPF and DMARC records in a way that will not cause > more problems than it solves! While it's tempting to stay away > from this stuff until it all settles down, that's becoming more > difficult, and not only because my parent domain at work might > be poised to publish a DMARC record which could interfere with > my domain's outgoing mail. Even at home, a few months ago, > Gmail started tagging my outgoing mail as spam, and when I > tried to troubleshoot this, their "why is this spam" web page > essentially insisted that I publish an SPF record before going > any further! > (end of rant) > > It's only fair to admit that despite my frustration, I'm > grateful for all the work being done on these issues, both to > combat spam, and to document what on earth is going on. > I think once you get aggregate reports, all these questions won't matter much... Seriously, if you DKIM sign your email with an aligned domain, then it will give you a DMARC pass, SPF will be here for the <0.5% of cases where DKIM fails for not apparent reason (provided you can DKIM sign your bounces, which many people can but forget to do). From nobody Fri Jan 23 16:15:46 2015 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 A86031A891F for ; Fri, 23 Jan 2015 16:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xhE92DZsR5K0 for ; Fri, 23 Jan 2015 16:15:42 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6C62B1A891A for ; Fri, 23 Jan 2015 16:15:39 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 0FF7B56414E; Fri, 23 Jan 2015 18:15:39 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E9CB5A03F7; Fri, 23 Jan 2015 18:15:38 -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 Gq43wTYEXyeG; Fri, 23 Jan 2015 18:15:38 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B3EE8A03E7; Fri, 23 Jan 2015 18:15:38 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com B3EE8A03E7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1422058538; bh=jqXjtSA16ig+BIKWfQcVjoj8j+jkWiNnHF+8pTJ0l9I=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=iglR4x7j8sgs2oXAcGJroIo3hpd4YE44X0xo0pJfvI1LXnhCFgTHVcXHwCmStxN81 vBgDjFamBIH70zUJfqESYIP6H8C46tgCThj0no3AlhYuofnZ1+92BY8DsDS/ksWHDR Mh1t1JDhSZg6YFkRj+TlBE+MlBRIQPFyF77Fig00= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 80A02A03F7; Fri, 23 Jan 2015 18:15:38 -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 Fb2BqDnKBPSc; Fri, 23 Jan 2015 18:15:38 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 48F68A03E7; Fri, 23 Jan 2015 18:15:38 -0600 (CST) Date: Fri, 23 Jan 2015 18:15:38 -0600 (CST) From: Franck Martin To: Michael Jack Assels Message-ID: <2015668473.125096.1422058538207.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150121021457.1947.qmail@ary.lan> <201501240006.t0O06CmR029998@shadrach.encs.concordia.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: questions on the spec, was ... and two more tiny nits, while I'm at it Thread-Index: +JGEr+IW8IOa5rnvzJUfN5mVOLLAZA== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it 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, 24 Jan 2015 00:15:44 -0000 ----- Original Message ----- > From: "Michael Jack Assels" > To: dmarc@ietf.org > Sent: Friday, January 23, 2015 4:06:12 PM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny nits, while I'm at it > > What seems like ages ago, on Thu, 22 Jan 2015 10:27:40 PST, > "Murray S. Kucherawy" wrote: > > > On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy > > wrote: > > http://www.blackops.org/~msk/dmarc/diff.html > > That sound to me like a call for thumbs up or thumbs down. I'd > personally like to change the infelicitous word "contradiction" > to "contrast", but rather than argue about changes, I think any > remaining argument should be simply about making the change as > proposed by Murray or not making any change at all. I've paid > attention to all the points raised, and I still think -13 is > better than -12. I don't think the floor is open for -14. > Yes "contrast" would make me more happy. From nobody Fri Jan 23 16:18:07 2015 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 0C0901A8953 for ; Fri, 23 Jan 2015 16:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 wk79JyFEtqEH for ; Fri, 23 Jan 2015 16:18:03 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A8B1A893B for ; Fri, 23 Jan 2015 16:18:00 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 865D2C40472; Fri, 23 Jan 2015 18:21:09 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1422058869; bh=zUaqzJUhLLI7y//okEe5olhsEu2xhar1azjkyRPIte4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JCLFHRYQ416KpIL96hKP683v3vlC6yYHPKH74z2/a2fJpqq8e1CXb+r/PqZeTSdqP 13G4LbqnUDVk9Yu6ynSZvQwH55kot132czJyf2j+79yJt7QyVDgTKYyeCJpkW9Qgbg AUhd0UOBB4kibw5VZzOVNIWtQzh/7W/Vp84pSI44= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 23 Jan 2015 19:17:57 -0500 Message-ID: <9237572.lqxrj8i0PO@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-44-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <8589.1422055666@vindemiatrix.encs.concordia.ca> References: <8589.1422055666@vindemiatrix.encs.concordia.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 24 Jan 2015 00:18:06 -0000 On Friday, January 23, 2015 18:27:46 Anne Bennett wrote: > I seem to have wandered into a bit of a minefield. :-/ > > Obviously I like Murray's proposed changes, since they're > based on mine :-), but I see that he has added "typically" > in a couple of places... and I begin to understand why it's > necessary to waffle somewhat. > > > ** What is interoperability in this context? ** > > Interestingly, Murray explains that changes "will be limited to > correcting serious problems that would prevent current DMARC > implementations from interacting properly". If I may be a > bit pedantic for a moment, it doesn't look as though DMARC > implementations interact (with each other) at all. Rather, > as mail receivers, they "interact" with values published in > the DNS by mail senders. > > In that light, one could argue that a problem which prevents > a sending domain from predicting what "pass/fail/none" result > a DMARC-compliant receiver will assign to its messages, is a > problem which "prevents proper interaction". > > Unfortunately, since this effort is one to document what's out > there now, and since (it's slowly becoming clear to me) not > all DMARC implementations produce the same evaluation results, > it's impossible to define the DMARC mechanism unambiguously. > Murray would like the "goal posts [to] sit still for a while", > but I think the goal posts are behaving more like waves than > like particles! > > > ** A technical problem: how many results from SPF? ** > > [SPF] defines a test which is recommended to be applied to > two separate identifiers (HELO and MAIL FROM), where the receiver > can consider the results of each test independently. (However, > I can publish only one SPF record for a name - that is, I cannot > say "my policy is *this* if the name is used for HELO, but my > policy is *that* if it is used in MAIL FROM". But that's not a > topic for this list.) FWIW, in a decade of doing SPF work I've yet to run into a case where this was a real life problem. > Along comes DMARC, which expects to receive *one* result from > "the SPF test", but there are *two* possible SPF tests. Scott > takes the position that this doesn't much matter, and for all > I know he may be right in practice, but from the point of view > of the poor sod trying to figure out what will happen when she > publishes SPF and DMARC records, it sure makes life difficult. > > I doubt we're going to be able to do much better than the > proposed "-13" (or something very similar) with respect to HELO, > but at least it raises the issue instead of leaving people like > me perplexed, and it admits that there's more than one way a > DMARC implementation could choose to use (or ignore!) the two > SPF results. > > > ** A "political" issue: how is receiver policy determined? ** > > Scott points out, with respect to the SPF RFCs, that the results > of each SPF check are unambiguous, that "The almost complete > lack of receiver policy specification in RFC 4408 (and RFC 7208) > is not an oversight. It was a deliberate design choice", and > that "[Franck's] mistake [is] to insist that there be one and > only one defined way to deal with SPF results from both HELO > and Mail From and there isn't". > > All of this is fair enough and true, but some of it is > tautological: the receiver can do as it pleases, and no one can > stuff an unwanted e-mail message down someone else's throat. > I suspect I can choose to refuse all mail on Tuesdays if I want > to, so certainly I can do whatever I wish with SPF results. > > I think that discussion about who determines the receiver's > policy misses the point. The current draft even states that > "Final disposition of a message is always a matter of local > policy". > > The point, IMHO, is that when I publish DMARC and SPF and > DKIM records, I should be able to reliably predict whether > a given message will result in a DMARC pass, fail, or none, > quite regardless of what the receiver will choose to do based > on that result. > > It looks as though that won't happen in this go-round, no > matter what. :-( You may not be able to get to 100%, but you can get very close. > > ** 4408 vs 7208 - does it matter? ** > > Hector points out that SPF implementations using the "obsoleted" > RFC 4408 will be around for some time, and expresses > the concern (if I understand him correctly) that if DMARC > references the newer 7208, there may be an implication that the > 5322.Authentication-Result header will be expected to be present > so DMARC can "consume" it. But there's no mention of the use > of these headers in the current draft (except, in passing, > "Original-Authentication-Results"). The draft mentions using > the *results* of the SPF and DKIM tests, but not how they are > obtained, and I think that may be the right approach. RFC 7208 didn't replace Received SPF, it just added reference to the A-R header field as an option. Since that was already documented in other RFCs, that didn't change anything. How authentication information is communicated to different parts of an entity's mail system is a local choice without a global interoperability impact. One way to do it is by adding either a Received SPF or A-R field to a message for consumption by a downstream process. There are others. In the case of SPF Received versus A-R, all that matters is that the SPF verifier includes the one that the downstream processor can use. Adding A-R to RFC 7208 changed nothing. Not trying to specify internal mail system design details (which is what the current DMARC draft does) is the correct approach. > Or, Hector, are you concerned that DMARC implementations > will be expected to *provide* one or both those headers, > and if so, that this should be explicitly stated? It would be SPF implementations. A DMARC verifier might need to be prepared to consume both data formats (as opendmarc does), but that's really not very hard. It's also unrelated to RFC 4408 versus RFC 7208 because even if RFC 4408 had never been updated, there were standards track RC defining how to use A-R to report SPF results. > > ** The word "contradiction" ** > > Murray proposed this text for 4.1, based on my suggestion: > > [SPF], which authenticates the domain found in an [SMTP] > MAIL command, or the domain found in the HELO/EHLO command if > the MAIL command has a null path. Note that in contradiction > to [SPF], in the context of DMARC, this latter identity is > typically only used in the case of a MAIL null path. > > Franck objects to the word "contradiction", and suggests: > > [SPF], which authenticates the HELO identity and the MAIL > FROM identity: the domain found in an [SMTP] MAIL command, > or the domain found in the HELO/EHLO command if the MAIL > command has a null path. Note that in the context of DMARC, > this later identity is only used. This is close. It's really only the SPF Mail From result that's used. The trick is that in the case of a null Mail From, that result is calculated using a synthetic Mail From built using the HELO domain. > Hmm. How about this: > > [SPF], which authenticates: > - the domain found in an [SMTP] HELO or EHLO command > (the "HELO result"), and/or > - the domain found in an [SMTP] MAIL command, or the domain > found in the HELO/EHLO command if the MAIL command has a > null path (the "MAIL FROM" result). > It is not specified whether DMARC uses the "HELO result" > or the "MAIL FROM result"; implementations differ. > > It certainly exposes the ugly truth. ;-) I think this is good too, but we can simplify it, I think. > But speaking of ugly truths, the document already allows for > differences; in section 6.7 we have: > > -12> DMARC-compliant Mail Receivers typically disregard any mail handling > -12> directive discovered as part of an authentication mechanism (e.g., > -12> ADSP, SPF) where a DMARC record is also discovered that specifies a > -12> policy other than "none". Deviating from this practice introduces > -12> inconsistency among DMARC operators in terms of handling of the > -12> message. However, such deviation is not proscribed. > > > ** A tiny rant ** > > Necessary as this flexibility is if this document is to be > finished any time soon, it causes problems for a person trying > to create SPF and DMARC records in a way that will not cause > more problems than it solves! While it's tempting to stay away > from this stuff until it all settles down, that's becoming more > difficult, and not only because my parent domain at work might > be poised to publish a DMARC record which could interfere with > my domain's outgoing mail. Even at home, a few months ago, > Gmail started tagging my outgoing mail as spam, and when I > tried to troubleshoot this, their "why is this spam" web page > essentially insisted that I publish an SPF record before going > any further! > (end of rant) > > It's only fair to admit that despite my frustration, I'm > grateful for all the work being done on these issues, both to > combat spam, and to document what on earth is going on. I appreciate you sticking with it. It's good to get in depth review from new sets of eyes. I certainly was sure I was sure I knew what the discussion about SPF meant, but then I already knew what was intended, so it's good to have someone else reviewing. How about this: [SPF] can authenticate both the domain found in an [SMTP] HELO/EHLO command (the HELO identity) and the domain found in an [SMTP] MAIL command (the MAIL FROM identity). DMARC uses the result of SPF authentication of the MAIL FROM identity. Section 2.4 of [SPF] describes SPF MAIL FROM processing for cases in which the MAIL command has a null path. Scott K From nobody Fri Jan 23 16:24:00 2015 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 CE9431AD2D5 for ; Fri, 23 Jan 2015 16:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Q1DK2-VQGAGX for ; Fri, 23 Jan 2015 16:23:55 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id AFD711AD2C0 for ; Fri, 23 Jan 2015 16:23:55 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 50F8D56419F; Fri, 23 Jan 2015 18:23:55 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 4175E60275; Fri, 23 Jan 2015 18:23:55 -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 ybP_ujIEk-o6; Fri, 23 Jan 2015 18:23:55 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 0C4EF6027A; Fri, 23 Jan 2015 18:23:55 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 0C4EF6027A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1422059035; bh=ER42tuPbZeMvQvtEfq4ow8EhdoUixul4PPcgjhTfOCc=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=AhJKhTEjhbTOUbCaIt1yOSzH8xrw3GzmJqA1Gav1lr9XFPaxWNF9vgcF/BXrk5cfb Htn9n9I0M/DdYyqKAYPnOm7ecrZPbSqvwVFIGQJDDLorLfJ9fg4c90MEi3P7aGh3o8 RhAqQbY2j4BelAo5RazllgdI1BJmnW/8MEoF/TW4= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id EB6FB60279; Fri, 23 Jan 2015 18:23:54 -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 ZlFos5krwWTb; Fri, 23 Jan 2015 18:23:54 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id D570660275; Fri, 23 Jan 2015 18:23:54 -0600 (CST) Date: Fri, 23 Jan 2015 18:23:54 -0600 (CST) From: Franck Martin To: Scott Kitterman Message-ID: <1105010941.125154.1422059034711.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <8589.1422055666@vindemiatrix.encs.concordia.ca> <9237572.lqxrj8i0PO@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: the painful issue of SPF HELO Thread-Index: /OQfERjiyznwhZYM7cX9dTfdy5JNmw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 24 Jan 2015 00:23:58 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Friday, January 23, 2015 4:17:57 PM > Subject: Re: [dmarc-ietf] the painful issue of SPF HELO > > On Friday, January 23, 2015 18:27:46 Anne Bennett wrote: > > I seem to have wandered into a bit of a minefield. :-/ > > > > (end of rant) > > > > It's only fair to admit that despite my frustration, I'm > > grateful for all the work being done on these issues, both to > > combat spam, and to document what on earth is going on. > > I appreciate you sticking with it. It's good to get in depth review from new > sets of eyes. I certainly was sure I was sure I knew what the discussion > about SPF meant, but then I already knew what was intended, so it's good to > have someone else reviewing. +1 > > How about this: > > [SPF] can authenticate both the domain found in an [SMTP] HELO/EHLO > command (the HELO identity) and the domain found in an [SMTP] MAIL > command (the MAIL FROM identity). DMARC uses the result of SPF > authentication of the MAIL FROM identity. Section 2.4 of [SPF] describes > SPF MAIL FROM processing for cases in which the MAIL command has a > null path. > +1 Ship it! From nobody Fri Jan 23 17:05:55 2015 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 2022B1A89AA for ; Fri, 23 Jan 2015 17:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 fbaO44ljVOiI for ; Fri, 23 Jan 2015 17:05:53 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E919C1A004C for ; Fri, 23 Jan 2015 17:05:52 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id k14so406709wgh.10 for ; Fri, 23 Jan 2015 17:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Y4Kt1VKY3oaz9KCNPjLGTDVFlG4mClOenpbyd42kYU0=; b=fvdGe37H9/CRsXTKPRI7WJQp66TJgQ6FVb4ds83ak5mShHsk91EGq4PyKCLNZuYu62 +glo86bDnTb0YV/Wg0R4MNq2bwbNHLR9uyFbxS8RYbbzdT9I1kkUDU1IkpMkcnF6Z86p l1/4ySMbnss6D9bZ1Lu/Za19uCbcvnT0x50wE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y4Kt1VKY3oaz9KCNPjLGTDVFlG4mClOenpbyd42kYU0=; b=nJXMeaXD1Vtzh2fjYFCQ+ldqAmK5Fyfk22bSOwMTP0a1B/rrR+V3BTYSUkz9yyGYHz 63K6akSfs3yrZEZsGqgaWRtc7NIEf0QMavRYOx+VPPwezJFadMfHC5PfTkq12JZCqsge uo/YEntqKKbLLkZy2JadUR1Z/2ccpaQ1J0DeYMKlyWPjsIVM5gNlvBSb3nUFHwaIpskk 0jrJPqLing9UDvp7Ltf07cWWA07G1htp+2HBy8kuL0csPkd69MuDeH6gzHTIevKDcYcl JPaC8PHvsQXyjhTde2xa1y8+iac1jDxf9+BNg9L8qOBFBBwFrZKu5xyjdFIj9C6XIGU9 gWDg== X-Gm-Message-State: ALoCoQlCg6z79QOi97r0EEPBroXiw8d/+XMqCLAbFSRa1KlFXvjYIU3TnxWtqgBWpkQK0tcaZuCY MIME-Version: 1.0 X-Received: by 10.194.237.202 with SMTP id ve10mr20054207wjc.36.1422061551701; Fri, 23 Jan 2015 17:05:51 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.41.161 with HTTP; Fri, 23 Jan 2015 17:05:51 -0800 (PST) In-Reply-To: <1105010941.125154.1422059034711.JavaMail.zimbra@peachymango.org> References: <8589.1422055666@vindemiatrix.encs.concordia.ca> <9237572.lqxrj8i0PO@scott-latitude-e6320> <1105010941.125154.1422059034711.JavaMail.zimbra@peachymango.org> Date: Fri, 23 Jan 2015 17:05:51 -0800 X-Google-Sender-Auth: OjgOZFk1Z26qKo2YUM-By61VBeg Message-ID: From: Kurt Andersen To: Franck Martin Content-Type: multipart/alternative; boundary=089e01493f06a36c4c050d5b81d4 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 24 Jan 2015 01:05:54 -0000 --089e01493f06a36c4c050d5b81d4 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 23, 2015 at 4:23 PM, Franck Martin wrote: > On Friday, January 23, 2015 18:27:46 Anne Bennett wrote: > > How about this: > > > > [SPF] can authenticate both the domain found in an [SMTP] HELO/EHLO > > command (the HELO identity) and the domain found in an [SMTP] MAIL > > command (the MAIL FROM identity). DMARC uses the result of SPF > > authentication of the MAIL FROM identity. Section 2.4 of [SPF] > describes > > SPF MAIL FROM processing for cases in which the MAIL command has a > > null path. > > > > +1 > > Ship it! +1 also :-) --089e01493f06a36c4c050d5b81d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Jan 23, 2015 at 4:23 PM, Franck Martin <franck@peachymango.or= g> wrote:
On Friday, January 23, 20= 15 18:27:46 Anne Bennett wrote:
> How about this:
>
>=C2=A0 =C2=A0 [SPF] can authenticate both the domain found in an [SMTP]= HELO/EHLO
>=C2=A0 =C2=A0 command (the HELO identity) and the domain found in an [S= MTP] MAIL
>=C2=A0 =C2=A0 command (the MAIL FROM identity).=C2=A0 DMARC uses the re= sult of SPF
>=C2=A0 =C2=A0 authentication of the MAIL FROM identity.=C2=A0 Section 2= .4 of [SPF] describes
>=C2=A0 =C2=A0 SPF MAIL FROM processing for cases in which the MAIL comm= and has a
>=C2=A0 =C2=A0 null path.
>

+1

Ship it!

+1 also :-)=
--089e01493f06a36c4c050d5b81d4-- From nobody Fri Jan 23 17:29:08 2015 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 CF41A1A1B1C for ; Fri, 23 Jan 2015 17:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 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, GB_NOSCRIP=2, HTML_MESSAGE=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 0WuNUiIhE4xj for ; Fri, 23 Jan 2015 17:29:03 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2701A887D for ; Fri, 23 Jan 2015 17:29:03 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id u56so493137wes.0 for ; Fri, 23 Jan 2015 17:29:02 -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=oZZXGKn1hqXrmXdwthPVUlWg74+UMXCpM9OSH+vf/Bk=; b=DC+etsKWEVfdfIbR0MHD3goYpbEzatptL8gW4GID/E8fzWm1Tn5pdprPgNJOwtFHFb 3QdtjmKZJNw1gu/GWSAGx2A1/RLRTHAAgj484soG1YBAeyPUMgkPDu51cabEE6ovLcv+ ygENiTGZvaUmbxBzqG6BCG5MROJOh28MexKB1TErfgZta0SYnUyBXuJUET7DJPF0f/9F W/DO/j6ZzWPGfkGr+dJC1DSKD7I/ZY8P1S2pnlrrzilcwUs+ZBESZFY9lFjxxtm1tIki Stbquj0aBaciTtqxW1yMHyxy4Owf9/FUfALYr+bXlyEipf4E/+mpAV8IAHyewHIIZk9p Uuvg== MIME-Version: 1.0 X-Received: by 10.194.184.76 with SMTP id es12mr10536659wjc.110.1422062942182; Fri, 23 Jan 2015 17:29:02 -0800 (PST) Received: by 10.27.204.198 with HTTP; Fri, 23 Jan 2015 17:29:02 -0800 (PST) In-Reply-To: <8589.1422055666@vindemiatrix.encs.concordia.ca> References: <8589.1422055666@vindemiatrix.encs.concordia.ca> Date: Fri, 23 Jan 2015 17:29:02 -0800 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=047d7bd6af188463c1050d5bd4e1 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 24 Jan 2015 01:29:07 -0000 --047d7bd6af188463c1050d5bd4e1 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 23, 2015 at 3:27 PM, Anne Bennett wrote: > ** What is interoperability in this context? ** > > Interestingly, Murray explains that changes "will be limited to > correcting serious problems that would prevent current DMARC > implementations from interacting properly". If I may be a > bit pedantic for a moment, it doesn't look as though DMARC > implementations interact (with each other) at all. Rather, > as mail receivers, they "interact" with values published in > the DNS by mail senders. > Right. The statement is a very general one about making edits this late in a protocol document's life cycle, not something specific to how DMARC works. In that light, one could argue that a problem which prevents > a sending domain from predicting what "pass/fail/none" result > a DMARC-compliant receiver will assign to its messages, is a > problem which "prevents proper interaction". > I think that's impossible to resolve completely because, for a given receiver, there's no guarantee that you'll be told your message was rejected specifically because of DMARC policy. Some operators specifically choose never to reveal which test you failed so that you don't have any specific information about how to get through their filters. (See Section 5 of RFC7372.) Thus, you may never know what result a DMARC-compliant receiver assigns to your messages since there are other factors that can come into play before your message gets rejected. > Unfortunately, since this effort is one to document what's out > there now, and since (it's slowly becoming clear to me) not > all DMARC implementations produce the same evaluation results, > it's impossible to define the DMARC mechanism unambiguously. > Murray would like the "goal posts [to] sit still for a while", > but I think the goal posts are behaving more like waves than > like particles! > You're not talking about the same goal posts I am. The DMARC document has been alive for no less than three years, and we've had one last call after another for making changes or finding defects. The changes get made, everyone says we're ready, we make some progress, and then some other big change gets proposed. I believe we've reached a point of diminishing returns for this version of the document, imperfect as it might still be, in terms of holding it for one more edit and one more edit. Despite issues like the one you've raised that might still be in there, there's also abundant evidence that it is useful to some operators in its current form. That might be because they've all assumed, agreed, etc., that the HELO value is not used, and just forgot to write that down. Or it might be coincidence that many (but not all) implemented it that way since the goal is to match as well as possible against what's in the From: field. For reasons not worth getting into now, this version of the base specification is on track to be published not as a standard but as an "Informational" document, kind of as a handoff step between the team that first developed DMARC and the IETF, which is more rigorous in terms of developing standards. The goal posts to which I'm referring are the completion of that handoff. We need to publish DMARC in its current state, even if it's not full-standard quality yet, to do so. If we reset that process every time a defect is identified, we might not be done for a really long time. DMARC will not be final when this version is published. If it's broken, I agree it should be fixed, and we have a process for that. This iteration of the document, though, shouldn't be held indefinitely. So how long is long enough? We need to draw a line someplace, and hand off what's left to the working group for a proper standardization effort. I've already opened a ticket in the working group's tracker identifying this issue so the working group can decide if and how it wants to handle this matter. > The point, IMHO, is that when I publish DMARC and SPF and > DKIM records, I should be able to reliably predict whether > a given message will result in a DMARC pass, fail, or none, > quite regardless of what the receiver will choose to do based > on that result. > But how can you tell? I'm not trying to deflect your question -- I know you want at least the DMARC part to be deterministic, which isn't an unreasonable request -- but there's really no way to determine whether a particular receiver is applying bare DMARC or is applying local stuff on top of it. So if receiver behaviour is unreliable in the first place, how can one reasonably claim that this is clearly a defect in DMARC? DMARC's not introducing that uncertainty; clearly the issue you're talking about certainly isn't helping it either, but it's not as if resolving that here will suddenly make receiver handling of email deterministic. ** 4408 vs 7208 - does it matter? ** > > Hector points out that SPF implementations using the "obsoleted" > RFC 4408 will be around for some time, and expresses > the concern (if I understand him correctly) that if DMARC > references the newer 7208, there may be an implication that the > 5322.Authentication-Result header will be expected to be present > so DMARC can "consume" it. But there's no mention of the use > of these headers in the current draft (except, in passing, > "Original-Authentication-Results"). The draft mentions using > the *results* of the SPF and DKIM tests, but not how they are > obtained, and I think that may be the right approach. > There is no prescription of how SPF or DKIM results are communicated to the DMARC agent. Authentication-Results (RFC7001) is one way, but it's not the only way. There are DMARC implementations (mine, for example), that use that header field to signal results between modules attached to the MTA, but there are commercial implementations where that information is passed across API calls within the same process. It doesn't matter, really, so DMARC doesn't specify. So I claim "will be expected" is false. Moreover, Authentication-Results does support returning two SPF results, and disambiguating them. On the other hand, RFC7001 is the suggested way to report DMARC results to whatever wants to consume them, though again that's not mandatory. Personally, I fall on the "doesn't matter" side because I don't believe this is a change in behaviour between the two versions of the SPF specification. Both of them say checking HELO is RECOMMENDED, leaving it to the careful discretion of the receiver. We'd therefore have to have a rather good reason for making a normative reference in DMARC to an obsolete document. ** The word "contradiction" ** > > Murray proposed this text for 4.1, based on my suggestion: > > [SPF], which authenticates the domain found in an [SMTP] > MAIL command, or the domain found in the HELO/EHLO command if > the MAIL command has a null path. Note that in contradiction > to [SPF], in the context of DMARC, this latter identity is > typically only used in the case of a MAIL null path. > > Franck objects to the word "contradiction", and suggests: > > [SPF], which authenticates the HELO identity and the MAIL > FROM identity: the domain found in an [SMTP] MAIL command, > or the domain found in the HELO/EHLO command if the MAIL > command has a null path. Note that in the context of DMARC, > this later identity is only used. > > Hmm. How about this: > > [SPF], which authenticates: > - the domain found in an [SMTP] HELO or EHLO command > (the "HELO result"), and/or > - the domain found in an [SMTP] MAIL command, or the domain > found in the HELO/EHLO command if the MAIL command has a > null path (the "MAIL FROM" result). > It is not specified whether DMARC uses the "HELO result" > or the "MAIL FROM result"; implementations differ. > I would leave off "implementations differ", but that's fine with me if it's fine with others. It's probably more accurate. > But speaking of ugly truths, the document already allows for > differences; in section 6.7 we have: > > -12> DMARC-compliant Mail Receivers typically disregard any mail handling > -12> directive discovered as part of an authentication mechanism (e.g., > -12> ADSP, SPF) where a DMARC record is also discovered that specifies a > -12> policy other than "none". Deviating from this practice introduces > -12> inconsistency among DMARC operators in terms of handling of the > -12> message. However, such deviation is not proscribed. > This is there for two reasons: a) because (as you've acknowledged) we can't force the receiver to do anything; and b) because if SPF rejects the message by enforcing "-all" after MAIL FROM, there's no chance for DKIM to report a "pass", which could satisfy the DMARC test. -MSK --047d7bd6af188463c1050d5bd4e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 23, 2015 at 3:27 PM, Anne Bennett <anne@= encs.concordia.ca> wrote:
** What is interoperab= ility in this context? **

Interestingly, Murray explains that changes "will be limited to
correcting serious problems that would prevent current DMARC
implementations from interacting properly".=C2=A0 If I may be a
bit pedantic for a moment, it doesn't look as though DMARC
implementations interact (with each other) at all.=C2=A0 Rather,
as mail receivers, they "interact" with values published in
the DNS by mail senders.

Right.=C2=A0 T= he statement is a very general one about making edits this late in a protoc= ol document's life cycle, not something specific to how DMARC works.
In that light, one could argue that a problem which prevents
a sending domain from predicting what "pass/fail/none" result
a DMARC-compliant receiver will assign to its messages, is a
problem which "prevents proper interaction".

I think that's impossible to resolve completely because= , for a given receiver, there's no guarantee that you'll be told yo= ur message was rejected specifically because of DMARC policy.=C2=A0 Some op= erators specifically choose never to reveal which test you failed so that y= ou don't have any specific information about how to get through their f= ilters.=C2=A0 (See Section 5 of RFC7372.)=C2=A0 Thus, you may never know wh= at result a DMARC-compliant receiver assigns to your messages since there a= re other factors that can come into play before your message gets rejected.=
=C2=A0
Unfortunately, since this effort is one to document what's out
there now, and since (it's slowly becoming clear to me) not
all DMARC implementations produce the same evaluation results,
it's impossible to define the DMARC mechanism unambiguously.
Murray would like the "goal posts [to] sit still for a while", but I think the goal posts are behaving more like waves than
like particles!

You're not talking = about the same goal posts I am.=C2=A0 The DMARC document has been alive for= no less than three years, and we've had one last call after another fo= r making changes or finding defects.=C2=A0 The changes get made, everyone s= ays we're ready, we make some progress, and then some other big change = gets proposed.=C2=A0 I believe we've reached a point of diminishing ret= urns for this version of the document, imperfect as it might still be, in t= erms of holding it for one more edit and one more edit.

Despite issu= es like the one you've raised that might still be in there, there's= also abundant evidence that it is useful to some operators in its current = form.=C2=A0 That might be because they've all assumed, agreed, etc., th= at the HELO value is not used, and just forgot to write that down.=C2=A0 Or= it might be coincidence that many (but not all) implemented it that way si= nce the goal is to match as well as possible against what's in the From= : field.

For reasons not worth getting into now, this version of the= base specification is on track to be published not as a standard but as an= "Informational" document, kind of as a handoff step between the = team that first developed DMARC and the IETF, which is more rigorous in ter= ms of developing standards.=C2=A0 The goal posts to which I'm referring= are the completion of that handoff.=C2=A0 We need to publish DMARC in its = current state, even if it's not full-standard quality yet, to do so.=C2= =A0 If we reset that process every time a defect is identified, we might no= t be done for a really long time.

DMARC will not be final when this = version is published.=C2=A0 If it's broken, I agree it should be fixed,= and we have a process for that.=C2=A0 This iteration of the document, thou= gh, shouldn't be held indefinitely.=C2=A0 So how long is long enough?= =C2=A0 We need to draw a line someplace, and hand off what's left to th= e working group for a proper standardization effort.

I= 9;ve already opened a ticket in the working group's tracker identifying= this issue so the working group can decide if and how it wants to handle t= his matter.
=C2=A0
The point, IMHO, is that when I publish DMARC and SPF and
DKIM records, I should be able to reliably predict whether
a given message will result in a DMARC pass, fail, or none,
quite regardless of what the receiver will choose to do based
on that result.

But how can you tell?=C2=A0
I'm not trying to deflect your question -- I kno= w you want at least the DMARC part to be deterministic, which isn't an = unreasonable request -- but there's really no way to determine whether = a particular receiver is applying bare DMARC or is applying local stuff on = top of it.=C2=A0 So if receiver behaviour is unreliable in the first place,= how can one reasonably claim that this is clearly a defect in DMARC?=C2=A0= DMARC's not introducing that uncertainty; clearly the issue you're= talking about certainly isn't helping it either, but it's not as i= f resolving that here will suddenly make receiver handling of email determi= nistic.

** 4408 vs 7208 - does it matter? **

Hector points out that SPF implementations using the "obsoleted"<= br> RFC 4408 will be around for some time, and expresses
the concern (if I understand him correctly) that if DMARC
references the newer 7208, there may be an implication that the
5322.Authentication-Result header will be expected to be present
so DMARC can "consume" it.=C2=A0 But there's no mention of th= e use
of these headers in the current draft (except, in passing,
"Original-Authentication-Results").=C2=A0 The draft mentions usin= g
the *results* of the SPF and DKIM tests, but not how they are
obtained, and I think that may be the right approach.
=
There is no prescription of how SPF or DKIM results are comm= unicated to the DMARC agent.=C2=A0 Authentication-Results (RFC7001) is one = way, but it's not the only way.=C2=A0 There are DMARC implementations (= mine, for example), that use that header field to signal results between mo= dules attached to the MTA, but there are commercial implementations where t= hat information is passed across API calls within the same process.=C2=A0 I= t doesn't matter, really, so DMARC doesn't specify.=C2=A0 So I clai= m "will be expected" is false.=C2=A0 Moreover, Authentication-Res= ults does support returning two SPF results, and disambiguating them.
On the other hand, RFC7001 is the suggested way to report DMAR= C results to whatever wants to consume them, though again that's not ma= ndatory.

Personally, I fall on the "doesn't matt= er" side because I don't believe this is a change in behaviour bet= ween the two versions of the SPF specification.=C2=A0 Both of them say chec= king HELO is RECOMMENDED, leaving it to the careful discretion of the recei= ver.=C2=A0 We'd therefore have to have a rather good reason for making = a normative reference in DMARC to an obsolete document.

** The word "contradiction" **

Murray proposed this text for 4.1, based on my suggestion:

=C2=A0 [SPF], which authenticates the domain found in an [SMTP]
=C2=A0 MAIL command, or the domain found in the HELO/EHLO command if
=C2=A0 the MAIL command has a null path. Note that in contradiction
=C2=A0 to [SPF], in the context of DMARC, this latter identity is
=C2=A0 typically only used in the case of a MAIL null path.

Franck objects to the word "contradiction", and suggests:

=C2=A0 [SPF], which authenticates the HELO identity and the MAIL
=C2=A0 FROM identity: the domain found in an [SMTP] MAIL command,
=C2=A0 or the domain found in the HELO/EHLO command if the MAIL
=C2=A0 command has a null path. Note that in the context of DMARC,
=C2=A0 this later identity is only used.

Hmm.=C2=A0 How about this:

=C2=A0 [SPF], which authenticates:
=C2=A0 =C2=A0 - the domain found in an [SMTP] HELO or EHLO command
=C2=A0 =C2=A0 =C2=A0 (the "HELO result"), and/or
=C2=A0 =C2=A0 - the domain found in an [SMTP] MAIL command, or the domain =C2=A0 =C2=A0 =C2=A0 found in the HELO/EHLO command if the MAIL command has= a
=C2=A0 =C2=A0 =C2=A0 null path (the "MAIL FROM" result).
=C2=A0 It is not specified whether DMARC uses the "HELO result" =C2=A0 or the "MAIL FROM result"; implementations differ.

I would leave off "implementations differ= ", but that's fine with me if it's fine with others.=C2=A0 It&= #39;s probably more accurate.
=C2=A0
But speaking of ugly truths, the document already allows for
differences; in section 6.7 we have:

-12>=C2=A0 DMARC-compliant Mail Receivers typically disregard any mail h= andling
-12>=C2=A0 directive discovered as part of an authentication mechanism (= e.g.,
-12>=C2=A0 ADSP, SPF) where a DMARC record is also discovered that speci= fies a
-12>=C2=A0 policy other than "none".=C2=A0 Deviating from this= practice introduces
-12>=C2=A0 inconsistency among DMARC operators in terms of handling of t= he
-12>=C2=A0 message.=C2=A0 However, such deviation is not proscribed.
=

This is there for two reasons:

a) b= ecause (as you've acknowledged) we can't force the receiver to do a= nything; and
b) because if SPF rejects the message by enforci= ng "-all" after MAIL FROM, there's no chance for DKIM to repo= rt a "pass", which could satisfy the DMARC test.
-MSK
--047d7bd6af188463c1050d5bd4e1-- From nobody Fri Jan 23 19:22:47 2015 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 EE6C61A1A97 for ; Fri, 23 Jan 2015 19:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 O7iZHgNE4N0X for ; Fri, 23 Jan 2015 19:22:42 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB3A1A1A96 for ; Fri, 23 Jan 2015 19:22:41 -0800 (PST) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0O3MfAW031989 for ; Fri, 23 Jan 2015 22:22:41 -0500 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0O3Me17015573 for ; Fri, 23 Jan 2015 22:22:40 -0500 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Fri, 23 Jan 2015 18:14:12 CST References: <8589.1422055666@vindemiatrix.encs.concordia.ca> <1374787805.125075.1422058452307.JavaMail.zimbra@peachymango.org> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 23 Jan 2015 22:22:40 -0500 Message-ID: <15572.1422069760@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-23 22:22:41 EST Archived-At: Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 24 Jan 2015 03:22:44 -0000 Franck Martin responds to my suggestion for text for 4.1: >> [SPF], which authenticates: >> - the domain found in an [SMTP] HELO or EHLO command >> (the "HELO result"), and/or >> - the domain found in an [SMTP] MAIL command, or the domain >> found in the HELO/EHLO command if the MAIL command has a >> null path (the "MAIL FROM" result). >> It is not specified whether DMARC uses the "HELO result" >> or the "MAIL FROM result"; implementations differ. > Your text is clearer but replace the last sentence by: > DMARC uses the MAIL FROM result. > > If you look Terri's, my implementation, which is used at > least by another large ISP, and Tim's conformance tests, > that were used for much code out there. Then I can say DMARC > uses the MAIL from result today. I cannot speak for everyone, > but this is what I feel is true out there. > > I have not seen any evidence that DMARC uses the HELO result, > so your implementation differ is conjecture. Not quite conjecture; it's based on Murray writing, a few days ago: MK> I can say that OpenDMARC consumes the Authentication-Results MK> field, or the Received-SPF field if the former isn't there, MK> but it prefers a result based on MAIL FROM over one based on MK> HELO if both are present. But it will use both. Perhaps I misunderstood him? I certainly have no objection to Scott's text, which he proposed in another message, assuming it is correct, which I certainly don't feel qualified to comment on. My efforts have been aimed at making things clear - whether they are correct has to be someone else's call! ;-) Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Sat Jan 24 00:35:58 2015 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 B7D301A01C6 for ; Sat, 24 Jan 2015 00:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 qQAso5zi4bgX for ; Sat, 24 Jan 2015 00:35:55 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 142311A0154 for ; Sat, 24 Jan 2015 00:35:54 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 9D6981C384D; Sat, 24 Jan 2015 17:35:53 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 78B161A2D18; Sat, 24 Jan 2015 17:35:53 +0900 (JST) From: "Stephen J. Turnbull" To: Anne Bennett In-Reply-To: <8589.1422055666@vindemiatrix.encs.concordia.ca> References: <8589.1422055666@vindemiatrix.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 24 Jan 2015 17:35:53 +0900 Message-ID: <87h9vgtw2e.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: [dmarc-ietf] the painful issue of SPF HELO 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, 24 Jan 2015 08:35:57 -0000 Anne Bennett writes: > ** A tiny rant ** > > Necessary as this flexibility is if this document is to be > finished any time soon, That's not why the flexibility is there, though. The point of the flexibility is that *this* RFC is being published to document what is already "out there", based on the original non-IETF spec. Clarifying ambiguity only helps if we're pretty sure that in fact there aren't any implementations based on an alternative interpretation. If we're not sure enough, we're exposing you to additional risk. This is not to say that your technical points aren't well-taken. But the sooner we put *this one* to bed, the sooner we can get to work on a normative RFC, and *picking* interpretations of existing ambiguity that make it easier to configure the mail system and still enable filtering of malicious mail. Maybe even fixing unambiguous problems in the current spec (although propagating changes to deliberately chosen specifications to implementations is always a difficult task). > it causes problems for a person trying to create SPF and DMARC > records in a way that will not cause more problems than it solves! No, since this RFC is informational, it simply fails to help where it is ambiguous. Any actual problems already exist "out there" -- and there probably aren't going to be a lot of new ones because the DMARC consortium claims that 80% of mail is already protected by DMARC. If you stay away from SPF "-all" and use DMARC "p=none", I don't see that there's much risk. Steve From nobody Sat Jan 24 03:08:55 2015 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 43CBA1A1A7C for ; Sat, 24 Jan 2015 03:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.339 X-Spam-Level: **** X-Spam-Status: No, score=4.339 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_ILLEGAL_IP=3.399, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 K5LCqUsG9zS2 for ; Sat, 24 Jan 2015 03:08:52 -0800 (PST) Received: from nm39-vm8.bullet.mail.bf1.yahoo.com (nm39-vm8.bullet.mail.bf1.yahoo.com [72.30.239.152]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9BA1A1A7B for ; Sat, 24 Jan 2015 03:08:52 -0800 (PST) Received: from [98.139.212.151] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2015 11:08:51 -0000 Received: from [98.139.215.253] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2015 11:08:51 -0000 Received: from [127.0.0.1] by omp1066.mail.bf1.yahoo.com with NNFMP; 24 Jan 2015 11:08:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 609640.62444.bm@omp1066.mail.bf1.yahoo.com Received: (qmail 74329 invoked by uid 60001); 24 Jan 2015 11:08:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1422097731; bh=ucHsL9LZvkCdLcg5FPv5dMK5uBp/x0uwSBISBW4UvyA=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=NjBLENG9JEQq237UIAHPi+LHXcTfjySSjVadZaUh27q74LIrNiI8H++R5MqACw5kuWgznav5+bn7XQCtatgxae49uGGD7J6gOJA2F9lWcYIFqZXQ0h66s3lkdS1vRjgfBZo43OOYpuzXZ4vH3MmINQHMJ/YUrLK5SM+we8nVHG8= X-YMail-OSG: lDoXEN8VM1mXv1Pot552RAIewPSkE8pNTx19xu0xqktiMvT tzoh3DeBGh3wCh8saEuPOkaKODG08smhoeldciGgApq17anLyN1SSaNFJdBA YjkMLXHBa4OQUeSlirIx7__G7ph25OyR1io54Z6T_MLJ4j1g6ooTAB4KovTk C6q4OEVmwDU1wkF_b2_1aGOXaU1nd1GXTB7BaJqJdafBpAZb7yfqsG34mpav c6dLO17YuvMWTct_KEpZ6rlJEZM_CE1XFyZTsDEIInPO__RsQUQAWSKnIPmJ 5D1tqEUro8WKEEAOaY1OwaBSidUsfY_4h7cie_LlrAn80NLcTqBhqY10gdRj iJjMEyJKqACFs.pOpxq9v9MjHp.N.kL4EwSNVvpefbbYz1Z42uBgxPRq7SeH H.SkGkuRe9XVeFOMx947pPu8a2aB7JtFJyNdd5tsy7kaLhVl4LZkIbCtB4yZ Yd64KFIklhV5Z2pwxKmyIBRK.vjdc9EkdDIfsV_kTY4RMnTzeIsx.zoTc57O C8kdb1k4cbYUZ0V.icGeHRWSb_IbzvzCJ4Wc8jcgOkMg38bhcB08M3fcNkLX mZ7_rfAW9 Received: from [238.141.119.217] by web160504.mail.bf1.yahoo.com via HTTP; Sat, 24 Jan 2015 03:08:51 PST X-Rocket-MIMEInfo: 002.001, QXMgYW4gSVQgbm9uLXByb2Zlc3Npb25hbCAoaW4gZXZlcnkgc2Vuc2Ugb2YgdGhlIHdvcmQsIEkgb25seSBqb2luZWQgdGhpcyBncm91cCBvdXQgb2YgZnJ1c3RyYXRpb24gYXQgbm8gbG9uZ2VyIGhhdmluZyByZWxpYWJsZSBhY2Nlc3MgdG8gc2V2ZXJhbCBlbWFpbCBsaXN0cyBJIGhhZCBlbmpveWVkIGZvciB5ZWFycyBwcmV2aW91c2x5LCBpbiBhbiBhdHRlbXB0IHRvIHVuZGVyc3RhbmQgV0hZIHRoYXQgd2FzIHNvKSBWRVJZIGZydXN0cmF0ZWQgYnkgdGhlIGJvdW5jaW5nIG1lc3MgZG1hcmMgY3JlYXRlZCABMAEBAQE- X-Mailer: YahooMailClassic/948 YahooMailWebService/0.8.203.740 Message-ID: <1422097731.90387.YahooMailBasic@web160504.mail.bf1.yahoo.com> Date: Sat, 24 Jan 2015 03:08:51 -0800 From: eugene hayhoe To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: [dmarc-ietf] update on dmarc from a mailing list USER'S perspective? 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, 24 Jan 2015 11:08:53 -0000 As an IT non-professional (in every sense of the word, I only joined this group out of frustration at no longer having reliable access to several email lists I had enjoyed for years previously, in an attempt to understand WHY that was so) VERY frustrated by the bouncing mess dmarc created a year ago for people like me, I'm here to ask ''is there any kind of a fix on the horizon yet?'' My occasional perusing of messages on this list leads me to believe ''not yet.'' Is this accurate? ANY ''update for the layman'' that anyone could volunteer would be MUCH appreciated. I miss my mailing lists. Gene Hayhoe From nobody Sat Jan 24 16:06:03 2015 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 9392B1A1BA7 for ; Sat, 24 Jan 2015 16:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.639 X-Spam-Level: X-Spam-Status: No, score=-98.639 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 PZ87FKEbcq8F for ; Sat, 24 Jan 2015 16:05:57 -0800 (PST) Received: from ntbbs.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7351A1BA3 for ; Sat, 24 Jan 2015 16:05:57 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4742; t=1422144352; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/izNYBzudUQ6REw5VQ86IaAwFk8=; b=CwEowVr9RsUFNxKBgwDg 5XPmO5vNlU0Si8crammpAGeXXGSlHqgB7SpQJQ9Q/uPzMBlNgCeFwmbWgmqx9W7A 73iGC8vD6wqHn21bCm+StrUcXrowlVBCGZ+OsAkAoeNte75s8Eb9TNTU4avoD+ea 1dM+MZfn/l7WZ0VTlEIiX4g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 Jan 2015 19:05:52 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 149413522.7652.3412; Sat, 24 Jan 2015 19:05:52 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4742; t=1422144255; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=WgDxiwk 2/wxgZMA5DGazwU8FEpOsByWJ+dIj/lv+7X4=; b=TXxvwBSlaMcV/pH3O9NV1LJ sroUliHDfDO1Wr4pIexwaeWAVWYaTa352t6/mOxJrukJx4FpGq4xX1vfp0jsLd0V TiCOEwMwt8YtKD5wtLyNaRzZ9y36qZF8taPNk8Sq6d5ePHkJmQhHoJ8trwElXhsB lVNfFs3PrYVVU/6YXZZc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 Jan 2015 19:04:15 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3036725158.9.8512; Sat, 24 Jan 2015 19:04:14 -0500 Message-ID: <54C43362.4040701@isdg.net> Date: Sat, 24 Jan 2015 19:05:54 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Anne Bennett , dmarc@ietf.org References: <8589.1422055666@vindemiatrix.encs.concordia.ca> In-Reply-To: <8589.1422055666@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 25 Jan 2015 00:06:01 -0000 On 1/23/2015 6:27 PM, Anne Bennett wrote: > > ** 4408 vs 7208 - does it matter? ** > > Hector points out that SPF implementations using the "obsoleted" > RFC 4408 will be around for some time, and expresses > the concern (if I understand him correctly) that if DMARC > references the newer 7208, there may be an implication that the > 5322.Authentication-Result header will be expected to be present > so DMARC can "consume" it. But there's no mention of the use > of these headers in the current draft (except, in passing, > "Original-Authentication-Results"). The draft mentions using > the *results* of the SPF and DKIM tests, but not how they are > obtained, and I think that may be the right approach. > > Or, Hector, are you concerned that DMARC implementations > will be expected to *provide* one or both those headers, > and if so, that this should be explicitly stated? Being Specific is Terrific. Note -12 rev has no mentioning of Received-SPF. Also note, during SPFBIS there was an attempt (Issue #10) to deprecate Received-SPF which was shot down. Murray was concern of having two mechanisms here. Of course, he was also the author of the Authentication-Result header. Anyway, it depends on the type implementations and there are many kinds. If you starting fresh, you have the luxury to do whatever you want. For others, its can be an expensive change endeavor and for some (like me), they will wait until its all settled. It can also possibly be done via private meta-data when the 5322 payload is saved for mail processing during DATA. In all, we are talking about an integrated framework of a total possible four or even seven components and the possible variations: SMTP SPF, SUBMITTER DKIM ADSP, ATPS DMARC If you are adding DMARC to an existing framework, it needs to decide what it needs to use. DMARC is classified in DMARC as a "Super-ADSP." See appendix A.5. Is this deprecated too? IMO, if its not the developer of the SPF component, the better DMARC implementation should expect 4408 operations. There are new designs and plug and play considerations here. There is also new SMTP change requirements too. This DMARC doc needs to be clear in the migration path. I believe you are concern about the HELO mostly. Historically, it was an unreliable check. Very high overhead with little payoff. The default is NO CHECKING, but I will recognize this is changing and overall DNS lookup waste more feasible to handle across the board. But in general, I always felt that would be a boolean TRUR or FALSE output as a function of SPF and for implementations of all the SPF and related protocols, like SENDER-ID, it included RFC4405 (SUBMITTER) field as well as input to the CheckHost() function SPF.Result = CheckHost(HELO, MAIL.FROM, MAIL.SUBMITTER) despite Scott's adamant refusal to not recognize the existence and its impact (SPFBIS issue #11). There are ESMTP clients do send the SUBMITTER field in MAIL FROM for SPF processing. Unless it can be very clear about it, how is is done, the order, etc, is generally out of scope for IETF protocols. What is important is that the end result is mostly the same. IMO, DMARC is problematic when it looks for an alignment concept because an -ALL at SMTP can preempt a DMARC process altogether, i.e. the DATA payload will not be received/transferred. But DMARC also has semantics for DELAYING SPF processing until the PAYLOAD is received. IMO, that encourages waste, however, getting the REPORTING requirements seems to be also important for many, still. Keep in mind this redundancy will turn into waste, so even processing delay options are provided, implementation needs should allow it to be optimized (turned off). Thats all optional implementation design decisions. I steer towards optimized and scaled designs so the only data received for DMARC processing would be transactions with: SPF.Result = NONE|SOFTFAIL|NEUTRAL|PASS In our implementation, DMARC will never see a -ALL failure since its immediately rejected before DATA. So the alignment can alter the DMARC result, not the SPF result. If you think SMTP should have information about the DMARC policy before DATA is reached, then we don't that ESMTP (Extended SMTP) idea officially proposed yet. Keep in mind, there was once a proposal on the table called CSV/DNA that did allow for Reputation, Authentication and Authorization Policies at the EHLO level. Many DNS-based Email Policy applications have been proposed and explored at various levels. DMARC is the latest one and its DOMAIN anchor is the Author Domain. That piece of data is not at SMTP until DATA is received. -- HLS From nobody Sat Jan 24 16:29:20 2015 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 0170C1A1BD7 for ; Sat, 24 Jan 2015 16:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-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 tbQ1fEGJPqey for ; Sat, 24 Jan 2015 16:29:17 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 92BE91A1BD2 for ; Sat, 24 Jan 2015 16:29:17 -0800 (PST) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 654BD812CF for ; Sat, 24 Jan 2015 16:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1422145757; bh=39NsmQ7D39IpqoyssBOMeH3VjQ/nTYjSpw3M1Qb5T3Y=; h=Subject:From:In-Reply-To:Date:References:To:From; b=WLzMmlG7imr11oTvQ1VI9O098G4/3bykHrcPIurFv+BHGE2WxeOpW1LmP8NRX4fOQ AONYr5efnstuwMwWGy4/OamLTkEAogvQ6MkuqRYybhLEiiVmeFtE5/pEmTAopWodOt 9sMdqfAbYgig8nO0pt8EsHLz3s7SUXIbIGXB2D6M= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: <1422097731.90387.YahooMailBasic@web160504.mail.bf1.yahoo.com> Date: Sat, 24 Jan 2015 16:29:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1422097731.90387.YahooMailBasic@web160504.mail.bf1.yahoo.com> To: dmarc X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [dmarc-ietf] update on dmarc from a mailing list USER'S perspective? 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, 25 Jan 2015 00:29:19 -0000 On Jan 24, 2015, at 3:08 AM, eugene hayhoe = wrote: > As an IT non-professional (in every sense of the word, I only joined = this group out of frustration at no longer having reliable access to = several email lists I had enjoyed for years previously, in an attempt to = understand WHY that was so) VERY frustrated by the bouncing mess dmarc = created a year ago for people like me, I'm here to ask ''is there any = kind of a fix on the horizon yet?'' Your ISP has made a policy statement that you are not allowed to use = mailing lists from their service. DMARC didn't create the issue, Yahoo = did. You have two choices if you want to be able to reliably participate in = mailing lists - persuade Yahoo to reverse their decision about what they = will allow you to do with a yahoo.com email address, or move to a = different email provider. > My occasional perusing of messages on this list leads me to believe = ''not yet.'' Is this accurate? Kinda. "Not any time soon" would be more accurate. "Not ever" might be = even more accurate. > ANY ''update for the layman'' that anyone could volunteer would be = MUCH appreciated. I miss my mailing lists. Move to a different ISP. All the ISPs highlighted in red on this - = http://dmarc.wordtothewise.com - list have stated that they do not wish = their users to send email via anything other than their mail systems. = That includes, amongst other things, typical mailing lists. That list of = ISPs has been pretty stable for a while - I don't expect any of those = listed in red to change any time soon, and I hope there won't be any = changes to red either. Cheers, Steve (apologies for possible duplicate mail)= From nobody Sat Jan 24 16:35:21 2015 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 8C0351A1BDE for ; Sat, 24 Jan 2015 16:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 YpERlCSND6LV for ; Sat, 24 Jan 2015 16:35:17 -0800 (PST) Received: from ntbbs.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6376F1A036B for ; Sat, 24 Jan 2015 16:35:17 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1379; t=1422146113; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=OZdenZr97gKXle0Uk5LolQWa4pM=; b=dIFMb/4qVGAo4DsLiwkK BcEYdUCwQSD5BPu7yRQjklrpN0jJHR6oh+XmLoavI3b3nsp1K8yKsnWdEQVrTAEj zkifjlke1dMapybo/BiOObqaX9cpKXdlzjHB62i6In6kJ2Vh33oq4vgz/xYCEh5Z Ncgmyj1P4cnyObNy1FzBfbc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 Jan 2015 19:35:12 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 151173806.7652.4704; Sat, 24 Jan 2015 19:35:12 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1379; t=1422146014; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=3op/7Uw 477r+PVSqDH2ZZTqtz9/y2CWL2qq5BdEWivk=; b=3OReEp2AJSQHhfN+0fJZmvY UdVyv0xjr9p9Wgj55Q4YuFkUegvWxPygBoTwRMjcSzxfiXnOra1CZ9izGOyIJcBk q4kiOwivXGR5emJz4K3JjB6S0IJmupTILfZOCnCNaMEHHHlHJuQUy9yTXjTkfXMY cOJvMGeUZs2T51pCAutU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 Jan 2015 19:33:34 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3038485065.9.10300; Sat, 24 Jan 2015 19:33:34 -0500 Message-ID: <54C43A42.2060505@isdg.net> Date: Sat, 24 Jan 2015 19:35:14 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: eugene hayhoe , dmarc@ietf.org References: <1422097731.90387.YahooMailBasic@web160504.mail.bf1.yahoo.com> In-Reply-To: <1422097731.90387.YahooMailBasic@web160504.mail.bf1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] update on dmarc from a mailing list USER'S perspective? 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, 25 Jan 2015 00:35:19 -0000 On 1/24/2015 6:08 AM, eugene hayhoe wrote: > As an IT non-professional (in every sense of the word, I only joined this group out of frustration at no longer having reliable access to several email lists I had enjoyed for years previously, in an attempt to understand WHY that was so) VERY frustrated by the bouncing mess dmarc created a year ago for people like me, I'm here to ask ''is there any kind of a fix on the horizon yet?'' > > My occasional perusing of messages on this list leads me to believe ''not yet.'' Is this accurate? > > ANY ''update for the layman'' that anyone could volunteer would be MUCH appreciated. I miss my mailing lists. > > Gene Hayhoe Gene, I feel ya, but IMO your options are: [1] Change your favorite email to another that isn't strict, [2] Wait until the IETF designs new 3rd party DKIM Policy protocols, [3] Encourage your list provider/market to support and push for #2, ASAP. None of this is new. Its been known for at least 10+ years now. Its like politics now, DEM vs GOP. DEM wants DKIM POLICY designs, the GOP want DKIM TRUST designs. DMARC is providing new hope DKIM POLICY will prevail and now that more BIG systems are supporting it and also turning on the REJECTION switch, maybe 3rd party POLICIES is next. Cross your fingers. Vote for 3rd Party Domain Authorization Signing Solutions. -- HLS From nobody Sat Jan 24 17:01:21 2015 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 CE31B1A1BDE for ; Sat, 24 Jan 2015 17:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 i2Q8wY50SxSw for ; Sat, 24 Jan 2015 17:01:18 -0800 (PST) Received: from ntbbs.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 75DC61A1B7F for ; Sat, 24 Jan 2015 17:01:18 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1943; t=1422147673; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lqzwFAKFf3H1BRe1hxYxQvb7mI8=; b=fCHcWuPPzIwSmwWOTMzT EH/CtDHsmQpOLypBSTeWlbaouDa46fpbqbUXBdtv7XMboZ+gYYaVgwwULwgNAKny 108V3TcmVc9Rc8msz+1ZiOWnA/R59lfEXkGPq5tVAc8TSSBf+gG8kKMx2J2ATZBo NBjrMyB1YPvCqJTYd/IQJ3g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 Jan 2015 20:01:13 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 152734112.7652.3756; Sat, 24 Jan 2015 20:01:12 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1943; t=1422147578; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+Pm8Itd 4x/oeC9PUBn0fS3u4OAidAUD8hhkHi9Sklgo=; b=PBTJkfRCCCp+9dHghrJ/ASo rnbBkgJof5QCgi6Mw6SCJ6J+xZQET7hVIU5Ch4aFs5YqIgfjoreprlBj0zEhcHeq TjnKFmbV32W7cC4g+1RcZL19x3syqaaqmj92SdmRnsi4eXJOmzwU+4WtnU0OTGxE gcx2JFkuiby+oTNyaIj4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 Jan 2015 19:59:38 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3040047940.9.2608; Sat, 24 Jan 2015 19:59:36 -0500 Message-ID: <54C4405D.4040405@isdg.net> Date: Sat, 24 Jan 2015 20:01:17 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Anne Bennett References: <8589.1422055666@vindemiatrix.encs.concordia.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 25 Jan 2015 01:01:20 -0000 On 1/23/2015 8:29 PM, Murray S. Kucherawy wrote: > For reasons not worth getting into now, this version of the base > specification is on track to be published not as a standard but as an > "Informational" document, kind of as a handoff step between the team > that first developed DMARC and the IETF, which is more rigorous in > terms of developing standards. The goal posts to which I'm referring > are the completion of that handoff. We need to publish DMARC in its > current state, even if it's not full-standard quality yet, to do so. > If we reset that process every time a defect is identified, we might > not be done for a really long time. The probably you face is new implementations of this "info" version which to them is a "pseudo" standard track item. I think you got most of whats needed. But I would add more info as a "Get Ready" guide to minimize changes in the future. [1] Get ready for 3rd Party Extensions [2] Make sure DMARC processors DO NOT BARF on unknown #1 tags. [3] Forget about ADSP, remove A.5 [4] Independent DMARC modules need to be aware of independent SPF 4408 only modules > DMARC will not be final when this version is published. If it's > broken, I agree it should be fixed, and we have a process for that. Too long and costly and that fact we have to wait for you, its has a major delay and cost impact now, i.e. no rush to do anything now, list systems and list users have to wait for solutions (until you are are ready to work with it). Seriously, the IETF AD needs to be aware of the man power issue. There is no reason why can't have parallel 3rd party Policy Design teams working. There are interested parties to help here. There is no reason why ATPS can't be updated for DMARC to get early explorers started. Remember, before, the interest was not there with ADSP. But now you have it with DMARC. Much different situation now. Good luck -- HLS From nobody Sat Jan 24 18:04:03 2015 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 844D81A1DE1 for ; Sat, 24 Jan 2015 18:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 ZUrizR8ZTFkG for ; Sat, 24 Jan 2015 18:03:59 -0800 (PST) Received: from mail.catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 275B71A1BFE for ; Sat, 24 Jan 2015 18:03:59 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1370; t=1422151429; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=N0AYEFoeLR3sdA/1WHHPI7F6UKE=; b=V03DjcygDAw7jwlgL+zl VP7TFgePIISMTKRSkz5ZnEfiUzytlvLww7wzCunPOKquVFbWSIFvu/22JrSK0Rnp XysMMwlWtAIpmPPp53VS+zw5jdWH5FFsx3TPR5ed+HWB6OLAKB9N//zuD0pP5jrP 3RiNYZzjlhhi5gX5E0+ETT4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 Jan 2015 21:03:49 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 156489431.7652.4520; Sat, 24 Jan 2015 21:03:48 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1370; t=1422151332; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9R96Rln V7pO1yneVuejtBnyO4V0C6kewFOr5bgr5TMY=; b=hljzQERK6FopbvXdhSVvaix Ckv/8U9j39/ociEtZ3ShRJWfGo0LF4yP5tAR/+bJL2PnyIKnU/12TKUbqggEh91q PbMeamndIZwxTAD9e3i5xTl3r23ljvFsRv4mwVx0TRSpiNJ7ck1oRFWXydIgK+hJ JfJfRRsihpQv4n2Q1RTE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 Jan 2015 21:02:12 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3043802268.9.11412; Sat, 24 Jan 2015 21:02:11 -0500 Message-ID: <54C44F07.5060909@isdg.net> Date: Sat, 24 Jan 2015 21:03:51 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Kurt Andersen , Franck Martin References: <8589.1422055666@vindemiatrix.encs.concordia.ca> <9237572.lqxrj8i0PO@scott-latitude-e6320> <1105010941.125154.1422059034711.JavaMail.zimbra@peachymango.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 25 Jan 2015 02:04:01 -0000 On 1/23/2015 8:05 PM, Kurt Andersen wrote: >Scott proposed: > How about this: > > [SPF] can authenticate both the domain found in an [SMTP] HELO/EHLO > command (the HELO identity) and the domain found in an [SMTP] MAIL > command (the MAIL FROM identity). DMARC uses the result of SPF > authentication of the MAIL FROM identity. Section 2.4 of [SPF] describes > SPF MAIL FROM processing for cases in which the MAIL command has a > null path. > >> Frank voted: >> +1 >> Ship it! > > > +1 also :-) Slow down. :) I don't get that second sentence: "DMARC uses the result of SPF authentication of the MAIL FROM identity." Does that mean it gets return-path from the "Authentication-Result:" header? or the "Return-Path:", "Sender:" headers? or is about what SPF should report? I believe, it sounds to me, that it should be: [SPF] can authenticate both the domain found in an [SMTP] HELO/EHLO command (the HELO identity) and the domain found in an [SMTP] MAIL command (the MAIL FROM identity). Section 2.4 of [SPF] describes SPF MAIL FROM processing for cases in which the return path is null, for example MAIL FROM:<>. For DMARC domain alignment policies, DMARC uses the return path (MAIL FROM) of the transaction for alignment with the author domain, see Section 3.1. Its really two separate ideas imo. -- HLS From nobody Sat Jan 24 20:26:17 2015 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 3D0CE1A1EF1 for ; Sat, 24 Jan 2015 20:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.94 X-Spam-Level: X-Spam-Status: No, score=0.94 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 JnH2IOoTBifB for ; Sat, 24 Jan 2015 20:26:12 -0800 (PST) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E501A009B for ; Sat, 24 Jan 2015 20:26:12 -0800 (PST) Received: from [98.139.212.151] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jan 2015 04:26:11 -0000 Received: from [98.139.212.240] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jan 2015 04:26:11 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 25 Jan 2015 04:26:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 877294.15983.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 59163 invoked by uid 60001); 25 Jan 2015 04:26:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1422159971; bh=zzlf5I77GknVj9wMJ6wJeBMglnTJQbI0RJ8YeWQnF/o=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=SVMk6IFO2ncHc1/TIDHb1axCZof9qOY+NXEmnbrWJUY3+nVDWkE8pQHbKlehiXaMeNKyJ25sFOcf5RBYJ8OEPegW82HDnZ/GDrrhDaW0XFBJcX0YGGeeuI+t62TW06RN7vTaW1P1OxVzBFNVOorntUhvufQD6LNZdfGQ3jVSXaI= X-YMail-OSG: S5QFuz4VM1ktdfEWD0ko74P5VT0Yu9VpT1yKC_0sa.c32kO fF.f2ZLf6AlyYdrIULCYehNMp_4hOKolIu6zQqHNy2lP4Bf_20_7F9HxM4RL 3Z4oXs9WA4_nVFj9zGPqZc0rxVSmjp854V7Krv9xGp0j6fOh4Ped8W6w_sii _wusn7IDwopCZWObHK4_OZlTkh57a8QKXavSrVw8w.MgFkBmc.rn8jFDq.N_ xKSiX0FEhDrIMqNTGWNX8PwBZO7dQU.jFVl4IMSal0wUGYI4ST.orOxE4GaE YceGxUQ32sD1H.iImDw156ZxDz4TxfWp3hWsW.Jqhr7WcQ2LG_VhPRYmimP. wAf3MZCJLVhp1W1h2WVZxRQaDnxisTENMtElqKobfljyeu9MF8w60qSuwpNx _3oRjA2Crk9ZX7YhmubEn3pLsomj8D411u4xxdKlt9p6t2ftKdeM21RQr0Sv Wsm1tFij_ySnWh2wjntS3fQskQYAMsYPxZ9VhVHO0OPpVhQUXRu3ZhxeWIoS VWcqt0libjEwEDRWLADyi_9nbmtI0FCLhTkCbDGqOSHdmZ6AXUTGzywJGm8x x9r_kHdBRAYb4vuckK2USjRft7_CBzDnh20HI8S4HRqrdItHF8UU5c1bhN7E Zxfnj95w- Received: from [99.121.78.221] by web160503.mail.bf1.yahoo.com via HTTP; Sat, 24 Jan 2015 20:26:11 PST X-Rocket-MIMEInfo: 002.001, TE9MLCBIZWN0b3IgJiBTdGV2ZSAtIHRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlcyBhbmQgc3RyYWlnaHQgdGFsaywgc2FkIGFzIGl0IGlzLg0KDQpUaGUgcHJvYmxlbSBpcyB0aGUgbGlzdCBwcm92aWRlcnMgd2hvIGR1bXAgbXkgZW1haWwgYWRkcmVzcyBmb3IgJydib3VuY2luZy9ub3QgZ2V0dGluZyBhbGwgbWVzc2FnZXMnJyBhbGxlZ2VkbHksIG5vdCBlbWFpbCBwcm92aWRlcnMgKG5vdCB0aGF0IHRoZXkgZG9uJ3QgaGF2ZSBpc3N1ZXMgdG9vLCBidXQgdGhhdCdzIGFub3RoZXIgdG9waWMpLiANCg0KWWFob28BMAEBAQE- X-Mailer: YahooMailClassic/948 YahooMailWebService/0.8.203.740 Message-ID: <1422159971.79987.YahooMailBasic@web160503.mail.bf1.yahoo.com> Date: Sat, 24 Jan 2015 20:26:11 -0800 From: eugene hayhoe To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: Subject: Re: [dmarc-ietf] update on dmarc from a mailing list USER'S perspective? 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, 25 Jan 2015 04:26:14 -0000 LOL, Hector & Steve - thanks for the responses and straight talk, sad as it is. The problem is the list providers who dump my email address for ''bouncing/not getting all messages'' allegedly, not email providers (not that they don't have issues too, but that's another topic). Yahoo is NOT the only one I've had issues with; hotmail is the same - a couple weeks and I'm bounced again on either from the ARSClist. Based on my experiences with Yahoo in the past, I'm not even going to waste my time CONTACTING them, let alone trying to lobby them. Thanks for the link Steve - will check it out - you gave me more info than I've ever gotten from Yahoo. Tis depressing indeed to hear the comparison to the Ds and Rs, as I washed my hands of BOTH years ago, and this sounds just as hopeless, apparently. Gene -------------------------------------------- On Sat, 1/24/15, Hector Santos wrote: Subject: Re: [dmarc-ietf] update on dmarc from a mailing list USER'S perspective? To: "eugene hayhoe" , dmarc@ietf.org Date: Saturday, January 24, 2015, 7:35 PM On 1/24/2015 6:08 AM, eugene hayhoe wrote: > As an IT non-professional (in every sense of the word, I only joined this group out of frustration at no longer having reliable access to several email lists I had enjoyed for years previously, in an attempt to understand WHY that was so) VERY frustrated by the bouncing mess dmarc created a year ago for people like me, I'm here to ask ''is there any kind of a fix on the horizon yet?'' > > My occasional perusing of messages on this list leads me to believe ''not yet.'' Is this accurate? > > ANY ''update for the layman'' that anyone could volunteer would be MUCH appreciated. I miss my mailing lists. > > Gene Hayhoe Gene, I feel ya, but IMO your options are: [1] Change your favorite email to another that isn't strict, [2] Wait until the IETF designs new 3rd party DKIM Policy protocols, [3] Encourage your list provider/market to support and push for #2, ASAP. None of this is new. Its been known for at least 10+ years now. Its like politics now, DEM vs GOP. DEM wants DKIM POLICY designs, the GOP want DKIM TRUST designs. DMARC is providing new hope DKIM POLICY will prevail and now that more BIG systems are supporting it and also turning on the REJECTION switch, maybe 3rd party POLICIES is next. Cross your fingers. Vote for 3rd Party Domain Authorization Signing Solutions. -- HLS _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -------------------------------------------- On Sat, 1/24/15, Steve Atkins wrote: Subject: Re: [dmarc-ietf] update on dmarc from a mailing list USER'S perspective? To: "dmarc" Date: Saturday, January 24, 2015, 7:29 PM On Jan 24, 2015, at 3:08 AM, eugene hayhoe wrote: > As an IT non-professional (in every sense of the word, I only joined this group out of frustration at no longer having reliable access to several email lists I had enjoyed for years previously, in an attempt to understand WHY that was so) VERY frustrated by the bouncing mess dmarc created a year ago for people like me, I'm here to ask ''is there any kind of a fix on the horizon yet?'' Your ISP has made a policy statement that you are not allowed to use mailing lists from their service. DMARC didn't create the issue, Yahoo did. You have two choices if you want to be able to reliably participate in mailing lists - persuade Yahoo to reverse their decision about what they will allow you to do with a yahoo.com email address, or move to a different email provider. > My occasional perusing of messages on this list leads me to believe ''not yet.'' Is this accurate? Kinda. "Not any time soon" would be more accurate. "Not ever" might be even more accurate. > ANY ''update for the layman'' that anyone could volunteer would be MUCH appreciated. I miss my mailing lists. Move to a different ISP. All the ISPs highlighted in red on this - http://dmarc.wordtothewise.com - list have stated that they do not wish their users to send email via anything other than their mail systems. That includes, amongst other things, typical mailing lists. That list of ISPs has been pretty stable for a while - I don't expect any of those listed in red to change any time soon, and I hope there won't be any changes to red either. Cheers, Steve (apologies for possible duplicate mail) _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Sun Jan 25 07:04:02 2015 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 489871A1A6B for ; Sun, 25 Jan 2015 07:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 17JbHNCA0Vol for ; Sun, 25 Jan 2015 07:03:57 -0800 (PST) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE891A036F for ; Sun, 25 Jan 2015 07:03:57 -0800 (PST) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t0PF3uvP007465 for ; Sun, 25 Jan 2015 10:03:56 -0500 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t0PF3u12021060 for ; Sun, 25 Jan 2015 10:03:56 -0500 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Sat, 24 Jan 2015 21:03:51 EST References: <8589.1422055666@vindemiatrix.encs.concordia.ca> <9237572.lqxrj8i0PO@scott-latitude-e6320> <1105010941.125154.1422059034711.JavaMail.zimbra@peachymango.org> <54C44F07.5060909@isdg.net> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Sun, 25 Jan 2015 10:03:56 -0500 Message-ID: <21059.1422198236@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-01-25 10:03:56 EST Archived-At: Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 25 Jan 2015 15:04:00 -0000 Hector Santos : > "DMARC uses the result of SPF authentication of the MAIL FROM > identity." > > Does that mean it gets return-path from the "Authentication-Result:" > header? or the "Return-Path:", "Sender:" headers? It doesn't say how it gets the results, which IMHO is appropriate, since this is implementation dependent - who are we to say how the components of an e-mail filtering system should communicate with each other internally? > or is about what SPF should report? I definitely would not read the above sentence that way; I raised this because I was trying to understand your objection with respect to the headers. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Sun Jan 25 09:24:49 2015 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 7AFF11A86FE for ; Sun, 25 Jan 2015 09:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 vMdOlFNlandT for ; Sun, 25 Jan 2015 09:24:47 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519651A870A for ; Sun, 25 Jan 2015 09:24:47 -0800 (PST) Received: (qmail 13074 invoked from network); 25 Jan 2015 17:24:46 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 25 Jan 2015 17:24:46 -0000 Date: 25 Jan 2015 17:24:24 -0000 Message-ID: <20150125172424.9631.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <1422159971.79987.YahooMailBasic@web160503.mail.bf1.yahoo.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: jazzme48912@yahoo.com Subject: Re: [dmarc-ietf] update on dmarc from a mailing list USER'S perspective? 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, 25 Jan 2015 17:24:48 -0000 >Yahoo is NOT the only one I've had issues with; hotmail is the same - a couple weeks and I'm >bounced again on either from the ARSClist. Based on my experiences with Yahoo in the past, I'm not >even going to waste my time CONTACTING them, let alone trying to lobby them. The problem is that Yahoo is telling the world that yahoo.com users aren't allowed to send mail through lists. Hotmail is one of the providers that takes their advice. Steve's list has some providers that don't say that. I would agree that if there were any chance Yahoo were going to change their policy due to complaints from non-paying users, it would have happaned by now. Sometimes free services are worth what they cost. R's, John From nobody Tue Jan 27 08:36:21 2015 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 E63CF1A886E for ; Tue, 27 Jan 2015 08:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.103 X-Spam-Level: X-Spam-Status: No, score=-100.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 uLzbnbz5Ad0y for ; Tue, 27 Jan 2015 08:36:16 -0800 (PST) Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AC30A1A8845 for ; Tue, 27 Jan 2015 08:36:15 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1326; t=1422376573; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=yjIVSv7vJuAFZbIMKhyPtgq5FSo=; b=pH7IFZFQg4TMZeoujQt8 ESkkO/zLDX9C6zdO87q5xeGGVVmK3pGcHOjL3AMhqf5KUQdlGUBnX54zvebsG70q Y2JynDjGm+Ih5MUjk7IenT/qR4rxJkvUrbUyIyoNKxBO6o1aEqCFzrbTmZ7uKkxN twQvTSCvNNeZ0g8Cq1dfF+I= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 27 Jan 2015 11:36:13 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 381631915.2496.4620; Tue, 27 Jan 2015 11:36:13 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1326; t=1422376471; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=P+v3hvs zsbKmeXjAK09OPLwgaj1SKUjPXjBrcMgSczU=; b=3KA5lqrvAL5QypsEQuD0Qym O8gID5Vq2EaOWCu7/IM5sqm4DzWaFUgy4I1eo7T3pXnSmNx4iyHffmCsaTO+RZAt 0wZMBUHe7QHA/LoYUfi9vV+IyaSYs15d2LJ5DHLTgvC3GoMYTTKKVL3DYHRmyDSM meiV62WKRCaxd/PJZZI8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 27 Jan 2015 11:34:31 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3268941924.9.5060; Tue, 27 Jan 2015 11:34:30 -0500 Message-ID: <54C7BE7A.50800@isdg.net> Date: Tue, 27 Jan 2015 11:36:10 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Anne Bennett , dmarc@ietf.org References: <8589.1422055666@vindemiatrix.encs.concordia.ca> <9237572.lqxrj8i0PO@scott-latitude-e6320> <1105010941.125154.1422059034711.JavaMail.zimbra@peachymango.org> <54C44F07.5060909@isdg.net> <21059.1422198236@vindemiatrix.encs.concordia.ca> In-Reply-To: <21059.1422198236@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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, 27 Jan 2015 16:36:20 -0000 On 1/25/2015 10:03 AM, Anne Bennett wrote: > > Hector Santos : > >> "DMARC uses the result of SPF authentication of the MAIL FROM >> identity." >> >> Does that mean it gets return-path from the "Authentication-Result:" >> header? or the "Return-Path:", "Sender:" headers? > > It doesn't say how it gets the results, which IMHO is > appropriate, since this is implementation dependent - who are > we to say how the components of an e-mail filtering system > should communicate with each other internally? > >> or is about what SPF should report? > > I definitely would not read the above sentence that way; I > raised this because I was trying to understand your objection > with respect to the headers. > I don't have a objection. The two headers are needed for maximum upward and backward compatibility support. I was just making a note that it is highly possible that a 4408 module may only exist for the new dmarc module to work with. It will only see Received-SPF, otherwise it is custom-made to support internal I/O meta-data or its responsible for updating the 4408 module to possible do it all with Auth-Res. In other words, a DMARC developer needs to be aware of possible scenarios. It can not assume AUTH-RES is guaranteed to have all the SPF information. -- HLS From nobody Wed Jan 28 09:34:12 2015 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 DE6811A1A66 for ; Wed, 28 Jan 2015 09:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.501 X-Spam-Level: X-Spam-Status: No, score=-97.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_41=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 E6LavIaO3FsF for ; Wed, 28 Jan 2015 09:34:08 -0800 (PST) Received: from pop3.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 13F8C1A00F6 for ; Wed, 28 Jan 2015 09:34:07 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4834; t=1422466436; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ofuFysbFeYGy/6HjRdOKa6St6Mg=; b=gwZQo4N7X5CkyY6yz2ut JidjwTtwwe04/WuVKTtpbKS+z2Kt5XtHeYHRCbwUvCcSG9P3BMbOsba0dEFykhuK J/XhIf7FLd37LM2gwNHvORl/5odmLlZ7QUFLv0y2N7BYdxCiBBvC5TfI7JQvNubk ul8Zwb9l0SstIIpmk5Q3gH8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 28 Jan 2015 12:33:56 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 471492921.1.4584; Wed, 28 Jan 2015 12:33:55 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4834; t=1422466334; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=A/yhs6x v+iR9graJ0enebZAsbAMwcy4CzhUENVW2F1c=; b=WefCk/xlblYjA3HwDuNBNcT KCDZJpptM/Okq80rMK8CTrM+aeKktyF62sTlu7awOBKe/H7l3T9S8iJtOFC1PhgW fkRP0rfrXJm6QI0GFOX2y8j6dN4WkHG1MzrTIACCUVXSIciQDSRgYr8rMhKhyhuE oh2XyeYij2MIkeXz76rU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 28 Jan 2015 12:32:14 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3358804705.9.12104; Wed, 28 Jan 2015 12:32:13 -0500 Message-ID: <54C91D84.1080305@isdg.net> Date: Wed, 28 Jan 2015 12:33:56 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Anne Bennett , dmarc@ietf.org References: <8589.1422055666@vindemiatrix.encs.concordia.ca> <9237572.lqxrj8i0PO@scott-latitude-e6320> <1105010941.125154.1422059034711.JavaMail.zimbra@peachymango.org> <54C44F07.5060909@isdg.net> <21059.1422198236@vindemiatrix.encs.concordia.ca> <54C7BE7A.50800@isdg.net> In-Reply-To: <54C7BE7A.50800@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] the painful issue of SPF HELO 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: Wed, 28 Jan 2015 17:34:11 -0000 In all honesty, I have fallen behind on Murray's work with Auth-Res. A number of years back, I know that it wasn't quite ready for full ADSP (reporting/tracing) support and I had slightly deviated from what he was pushing/registering. I didn't feel it covered all the information what a ADSP plus ATPS downlink consumer would need for support or for a MFA (Mail Filtering Agent). For example, this what I have so far with Auth-Res for the message I posted. I just added DMARC processing (without the rejection/quarantine switch): Authentication-Results: dkim.winserver.com; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; adsp=pass policy=all author.d=isdg.net asl.d=ietf.org; dmarc=pass author.d=isdg.net signer.d=ietf.org (atps signer); dkim=fail (DKIM_SIGNATURE_BAD) header.d=isdg.net header.s=tms1 header.i=isdg.net; adsp=pass author.d=isdg.net signer.d=isdg.net (originating signer); dmarc=pass author.d=isdg.net signer.d=isdg.net (originating signer); dkim=fail (DKIM_SIGNATURE_BAD) header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Try to make sense out of that!!! We have no SPF AUTH-RES reporting yet! I should note that our mail system was one of the first few, if only one, that supported DKIM+ADSP+ATPS and the current effort and desire is to basically replace ADSP with its "Super-ADSP" DMARC but also with ATPS support (see section 3.1.3): 3.1.3. Alignment and Extension Technologies If in the future DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified. We have wizards for the ADSP setup and now with DMARC: DKIM ADSP Policy Wizard http://www.winserver.com/public/wcadsp DKIM DKIM Policy Wizard http://www.winserver.com/public/wcdmarc In the above real Auth-Res header example, the top AUTH-RES results pass because of the 3rd party ATPS authorization for the IETF.ORG domain published in our DMARC extended records for 3rd party authorization: v=DMARC1; p=none; atps=y; rua=mailto:dmarc-rua@isdg.net; ruf=mailto:dmarc-ruf@isdg.net; The atps=y tag tells a DMARC+ATPS compliant receiver to check for the unaligned signer (d=ietf.org) domain authorization. The lookup follows this ATPS algorithm for a DNS A record: base32(sha1({SIGNER-DOMAIN}))._atps.{AUTHOR-DOMAIN} So the solution has been known. The question is one of feasibility and scalability. I believe it is for the MAJORITY of domains and even for the big guys, it isn't going to break their back. Anyway, not trying to change the topic regarding 3rd party policies, but to point out this is a very complex integrated solution. Canned or total package solutions have an advantage since they see how things all fit. We have to make it work generically for an automated protocol framework (the MUSTs features) and with extracted options for administrators to play with (the SHOULDs, MAYs features). PS: To Murray, you might find it useful that I have not seen any DMARC parser barfing on the unknown tag "atps=y" which is good and tells us we are very ready for a DMARC extensions market. Bye -- HLS On 1/27/2015 11:36 AM, Hector Santos wrote: > On 1/25/2015 10:03 AM, Anne Bennett wrote: >> >> Hector Santos : >> >>> "DMARC uses the result of SPF authentication of the MAIL FROM >>> identity." >>> >>> Does that mean it gets return-path from the "Authentication-Result:" >>> header? or the "Return-Path:", "Sender:" headers? >> >> It doesn't say how it gets the results, which IMHO is >> appropriate, since this is implementation dependent - who are >> we to say how the components of an e-mail filtering system >> should communicate with each other internally? >> >>> or is about what SPF should report? >> >> I definitely would not read the above sentence that way; I >> raised this because I was trying to understand your objection >> with respect to the headers. >> > > I don't have a objection. The two headers are needed for maximum > upward and backward compatibility support. I was just making a note > that it is highly possible that a 4408 module may only exist for the > new dmarc module to work with. It will only see Received-SPF, > otherwise it is custom-made to support internal I/O meta-data or its > responsible for updating the 4408 module to possible do it all with > Auth-Res. In other words, a DMARC developer needs to be aware of > possible scenarios. It can not assume AUTH-RES is guaranteed to have > all the SPF information. > From nobody Thu Jan 29 11:00:37 2015 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 C841B1A3B9B for ; Thu, 29 Jan 2015 11:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QeBd6un3LJsR for ; Thu, 29 Jan 2015 11:00:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3B21A1F1D for ; Thu, 29 Jan 2015 11:00:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: dmarc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129190035.17068.20875.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 11:00:35 -0800 From: IETF Secretariat Archived-At: Subject: [dmarc-ietf] Milestones changed for dmarc WG X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 19:00:37 -0000 Changed milestone "Complete draft on DMARC interop issues + possible methods to address", set due date to February 2015 from December 2014, added draft-ietf-dmarc-interoperability to milestone. URL: http://datatracker.ietf.org/wg/dmarc/charter/ From nobody Thu Jan 29 11:01:56 2015 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 74CA51A1C05; Thu, 29 Jan 2015 10:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PMDT3W6hrioW; Thu, 29 Jan 2015 10:56:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F20031A1EE8; Thu, 29 Jan 2015 10:56:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150129185623.15136.66399.idtracker@ietfa.amsl.com> Date: Thu, 29 Jan 2015 10:56:23 -0800 Archived-At: X-Mailman-Approved-At: Thu, 29 Jan 2015 11:01:55 -0800 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 18:56:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Filename : draft-ietf-dmarc-interoperability-00.txt Pages : 16 Date : 2015-01-29 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages originate from third party sources, are modified in transit, or are forwarded enroute to their final destination. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmarc-interoperability-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 29 11:09:59 2015 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 3D1991A1A9A for ; Thu, 29 Jan 2015 11:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 7IdSROhnDZ-o for ; Thu, 29 Jan 2015 11:09:55 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 62A021A1A66 for ; Thu, 29 Jan 2015 11:09:55 -0800 (PST) Received: from [10.0.1.3] (208-104-146-37.brvd.dsl.dyn.comporium.net [208.104.146.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 4AE20CB46 for ; Thu, 29 Jan 2015 14:09:45 -0500 (EST) From: Tim Draegen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 29 Jan 2015 14:09:52 -0500 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dmarc-ietf] interoperability draft for review 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: Thu, 29 Jan 2015 19:09:57 -0000 Hi all, Frank, Eliot, and myself have finished up a first cut at the WG=E2=80=99s = 1st real deliverable: =E2=80=A2 Document describing interoperability issues with DMARC = and indirect mail flows and possible methods for addressing them. Please review at your convenience and submit comments, feedback, and = suggestions for text to this list. Frank and/or Eliot will be folding = in edits. A serious effort to cast issues in the language of RFC 5598 = was made. Find it here: = https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ Our aim is to have this document ready for publication by end of = February. Have fun! =3D- Tim From nobody Fri Jan 30 01:23:53 2015 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 028D31A8A78 for ; Fri, 30 Jan 2015 01:23:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.703 X-Spam-Level: X-Spam-Status: No, score=0.703 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 Ua13u6CR8pAM for ; Fri, 30 Jan 2015 01:23:50 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DCD1A8A77 for ; Fri, 30 Jan 2015 01:23:50 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id fb4so1596980wid.2 for ; Fri, 30 Jan 2015 01:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pBQoZtKWy95tiVu0KuZ0aUUebZ6XXa+Ulb7MBpIjExY=; b=jBSFnEDkZHQZNKt7uKuOlHq1Uk6poEKsuaIcIO5WCTEsrrCakBA4YbmZU3pIpZfIbz dLZzRwoTF6ZjAyG7f9PNoeUBXKjJWUpqi5CgjXIuqq4qBSTqOgAyu7faK/XJlZ3ucODd an/CTykFcVeGunEiOzpinHb8Iw/VhVj6HbaTBS3UkuOZGtTvKFnzCwjL1Dw4ZA8A4eiw ZbTOC3gt/+4ZjxX/t5qUPC3IMEBgg6u4NpZRW5CHlovwFt+tuSilkfXX2XCU+2/Vp2jj pYNu8Kr3VwV0/wClyhrw7RDBMT+7mpsiVNNpyZb8CeLt0Zq/effUxjLqACNFTwAo+Yoo PqyQ== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr9715561wjz.89.1422609828838; Fri, 30 Jan 2015 01:23:48 -0800 (PST) Received: by 10.27.85.157 with HTTP; Fri, 30 Jan 2015 01:23:48 -0800 (PST) Date: Fri, 30 Jan 2015 01:23:48 -0800 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=089e0102e49880890a050ddb29d4 Archived-At: Subject: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability 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, 30 Jan 2015 09:23:53 -0000 --089e0102e49880890a050ddb29d4 Content-Type: text/plain; charset=UTF-8 Thanks for putting this together. Here are the results of a late-night first-time reading: Section 2: The sentence starting "This the secondary" appears to be mangled. I can't parse it. Section 2.1, paragraph 1: The first sentence reads like a basic tautology: "A fundamental aspect of X is the method of X." I think you could strike that sentence, and add "to message source validation" to the next one, and it's more readable while saying the same thing. Also, I believe it should be DKIM and SPF, not DKIM or SPF. "organizational domain" should be defined before first use here. I suggest capitalizing it ("Organizational Domain") and indicating, perhaps in Section 1, that the definition of it is in dmarc-base. Section 2.3: MIME should be at least an informative reference given the discussion here. Section 3.1.1: "5322.From header" should be "5322.From header field". Also, I suggest calling it the RFC5322.From header field (including "RFC") to align with what's in dmarc-base, though that's not strictly necessary. (This appears throughout the document, not just this section.) There's a reference to "authenticated domain identifiers", but also a reference earlier to "Authenticated Identifiers". Should we just pick one and stick to it? The latter seems better since we have an existing definition in dmarc-base to reference. Suggest "aligned with" instead of "related to", to use consistent terminology. Section 3.1.2.1: s/8bits/8-bit/ s/7bits/7-bit/ Section 3.1.2.2: s/transfers message,/transfers a message/ Section 3.2.1: s/alternate/alternative/ The list of ways aliasing can happen isn't complete; for example, an MTA's alias table isn't covered. The way one sets up forwarding in Outlook/Exchange is probably something else again. I suggest including "such as". The "local-part of the addr-spec" -- Which addr-spec are you referring to? Section 3.2.3: Might want to mention that RFC7372 was produced to help this, but it's too early to tell if it's going to be successful. The unsubscribe problem is described in RFC6377, and I think also in dmarc-base. A reference from here might be helpful. Section 3.3: Change "...." to "etc." Section 4: I think we need to say something here about the uphill battle of getting any or all of these suggestions into widespread adoption. Section 4.1: I wouldn't call dkim-list-canon "light transformations", but rather something like "constrained transformations". You could add a gigantic MIME part under that proposal and still be able to recover some valid content. Section 4.3: RFC6648 discourages the use of X- header field names, and I don't think "X-Original-From" was ever registered or otherwise permanently described, so is it a good idea to include it here? In the next paragraph you refer to "Original-From". Is that one registered? Section 4.3.1: This isn't a complete sentence. Section 4.4.1.3: There's too much comma splicing going on here. Suggest a rewrite. Also, I don't understand the point about considering that syntax "suspicious". Section 4.5.1: Some mitigations are described in RFC6377, if that might be helpful to reference here. Also, it looks like another place where RFC7372 might be useful. Section 4.6: s/alignement/alignment/ Section 5: More traditionally: "This document contains no actions for IANA. [RFC Editor: Please delete this section prior to publication.]" Section 6: More traditionally: "This document is an analysis of DMARC's impact on indirect email flows. It describes the possibility of accidental denial-of-service that can be created by false rejections of messages by DMARC-aware Mail Receivers. However, it introduces no new security issues to Internet messaging." -MSK --089e0102e49880890a050ddb29d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for putting this together.=C2=A0 Here are the = results of a late-night first-time reading:

Section 2:

The se= ntence starting "This the secondary" appears to be mangled.=C2=A0= I can't parse it.

Section 2.1, paragraph 1:

The fi= rst sentence reads like a basic tautology: "A fundamental aspect of X = is the method of X."=C2=A0 I think you could strike that sentence, and= add "to message source validation" to the next one, and it's= more readable while saying the same thing.

Also, I believe it= should be DKIM and SPF, not DKIM or SPF.

"organizational= domain" should be defined before first use here.=C2=A0 I suggest capi= talizing it ("Organizational Domain") and indicating, perhaps in = Section 1, that the definition of it is in dmarc-base.

Section= 2.3:

MIME should be at least an informative reference given t= he discussion here.

Section 3.1.1:

"532= 2.From header" should be "5322.From header field".=C2=A0 Als= o, I suggest calling it the RFC5322.From header field (including "RFC&= quot;) to align with what's in dmarc-base, though that's not strict= ly necessary.=C2=A0 (This appears throughout the document, not just this se= ction.)

There's a reference to "authenticated domain = identifiers", but also a reference earlier to "Authenticated Iden= tifiers".=C2=A0 Should we just pick one and stick to it?=C2=A0 The lat= ter seems better since we have an existing definition in dmarc-base to refe= rence.

Suggest "aligned with" instead of "relat= ed to", to use consistent terminology.

Section 3.1.2.1:

s/8bits/8-bit/
s/7bits/= 7-bit/

Section 3.1.2.2:
s/transfers message,/transfers a message/

Section = 3.2.1:

s/alternate/alternative/

The lis= t of ways aliasing can happen isn't complete; for example, an MTA's= alias table isn't covered.=C2=A0 The way one sets up forwarding in Out= look/Exchange is probably something else again.=C2=A0 I suggest including &= quot;such as".

The "local-part of the addr-spec= " -- Which addr-spec are you referring to?

Section 3= .2.3:

Might want to mention that RFC7372 was produced to = help this, but it's too early to tell if it's going to be successfu= l.

The unsubscribe problem is described in RFC6377, and I= think also in dmarc-base.=C2=A0 A reference from here might be helpful.
Section 3.3:

Change "...." to &= quot;etc."

Section 4:

I think we need to say = something here about the uphill battle of getting any or all of these sugge= stions into widespread adoption.

Section 4.1:

I wo= uldn't call dkim-list-canon "light transformations", but rath= er something like "constrained transformations".=C2=A0 You could = add a gigantic MIME part under that proposal and still be able to recover s= ome valid content.

Section 4.3:

RFC6648= discourages the use of X- header field names, and I don't think "= X-Original-From" was ever registered or otherwise permanently describe= d, so is it a good idea to include it here?

In the next p= aragraph you refer to "Original-From".=C2=A0 Is that one register= ed?

Section 4.3.1:

This isn't a complete sente= nce.

Section 4.4.1.3:
<= br>
There's too much comma splicing going on here.=C2=A0 Sugg= est a rewrite.

Also, I don't understand the point abo= ut considering that syntax "suspicious".

Sectio= n 4.5.1:

Some mitigations are described in RFC6377, if th= at might be helpful to reference here.=C2=A0 Also, it looks like another pl= ace where RFC7372 might be useful.

Section 4.6:

s/= alignement/alignment/

Section 5:

More t= raditionally:

"This document contains no actions for= IANA.=C2=A0 [RFC Editor: Please delete this section prior to publication.]= "

Section 6:

More traditionally:

"This document is an analysis of DMARC's impact on indirect = email flows.=C2=A0 It describes the possibility of accidental denial-of-ser= vice that can be created by false rejections of messages by DMARC-aware Mai= l Receivers.=C2=A0 However, it introduces no new security issues to Interne= t messaging."

-MSK
--089e0102e49880890a050ddb29d4-- From nobody Fri Jan 30 16:05:44 2015 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 2B6BF1A87E2 for ; Fri, 30 Jan 2015 16:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DbtN1cmvh61k for ; Fri, 30 Jan 2015 16:05:37 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id D4D7C1A87E0 for ; Fri, 30 Jan 2015 16:05:36 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 2AAE5564122; Fri, 30 Jan 2015 18:05:34 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1193560260; Fri, 30 Jan 2015 18:05:34 -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 vXB0wT7rH7cq; Fri, 30 Jan 2015 18:05:33 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B2F056027B; Fri, 30 Jan 2015 18:05:33 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com B2F056027B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1422662733; bh=ZMKcsWoxZHb6P3tECJgRyqxYJ5tPMmQd3ZHPonpK/Os=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=THn71h5mYOK43NobzspUn5dayJmWoBtjcXBkXP7Q32G5/Jt7b32Z2Ovu4UxsmHign uSjbf68AFI4or/dlXfmQJ05h/gY1n9rzPA8KsKOPLjd4wUdBriPfowls3fRM+3yus2 Li6WHqUL1ktxWOUGn4ymm/YfKDjFW1H3BN00E7eQ= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9B81260274; Fri, 30 Jan 2015 18:05:33 -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 wweT2dIIH8VL; Fri, 30 Jan 2015 18:05:33 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 76BE160260; Fri, 30 Jan 2015 18:05:33 -0600 (CST) Date: Fri, 30 Jan 2015 18:05:31 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <298376386.132826.1422662731905.JavaMail.zimbra@peachymango.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_132825_394453525.1422662731904" X-Originating-IP: [10.1.101.178] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: Comments on draft-ietf-dmarc-interoperability Thread-Index: TpGshY34eQSr8CAG2tWu2ikGB/sFWQ== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability 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, 31 Jan 2015 00:05:42 -0000 ------=_Part_132825_394453525.1422662731904 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: dmarc@ietf.org > Sent: Friday, January 30, 2015 1:23:48 AM > Subject: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability > Thanks for putting this together. Here are the results of a late-night > first-time reading: Thanks for suggestions after late-night reading > Section 2: > The sentence starting "This the secondary" appears to be mangled. I can't > parse it. Me neither yet, it is Friday, asking co-authors for suggested text, will fix later... :P > Section 2.1, paragraph 1: Fixed all the rest, you can see a diff at https://github.com/dmarc-ietf/id/commit/24ccb9507086e05732ff477ec7330a481bebcee9#diff-8b30e28a625f335e70d97d9b89dcd243 if you are ok, and when I have section 2, I'll push as -01. ------=_Part_132825_394453525.1422662731904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: dmarc@ietf.org
Sent: Friday, January = 30, 2015 1:23:48 AM
Subject: [dmarc-ietf] Comments on draft-ietf-= dmarc-interoperability

Thanks for p= utting this together.  Here are the results of a late-night first-time= reading:
=

Thanks for sugges= tions after late-night reading

Section 2:
=

The sentence starting "This the secondary" appears to be man= gled.  I can't parse it.
M= e neither yet, it is Friday, asking co-authors for suggested text, will fix= later... :P

Section 2.1, paragraph 1:

Fixed all the rest= , you can see a diff at

if you are ok, and when I have section 2, I'll push as -01= .

------=_Part_132825_394453525.1422662731904-- From nobody Fri Jan 30 16:36:16 2015 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 01F2F1A87E3 for ; Fri, 30 Jan 2015 16:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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 0wI_V_MlruUJ for ; Fri, 30 Jan 2015 16:36:10 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612771A1B18 for ; Fri, 30 Jan 2015 16:36:10 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id b13so29543152wgh.13 for ; Fri, 30 Jan 2015 16:36: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=Wkjl2K5B1Ll+I1fYp2Dq8nvkcwikfMpR0IBPkV9WtOw=; b=BfKCW/J6qNE9qynDYzBaXwxiTzW7GJVOsf8kuL87Aqoob0CYP/GGi9Jwruw6lXa9sA po7xFE+OCdPz+lwtXXYQMWYXKwO0IgwRPxqtX6k++iZF05hpDBjja3qLz/8OBRMeH6dL ZZE23gqhMJTjlsund2uUdbD8Fvwe7soqrNZIlE3YclUBrLyue8l9qqlMNoHj1DItUBZg QuCiXBeaDfSYfCKK9Vw4p+Owb1uw+YTpt+9RVUni5DbuwAhl/8Z0Rxu6W1JoPnEUS9uN E6bkkAXNfVZEJ5Pmu3g0XrbSXoT0KSQRmbOvgA17s+oeuRGDPWxVfcZraaPvL5cCOhvF TLQA== MIME-Version: 1.0 X-Received: by 10.194.86.135 with SMTP id p7mr17234969wjz.89.1422664569158; Fri, 30 Jan 2015 16:36:09 -0800 (PST) Received: by 10.27.85.157 with HTTP; Fri, 30 Jan 2015 16:36:09 -0800 (PST) In-Reply-To: <298376386.132826.1422662731905.JavaMail.zimbra@peachymango.org> References: <298376386.132826.1422662731905.JavaMail.zimbra@peachymango.org> Date: Fri, 30 Jan 2015 16:36:09 -0800 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=089e0102e498478293050de7e8e7 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability 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, 31 Jan 2015 00:36:15 -0000 --089e0102e498478293050de7e8e7 Content-Type: text/plain; charset=UTF-8 That diff format is a little challenging. You might try using "rfcdiff", which eliminates a lot of the reporting of changes that amount to just moving across page breaks and the like. Anyway, I'll give it a thorough review this evening. Thanks for the quick turnaround! -MSK On Fri, Jan 30, 2015 at 4:05 PM, Franck Martin wrote: > ------------------------------ > > *From: *"Murray S. Kucherawy" > *To: *dmarc@ietf.org > *Sent: *Friday, January 30, 2015 1:23:48 AM > *Subject: *[dmarc-ietf] Comments on draft-ietf-dmarc-interoperability > > Thanks for putting this together. Here are the results of a late-night > first-time reading: > > > Thanks for suggestions after late-night reading > > > Section 2: > > The sentence starting "This the secondary" appears to be mangled. I can't > parse it. > > Me neither yet, it is Friday, asking co-authors for suggested text, will > fix later... :P > > > Section 2.1, paragraph 1: > > Fixed all the rest, you can see a diff at > > https://github.com/dmarc-ietf/id/commit/24ccb9507086e05732ff477ec7330a481bebcee9#diff-8b30e28a625f335e70d97d9b89dcd243 > > if you are ok, and when I have section 2, I'll push as -01. > > --089e0102e498478293050de7e8e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That diff format is a little challenging.=C2=A0 = You might try using "rfcdiff", which eliminates a lot of the repo= rting of changes that amount to just moving across page breaks and the like= .

Anyway, I'll give it a thorough review this evening.=C2= =A0 Thanks for the quick turnaround!

-MSK

On Fri, Jan 30, 2015 at 4:0= 5 PM, Franck Martin <franck@peachymango.org> wrote:
=
From: "Murray S. Kucherawy"= <superuser@gma= il.com>
To: dmarc@ietf.org
Sent: Friday, January 30, 2015 1:23:48 A= M
Subject: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperabi= lity

Thanks for pu= tting this together.=C2=A0 Here are the results of a late-night first-time = reading:
<= /div>

Thanks for = suggestions after late-night reading
Section 2:

The sentence starting "This the s= econdary" appears to be mangled.=C2=A0 I can't parse it.
<= /div>
Me neither yet, it is Friday, ask= ing co-authors for suggested text, will fix later... :P
=
=
Section 2.1, paragraph 1:

=
Fixed all the rest, you can see a diff at
=

if you are ok, and when I have section 2, I'll push as -01.
=


--089e0102e498478293050de7e8e7-- From nobody Fri Jan 30 17:32:19 2015 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 CEA1F1A8825 for ; Fri, 30 Jan 2015 17:32:18 -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, 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 GhP0czmgRMKy for ; Fri, 30 Jan 2015 17:32:17 -0800 (PST) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 772721A87F2 for ; Fri, 30 Jan 2015 17:32:17 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 1A742563DF9; Fri, 30 Jan 2015 19:32:17 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1440160280; Fri, 30 Jan 2015 19:32: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 H9vZJ46zczr8; Fri, 30 Jan 2015 19:32:16 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D9FB760287; Fri, 30 Jan 2015 19:32:16 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com D9FB760287 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1422667936; bh=6cRgT/LEh+izjoC/Sv6TQX+/1mLBn7QCa5vRIdhcjd8=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=fwGl0gViq5fIGo12244NEFXIYUFkj01nkS4bNDHXNYJSfaQL+vT/HoG3VY07Tz3s8 TpdMD/0y5mU+r07Mxb+6Jc9bInbHjNZYBnR7XOBqE5eHBTmfnfkp6ERWpKCl0QpL+J APrRf59FCeWfHJriaVIBlamYBeK2XdKwcDl/p13c= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id BB9BA60283; Fri, 30 Jan 2015 19:32:16 -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 mLwgiNS6GAiI; Fri, 30 Jan 2015 19:32:16 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 9686460280; Fri, 30 Jan 2015 19:32:16 -0600 (CST) Date: Fri, 30 Jan 2015 19:32:02 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1606083558.133247.1422667922271.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <298376386.132826.1422662731905.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_133246_458673463.1422667922271" X-Originating-IP: [10.1.101.179] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF35 (Mac)/8.0.5_GA_5839) Thread-Topic: Comments on draft-ietf-dmarc-interoperability Thread-Index: 00Kvm4nMhpJfYqDLGgcnM2NgKXibGQ== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability 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, 31 Jan 2015 01:32:19 -0000 ------=_Part_133246_458673463.1422667922271 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Friday, January 30, 2015 4:36:09 PM > Subject: Re: [dmarc-ietf] Comments on draft-ietf-dmarc-interoperability > That diff format is a little challenging. You might try using "rfcdiff", > which eliminates a lot of the reporting of changes that amount to just > moving across page breaks and the like. Using github tools... :( The diff of the xml later on that page is may be easier to read. ------=_Part_133246_458673463.1422667922271 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Franck Martin" <franck@peachymango.org><= br>Cc: dmarc@ietf.org
Sent: Friday, January 30, 2015 4:36:= 09 PM
Subject: Re: [dmarc-ietf] Comments on draft-ietf-dmarc-inte= roperability

That diff format = is a little challenging.  You might try using "rfcdiff", which elimina= tes a lot of the reporting of changes that amount to just moving across pag= e breaks and the like.
Using github = tools... :(

The diff of the xml later on that = page is may be easier to read.
------=_Part_133246_458673463.1422667922271-- From nobody Sat Jan 31 08:59:14 2015 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 ECC641A1A46 for ; Sat, 31 Jan 2015 08:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, 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 wpCDcEUETA3B for ; Sat, 31 Jan 2015 08:59:09 -0800 (PST) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:a60:f0b4:e503:2cdb:beff:feaa:880b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFCB1A00B8 for ; Sat, 31 Jan 2015 08:59:08 -0800 (PST) Received: from horde.andreasschulze.de (horde.andreasschulze.de [IPv6:2001:a60:f0b4:e503:e49d:e7ff:fea2:4010]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3kZM890kRNzDgS for ; Sat, 31 Jan 2015 17:59:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1422723545; bh=9o6o1/CRzIWbLD9YwyOke0qcpgHwz9Vl4CggXeyfFy4=; h=Date:From:To:Subject:In-Reply-To; b=LclnRpZOmPDqkAG8Iy2bgJiMtwAc9+o6Plz/UYyBGUe4PNJmy5Q+YtGl/VDgyPrrN 7ImRGRNzIOv0K/Ior1Rrw/mzVvhpAAuS7gQxuStGJDJEqx7Ba3xAYnXTt9yMLXtPLo ZtUc7oCxkKn3OB956xZXrHaNuwd7tweiyFqm3GPOh471aKWzpihDoDaiL10GL+5llt WCmdq+AtW0YQO04MOHe/nC6lB5NuESmZWxe/lccyLBMm1G7e8DvISmGzTvh2fwtfFM akLMFVAc+rqsSg/I79ekO9jkDF2N6aQ0XWOEmtJHGv+7W7QbJJ564EL2Lep6eL/dnz f1vIhaJ8tIkolB1t2upVwMyLd2Z99CMqPrUuy+jHclIgGHihrpxftsSr6xsuEM0I2c bj4KrXMHVw8SGdNtH7DemyF/aUdXe5EM9ZHSbQ9lufhZkgnSgXlBStGwhPzu09PjZ8 hQRa405h60vEQCsusl1vCNTJVATK+JKU7CEfnIyymF5GhmcqatKi1ry7FoM7dRJpgl YJVZAQJlLAGnGuHCWaiMrF29QVF5GOs4ClrN8vaL5zL8173r6XNL/qSgMulWms7SOI Lp+S/LzkRlEtXZop9y83x5xBPM/67wIiayQjzF8luIUEJFhvL//1ZNVkh2GCSI3Iut 7k2CqrO+tnBqSi2xeavHopeQ= Received: from dimos.andreasschulze.de (dimos.andreasschulze.de [2001:a60:f0b4:e502::152]) by horde.andreasschulze.de (Horde Framework) with HTTP; Sat, 31 Jan 2015 17:59:04 +0100 Date: Sat, 31 Jan 2015 17:59:04 +0100 Message-ID: <20150131175904.Horde.TIp_qUi__CM-jMhpSTMV8Q1@horde.andreasschulze.de> From: "A. Schulze" To: dmarc@ietf.org In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: Subject: Re: [dmarc-ietf] interoperability draft for review 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, 31 Jan 2015 16:59:12 -0000 Tim Draegen: > Find it here: > https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ I read the draft yesterday. Well done... One note on Section 2.1 / SPF More often than not operators have not put an SPF record on domains found in the HELO/EHLO SMTP command Assumed I translate to German and back to English correctly, is the following the same sense? "Rarely operators put an SPF record on domains found in the HELO/EHLO SMTP command." and when present, it could be difficult to change this domain to the domain in the 5322.From, especially when several mail streams share the same sending IP address. - could be a separate sentence. Also here: is it right if I understand "mostly domains found in the HELO/EHLO SMTP command do not match the RFC5322.From" ? Andreas