From nobody Wed Nov 2 09:00:42 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099F71296BD for ; Wed, 2 Nov 2016 09:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaB_QDVDTWGe for ; Wed, 2 Nov 2016 09:00:39 -0700 (PDT) Received: from smtp69.ord1c.emailsrvr.com (smtp69.ord1c.emailsrvr.com [108.166.43.69]) (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 7B1711296C4 for ; Wed, 2 Nov 2016 09:00:37 -0700 (PDT) Received: from smtp1.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E2B8520587; Wed, 2 Nov 2016 12:00:36 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A4F2A2055F; Wed, 2 Nov 2016 12:00:36 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.7); Wed, 02 Nov 2016 12:00:36 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Wed, 2 Nov 2016 10:00:35 -0600 Message-Id: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> To: ietf@ietf.org, dmarc@ietf.org X-Mailer: Apple Mail (2.3226) Archived-At: Subject: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 16:00:41 -0000 So if someone send a email with a bad signature to an IETF list from a = domain that has a reject policy, and the IETF server forwards it to my = email email provider, my email provider rejects it. Now the IETF email = server counts that as a bounce. Too many bounces in a row and the IETF = server unsubscribes me from the list.=20 This does not seem OK that anyone can trivially send some SPAM and get = me unsubscribed.=20 What's the right advice on how the IETF server should be run? Now to a more detailed problem - Jana sends lots of email to the quic = list. I don't get any of them. It appears that my email server (run by = rackspace) rejects them with an=20 Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for = google.com (G15) If Jana sends the email directly to me, it works. This seems to point at = the IETF server is doing something that breaks signature in Jana email.=20= I realize this is not the "debug your email" list, but I have no idea = where is the right place to ask about this so I sent it here. Sorry.=20 Can anyone tell me how their DMARC system views the emails from Jana to = the quic@ietf.org list ? From nobody Wed Nov 2 12:00:52 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DD4129B86; Wed, 2 Nov 2016 12:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCsZu93w_QbU; Wed, 2 Nov 2016 12:00:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D92129B89; Wed, 2 Nov 2016 12:00:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F3945E1A7; Wed, 2 Nov 2016 15:16:02 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9E99B637A6; Wed, 2 Nov 2016 15:00:35 -0400 (EDT) From: Michael Richardson To: Cullen Jennings In-Reply-To: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: dmarc@ietf.org, ietf@ietf.org Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:00:50 -0000 --=-=-= Content-Type: text/plain Cullen Jennings wrote: > So if someone send a email with a bad signature to an IETF list from a > domain that has a reject policy, and the IETF server forwards it to my > email email provider, my email provider rejects it. Now the IETF email > server counts that as a bounce. Too many bounces in a row and the IETF > server unsubscribes me from the list. > This does not seem OK that anyone can trivially send some SPAM and get > me unsubscribed. yeah, that's a real problem isn't it. After nearly three years of yelling about this problem, we are not even close to consensus that it's a problem, with many people suggesting that IETF mailing list software should just munge headers. DMARC WG was supposedly designing a solution. I don't know where that is. My take is that IETF mailing list software should reject email from p=reject senders, since that's their stated policy. The original threads include: https://www.ietf.org/mail-archive/web/ietf/current/msg99659.html > What's the right advice on how the IETF server should be run? > Now to a more detailed problem - Jana sends lots of email to the quic > list. I don't get any of them. It appears that my email server (run by > rackspace) rejects them with an > Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for > google.com (G15) > If Jana sends the email directly to me, it works. This seems to point > at the IETF server is doing something that breaks signature in Jana > email. Jana needs to stop sending from google.com. Their policy is that not to forward, so sad to lose all the google.com contributors.... we really shouldn't violate their stated policy. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWBo30YCLcPvd0N1lAQJgKAf/U5AHCx0bAJXj/X/QyyjEREa45ZCV+YRu C/O9IDObHk24eG6YGUb1SP3CU6LwCghtuCHzcOMNrvafbkgr1nkcniM/Ic5T6gwU H0dsZvEwkypbF6ckg+/5T+aP99wE0AyRRmn8dvVG6k/j7xRPxF1SCZnXzbwZ5Dgz +wRKXWDb/XtH49Uz766LoZSEeM5lH3yD8O42CBbFf7cB1w5piBZMDX/BZgdamFf9 IVAxmqL2p76XwiyWCAySm8k4zcz9PjSlVSmiWuH20X0rlsh/8VtCgV3068kfdgWm 9ee0EJt0fiDNlBarEsJfzr18fRENJuqe3kusQKTUeX5VtBBy12u+FA== =4ZxR -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 2 12:13:20 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D2C1297C5 for ; Wed, 2 Nov 2016 12:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jsfRafht2vj for ; Wed, 2 Nov 2016 12:13:13 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21D81297C3 for ; Wed, 2 Nov 2016 12:13:12 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id c13so21004566lfg.0 for ; Wed, 02 Nov 2016 12:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UYthvET4e8E5Xu58FFRsrwv0jvmk6k/mOP2PoIIaP78=; b=K3pYmahPQABuRQTdkXSDd7DnFrqRM+FcjfhKvaNXP3SzY9xQol/Xp8jsd7AzaJ3nJu wPQUvMud11d/T6IiMr+PmhaJvFbdKsGwEZDbfK7CYN+q5ws9D8QHJAQTSYprGi/inbLY B+wna9cHleVeXqcAWd61fLuVyX0rUFajT7ft20gT7Pujng10GwwDfLAGy/OO9wELQMia u1AgKBiCfxuPFw0Z652VgVjjhZLnoaq0ugH6fsVyb4syDZUZKwPjnIbNUON1CAXl53G5 +RHD5oQ4mOR4YpS+fGSuLOi2FpkX+qyU1Rz+eOIKA+Y9Rel4o5D09tAmdqgmgmB+hDk9 1bUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UYthvET4e8E5Xu58FFRsrwv0jvmk6k/mOP2PoIIaP78=; b=dMRVw0TlKZaEjQlSf2RcIeXbnI3jMe+WqV7Sx5HoRcQmOBpRWxklJNCO7VAwH3PXvZ 5j3oZv8RnVkUq3Ce/dFPFICuygI502RA88eELcnxNn9gnMj+w6wwmor7PcXJPLK+wI1D 57bEM3c1aZNt1qiKwTyAg5wTLZXAp3qVZG0OCfpidmf5HRMl+0THoMJoMh4UvPewXo4f JTUM/3N2nO7JE4ckreMF52gfJt++2pWnJRah14aHBvzKlLjc2/kIio2zz9KjK8Xn3vRV LSEe4VGvP0RfpY+4S5QoU8ERiqQMWJWhBaDqEga/HfbnhVSjwXLARCUt39E6rsmCiMXa gGMA== X-Gm-Message-State: ABUngvdoTCcHLDEf103Di8VlRBtQI3dbJYARyNg5mXWRZ4j0Bn7HMdUuSWH/G1RsW6yTT5KfqZ3fv2BaJS+pog== X-Received: by 10.25.141.19 with SMTP id p19mr3152970lfd.56.1478113990979; Wed, 02 Nov 2016 12:13:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.160.202 with HTTP; Wed, 2 Nov 2016 12:12:30 -0700 (PDT) In-Reply-To: <29429.1478113235@obiwan.sandelman.ca> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> From: Ted Lemon Date: Wed, 2 Nov 2016 15:12:30 -0400 Message-ID: To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dmarc@ietf.org, ietf , Cullen Jennings Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:13:16 -0000 FWIW, I use Google For Work (or whatever it's called this week) and it doesn't automatically add DMARC headers--that's something that you have to configure, apparently. So while I think that gmail.com is probably a lost cause, if your org is using GfW, you don't have to use DMARC. On Wed, Nov 2, 2016 at 3:00 PM, Michael Richardson wrote: > > Cullen Jennings wrote: > > So if someone send a email with a bad signature to an IETF list from a > > domain that has a reject policy, and the IETF server forwards it to my > > email email provider, my email provider rejects it. Now the IETF email > > server counts that as a bounce. Too many bounces in a row and the IETF > > server unsubscribes me from the list. > > > This does not seem OK that anyone can trivially send some SPAM and get > > me unsubscribed. > > yeah, that's a real problem isn't it. > > After nearly three years of yelling about this problem, we are not even close > to consensus that it's a problem, with many people suggesting that IETF mailing > list software should just munge headers. > > DMARC WG was supposedly designing a solution. I don't know where that is. > > My take is that IETF mailing list software should reject email from p=reject > senders, since that's their stated policy. > > The original threads include: > https://www.ietf.org/mail-archive/web/ietf/current/msg99659.html > > > What's the right advice on how the IETF server should be run? > > > Now to a more detailed problem - Jana sends lots of email to the quic > > list. I don't get any of them. It appears that my email server (run by > > rackspace) rejects them with an > > > Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for > > google.com (G15) > > > If Jana sends the email directly to me, it works. This seems to point > > at the IETF server is doing something that breaks signature in Jana > > email. > > Jana needs to stop sending from google.com. > > Their policy is that not to forward, so sad to lose all the google.com > contributors.... we really shouldn't violate their stated policy. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Wed Nov 2 12:27:56 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0A1129455; Wed, 2 Nov 2016 12:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXLDj3Y3VVav; Wed, 2 Nov 2016 12:27:50 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 4BE6B129865; Wed, 2 Nov 2016 12:17:56 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id n67so57635593wme.1; Wed, 02 Nov 2016 12:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=blLwYNp0YyyoLQ0szNOcQ39z90FbZw5ZPYmSpZDZkrQ=; b=sntIdda5ZuaUCq2/a0JYXiiRqk8RcLz8fUZMStM9XgClyGC5j8BrSAqSQR+sY4NftC eAlMGv14QoHsYexZAoQMnGb+Hf6+aGTnpBUt8CmVRM0LCAbdNdc009hcvA64yN9/UXj1 tJGv+oG5mt6VDVngLzOsnA4FQlHqujr58yfxXcxucsvazWnAgxmbbm1G7EWKm3YfI8bn Y7mi8JQyMfTHrTrdwnbbpia1Qedu3/MtmCexaocf1/RBi/KJut+tR133djbzgstUgpAp MTyAowkcx6ZgO1iQ59n25EmRe8yPE7bX8bSmt8ijAEk9D5t1Kl3ggyC+5xNqWbdDjXrz AJsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=blLwYNp0YyyoLQ0szNOcQ39z90FbZw5ZPYmSpZDZkrQ=; b=eVIbCLD8NxUtvuyEYVjhpTvTSqDpI6A2mRc9soHTv4DAgU11XFGA7ggQ1Q5vz8aSB3 zo+rg6QLNTpRlKqSAEL2QFqLs/HOcUSYRku+rFC4dAMLpPiiHSJh0YwMX62isNym87yh EzJX9uVsCzmUOCvNEWwJ9GFe/I5ai74GL9Msqy5En2JLrTDdrGFqHKqqIWix8zWVlGIe R9MucpSMCr1SsS7kbjpUTktczMdlBfR2tqoCkO7O1MZ2cqiiNNP2Zxnm71tfdaFCvDoR jK5ByxsxLbkcqKa1+aX+Xm562lY0LGVW6CMQ61SfXnjqDkT37FMzDkHHKEqPGqvF6uWA iUaQ== X-Gm-Message-State: ABUngve6F5muAWyH31xfjY4VfqbC5OCEv/iMjCNpKyowJxE9GS2Qsn8gM+xiq6KV0XE5lg== X-Received: by 10.194.192.105 with SMTP id hf9mr4289637wjc.41.1478114274829; Wed, 02 Nov 2016 12:17:54 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id jq10sm4399381wjb.46.2016.11.02.12.17.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 12:17:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: Date: Wed, 2 Nov 2016 21:17:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0BADD208-4D6F-42E1-8B7F-A8822C68A244@gmail.com> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> To: Ted Lemon X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Michael Richardson , dmarc@ietf.org, ietf , Cullen Jennings Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 19:27:51 -0000 > On 2 Nov 2016, at 21:12, Ted Lemon wrote: >=20 > FWIW, I use Google For Work (or whatever it's called this week) and it > doesn't automatically add DMARC headers--that's something that you > have to configure, apparently. So while I think that gmail.com is > probably a lost cause, if your org is using GfW, you don't have to use > DMARC. Actually there=E2=80=99s no issue with @gmail.com. The problem is only = with @google.com Yoav From nobody Wed Nov 2 13:05:30 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E691812989F for ; Wed, 2 Nov 2016 13:05:25 -0700 (PDT) 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=twhXt8L/; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=ubq9bnhD 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 O05qZ2KryGa5 for ; Wed, 2 Nov 2016 13:05:22 -0700 (PDT) Received: from news.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C7BA812988A for ; Wed, 2 Nov 2016 13:05:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4544; t=1478117116; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=JXoLz/0xu0NsWppzZKJiMXi3/hU=; b=twhXt8L/rwYqCvz4at+f1G9IgQW/YPyrU23YYttMuKacNuBA3hXWjFAwN+vcSS r7SMXFvqzl8vP65lMtRMUwQjBoTSRWbcEHPM+djrwc0JLM8sSOZ7Mf9dvty9SbBq sSUUxTgoau5VMtFMdL3JdfUzeLrdoWds2TdeF42byQGro= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Wed, 02 Nov 2016 15:05:16 -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; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 605626541.1.5384; Wed, 02 Nov 2016 15:05:14 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4544; t=1478117106; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=dZ8Y/ii 8f+pxOyQEvKXtGP000Xe6mUijDmH6wG80J6I=; b=ubq9bnhDBqjRskzA6l8jUTX OpN32hQHtscp0leilkvuNvD4T9H5pN5YBsJaunyUVQfYbZAcfIba675x9jq3HuU/ CUMEm1nHGCTq3ZDHmGM/PMK+XDWZ/R2unL4gWYBYMHM2Rsx7mZ20UD4mYcXtkxHE byZLN8Oa9ptMyihsubo8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Wed, 02 Nov 2016 16:05:06 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 61185937.9.16276; Wed, 02 Nov 2016 16:05:05 -0400 Message-ID: <581A46FA.6040001@isdg.net> Date: Wed, 02 Nov 2016 16:05:14 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Cullen Jennings , ietf@ietf.org, dmarc@ietf.org References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> In-Reply-To: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 20:05:26 -0000 Since its inception, this has been the "Achilles' heel" of DKIM without a Signature Policy Authorization framework. i.e. authorizing 3rd party mail processors, such as a list manager/server or could bring the integrity and/or resign the mail as a 3rd party. The IETF abandoned the proposed standard ADSP RFC (and hence any add-on extension work like ATPS) and replaced it with an informative DMARC RFC described as a "Super ADSP" without resolving the 3rd party authorization problem. ATPS was the original proposed standard to authorize the first party signature and combined with ADSP extension ATPS, it covered the Third Party Signature authorization. ADSP/ATPS actually works very well. Its been in production for a number of years. I have "ietf.org" as a 3rd party signer assigned to my ATPS records in DNS. Supportive receivers can then see that I authorize ietf.org to sign my IETF submissions as my receivers do when I get a copy. My ADSP record for isdg.net is: dkim=all; atps=y; asl=ietf.org,beta.winserver.com,santronics.com,isdg.net,winserver.com,megabytecof fee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;" The asl list contains my small list of authorized list servers plus other 3rd party associates. For the larger "registered" list, the "atps=" says to lookup the ATPS record the signer domain in the author's zone. It works very well. This wizards helps illustrates how records are created updated for the DMARC record: http://www.winserver.com/public/wcdmarc/default.wct However, this solution requires a "Registration Of 3rd party Domains" solution, i.e. you have to learn/teach your personal network of email domains and registered them somehow for others to lookup query and many feel this won't scale. It won't for some, it will for others. Now there is the ARC effort that could help resolve the problem, iff everyone supports it. IMO, it appears complex (doc is very verbose). I believe it has RFC5222 overhead related code changes. If you have an API ready for it, it should help. While receivers still need to support it, not all receivers use the same API base code. I was not happy when a big investment was lost when the IETF abandoned (incorrect in my opinion) the ADSP work in particular when DMARC effectively replaced ADSP, literally described as a "Super ADSP" and it didn't offer any 3rd party policy support whatsoever. So I am not too eager to jump on more IETF DKIM, including ARC, related work. DMARC is not complete. Its not even a proposed standard. Lots of work still needs to be done but I'm sure that RFC status can change when desired by the key cogs. All I would like to see is for DMARC to begin offering 3rd party policy models with known solutions that include simple DNS lookup like ADSP/ATPS offered. It shouldn't be limited to just ARC. That said, the only other current way to resolve this with DMARC is to relax your policy to "p=none" By making it "p=reject" all DMARC compatible receivers are designed to reject it when its signed by 3rd party signers and/or the original mail integrity, hence 1st party signature, is broken. -- HLS On 11/2/2016 12:00 PM, Cullen Jennings wrote: > > So if someone send a email with a bad signature to an IETF list from a domain that has a reject policy, and the IETF server forwards it to my email email provider, my email provider rejects it. Now the IETF email server counts that as a bounce. Too many bounces in a row and the IETF server unsubscribes me from the list. > > This does not seem OK that anyone can trivially send some SPAM and get me unsubscribed. > > What's the right advice on how the IETF server should be run? > > Now to a more detailed problem - Jana sends lots of email to the quic list. I don't get any of them. It appears that my email server (run by rackspace) rejects them with an > > Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for google.com (G15) > > If Jana sends the email directly to me, it works. This seems to point at the IETF server is doing something that breaks signature in Jana email. > > I realize this is not the "debug your email" list, but I have no idea where is the right place to ask about this so I sent it here. Sorry. > > Can anyone tell me how their DMARC system views the emails from Jana to the quic@ietf.org list ? > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Wed Nov 2 13:23:24 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E361296BF; Wed, 2 Nov 2016 13:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWVKjsD57_Gl; Wed, 2 Nov 2016 13:23:16 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 2DFE41295B7; Wed, 2 Nov 2016 13:23:16 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id d2so17540152pfd.0; Wed, 02 Nov 2016 13:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FtbYJJA/7/3KsZnlk8JX7fWF5R2l7rYA9+lJg63XjzY=; b=j7Uba3HtrsLNpP60kLtjZ//yWymGI9P8oZuaSXteEnj6C8RsTZfSCwXj/1YiBKWS1/ 4YRd31nqaQZVnsirnnjks0bxD6ZIo7EA0Myy5U2emBvz2tvT+sRuWzqI0d1IvXK9YFll rEsMyZwFpwkFRO6GOnZW53rvrWcMXOzlScuEQvb+MyZrF4cpUCXBAXXflLqPw/0nO0Ty meqeAAzP6j7/Mat2KcYBU1pGaqY2Lj447Z74VJsiAPjKSbM7ZE27/HIL1Gf8FtDrw50/ sCe8+75JybehOWO7L7ZXcG65idJgGdo5ect3q/rUUZ1rsw1EzXXWUBY9sE3p/++5frvg +QoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:reply-to:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=FtbYJJA/7/3KsZnlk8JX7fWF5R2l7rYA9+lJg63XjzY=; b=ZT5eGM/IZrp279TZZE2FLo3maH+gDNa5WJe+h9fmDvVyRMgG3IdSErvK+5A1G+URuJ TIiY8zoHg4OPFdDhxROtc+VlG8TDb7VUy3lr4bmfEU71SJjb6XTt/o4bm2/jSpwLAoBh Jzh1NZD/rTbBUBge4+LNAfdOmeXPbL5y3a8kPXTCo5uyg/TLQPtnTcBAZKtJV19N/uIU cQpTvK+Pee8QSJgHKQ9ccvH7Tm6eXjOaiCSTShKqt2ejU6XbSN8uvbG0oowpDk6WAYYO 2wqhzSxek/LcfKv3EWljwGI6250B45xtfnkk7DL8SRdmwqpkY5DeI2SLD5idIucQjHx+ xrMw== X-Gm-Message-State: ABUngvc5NJ4IzdTEKkNhFeWhtAY/rH9sU0Ru/WjMnOKzJgq3ZXw6QM7qi41kmozfg+egmQ== X-Received: by 10.98.84.135 with SMTP id i129mr10010120pfb.93.1478118195835; Wed, 02 Nov 2016 13:23:15 -0700 (PDT) Received: from [10.71.12.45] ([8.25.222.2]) by smtp.gmail.com with ESMTPSA id e6sm6847673pad.0.2016.11.02.13.23.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 13:23:15 -0700 (PDT) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Hector Santos , Cullen Jennings , ietf@ietf.org, dmarc@ietf.org References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <581A46FA.6040001@isdg.net> Organization: Brandenburg InternetWorking Message-ID: <52be7430-062f-3f20-57e9-7c44bd018ff3@dcrocker.net> Date: Wed, 2 Nov 2016 13:23:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <581A46FA.6040001@isdg.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 20:23:17 -0000 On 11/2/2016 1:05 PM, Hector Santos wrote: > Since its inception, this has been the "Achilles' heel" of DKIM without > a Signature The issue, here, is with features added by DMARC. As such, the problem has nothing to do with DKIM. DKIM does not present any problems, with respect to retaining the rfc5322.From field contents. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 2 14:58:38 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67ABA129998 for ; Wed, 2 Nov 2016 14:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4QVcqCKzSIY for ; Wed, 2 Nov 2016 14:58:34 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 0015A1298A3 for ; Wed, 2 Nov 2016 14:58:33 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id x4so40911740oix.2 for ; Wed, 02 Nov 2016 14:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1GMQlioB9FuLwTTnmBUK7vEedXVGbu90kL/Uf4vbmCI=; b=jRWlnROagwj1vZZkT40GWqyWFD1NlSGX1C9oQFtWRkYZ3ry2E4jE/yKxTECoHBLREu aiGJxWgUrKm26ZFzEsq6Nx5rfCL6fd9ITjMjCijFpPG0jm9q6KEtAgiSBrfyLDH1j4cg t7OixQJUdpvS/CrbH4U1EeyWl/OQqiQpUkRUtSYaMsTY/LpIXcqNoAIYWuSfHkZhLeQQ fkn6fsqXZJGad4uergkGN4WOt6BFTNFe1AWnrlQ4/K18hF1h+HLMCwFt7a4gTOjW+DRJ 8nIdePyyqeXvV6oGlVQDJ3grGUFNCQS5MB8iaYGE/WiPWguRVJqRLmBMpiYlqz9zs8Qk Sn5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1GMQlioB9FuLwTTnmBUK7vEedXVGbu90kL/Uf4vbmCI=; b=MAdKj+eZT7tqdMfGOAHeSe6C8jpw1R655/IgXDh9HMKzoblpfqkeLW7a4C6X6XXGLO Qfsul61EwGrsBtt1FCl9b9SCaKbLF+kuoj43HQsPuNTnoPpj4AncY8NriXtV2UflivWk i3Re0ZDKFjb42bWv/KgcxQYM4HQu9GVwM2P3vXEks8skx+Z7/FEz3b0YSFP+ciLY9AN+ roSS6HE+lhAPcY00fCGfWFZxF/hokF1UcpveZXiLowBr7Qqcj0AXR2i2n7C+fJcwd/Xe za29eTAiKzd0jQjo8ESOM3rSwji8/ve0eTCkkoLuDgtpBYIJuAcKnBuYqMZIX9zSkNNm 7CdA== X-Gm-Message-State: ABUngvd9smPFalbWBs7xART59A+2hMMqCfvcJOm8uiWkyJTWn03BvdvhCpD3x1IqxOrKuWjvbDuU190j07DJCKfc X-Received: by 10.157.29.72 with SMTP id m66mr4085463otm.152.1478123913120; Wed, 02 Nov 2016 14:58:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.11.162 with HTTP; Wed, 2 Nov 2016 14:58:31 -0700 (PDT) In-Reply-To: <29429.1478113235@obiwan.sandelman.ca> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> From: Brandon Long Date: Wed, 2 Nov 2016 14:58:31 -0700 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=001a113ba4c0c6f5170540588a37 Archived-At: Cc: "dmarc@ietf.org" , IETF , Cullen Jennings Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 21:58:36 -0000 --001a113ba4c0c6f5170540588a37 Content-Type: text/plain; charset=UTF-8 With the understanding that my email is unlikely to be received by some of those having issues... Let us assume that those who specify p=REJECT have a good reason for doing so, and that after 2-3 years, they are unlikely to change back. Let us also assume that the members of these organizations who are participating in IETF may or may not have any power over whether their admins have decided to be p=REJECT. And let us assume that we want these folks to participate in IETF. I will assume that if you're not willing to stipulate to the above, then you don't actually want a solution. We are then left with only moving forward. If this is a problem for you as a receiver, you can choose to attempt to whitelist the ietf mailing list mail from DMARC enforcement. You may not be able to do so, just like the sender may not be able to change their organizations DMARC record. The middle man, ietf, can work around this today. They need to run a new enough version of mailman and enable one of the workarounds. For mailman, this means munging the mail, usually the From header. It's not pretty, but it works, it works now, and it will work for everyone. The difference is mostly cosmetic, though depending on your mail client, there may be other downsides. And it may violate RFC 5322. I don't think this is possible with mailman, but theoretically it is also possible for a mailing list to pass the message through without breaking the DKIM signature. This means no footers and no subject tags. Which of these a list would choose is probably dependent on the list members. mailman should also know how to tell the difference between a message specific policy bounce, and particular DMARC bounces, and should apply different heuristics to handling them. I have no idea if that existing in any version of mailman or is a planned feature. There is a proposed standard, ARC, that would allow mail receivers to do more intelligent whitelisting. It's not ready yet. It is unfortunate that these types of choices have to be made. Brandon On Wed, Nov 2, 2016 at 12:00 PM, Michael Richardson wrote: > > Cullen Jennings wrote: > > So if someone send a email with a bad signature to an IETF list from > a > > domain that has a reject policy, and the IETF server forwards it to > my > > email email provider, my email provider rejects it. Now the IETF > email > > server counts that as a bounce. Too many bounces in a row and the > IETF > > server unsubscribes me from the list. > > > This does not seem OK that anyone can trivially send some SPAM and > get > > me unsubscribed. > > yeah, that's a real problem isn't it. > > After nearly three years of yelling about this problem, we are not even > close > to consensus that it's a problem, with many people suggesting that IETF > mailing > list software should just munge headers. > > DMARC WG was supposedly designing a solution. I don't know where that is. > > My take is that IETF mailing list software should reject email from > p=reject > senders, since that's their stated policy. > > The original threads include: > https://www.ietf.org/mail-archive/web/ietf/current/msg99659.html > > > What's the right advice on how the IETF server should be run? > > > Now to a more detailed problem - Jana sends lots of email to the quic > > list. I don't get any of them. It appears that my email server (run > by > > rackspace) rejects them with an > > > Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for > > google.com (G15) > > > If Jana sends the email directly to me, it works. This seems to point > > at the IETF server is doing something that breaks signature in Jana > > email. > > Jana needs to stop sending from google.com. > > Their policy is that not to forward, so sad to lose all the google.com > contributors.... we really shouldn't violate their stated policy. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a113ba4c0c6f5170540588a37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With the understanding that my email is unlikely to be rec= eived by some of those having issues...

Let us assume th= at those who specify p=3DREJECT have a good reason for doing so, and that a= fter 2-3 years, they are unlikely to change back.

= Let us also assume that the members of these organizations who are particip= ating in IETF may or may not have any power over whether their admins have = decided to be p=3DREJECT.

And let us assume that w= e want these folks to participate in IETF.

I will = assume that if you're not willing to stipulate to the above, then you d= on't actually want a solution.

We are then lef= t with only moving forward.

If this is a problem f= or you as a receiver, you can choose to attempt to whitelist the ietf maili= ng list mail from DMARC enforcement.=C2=A0 You may not be able to do so, ju= st like the sender may not be able to change their organizations DMARC reco= rd.

The middle man, ietf, can work around this tod= ay.=C2=A0 They need to run a new enough version of mailman and enable one o= f the workarounds.=C2=A0 For mailman, this means munging the mail, usually = the From header.=C2=A0 It's not pretty, but it works, it works now, and= it will work for everyone.=C2=A0 The difference is mostly cosmetic, though= depending on your mail client, there may be other downsides.=C2=A0 And it = may violate RFC 5322.

I don't think this is po= ssible with mailman, but theoretically it is also possible for a mailing li= st to pass the message through without breaking the DKIM signature.=C2=A0 T= his means no footers and no subject tags.=C2=A0 Which of these a list would= choose is probably dependent on the list members.

mailman should also know how to tell the difference between a message spec= ific policy bounce, and particular DMARC bounces, and should apply differen= t heuristics to handling them.=C2=A0 I have no idea if that existing in any= version of mailman or is a planned feature.

There= is a proposed standard, ARC, that would allow mail receivers to do more in= telligent whitelisting.=C2=A0 It's not ready yet.

<= div>It is unfortunate that these types of choices have to be made.
Brandon


On Wed, Nov 2, 2016 at 12:00 PM, Michael = Richardson <mcr+ietf@sandelman.ca> wrote:

Cullen Jennings <fluffy@iii.ca> = wrote:
=C2=A0 =C2=A0 > So if someone send a email with a bad signature to an IE= TF list from a
=C2=A0 =C2=A0 > domain that has a reject policy, and the IETF server for= wards it to my
=C2=A0 =C2=A0 > email email provider, my email provider rejects it. Now = the IETF email
=C2=A0 =C2=A0 > server counts that as a bounce. Too many bounces in a ro= w and the IETF
=C2=A0 =C2=A0 > server unsubscribes me from the list.

=C2=A0 =C2=A0 > This does not seem OK that anyone can trivially send som= e SPAM and get
=C2=A0 =C2=A0 > me unsubscribed.

yeah, that's a real problem isn't it.

After nearly three years of yelling about this problem, we are not even clo= se
to consensus that it's a problem, with many people suggesting that IETF= mailing
list software should just munge headers.

DMARC WG was supposedly designing a solution. I don't know where that i= s.

My take is that IETF mailing list software should reject email from p=3Drej= ect
senders, since that's their stated policy.

The original threads include:
=C2=A0 =C2=A0 https://www.ietf.org/m= ail-archive/web/ietf/current/msg99659.html

=C2=A0 =C2=A0 > What's the right advice on how the IETF server shoul= d be run?

=C2=A0 =C2=A0 > Now to a more detailed problem - Jana sends lots of emai= l to the quic
=C2=A0 =C2=A0 > list. I don't get any of them. It appears that my em= ail server (run by
=C2=A0 =C2=A0 > rackspace) rejects them with an

=C2=A0 =C2=A0 > Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMAR= C policy for
=C2=A0 =C2=A0 > google.com (G15)

=C2=A0 =C2=A0 > If Jana sends the email directly to me, it works. This s= eems to point
=C2=A0 =C2=A0 > at the IETF server is doing something that breaks signat= ure in Jana
=C2=A0 =C2=A0 > email.

Jana needs to stop sending from google.com.

Their policy is that not to forward, so sad to lose all the google.com
contributors.... we really shouldn't violate their stated policy.


--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




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


--001a113ba4c0c6f5170540588a37-- From nobody Wed Nov 2 15:00:42 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8631294CE for ; Wed, 2 Nov 2016 15:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeaXAd69RJog for ; Wed, 2 Nov 2016 15:00:39 -0700 (PDT) Received: from smtp133.dfw.emailsrvr.com (smtp133.dfw.emailsrvr.com [67.192.241.133]) (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 C646D129960 for ; Wed, 2 Nov 2016 15:00:39 -0700 (PDT) Received: from smtp21.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 141AD40154; Wed, 2 Nov 2016 18:00:39 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 3E9D040379; Wed, 2 Nov 2016 18:00:38 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.7); Wed, 02 Nov 2016 18:00:39 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Cullen Jennings In-Reply-To: <29429.1478113235@obiwan.sandelman.ca> Date: Wed, 2 Nov 2016 16:00:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <81242B03-803E-4ECD-9131-B301CA932CA5@iii.ca> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3226) Archived-At: Cc: dmarc@ietf.org, ietf@ietf.org Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 22:00:41 -0000 > On Nov 2, 2016, at 1:00 PM, Michael Richardson = wrote: >=20 >=20 > Cullen Jennings wrote: >> So if someone send a email with a bad signature to an IETF list from = a >> domain that has a reject policy, and the IETF server forwards it to = my >> email email provider, my email provider rejects it. Now the IETF = email >> server counts that as a bounce. Too many bounces in a row and the = IETF >> server unsubscribes me from the list. >=20 >> This does not seem OK that anyone can trivially send some SPAM and = get >> me unsubscribed. >=20 > yeah, that's a real problem isn't it. >=20 > After nearly three years of yelling about this problem, we are not = even close > to consensus that it's a problem, with many people suggesting that = IETF mailing > list software should just munge headers. My apologies for not checking the archives. I did try but I downloaded a = mbox file from one of the IETF mail archive tools that when I importated = that into mail.crapp just turned out not to really be a valid mbox file = and just turned into one email - anyways, I digress about our broken = tools.=20 So how do we get this fixed ? Has someone talked to the IESG about this? = Right now as a chair, I am making consensus calls that are probably = ignoring any emails from people from google.com - and other - because I = am not getting their email. That seems like a serious process problem. From nobody Wed Nov 2 15:14:06 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B8712953E for ; Wed, 2 Nov 2016 15:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuP6PgozfNrK for ; Wed, 2 Nov 2016 15:14:02 -0700 (PDT) Received: from smtp141.dfw.emailsrvr.com (smtp141.dfw.emailsrvr.com [67.192.241.141]) (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 A69951296D5 for ; Wed, 2 Nov 2016 15:14:02 -0700 (PDT) Received: from smtp26.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B41C0A02A5; Wed, 2 Nov 2016 18:14:01 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0F57EA01AF; Wed, 2 Nov 2016 18:14:00 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.253] (d75-159-45-76.abhsia.telus.net [75.159.45.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.7); Wed, 02 Nov 2016 18:14:01 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Cullen Jennings In-Reply-To: Date: Wed, 2 Nov 2016 16:13:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> To: Brandon Long X-Mailer: Apple Mail (2.3226) Archived-At: Cc: Michael Richardson , "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 22:14:04 -0000 Agree with your assumptions ( and the later point that receiving person = can't controls what their admins do any more than sender can control = what their admins do) But there are two failure modes for something like this=20 1) sender knows their email was not received=20 2) email was not received by a bunch of people and neither the sender = nor receiver knows that The second failure mode is much worse than the first.=20 > On Nov 2, 2016, at 3:58 PM, Brandon Long wrote: >=20 > With the understanding that my email is unlikely to be received by = some of those having issues... >=20 > Let us assume that those who specify p=3DREJECT have a good reason for = doing so, and that after 2-3 years, they are unlikely to change back. >=20 > Let us also assume that the members of these organizations who are = participating in IETF may or may not have any power over whether their = admins have decided to be p=3DREJECT. >=20 > And let us assume that we want these folks to participate in IETF. >=20 > I will assume that if you're not willing to stipulate to the above, = then you don't actually want a solution. >=20 > We are then left with only moving forward. >=20 > If this is a problem for you as a receiver, you can choose to attempt = to whitelist the ietf mailing list mail from DMARC enforcement. You may = not be able to do so, just like the sender may not be able to change = their organizations DMARC record. >=20 > The middle man, ietf, can work around this today. They need to run a = new enough version of mailman and enable one of the workarounds. For = mailman, this means munging the mail, usually the =46rom header. It's = not pretty, but it works, it works now, and it will work for everyone. = The difference is mostly cosmetic, though depending on your mail client, = there may be other downsides. And it may violate RFC 5322. >=20 > I don't think this is possible with mailman, but theoretically it is = also possible for a mailing list to pass the message through without = breaking the DKIM signature. This means no footers and no subject tags. = Which of these a list would choose is probably dependent on the list = members. >=20 > mailman should also know how to tell the difference between a message = specific policy bounce, and particular DMARC bounces, and should apply = different heuristics to handling them. I have no idea if that existing = in any version of mailman or is a planned feature. >=20 > There is a proposed standard, ARC, that would allow mail receivers to = do more intelligent whitelisting. It's not ready yet. >=20 > It is unfortunate that these types of choices have to be made. >=20 > Brandon >=20 >=20 > On Wed, Nov 2, 2016 at 12:00 PM, Michael Richardson = wrote: >=20 > Cullen Jennings wrote: > > So if someone send a email with a bad signature to an IETF list = from a > > domain that has a reject policy, and the IETF server forwards it = to my > > email email provider, my email provider rejects it. Now the IETF = email > > server counts that as a bounce. Too many bounces in a row and = the IETF > > server unsubscribes me from the list. >=20 > > This does not seem OK that anyone can trivially send some SPAM = and get > > me unsubscribed. >=20 > yeah, that's a real problem isn't it. >=20 > After nearly three years of yelling about this problem, we are not = even close > to consensus that it's a problem, with many people suggesting that = IETF mailing > list software should just munge headers. >=20 > DMARC WG was supposedly designing a solution. I don't know where that = is. >=20 > My take is that IETF mailing list software should reject email from = p=3Dreject > senders, since that's their stated policy. >=20 > The original threads include: > https://www.ietf.org/mail-archive/web/ietf/current/msg99659.html >=20 > > What's the right advice on how the IETF server should be run? >=20 > > Now to a more detailed problem - Jana sends lots of email to the = quic > > list. I don't get any of them. It appears that my email server = (run by > > rackspace) rejects them with an >=20 > > Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy = for > > google.com (G15) >=20 > > If Jana sends the email directly to me, it works. This seems to = point > > at the IETF server is doing something that breaks signature in = Jana > > email. >=20 > Jana needs to stop sending from google.com. >=20 > Their policy is that not to forward, so sad to lose all the google.com > contributors.... we really shouldn't violate their stated policy. >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 >=20 From nobody Wed Nov 2 15:19:57 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BAEF12711D; Wed, 2 Nov 2016 15:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwykyYyaNWkS; Wed, 2 Nov 2016 15:19:50 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 DC3E31296CC; Wed, 2 Nov 2016 15:19:49 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id d2so18946557pfd.0; Wed, 02 Nov 2016 15:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NfYVPat0i8cDIjXKn8hs8czwzaHpnPmVGtQbJ+pDwYw=; b=lYuFhTVBHNezj7jfAs2d8p+JNJ0Xz6R6IQbaaI5yv/OT4uLzcfXihlgRde1bsMC4eH MtptnDpX7DlyJ6IedJz/fwSsUo9PSgqwlRT3kJfAYqHqWlrk6IGclF+j4AaVt5mL3RUt g+IPLpXLTtZAhUQuUhHLibI4hLX2SecZlYdcP9n7G9ELXxmnZpraAIWicfF+ZyVP4EAN WXqJ8t1NM2qb2dXqRia8ibui2HXqJrFaxn00O6JHZqmWNswTnXcDzJvM6tQbEr9SrNqg FyrJ7zoSN8AlABW4auwnKo6rK/6ZXJs7eL6nufNTYgrp9Jiiv5JW2mgA6lBtRvBDixbu tpTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=NfYVPat0i8cDIjXKn8hs8czwzaHpnPmVGtQbJ+pDwYw=; b=L5KThIf+x7rojXVZ7uPkz5YClyiy0k2bZ3z9LEOsiELVr9zVHTQJNehXI57CbFhZRq NSB4EmmImOt6Jpq4FlcVmaLk7S3IJ63ewR8lsi2/pXTy+jtryCZVvvdfp99Vdeu9Uap0 Py08SCgsd5V+91CMEL9AE9WvAD6axKPJJnkrEPgjmBUEy8czRZz0YsMakbENixv+pYdE S6XASnDAqGqO5mm1Z1WSwXtsqGexXdj19ViUIvaDRpr+JUBXQP/O0TEmP4fEBjspCY/1 Vfn3SBLM3nf1SEMIieNU5o8uLmNzLw/GkhzvlDMkU0wjG0buAxKWCeT3md6VkEohpRlO y7kw== X-Gm-Message-State: ABUngvf//M8fS1UbFK+nsgZBgh5Zpj/j/ew34a1unYy25oYpLSibA13Xaso4wGe2K6er7A== X-Received: by 10.98.93.201 with SMTP id n70mr10869199pfj.161.1478125189330; Wed, 02 Nov 2016 15:19:49 -0700 (PDT) Received: from [192.168.178.23] ([118.148.78.158]) by smtp.gmail.com with ESMTPSA id e7sm7066910pfa.65.2016.11.02.15.19.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 15:19:48 -0700 (PDT) To: Brandon Long , Michael Richardson References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5c0220dd-20b6-5e8e-fe9c-b402675cc559@gmail.com> Date: Thu, 3 Nov 2016 11:19:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , IETF , Cullen Jennings Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 22:19:52 -0000 On 03/11/2016 10:58, Brandon Long wrote: > With the understanding that my email is unlikely to be received by some of > those having issues... > > Let us assume that those who specify p=REJECT have a good reason for doing > so, and that after 2-3 years, they are unlikely to change back. > > Let us also assume that the members of these organizations who are > participating in IETF may or may not have any power over whether their > admins have decided to be p=REJECT. > > And let us assume that we want these folks to participate in IETF. Let me stop you right there. Yes, we want everybody to be free to participate in the IETF, and presumably those people want to participate in the IETF. But participants have to be able to use the tools that the IETF has chosen, which includes mailing lists. That's always been true. (In 1992, when I started in the IETF, it meant knowing how to subscribe to a majordomo list. Today, subscribing is a bit easier, but it means avoiding the DMARC trap.) So such participants need to use an email sending address that works with IETF mailing lists. yahoo.com and google.com don't work properly with IETF mailing lists. Fortunately, very fine alternatives are available, such as gmail.com. (gmail's spam learning is even smart enough to work around p=reject, as it did for this very message that I'm replying too.) I think Michael Richardson made a very valid point. If our mailing list software detects a sender whose domain has p=reject, we *know* that the forwarded message will fail DMARC validation. So there's a strong case for rejecting the message immediately, so that the sender can be told about the problem and can choose a different sending address. Presumably, we'd only need to do this until ARC is deployable. > > I will assume that if you're not willing to stipulate to the above, then > you don't actually want a solution. > > We are then left with only moving forward. > > If this is a problem for you as a receiver, you can choose to attempt to > whitelist the ietf mailing list mail from DMARC enforcement. You may not > be able to do so, just like the sender may not be able to change their > organizations DMARC record. > > The middle man, ietf, can work around this today. They need to run a new > enough version of mailman and enable one of the workarounds. For mailman, > this means munging the mail, usually the From header. It's not pretty, but > it works, it works now, and it will work for everyone. The difference is > mostly cosmetic, though depending on your mail client, there may be other > downsides. And it may violate RFC 5322. No, it's actually not cosmetic, for reasons that Dave Crocker pointed out. Regards Brian > I don't think this is possible with mailman, but theoretically it is also > possible for a mailing list to pass the message through without breaking > the DKIM signature. This means no footers and no subject tags. Which of > these a list would choose is probably dependent on the list members. > > mailman should also know how to tell the difference between a message > specific policy bounce, and particular DMARC bounces, and should apply > different heuristics to handling them. I have no idea if that existing in > any version of mailman or is a planned feature. > > There is a proposed standard, ARC, that would allow mail receivers to do > more intelligent whitelisting. It's not ready yet. > > It is unfortunate that these types of choices have to be made. > > Brandon > > > On Wed, Nov 2, 2016 at 12:00 PM, Michael Richardson > wrote: > >> >> Cullen Jennings wrote: >> > So if someone send a email with a bad signature to an IETF list from >> a >> > domain that has a reject policy, and the IETF server forwards it to >> my >> > email email provider, my email provider rejects it. Now the IETF >> email >> > server counts that as a bounce. Too many bounces in a row and the >> IETF >> > server unsubscribes me from the list. >> >> > This does not seem OK that anyone can trivially send some SPAM and >> get >> > me unsubscribed. >> >> yeah, that's a real problem isn't it. >> >> After nearly three years of yelling about this problem, we are not even >> close >> to consensus that it's a problem, with many people suggesting that IETF >> mailing >> list software should just munge headers. >> >> DMARC WG was supposedly designing a solution. I don't know where that is. >> >> My take is that IETF mailing list software should reject email from >> p=reject >> senders, since that's their stated policy. >> >> The original threads include: >> https://www.ietf.org/mail-archive/web/ietf/current/msg99659.html >> >> > What's the right advice on how the IETF server should be run? >> >> > Now to a more detailed problem - Jana sends lots of email to the quic >> > list. I don't get any of them. It appears that my email server (run >> by >> > rackspace) rejects them with an >> >> > Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for >> > google.com (G15) >> >> > If Jana sends the email directly to me, it works. This seems to point >> > at the IETF server is doing something that breaks signature in Jana >> > email. >> >> Jana needs to stop sending from google.com. >> >> Their policy is that not to forward, so sad to lose all the google.com >> contributors.... we really shouldn't violate their stated policy. >> >> >> -- >> Michael Richardson , Sandelman Software Works >> -= IPv6 IoT consulting =- >> >> >> >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > From nobody Wed Nov 2 15:34:22 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94FB129525 for ; Wed, 2 Nov 2016 15:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjS9lRhXjd4U for ; Wed, 2 Nov 2016 15:34:19 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FA4D129501 for ; Wed, 2 Nov 2016 15:34:19 -0700 (PDT) Received: (qmail 11419 invoked from network); 2 Nov 2016 22:34:19 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Nov 2016 22:34:19 -0000 Date: 2 Nov 2016 22:34:07 -0000 Message-ID: <20161102223407.67758.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: mellon@fugue.com Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 22:34:21 -0000 In article you write: >FWIW, I use Google For Work (or whatever it's called this week) and it >doesn't automatically add DMARC headers-- Is it too much to ask that anyone who wants to tell us how to deal with DMARC should at least read RFC 7489 so he knows how DMARC works? R's, John Helpful tip: There's no such thing as a DMARC header. From nobody Wed Nov 2 15:46:57 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A304F129486 for ; Wed, 2 Nov 2016 15:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz6vdb-KLWyP for ; Wed, 2 Nov 2016 15:46:54 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 CE25C129413 for ; Wed, 2 Nov 2016 15:46:53 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id c13so24608202lfg.0 for ; Wed, 02 Nov 2016 15:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UF3vhThxd8fyn0e1Dhd2mzuTT6jOJ7LEvN04OPSrVww=; b=o0Vjy2xrv/+kailwUzaEEtmR4UMnh/XRC+pHownBSpSJFtGZ8uOB+8Gta2RLfihS8d j9jW7WNJ7yv6olW0/szap7XCdgeMn1OvZEqr+jwAzPJIgSuX6z9Eu1wKLlsgRVqjnof2 msz0AntlmMIbKdbC8s9k8ryi7FWersIbt05kDbf3ma8kMX0LKIlOrGME3Zz2WbIAjSJ2 uQekaus79j0d8I6dNll5vByIcr2ujkx9HzzJYW/ft3J8UompdeaPxXewdhZjrin8MFRH OQktnSEjOQGCfkBwx0aCBilADqGWgxNuwwGn7zTNHmWqq9wnO1vSgIp8YL80v8FC5AXA b/rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UF3vhThxd8fyn0e1Dhd2mzuTT6jOJ7LEvN04OPSrVww=; b=KHcmJmdeZrlTvclm4rPJGo2CzQJYGgxWWI5fllb/nevzBVFMr5ieCsQ2y9f0gNAg5Z O6CZ75Mw8ic8KjjkgjCra3RAoYSvWze8p7Nb3DJMiVGp8zTm5A6YMVC/m7KKqScLon7r hXIrO2EvHwQnvriRlrwFHO3Kl+gkYLQq6pRC5IyVTa4KqC8vsVjoCEy+DwR8aJ/Uynzv v4UYVjby4CLJkv43G7qF7iGVN4fJRuTu5Mu1B0Qfq7mzjO79KuAc0/Z+mliae1RSzf4/ VdNXcMmGyNzTt7l8SiMOVE+YjXrBXTFgUtryJfPdVYmV8k54SREApNVviYUGxg7XsCHt vk9g== X-Gm-Message-State: ABUngvepYlbXzQXWNdcu2VHdmSMb/0VYzvcOVjTInGAg7yqPaPnmpt6dXzDi10SKxzewGB7NlLJtYpLaKu47Yw== X-Received: by 10.25.204.69 with SMTP id c66mr3737560lfg.5.1478126811737; Wed, 02 Nov 2016 15:46:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.160.202 with HTTP; Wed, 2 Nov 2016 15:46:11 -0700 (PDT) In-Reply-To: <20161102223407.67758.qmail@ary.lan> References: <20161102223407.67758.qmail@ary.lan> From: Ted Lemon Date: Wed, 2 Nov 2016 18:46:11 -0400 Message-ID: To: John Levine Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 22:46:55 -0000 Yes, it is too much. I could care less how DMARC works, in the sense that it clearly _doesn't_ work. Knowing how it works is not my problem, and is not the secretariat's problem. Making IETF mailing lists work is the secretariat's problem (not mine anymore). Belittling people who are arguing that a long-standing problem needs to be fixed is not appropriate. On Wed, Nov 2, 2016 at 6:34 PM, John Levine wrote: > In article you write: >>FWIW, I use Google For Work (or whatever it's called this week) and it >>doesn't automatically add DMARC headers-- > > Is it too much to ask that anyone who wants to tell us how to deal > with DMARC should at least read RFC 7489 so he knows how DMARC works? > > R's, > John > > Helpful tip: There's no such thing as a DMARC header. > From nobody Wed Nov 2 15:51:23 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE3E129473; Wed, 2 Nov 2016 15:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_oaZLa_llXM; Wed, 2 Nov 2016 15:51:17 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 247F7128DF6; Wed, 2 Nov 2016 15:51:17 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id d2so19341446pfd.0; Wed, 02 Nov 2016 15:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:organization:reply-to:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=17uV4akHrQyn95Mo3xTIydCcehLDi+aU9HlOoxE1GDQ=; b=W0odZuz3KYKEWej83ISmq4Zr8u/mdXN0jX9dyOXCuABo/81rZeelDcD+aOerZZi632 293yT5NSlfyL68JpNegj5Xrkqq+AfTeDAko0UaWP9Qnx6sBvOjw7IPfprG1b5WC3D1RS +yZyPbo7FoZTr/z97LXbZEPJtMOZ04jZIicUvX+/f0AKbYJopbU8VGt044mPpMUvgwTG y5+Xz02T0lvgl4cGdml6B1H6Lg9Pjm5Yyl+GZjfTZtiqjGXh6Rzwm35DMLSWvmpBmkkf DZk6xx+quzXCgjnmLgG1TddZ/MrYcEZe5dwBhw6LEuv77AzPRNgldYZaILl5e/aBpfiI dhZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:organization :reply-to:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=17uV4akHrQyn95Mo3xTIydCcehLDi+aU9HlOoxE1GDQ=; b=MA+oFbVOsHE61X2M+cdPthkDvhOLad1WF989Q2bPCia59sQWndE69rtunPy6ZAyGIU JVVZQHi1qXEWjrKigVP+L1BCWNQCfbJqxnMdHLNCuTUDWzgpIzW8r8mAcT08as6P9vAb Nx+pUERuI3kMRWd5mYI449WSNca8u0wdXcoc3eltWKnOBZq5jKGIJEV/i0b8FPpUdkkK +o0JHDp3/1VzdMBSqIJNsDfR6TvaeHEsKTeYmghF3SO0GcOOsRjCgliA9cbt6vfpKQtc igeYSaVZ/xyUMMuYIk1kvtdzjpfdaRvNpO1UKhcGa316RExsUIjFs7e+H4Y8t8juO+RN chIQ== X-Gm-Message-State: ABUngvdJbOU0QjPY04xHpnRz9sgZCVHCEtX/8suTi2Od0bRh0WdxKxBCuTJLlkAdwadmdA== X-Received: by 10.98.34.218 with SMTP id p87mr10999392pfj.97.1478127076776; Wed, 02 Nov 2016 15:51:16 -0700 (PDT) Received: from [10.71.12.45] ([8.25.222.2]) by smtp.gmail.com with ESMTPSA id l11sm546204pfb.28.2016.11.02.15.51.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Nov 2016 15:51:16 -0700 (PDT) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Brandon Long References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> Organization: Brandenburg InternetWorking Message-ID: <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> Date: Wed, 2 Nov 2016 15:51:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , IETF Subject: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 22:51:18 -0000 On 11/2/2016 2:58 PM, Brandon Long wrote: > The difference is mostly cosmetic, though depending on your mail client, > there may be other downsides. And it may violate RFC 5322. Brandon, You know that I know that the attacks that generated the use of DMARC, which is causing the current situation, are serious. I'm mentioning that here to make sure the context for what follows is clear... Email is communication between an author and one or more recipients. Everything in between them is 'overhead'. The overhead functions need to be careful to avoid cavalierly reducing the utility of email, even as the changes are meant to aid in the use of email. Identification of the author and recipients is meaningful to them. That's not 'cosmetic'. And software tools employed by users take advantage of this identification, for searching and for organizing. In a highly diverse world, one of the problems of being a very major player is that it becomes far too easy not to see all the diversity or to appreciate its import to others. After all, most of that diversity is seen as such a tiny percentage of the activity. This is the essence of ethnocentrism. Changing the contents of the rfc5322.From field is changing basic statements about authorship. Perhaps there's no practical choice right now, but please let's not be cavalier about its import. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 2 16:24:08 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5591812967A; Wed, 2 Nov 2016 16:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org 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 O2dO9Hq8csUl; Wed, 2 Nov 2016 16:24:00 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (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 9F3F7129677; Wed, 2 Nov 2016 16:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=uv82srWeGG+H04UDJ5i4Ktp77deWz9lQ4hSY5/uIbCI=; b=w+fYPOuzocdNkwOHK1Q7vNv+u+iK//0zABI38RH6x/NS3wMSKu8irZUsgtCYsCYCKCLT1CKqPbRFWo6OXrick+JY0KiubprDq4ak1951MAqfcd901AV2bca2FKacmh/SnOmHlVCQ6KNDaoyPXiAt2uvB6vg9FwF7QjP8w6oy63k=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84_2) (envelope-from ) id 1c24sw-0004P7-QX; Wed, 02 Nov 2016 23:23:58 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 83736C00A04; Wed, 2 Nov 2016 19:23:57 -0400 (EDT) Date: Wed, 2 Nov 2016 19:23:57 -0400 From: Theodore Ts'o To: Brandon Long Message-ID: <20161102232357.b55vx7est7vjrdfo@thunk.org> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: Cc: Michael Richardson , "dmarc@ietf.org" , IETF , Cullen Jennings Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 23:24:02 -0000 On Wed, Nov 02, 2016 at 02:58:31PM -0700, Brandon Long wrote: > If this is a problem for you as a receiver, you can choose to attempt to > whitelist the ietf mailing list mail from DMARC enforcement. You may not > be able to do so, just like the sender may not be able to change their > organizations DMARC record. > > The middle man, ietf, can work around this today. They need to run a new > enough version of mailman and enable one of the workarounds. For mailman, > this means munging the mail, usually the From header. It's not pretty, but > it works, it works now, and it will work for everyone. The difference is > mostly cosmetic, though depending on your mail client, there may be other > downsides. And it may violate RFC 5322. > > I don't think this is possible with mailman, but theoretically it is also > possible for a mailing list to pass the message through without breaking > the DKIM signature. This means no footers and no subject tags. Which of > these a list would choose is probably dependent on the list members. > > mailman should also know how to tell the difference between a message > specific policy bounce, and particular DMARC bounces, and should apply > different heuristics to handling them. I have no idea if that existing in > any version of mailman or is a planned feature. > > There is a proposed standard, ARC, that would allow mail receivers to do > more intelligent whitelisting. It's not ready yet. There is a third option --- which is that if you want to participate on certain mailing lists, you have to use a non-DMARC e-mail address. There are people with google.com addresses that need to use non-Google addresses in order to participate on the Linux Kernel Mailing List. On Wed, Nov 02, 2016 at 04:00:36PM -0600, Cullen Jennings wrote: > > So how do we get this fixed ? Has someone talked to the IESG about > this? Right now as a chair, I am making consensus calls that are > probably ignoring any emails from people from google.com - and other > - because I am not getting their email. That seems like a serious > process problem. I would expect that most folks at Google.com who need to interact with external communities are painfully aware of the DMARC brain-damage, and at least with respect to the Googlers who work on the Linux kernel, so it shouldn't be coming as a surprise. I would expect that it would easy to determine how many who are on DMARC-hobbled domains on the IETF working gorup mailing lists, and it should be easy to create tools to send last-call announcements to those people to at least solve the process problem. But given that at the IETF attendees represent themselves, and not their companies, if it means that people at certain companies need to get alternate e-mail arrangements, I don't think that's a fatal issue. It certainly hasn't bothered the LKML administrators, which has a similar "we're all engieners, not corporate representatives" ethos. Cheers, - Ted From nobody Wed Nov 2 17:36:54 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC28A129434; Wed, 2 Nov 2016 17:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikh0jQPshsdl; Wed, 2 Nov 2016 17:36:50 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0098.outbound.protection.outlook.com [104.47.40.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A7DD12968B; Wed, 2 Nov 2016 17:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rYgF3Bku8gD1JhD8OecsHjbG/U9CwZGYCXI7ddG9sjQ=; b=RecTv8A8rczcW737L4PfzbV+mHPl6EV4SvHtcUm/o38r0ciOtQ9GjQ52S+qNyCyWJmrkESSUzXMVuFF7ySkrSZV2FVrLAlz8NxzK9LeX2E/7EQJgNP14cGYFw/6H5TQdSWfLp73R5bmRgW3ypSUYmgn6/JFVt4ALdWCAV5gTn5c= Received: from CO2PR00MB0101.namprd00.prod.outlook.com (10.166.215.142) by CO2PR00MB0102.namprd00.prod.outlook.com (10.166.215.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.730.0; Thu, 3 Nov 2016 00:36:48 +0000 Received: from CO2PR00MB0101.namprd00.prod.outlook.com ([10.166.215.142]) by CO2PR00MB0101.namprd00.prod.outlook.com ([10.166.215.142]) with mapi id 15.01.0730.000; Thu, 3 Nov 2016 00:36:48 +0000 From: Terry Zink To: "dmarc@ietf.org" , IETF Thread-Topic: [dmarc-ietf] IETF Mailing Lists and DMARC Thread-Index: AQHSNSJH3BjQyfeJdkSCE1IATqnOyqDGDISAgAAxtoCAABffgIAAExVw Date: Thu, 3 Nov 2016 00:36:47 +0000 Message-ID: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> In-Reply-To: <20161102232357.b55vx7est7vjrdfo@thunk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [75.165.54.109] x-ms-office365-filtering-correlation-id: 90e41db0-7aaa-4fbc-6579-08d403817edc x-ms-office365-filtering-ht: Tenant x-microsoft-exchange-diagnostics: 1; CO2PR00MB0102; 7:OeVyIPrv3IQ6OyyxcLvIpAuuWeV4Kn3un1WvkSHbrwuyELzOhzXQYDP9JJThi6egfXdRUm+A25OwQZjjnm1TqWZn0IE+YId2XwJgEv5imD2ULJ6cNf6K+F2y88Tcjca8bzBfTbM3qpKhi+pYqpMxN9p0LQxFHGTvsVXGoZDrilrT9LyXHpNuK1G0GRBZ6XE0WZvy/ssFjpyEhb3SZKC7vwpC5priivFOBM+yikfac1CJP/UF82yMrighv98xsdpAVGr4FWbBlis/NXMTJKcicIoMtIj3r5R2q0328N56srCAxapYytq9iLwEflvqtuDfPSPyIN2y25OLsuzafmWRFHp9QlmGiQybvaw3iTidO7pcWORYSbONDL345HBlG7hO x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR00MB0102; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6040176)(6060210)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(100007014)(6061207)(6046074)(6072074)(6047074); SRVR:CO2PR00MB0102; BCL:0; PCL:0; RULEID:; SRVR:CO2PR00MB0102; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(5002640100001)(97736004)(76576001)(50986999)(5001770100001)(76176999)(54356999)(15975445007)(77096005)(2900100001)(66066001)(450100001)(101416001)(93886004)(86362001)(189998001)(19580395003)(107886002)(122556002)(2501003)(7736002)(7846002)(305945005)(33656002)(106356001)(74316002)(3280700002)(105586002)(81156014)(81166006)(8676002)(99286002)(3660700001)(7696004)(9686002)(8936002)(102836003)(5660300001)(42882006)(2950100002)(68736007)(87936001)(6116002)(586003)(11100500001)(10090500001)(3846002)(10290500002)(106116001)(5005710100001)(8990500004)(2906002)(10400500002)(92566002)(197153002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR00MB0102; H:CO2PR00MB0101.namprd00.prod.outlook.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 03 Nov 2016 00:36:47.9229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0102 Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 00:36:53 -0000 >> There is a proposed standard, ARC, that would allow mail receivers to=20 >> do more intelligent whitelisting. It's not ready yet. > There is a third option --- which is that if you want to participate on c= ertain=20 > mailing lists, you have to use a non-DMARC e-mail address. There are peop= le=20 > with google.com addresses that need to use non-Google addresses in order = to=20 > participate on the Linux Kernel Mailing List. I've seen comments that people who were on Yahoo can fortunately go to Gmai= l. What happens when Gmail publishes a p=3Dreject like they said they were = going to (even if the timeline is delayed), per https://wordtothewise.com/2= 015/10/dmarc-news-gmail-preject-and-arc/? Perhaps people can go to Outlook.com? What happens if they go to DMARC p=3D= reject? Everyone can go an sign up for yet another domain? That just kicks the can down the road, but eventually that can will take no= more kicks. From nobody Wed Nov 2 20:12:28 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A7F1294C3 for ; Wed, 2 Nov 2016 20:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULX3MhTpfWAa for ; Wed, 2 Nov 2016 20:12:25 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229A21294DF for ; Wed, 2 Nov 2016 20:12:25 -0700 (PDT) Received: (qmail 98164 invoked from network); 3 Nov 2016 03:12:25 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Nov 2016 03:12:25 -0000 Date: 3 Nov 2016 03:12:13 -0000 Message-ID: <20161103031213.68333.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: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 03:12:26 -0000 >I've seen comments that people who were on Yahoo can fortunately go to Gmail. What happens when Gmail publishes a >p=reject like they said they were going to (even if the timeline is delayed), per >https://wordtothewise.com/2015/10/dmarc-news-gmail-preject-and-arc/? They have said multiple times that they won't do so until ARC is up and working. If they're lying, well, we're all schrod. >Perhaps people can go to Outlook.com? What happens if they go to DMARC p=reject? Everyone can go an sign up for yet >another domain? > >That just kicks the can down the road, but eventually that can will take no more kicks. Indeed. We look forward to hotmail/outlook implementing ARC so your users can resume using mailing lists the way they have for 30 years or more. R's, John From nobody Wed Nov 2 20:30:46 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780BE129851 for ; Wed, 2 Nov 2016 20:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hSDqFAEp3L0 for ; Wed, 2 Nov 2016 20:30:44 -0700 (PDT) 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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B21129894 for ; Wed, 2 Nov 2016 20:30:44 -0700 (PDT) Received: (qmail 5911 invoked from network); 3 Nov 2016 03:30:43 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Nov 2016 03:30:43 -0000 Date: 3 Nov 2016 03:30:31 -0000 Message-ID: <20161103033031.68374.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: mellon@fugue.com Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 03:30:45 -0000 >Belittling people who are arguing that a long-standing problem needs >to be fixed is not appropriate. We all agree that the problem needs to be fixed, but many of us believe we have a duty to try to understand a problem before demanding "solutions" which would cause at least as many problems as they solve. >>FWIW, I use Google For Work (or whatever it's called this week) and it >>doesn't automatically add DMARC headers-- You could solve your DMARC problems overnight by switching to a mail provider that doesn't throw away mailing list mail that you want. Fastmail would be a good place to look, competent and cheap. R's, John From nobody Thu Nov 3 02:21:38 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC42D129420 for ; Thu, 3 Nov 2016 02:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 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_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu 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 1QOmp0ydLvc0 for ; Thu, 3 Nov 2016 02:21:34 -0700 (PDT) Received: from linode.junc.eu (linode.junc.eu [IPv6:2a01:7e00:e000:146::2]) (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 EE9A81293FC for ; Thu, 3 Nov 2016 02:21:33 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by localhost.junc.eu (Postfix) with ESMTP id 5F41A1BF080 for ; Thu, 3 Nov 2016 09:21:30 +0000 (GMT) X-Spam-ASN: X-Spam-dcc_result: X-Spam-Uri-Domains: iii.ca ietf.org Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by linode.junc.eu (Postfix) with ESMTPSA id 2F0571BE0C9 for ; Thu, 3 Nov 2016 09:21:30 +0000 (GMT) X-Virus-Status: Clean DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=junc.eu; s=default; t=1478164890; x=1478596890; bh=O69hyGWMAhFQGRplimwnIkMhqEO55WrYaZCNne4xEC0=; h=Date:From:To:Subject:In-Reply-To:References; b=J+BeXpkFXvGDQJrhO7RkHVPMpE8todU9iJi97e7M4gzfxWbaWlbbQVg0wlkzgpNZT VhHnUXIwzBgBiOcOHbZGgnOxSEqOrBhCI73wNxX7cMEjtRXTCIBlcfycHglK2XKf26 PZHTKMYsOGsd2ncqhyrK1xCNp34V8q/Ysn2NABrs= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 03 Nov 2016 10:21:30 +0100 From: Benny Pedersen To: dmarc@ietf.org Organization: Jersore Underground Network Center In-Reply-To: <81242B03-803E-4ECD-9131-B301CA932CA5@iii.ca> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <81242B03-803E-4ECD-9131-B301CA932CA5@iii.ca> Message-ID: <9d344bec2f31e63bc3c9303bb6919a71@junc.eu> X-Sender: me@junc.eu User-Agent: Roundcube Webmail/1.2.0 Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:21:36 -0000 Cullen Jennings skrev den 2016-11-02 23:00: > So how do we get this fixed ? Has someone talked to the IESG about > this? Right now as a chair, I am making consensus calls that are > probably ignoring any emails from people from google.com - and other - > because I am not getting their email. That seems like a serious > process problem. Authentication-Results: linode.junc.eu; dmarc=none header.from=iii.ca Authentication-Results: linode.junc.eu; dkim=pass (1024-bit key; secure) header.d=ietf.org header.i=@ietf.org header.b=RihtPNGu; dkim-atps=neutral there is no problem as long no one breaks dkim try dkim sign iii.ca if i get dmarc pass back here its working as designed, but if its dmarc fail, ietf.org breaks dkim this is so to say, you should whitelist maillist that breaks dkim so you never reject it From nobody Thu Nov 3 02:30:23 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87960129878; Thu, 3 Nov 2016 02:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 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_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu 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 xStiOT9cHSQg; Thu, 3 Nov 2016 02:30:18 -0700 (PDT) Received: from linode.junc.eu (linode.junc.eu [IPv6:2a01:7e00:e000:146::2]) (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 572861297C5; Thu, 3 Nov 2016 02:30:16 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by localhost.junc.eu (Postfix) with ESMTP id ED67A1BF087; Thu, 3 Nov 2016 09:30:14 +0000 (GMT) X-Spam-ASN: X-Spam-dcc_result: X-Spam-Uri-Domains: ietf.org Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by linode.junc.eu (Postfix) with ESMTPSA id BAB1D1BE0C9; Thu, 3 Nov 2016 09:30:14 +0000 (GMT) X-Virus-Status: Clean DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=junc.eu; s=default; t=1478165414; x=1478597414; bh=n6k31060urOvQlOCnd+yzs3cMBCFXbpGFo1yGIBzK+I=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=RCuu4IZ71sqDD7BAvSDXlx0ZQcepWdjZLpVJ526oI0E0lclc6PAa6Zyn1brmoWV9T aojE3GpkoT/Fjutlx8QCm8iQup+S3PjsXQAahXaZMXOX5jkyPk+XAhpHz3QDjCwzFo 7CfuYUxj+XYbePmE0V4vWCiZUBLSjJ76Bhn6s2Tk= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 03 Nov 2016 10:30:14 +0100 From: Benny Pedersen To: dmarc@ietf.org Organization: Jersore Underground Network Center In-Reply-To: <9d344bec2f31e63bc3c9303bb6919a71@junc.eu> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <81242B03-803E-4ECD-9131-B301CA932CA5@iii.ca> <9d344bec2f31e63bc3c9303bb6919a71@junc.eu> Message-ID: X-Sender: me@junc.eu User-Agent: Roundcube Webmail/1.2.0 Archived-At: Cc: abuse@ietf.org, postmaster@ietf.org Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 09:30:21 -0000 Benny Pedersen skrev den 2016-11-03 10:21: > Cullen Jennings skrev den 2016-11-02 23:00: > there is no problem as long no one breaks dkim Authentication-Results: linode.junc.eu; dmarc=none header.from=junc.eu Authentication-Results: linode.junc.eu; dkim=pass (1024-bit key; secure) header.d=ietf.org header.i=@ietf.org header.b=bXpPFfNS; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=junc.eu header.i=@junc.eu header.b=J+BeXpkF; dkim-atps=neutral sure breaks dkim signed mails :( From nobody Thu Nov 3 04:30:50 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0C91297C1 for ; Thu, 3 Nov 2016 04:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 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_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu 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 nc2EeRVLhvHc for ; Thu, 3 Nov 2016 04:30:45 -0700 (PDT) Received: from linode.junc.eu (linode.junc.eu [176.58.121.172]) (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 343E812948A for ; Thu, 3 Nov 2016 04:30:45 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by localhost.junc.eu (Postfix) with ESMTP id BF29D1BE467 for ; Thu, 3 Nov 2016 11:30:42 +0000 (GMT) X-Spam-ASN: X-Spam-dcc_result: X-Spam-Uri-Domains: ietf.org isdg.net winserver.com Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by linode.junc.eu (Postfix) with ESMTPSA id 8BEF91BE372 for ; Thu, 3 Nov 2016 11:30:42 +0000 (GMT) X-Virus-Status: Clean DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=junc.eu; s=default; t=1478172642; x=1478604642; bh=7wtLpyB6XQeElnXZ/0ZqXcX1XY27yQ6aho59Y51teMk=; h=Date:From:To:Subject:In-Reply-To:References; b=SA+UPYqbpQwjdJrbDrfSHGYzWVVowOJNQWlYJ1OqfII5I5hyb85XvmMdMSB6O0L+3 BkZJ00gkUKiwxnwPlWosr5KLxdnMvGVHSPWBBiLF1Q8lKG8nAkOQocDFOOczzciFIh S60rxLGRHIZUjbGSVtWsxEjFIeRbVV6pY/lTVMN8= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 03 Nov 2016 12:30:42 +0100 From: Benny Pedersen To: dmarc@ietf.org Organization: Jersore Underground Network Center In-Reply-To: <581A46FA.6040001@isdg.net> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <581A46FA.6040001@isdg.net> Message-ID: <7f79d5b1d56ab163963ae44436eafd65@junc.eu> X-Sender: me@junc.eu User-Agent: Roundcube Webmail/1.2.0 Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 11:30:50 -0000 Hector Santos skrev den 2016-11-02 21:05: > ADSP/ATPS actually works very well. Its been in production for a > number of years. I have "ietf.org" as a 3rd party signer assigned to > my ATPS records in DNS. Supportive receivers can then see that I > authorize ietf.org to sign my IETF submissions as my receivers do when > I get a copy. My ADSP record for isdg.net is: > > dkim=all; atps=y; > asl=ietf.org,beta.winserver.com,santronics.com,isdg.net,winserver.com,megabytecof > fee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;" > Authentication-Results: linode.junc.eu; dmarc=none header.from=isdg.net Authentication-Results: linode.junc.eu; dkim=pass (1024-bit key; secure) header.d=ietf.org header.i=@ietf.org header.b=vqpaROA9; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=isdg.net header.i=@isdg.net header.b=twhXt8L/; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=beta.winserver.com header.i=@beta.winserver.com header.b=ubq9bnhD; dkim-atps=neutral so it works ? From nobody Thu Nov 3 06:49:24 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49075129612; Thu, 3 Nov 2016 06:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org 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 GKladrLEfksb; Thu, 3 Nov 2016 06:49:16 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (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 38FD41296D0; Thu, 3 Nov 2016 06:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=H2AGTeZMY6Wg2cQjK+GvDbtayWMwW6/E12KIW37lZvg=; b=FvrcNHjEwlMZsYaySnyykec0j4r5nfraUUYflbkk7GPPjfvE90cVuVGlXw4vVUkqBH+KK6rSjxyd5VhPHc0s3jDEMHxINBcM9hpxvEo0QoKtMlG7U25IOwHDNMBQKTXkNR0pNaax3QNrrpsv1rkgArK5EG95Hkh6FI+YPj1ya0s=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84_2) (envelope-from ) id 1c2IOE-0007IO-Mu; Thu, 03 Nov 2016 13:49:10 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 39FE9C00F4F; Thu, 3 Nov 2016 09:49:09 -0400 (EDT) Date: Thu, 3 Nov 2016 09:49:09 -0400 From: Theodore Ts'o To: Terry Zink Message-ID: <20161103134909.lnndzi6feaqfskyj@thunk.org> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 13:49:18 -0000 On Thu, Nov 03, 2016 at 12:36:47AM +0000, Terry Zink wrote: > > There is a third option --- which is that if you want to participate on certain > > mailing lists, you have to use a non-DMARC e-mail address. There are people > > with google.com addresses that need to use non-Google addresses in order to > > participate on the Linux Kernel Mailing List. > > I've seen comments that people who were on Yahoo can fortunately go > to Gmail. What happens when Gmail publishes a p=reject like they > said they were going to (even if the timeline is delayed), per > https://wordtothewise.com/2015/10/dmarc-news-gmail-preject-and-arc/? > > Perhaps people can go to Outlook.com? What happens if they go to > DMARC p=reject? Everyone can go an sign up for yet another domain? > > That just kicks the can down the road, but eventually that can will > take no more kicks. And then developers can move to fastmail.fm; there are quite a few mail providers, after all. And I would expect market forces, combined with mail providers who aren't trying to send official bills to consumers that can be easily phished from the same domain as their customers, such that there will probably be at least one mail provider that will meet the need of developers and other people who need traditional mailing lists as they have been implemented for decades. Alternatively, hopefully ARC will become ready before this is an issue. At least a few of the major mail providers have said they won't enable p=reject until ARC has had a chance to be deployed, probably because they don't want to have a wholesale (or high profile) defections from their mail service to providers such as fastmail.fm. Regards, - Ted From nobody Thu Nov 3 08:20:20 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2949129A7E for ; Thu, 3 Nov 2016 08:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.499 X-Spam-Level: X-Spam-Status: No, score=-8.499 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_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junc.eu 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 zp8eZ5nIwRU9 for ; Thu, 3 Nov 2016 08:20:18 -0700 (PDT) Received: from linode.junc.eu (linode.junc.eu [176.58.121.172]) (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 7EEBF129A2C for ; Thu, 3 Nov 2016 08:20:18 -0700 (PDT) Received: from localhost.junc.eu (localhost.junc.eu [127.0.0.1]) by localhost.junc.eu (Postfix) with ESMTP id 7BB251BE37B for ; Thu, 3 Nov 2016 15:20:16 +0000 (GMT) X-Spam-ASN: X-Spam-dcc_result: X-Spam-Uri-Domains: _URIDOMAINS_ Received: from localhost.junc.eu (localhost.junc.eu [IPv6:::1]) by linode.junc.eu (Postfix) with ESMTPSA id 4C0331BE0B0 for ; Thu, 3 Nov 2016 15:20:16 +0000 (GMT) X-Virus-Status: Clean DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=junc.eu; s=default; t=1478186416; x=1478618416; bh=CarCKSUFfwzfxuIeI67qAbfR1pOG2LhDEvJ3Luvb2kk=; h=Date:From:To:Subject:In-Reply-To:References; b=1QojjywcZVETYoAiQhkTWq4AnL+7/LsVJ7Elmk+m4vsmZRWRpcr7GMMWRyEHwcZYx K0aWsLCGBy7nBm521DWN+vgbcq3Iak4rmqizWfo6BrN/m/LWRyEbNqYGZJuz8Neb8G Vr5KcYE36k3YPhDUjEr8DyKyuHq6VOzEFi0bsYT0= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 03 Nov 2016 16:20:16 +0100 From: Benny Pedersen To: dmarc@ietf.org Organization: Jersore Underground Network Center In-Reply-To: <20161103031213.68333.qmail@ary.lan> References: <20161103031213.68333.qmail@ary.lan> Message-ID: <8baf647d497e3eb1af82fef50a9d4ca6@junc.eu> X-Sender: me@junc.eu User-Agent: Roundcube Webmail/1.2.0 Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:20:20 -0000 John Levine skrev den 2016-11-03 04:12: > Indeed. We look forward to hotmail/outlook implementing ARC so your > users can resume using mailing lists the way they have for 30 years or > more. waiting for ARC to solve something that is only a problem on maillists that break DKIM, whats next ? i see no problem on postfix maillist with dmarc pass, so why have others choiced a route of fails ? limit opendkim to only verify last signer could be a option, if last signer signs all mails, atleast dkim pass fron every mail here, but i dont like that route From nobody Thu Nov 3 08:30:54 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E230C12955D for ; Thu, 3 Nov 2016 08:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lu5hRYtw0F9 for ; Thu, 3 Nov 2016 08:30:51 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE491294EA for ; Thu, 3 Nov 2016 08:30:51 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id d2so33586251pfd.0 for ; Thu, 03 Nov 2016 08:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Or4lHlxIfhikk1fD42AywpKH33cM3GjuOjAGepXhOuU=; b=GgwchwodXhRz16vvyJa8xrdBtqFV9eZLtasFnHPqVIWpD0mOKwP8TUZzY/lPqyM5ZX NSANdn89vkr/ilxqK7uuOtdPjiViUB+OGnkI0aXdmhNCV3Ki7iHjpJzb26hsaJI8SNMB AdTQSR+AhJPFBRww65uNjCDraFy/NlPOkI7T64dT/XBJac1ZiJ4XafGSaGfmnTasZrio 6EHySJIvejjJ7O5JPqqzlo+1aNYJ8Z+ZOtSR1OfBEWWXWbPpqZXZSCH0yCvAauzUbhWv oZsKHYHLmk5OyJv57lg/on15Mbx8atV1K8KmdWaPqeQDNmybBobNwob9bw+GeZ9rRk0n YXuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:reply-to:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Or4lHlxIfhikk1fD42AywpKH33cM3GjuOjAGepXhOuU=; b=dLwj+3XmAge6jKVkQB8eTSDylKKRsZBNl9ri/fVmA2oG8nxmKVCGoB3qdY8xDlamFE kWboVqiKRTc1NXgGBW7CR98eA9Lc6HZdlBZnfQz4+N4U4Sr4IlZPlytQLvKYFFWvPQb5 xRnV4+nvh+tyzP8GvwDxgJ/yzq7MJwW8N2OUs6LX4g2Azka12HSKheY+oBwRT0bwBrZ+ FbxqjlPiE9D4xseFWn3tbzZ2CLDEctcU4EDe1rcjbpal6GncT2hYLBdCFhumvCe+wgJj LzwwNn/umcjsRDpVU3NclSTxw4BgR5hi5NI+Y0xuWzymGzrxKfk8VDYnu8KxXf4yVM9F 6AwA== X-Gm-Message-State: ABUngveTaJK+yvVLZYSWvKMToJWxMiVZ9zhvZP4URADvSJosBvLuy1yOXbvsszGXtjfFRA== X-Received: by 10.99.94.196 with SMTP id s187mr14838361pgb.107.1478187049953; Thu, 03 Nov 2016 08:30:49 -0700 (PDT) Received: from ?IPv6:2602:304:cda0:8800:9128:d0e7:8269:c31a? ([2602:304:cda0:8800:9128:d0e7:8269:c31a]) by smtp.gmail.com with ESMTPSA id 128sm13669582pfy.4.2016.11.03.08.30.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 08:30:49 -0700 (PDT) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Benny Pedersen , dmarc@ietf.org References: <20161103031213.68333.qmail@ary.lan> <8baf647d497e3eb1af82fef50a9d4ca6@junc.eu> Organization: Brandenburg InternetWorking Message-ID: Date: Thu, 3 Nov 2016 08:30:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8baf647d497e3eb1af82fef50a9d4ca6@junc.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net 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, 03 Nov 2016 15:30:53 -0000 On 11/3/2016 8:20 AM, Benny Pedersen wrote: > limit opendkim to only verify last signer could be a option, if last > signer signs all mails, atleast dkim pass fron every mail here, but i > dont like that route this would have no effect on dmarc analysis, other than perhaps increasing the rate of failures. again, the issue is with dmarc. dkim is, at best, a secondary issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Nov 3 08:54:11 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB7B129A90 for ; Thu, 3 Nov 2016 08:54:10 -0700 (PDT) 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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=oJA56jEC; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=uFmgYAde 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 Zs_WEQDMjwCr for ; Thu, 3 Nov 2016 08:54:07 -0700 (PDT) Received: from winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 513BC129A9E for ; Thu, 3 Nov 2016 08:53:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3518; t=1478188422; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=5zOfGYjfLx75af81FmB0rEk6DC8=; b=oJA56jECp6nStlWpaJBHWPHJFLGjPiO3RHzd+QtSjImXiZcz+WSS0MKudx5ZzD hyAyvitbMy962FLU+rZFz/uyHge6bAuduzXFakFcRF1TqnOfuoqyjyoUiEe3qJmH jkOizpMpo5exvYyGj+GpXm45BBjZ7qVSah4IyZf/hUwrE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Thu, 03 Nov 2016 10:53:42 -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; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 676932726.1.5768; Thu, 03 Nov 2016 10:53:41 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3518; t=1478188411; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=wCXmLsz RcJjUK9KW9N0FWis0uJglOk4tk7WmVnEOqmA=; b=uFmgYAdewrhJtNKTVjpetDC CP/RhL1nfpH/9FGMKUS7gRwnl0vIaEostT+W/NeWJptOdqBbE/mtj6smixlzQ4jX tvt6Lj8o+DG6KRKXHnhjX78cq48qZMtV67qB4fqrlQFCrEmVmKxlUOVUr8QdZ9VQ Qkb1iA4vp1NBiK5pNS7Y= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Thu, 03 Nov 2016 11:53:31 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 132490921.9.34264; Thu, 03 Nov 2016 11:53:30 -0400 Message-ID: <581B5D86.5080406@isdg.net> Date: Thu, 03 Nov 2016 11:53:42 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Benny Pedersen , dmarc@ietf.org References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <581A46FA.6040001@isdg.net> <7f79d5b1d56ab163963ae44436eafd65@junc.eu> In-Reply-To: <7f79d5b1d56ab163963ae44436eafd65@junc.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 15:54:10 -0000 On 11/3/2016 7:30 AM, Benny Pedersen wrote: > Hector Santos skrev den 2016-11-02 21:05: > >> ADSP/ATPS actually works very well. Its been in production for a >> number of years. I have "ietf.org" as a 3rd party signer assigned to >> my ATPS records in DNS. Supportive receivers can then see that I >> authorize ietf.org to sign my IETF submissions as my receivers do when >> I get a copy. My ADSP record for isdg.net is: >> >> dkim=all; atps=y; >> asl=ietf.org,beta.winserver.com,santronics.com,isdg.net,winserver.com,megabytecof >> >> fee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;" >> > > Authentication-Results: linode.junc.eu; dmarc=none header.from=isdg.net > Authentication-Results: linode.junc.eu; > dkim=pass (1024-bit key; secure) header.d=ietf.org > header.i=@ietf.org header.b=vqpaROA9; > dkim=fail reason="signature verification failed" (1024-bit key; > unprotected) header.d=isdg.net header.i=@isdg.net header.b=twhXt8L/; > dkim=fail reason="signature verification failed" (1024-bit key; > unprotected) header.d=beta.winserver.com header.i=@beta.winserver.com > header.b=ubq9bnhD; > dkim-atps=neutral > > so it works ? yes. So, my original isdg.net message was submitted to my beta.winserver.com submission server. It was DKIM signed (d=beta.winserver.com) which then gets routed to my isdg.net machine, signed again (d=isdg.net) and sent to ietf.org. The ietf.org list manager destroys my submission integrity by changing the subject line, adds a footer, etc, as most list systems has done for many years, thus destroying the first two DKIM signatures. The DKIM compatible LIST server then properly resigns with d=ietf.org as we want all list servers to do when they destroy data as long as the original signatures were valid before it does so (but I doubt the IETF list server has that logic). It just blindly resigns and begins to distribute the mail. Now it gets to a list downlink receiver with ADSP/ATPS support. The receiver sees at least one valid signature, d=ietf.org and checks the isdg.net author domain ADSP/ATPS record to see if ietf.org is authorized. If ietf.org was not in the short asl= list, a ATPS record lookup is done for in the author-domain zone: atps-hash("ietf.org").author-domain yes, it works very well. The concern has always been how do you "learn" your personal community of "authorized" 3rd party domains who are allowed to sign on your author domain behalf. We (or at least I) have called that the "registration" problem. So it has a scale issue, but I think it definitely works for the small to mid size individual and/or organization which is the majority of the market place. I would like to see adding support to the DMARC record for ATPS support, i.e. "atps=" and possible also an option for a short "asl=domain list." ATPS was an add-on for the then "proposed standard" but not abandoned ADSP proposal. DMARC had effectively replaced "ADSP" but oddly it decided to not deal with the 3rd party signer designs leaving us in limbo for many years and hence the problem you are seeing today. I added ATPS support to my DMARC implementation, so my DMARC record has: v=DMARC1; p=none; atps=y; rua=mailto:dmarc-rua@isdg.net; ruf=mailto:dmarc-ruf@isdg.net;" with the "atps=y" tag and I can attest that after a few years, there is no DMARC processor breakage that I am aware of using the "foreign" extension tag as DMARC allows per specification. -- HLS From nobody Thu Nov 3 09:30:34 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB5129648 for ; Thu, 3 Nov 2016 09:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRHlZJBRQtcs for ; Thu, 3 Nov 2016 09:30:30 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0095.outbound.protection.outlook.com [104.47.42.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5801C12963A for ; Thu, 3 Nov 2016 09:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3OTeaLBQquE5oFBlPZChlGr6UK09Ks4bg9djweMWx8Q=; b=ZtxIInYl/oxqB23RIDQ0dlI3Mf0NZSOB4JSkMWiBPwAYnUn4Zhpo5rxjVnaI9vFZNY6dNFJtH1pXaHhfnM06joL/oKsYKCpjsnrx5JO2bkiPlBbRuFlLiHpPIAr/b9dl5uJEpYCmmfkNBkC+jBO04r4v6w7yZZwLjUzwsDlYXUQ= Received: from CO2PR00MB0101.namprd00.prod.outlook.com (10.166.215.142) by CO2PR00MB0101.namprd00.prod.outlook.com (10.166.215.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.732.0; Thu, 3 Nov 2016 16:30:28 +0000 Received: from CO2PR00MB0101.namprd00.prod.outlook.com ([10.166.215.142]) by CO2PR00MB0101.namprd00.prod.outlook.com ([10.166.215.142]) with mapi id 15.01.0732.000; Thu, 3 Nov 2016 16:30:23 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] IETF Mailing Lists and DMARC Thread-Index: AQHSNSJH3BjQyfeJdkSCE1IATqnOyqDGDISAgAAxtoCAABffgIAAExVwgAAssoCAAN2aEA== Date: Thu, 3 Nov 2016 16:30:23 +0000 Message-ID: References: <20161103031213.68333.qmail@ary.lan> In-Reply-To: <20161103031213.68333.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:6::566] x-ms-office365-filtering-correlation-id: 2cfada56-c72e-4b82-adce-08d40406b62c x-ms-office365-filtering-ht: Tenant x-microsoft-exchange-diagnostics: 1; CO2PR00MB0101; 7:Xd1itgmtlkRDKp6xf+BJtlqnMSJXViPvCs20rscWJmZQE6ty7FHFWVHNyVusWBttThDhGj3oHERPBb2EadPhrhJXfLZ1HPvGlUZV6qzp279fwIQi7ZCFjv/DBB6dtmF6V3/52IrT90EJhmkNq5dWAYiescn9LUfODI8C8tOcc2wywePC76vDvi54bE/kASN0sLJMGwG3r1sajQ/ghHNbCoUvXNxPvf4q3+o2lKCEdldwfKKzlJTka04t9FvjWmksv4dPk4NE6oYYuGFBxQYejhbYM7PilaWF8UxJzSxuJ0hClV0XUOqZ/tzz3b5+JJ3AuvV5t7qhUQFpBtZXOVDnBwqSGN7rHIgEBp2h3jIWWkimg0u0qIrLzy+alvZu0jHp x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR00MB0101; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060211)(6045074)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6061208)(6047074)(6072074); SRVR:CO2PR00MB0101; BCL:0; PCL:0; RULEID:; SRVR:CO2PR00MB0101; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(10290500002)(87936001)(3660700001)(106116001)(8936002)(105586002)(106356001)(122556002)(9686002)(42882006)(2950100002)(6916009)(86362001)(5660300001)(110136003)(2351001)(7696004)(33656002)(76176999)(54356999)(101416001)(8676002)(81156014)(81166006)(1730700003)(5002640100001)(50986999)(3280700002)(92566002)(99286002)(74316002)(77096005)(8990500004)(76576001)(2900100001)(107886002)(6116002)(305945005)(189998001)(7736002)(68736007)(10090500001)(450100001)(2906002)(7846002)(2501003)(586003)(10400500002)(5005710100001)(102836003)(97736004)(5640700001)(197153002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR00MB0101; H:CO2PR00MB0101.namprd00.prod.outlook.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 16:30:23.6106 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0101 Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 16:30:32 -0000 Pj4gSSd2ZSBzZWVuIGNvbW1lbnRzIHRoYXQgcGVvcGxlIHdobyB3ZXJlIG9uIFlhaG9vIGNhbiBm b3J0dW5hdGVseSBnbyB0byANCj4+IEdtYWlsLiBXaGF0IGhhcHBlbnMgd2hlbiBHbWFpbCBwdWJs aXNoZXMgYSBwPXJlamVjdCBsaWtlIHRoZXkgc2FpZCB0aGV5IA0KPj4gd2VyZSBnb2luZyB0bz8N Cg0KPiBUaGV5IGhhdmUgc2FpZCBtdWx0aXBsZSB0aW1lcyB0aGF0IHRoZXkgd29uJ3QgZG8gc28g dW50aWwgQVJDIGlzIHVwIGFuZCB3b3JraW5nLiAgSWYgdGhleSdyZSBseWluZywgd2VsbCwgd2Un cmUgYWxsIHNjaHJvZC4NCg0KVGhpcyBtYWtlcyBpdCBwb3NzaWJsZSBmb3IgR21haWwgdG8gZ28g dG8gcD1yZWplY3QgYW5kIHNheSB0byBvdGhlcnMgIkhleSwganVzdCBkZXBsb3kgQVJDLiIgVGhl b3JldGljYWxseSB0aGF0IHdpbGwgd29yaywgYnV0IGluIHByYWN0aWNlIEkgaGF2ZSBteSBkb3Vi dHMgYmVjYXVzZToNCg0KMS4gSXQgcmVxdWlyZXMgYWxsIHRoZSBsaXN0IHNlcnZlcnMgb3V0IHRo ZXJlIHRvIGRlcGxveSBpdCwgYW5kIGdldHRpbmcgcGVvcGxlIHRvIHVwZ3JhZGUgc29mdHdhcmUg aXMgbm9uLXRyaXZpYWwNCjIuIEl0IHJlcXVpcmVzIGVtYWlsIHJlY2VpdmVycyB0byB2YWxpZGF0 ZSBBUkMuIEV2ZW4gaWYgYSBMaXN0IFNlcnZlciBkZXBsb3lzIGl0LCBpdCB3b24ndCBtYWtlIGEg ZGlmZmVyZW50IHVubGVzcyB3ZSBoYXZlIGNyaXRpY2FsIG1hc3Mgb2YgcmVjZWl2ZXJzIGFkb3B0 aW5nIGl0DQoNClNvLCBjZXJ0YWlubHkgR29vZ2xlICsgQU9MICsgWWFob28gKD8pICsgTWljcm9z b2Z0IGltcGxlbWVudGluZyBBUkMgaXMgZ3JlYXQsIGFuZCB0aGV5IGhhdmUgYSBsb3Qgb2YgbWFp bGJveGVzLCBidXQgaXQncyB1bmNsZWFyIHRoYXQgdGhlaXIgY292ZXJhZ2UgaXMgYnJvYWQgZW5v dWdoLiBJIHRoaW5rIHdlIHdpbGwgYmUgaW4gYSBoeWJyaWQgc3RhdGUgZm9yIGEgbG9uZyB0aW1l IHdoZXJlaW4gd2Ugd2lsbCBiZSBzdXBwb3J0aW5nIG11bHRpcGxlIHNvbHV0aW9ucyAtICgxKSBB UkMgZm9yIHRoZSBsb25nIHRlcm0sIGFuZCAoMikgc2tpcHBpbmcgRE1BUkMgZW5mb3JjZW1lbnQg Zm9yIGtub3duIG1haWxpbmcgbGlzdHMuDQoNCi0tVGVycnkNCg== From nobody Thu Nov 3 10:30:34 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F423B129A9E; Thu, 3 Nov 2016 10:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7gOIMHlX7cI; Thu, 3 Nov 2016 10:30:27 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0103.outbound.protection.outlook.com [104.47.37.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55DF6129A9F; Thu, 3 Nov 2016 10:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5LPFJDFC1ceStWfQFER1iA9fNy00q/2CQC0WZHKqOVY=; b=OYofWohr6FU8RXnbZ5hjwgNRYWmlfNFtnM9qz2jSEJ1+Gh0x99QyrZF+UFxWe7InaJVemrooJHpTrQoRb58p+JWtKaRd3Et7bn6XqQKUEqQ+EWWTjwu+auZUtegQHuVQD6TLZTYRd4vrQX405K6Mmb+I07j1rzmseTMu2mgRU7Q= Received: from CO2PR00MB0101.namprd00.prod.outlook.com (10.166.215.142) by CO2PR00MB0104.namprd00.prod.outlook.com (10.166.215.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.732.0; Thu, 3 Nov 2016 17:30:20 +0000 Received: from CO2PR00MB0101.namprd00.prod.outlook.com ([10.166.215.142]) by CO2PR00MB0101.namprd00.prod.outlook.com ([10.166.215.142]) with mapi id 15.01.0732.000; Thu, 3 Nov 2016 17:30:20 +0000 From: Terry Zink To: "dmarc@ietf.org" , IETF Thread-Topic: [dmarc-ietf] IETF Mailing Lists and DMARC Thread-Index: AQHSNSJH3BjQyfeJdkSCE1IATqnOyqDGDISAgAAxtoCAABffgIAAExVwgADep4CAADzIsA== Date: Thu, 3 Nov 2016 17:30:20 +0000 Message-ID: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> In-Reply-To: <20161103134909.lnndzi6feaqfskyj@thunk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:6::566] x-ms-office365-filtering-correlation-id: 02b8876b-2f1c-49d0-344e-08d4040f1600 x-ms-office365-filtering-ht: Tenant x-microsoft-exchange-diagnostics: 1; CO2PR00MB0104; 7:y8m6xLJfjmYjhMfZczOQ+OTG7Vi0ZeJ1+sKDaOBMU1iA/QSuTMgy55/bwLBmhtaiNpZOiQk4mmaLYTH9LtN2jLgP57MkAMTbuCdgkeB9kn1x1aDYSlMYY4jmmXqQD3D8KjU45/J/vcz5g+7+q05aS2bf/mYUroRqiiq/KcZjAMlDrSaSO7PN8q3cEAdptIV7QNlL6LF6+19X8nLDHt3I1BM5BzgxE61h1yHJ8jXCJENnRa+3UhUwA3GUpDQMMBMfXzngKBh1o03GKoDX8SJ62GEVEozJ753gCOQP9gMAMIMfrtrmAoqCUAyXiRQoPUFwIJSFRtT89AkWr+5fE2pL0UjV/WkroPT31zzR7o4KKmWs4XfS2+emghpBNdLXAn+L x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR00MB0104; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(6060213)(6045074)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(100007014)(6046074)(6061210)(6072074)(6047074); SRVR:CO2PR00MB0104; BCL:0; PCL:0; RULEID:; SRVR:CO2PR00MB0104; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(2501003)(33656002)(305945005)(86362001)(74316002)(7736002)(7846002)(189998001)(5001770100001)(54356999)(76176999)(97736004)(107886002)(102836003)(3660700001)(68736007)(101416001)(8990500004)(6116002)(8676002)(81166006)(81156014)(50986999)(76576001)(10290500002)(10400500002)(5005710100001)(106116001)(11100500001)(9686002)(450100001)(3280700002)(2900100001)(105586002)(99286002)(122556002)(77096005)(8936002)(92566002)(586003)(19580395003)(7696004)(2906002)(5660300001)(42882006)(87936001)(93886004)(106356001)(2950100002)(10090500001)(5002640100001)(197153002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR00MB0104; H:CO2PR00MB0101.namprd00.prod.outlook.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 03 Nov 2016 17:30:20.4573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0104 Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 17:30:29 -0000 >> Perhaps people can go to Outlook.com? What happens if they go to DMARC=20 >> p=3Dreject? Everyone can go an sign up for yet another domain? >>=20 >> That just kicks the can down the road, but eventually that can will=20 >> take no more kicks. > And then developers can move to fastmail.fm; there are quite a few mail p= roviders, after all. =20 > And I would expect market forces, combined with mail providers who aren't= trying to send=20 > official bills to consumers that can be easily phished from the same doma= in as their customers, > such that there will probably be at least one mail provider that will mee= t the need of developers=20 > and other people who need traditional mailing lists as they have been imp= lemented for decades. The average Internet user doesn't understand DMARC. The average person on a= n Internet mailing list doesn't understand DMARC either, and even the avera= ge tech person on a mailing list doesn't understand DMARC. All they know is= that their mailing list doesn't work, or that they have been unsubscribed.= Only people who work on DMARC understand DMARC. Asking the average person to switch their email address just so that they c= an participate in mailing lists isn't a solution. --Terry From nobody Thu Nov 3 10:56:38 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23314129ABE; Thu, 3 Nov 2016 10:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mT90S4jK-ZcT; Thu, 3 Nov 2016 10:56:32 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 1907E129546; Thu, 3 Nov 2016 10:56:32 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id x4so100403936oix.2; Thu, 03 Nov 2016 10:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T9kZtp8y30EaITi3SVlDCEbUGEWqTqB4iV5/o1w3feI=; b=UUqLiQN02sGEa4POTPSs5BZhVQgTP5U6bdnOG4zgeuzNSTwcDrYhVCy/rTliFeSvEz 9BQVHunkoNU85hBf2PgPxrlJnMlvxrxPjy3XbTL8VGAYUVXbU4nSI6J/gkIfcAGJyDeQ fAWGF+9qvHuZOaJUV4HGl++2pBMcEKINLovo6c8kkZp9JIslleJBTBqOsnd95Ozr4yhH sm/fzWZflz69jsYf3YisQhbhcrAuTg4iJv6mUruOPF4WjbW6ysXyzZtU1OBIN9gFfiJj yZ/FCQggTgQcOLlblIqRblTZivb1mZ24ayjy0Wf9H+RZUVDQkXFeYBrTlwSLUMI5W5Ka 3FDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T9kZtp8y30EaITi3SVlDCEbUGEWqTqB4iV5/o1w3feI=; b=EWgku9SAoI1j64ZLt2HpMYSyKW4PCxJPVkfnCGrXtOVduMjOLL0UECfYGGatr+HFLA LACkqafsWHcmlvHK7Nz32cvIUZXzQwCr4tVysQoQGVpIVds+9m6xjbZmc78or3Isc8XY 012C3YwXfvQdJ+WAgMIDs3TiYba2sBfvEW/gfnZSalF5rurzmSldcy78M7sd5PfLkNet bXPJbmrNZBVMrTqEv2i9Mmcp0bYbQbIqgQ8sPoWI6k6mRNEqaemVw5ubCm6hXkXun8t2 HawrPQTPicloPQd1H9zjQvvT+05Z/18VMMUhWRrgM6UiaFXm1d4SNBOAX3TBBsYz4Obe lCjQ== X-Gm-Message-State: ABUngvc6xvp6nXtUoGlxhKPCceqgZ3tgr/WU0Ee3gKfMetMaeBclub4BPfwLdNTEIagRkLy/qgESyjwZtNmPfg== X-Received: by 10.202.80.195 with SMTP id e186mr9369213oib.159.1478195791422; Thu, 03 Nov 2016 10:56:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.150.42 with HTTP; Thu, 3 Nov 2016 10:56:10 -0700 (PDT) In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> From: "Andrew G. Malis" Date: Thu, 3 Nov 2016 13:56:10 -0400 Message-ID: To: Terry Zink Content-Type: multipart/alternative; boundary=001a113adf2e0e6aa705406947a9 Archived-At: Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 17:56:37 -0000 --001a113adf2e0e6aa705406947a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 3, 2016 at 1:30 PM, Terry Zink wrote: > The average Internet user doesn't understand DMARC. The average person on > an Internet mailing list doesn't understand DMARC either, and even the > average tech person on a mailing list doesn't understand DMARC. All they > know is that their mailing list doesn't work, or that they have been > unsubscribed. Only people who work on DMARC understand DMARC. > > Asking the average person to switch their email address just so that they > can participate in mailing lists isn't a solution. > Three thumbs up on the last sentiment above - could you imagine saying to someone that you need to switch phone providers in order to reach certain recipients? And while my current use of gmail allows me to more or less get around DMARC list problems (although I need to check my incoming spam folder at least daily since mailing list DMARC failures send legitimate emails there), there=E2=80=99s no guarantee how long that will continue. And regarding Terry's previous paragraph, while I=E2=80=99m by no means an = expert on DMARC (or mailman for that matter), a bit of googling tells me that there are more recent versions of mailman than what the IETF is currently using that support DMARC mitigation. See, for example, http://www.spamresource.com/2016/09/dmarc-support-in-mailman.html . Cheers, Andy --001a113adf2e0e6aa705406947a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Nov 3, 2016 at 1:30 PM, Terry Zink <tzink@exchange.micr= osoft.com> wrote:
The average Intern= et user doesn't understand DMARC. The average person on an Internet mai= ling list doesn't understand DMARC either, and even the average tech pe= rson on a mailing list doesn't understand DMARC. All they know is that = their mailing list doesn't work, or that they have been unsubscribed. O= nly people who work on DMARC understand DMARC.

Asking the average person to switch their email address just so that they c= an participate in mailing lists isn't a solution.

Three thumbs up on the last sentimen= t above - could you imagine saying to someone that you need to switch phone= providers in order to reach certain recipients? And while my current use o= f gmail allows me to more or less get around DMARC list problems (although = I need to check my incoming spam folder at least daily since mailing list D= MARC failures send legitimate emails there), there=E2=80=99s no guarantee h= ow long that will continue.

And regarding Terry's previous paragraph, while I= =E2=80=99m by no means an expert on DMARC (or mailman for that matter), a b= it of googling tells me that there are more recent versions of mailman than= what the IETF is currently using that support DMARC mitigation. See, for e= xample, http://www.spamresource.com/2016/09/dmarc-support-in-mailman.htm= l .

Cheers,
Andy

--001a113adf2e0e6aa705406947a9-- From nobody Thu Nov 3 11:07:03 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F92129AC7; Thu, 3 Nov 2016 11:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTxgBwwXXW8q; Thu, 3 Nov 2016 11:07:00 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [IPv6:2001:470:1:6d::9a]) by ietfa.amsl.com (Postfix) with ESMTP id A0F66129695; Thu, 3 Nov 2016 11:06:59 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 4ED872337B; Thu, 3 Nov 2016 11:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1478196454; bh=CDoIASOi+2eVOvDjCkDsO9J5ScqlSCSBVvvI5e9BuOQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kDOzEvstP7TcupzD7ZbL2bBT9hvyReEtsvWQ/eDZzij8YXXDUOt7gKPTg6iNkR+tL miPby2kvxxWFNC5LdHG3s2rL5HfukdBtRnC/0RqKrqEUwEy63TIsFr//y9gEEcGknx LJdpok/PZ+i+aKPSpYXFPLtkvT/oqa0EX1yyekhc= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Steve Atkins In-Reply-To: Date: Thu, 3 Nov 2016 11:06:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 18:07:01 -0000 > On Nov 3, 2016, at 10:56 AM, Andrew G. Malis = wrote: >=20 >=20 > On Thu, Nov 3, 2016 at 1:30 PM, Terry Zink = wrote: > The average Internet user doesn't understand DMARC. The average person = on an Internet mailing list doesn't understand DMARC either, and even = the average tech person on a mailing list doesn't understand DMARC. All = they know is that their mailing list doesn't work, or that they have = been unsubscribed. Only people who work on DMARC understand DMARC. >=20 > Asking the average person to switch their email address just so that = they can participate in mailing lists isn't a solution. >=20 > Three thumbs up on the last sentiment above - could you imagine saying = to someone that you need to switch phone providers in order to reach = certain recipients? And while my current use of gmail allows me to more = or less get around DMARC list problems (although I need to check my = incoming spam folder at least daily since mailing list DMARC failures = send legitimate emails there), there=E2=80=99s no guarantee how long = that will continue. >=20 > And regarding Terry's previous paragraph, while I=E2=80=99m by no = means an expert on DMARC (or mailman for that matter), a bit of googling = tells me that there are more recent versions of mailman than what the = IETF is currently using that support DMARC mitigation. See, for example, = http://www.spamresource.com/2016/09/dmarc-support-in-mailman.html . "Mitigating the effects of the DMARC reject policy are difficult. All = known mitigation techniques break some user expectations and/or degrade = the user experience. Still, it's incumbent on the Mailman developers to = try to reduce the pain our users feel, and to provide some options for = site and list administrators who find themselves caught in the middle." dmarc@ietf.org, of all lists, is not one whose administrators are = "caught in the middle". Cheers, Steve= From nobody Thu Nov 3 11:25:09 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97295129452; Thu, 3 Nov 2016 11:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMytUtdZdlrd; Thu, 3 Nov 2016 11:25:04 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 51E34129697; Thu, 3 Nov 2016 11:25:04 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id v84so102383384oie.3; Thu, 03 Nov 2016 11:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VqyqDFfuntUPZFQiTaU/OK7zXu6qcxRljOzTXxlTRU4=; b=r41d6CQcs2L0FZnBx32G3r9p4Gn/4CtChznHkLfugGylBAw3Pxm8LwrKUfsEIXCZnK uOhYZgTCBZm7SZeh6QRfn6Fc0xuXWhEWt11QZgtd6Lw+x3a2bYGCUPFPtVrcfZViq75b LoYirUuNT3mC/GdD3qKKwvb1U000fSzX6PyF0Efi9wGr11/ycs39OkSGIycYGl4Gqh4G xpko/R83c8UnegU8/8mgzaD0Z8Hi0kuoFw8hqK4IUTWvShGtNFpPNQuvCTB3cz8cC1Bm csauQKoz1yWZijCXTQiEoMcdW/UPRknwPUXKzHxjibdExgRp/GrpSj6++0fnAxEl6cMb bnCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VqyqDFfuntUPZFQiTaU/OK7zXu6qcxRljOzTXxlTRU4=; b=Ah7bMj40Bxv72q3mQWrsIrqx/5/hng7/80prz6qYazfaoqhY7GL/i8aMfgsTevhtUj qnj6Md5Vd2GKWEcDCipnP582vjpli6T+aAT41IzwzG/wAEf4R2ozA47N5zjALuooRCua Vr9nl4vqGai7HBl2q5EflvgURErFrSFbXvM5pl9HyRsEnnCDgA03tFdW7gqUdE4jXH+L PIDQaJ+uG7HyZIq2Gx8GqLdBJpdqojXwm9+eroXVAZ7ASeujAO391yeDg4ST8xGw1ah4 kWbd8xeXTqP8lIzdY2NYCukoR5+IK0JH4nqCkpP/5INzgze3xQ7xn7041yU3Lgo+FxEr 8jww== X-Gm-Message-State: ABUngvcOOjyKqhm1TjxQ+vd1yaKJhNVkKVahMiEvqdy0rA9Cz+VypaBj1x/FFWl9c1AHITuAui8VFBQKu5l7cw== X-Received: by 10.157.20.225 with SMTP id r30mr7470693otr.148.1478197503748; Thu, 03 Nov 2016 11:25:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.150.42 with HTTP; Thu, 3 Nov 2016 11:24:43 -0700 (PDT) In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> From: "Andrew G. Malis" Date: Thu, 3 Nov 2016 14:24:43 -0400 Message-ID: To: Steve Atkins Content-Type: multipart/alternative; boundary=001a113cdada1e6fb3054069adec Archived-At: Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 18:25:06 -0000 --001a113cdada1e6fb3054069adec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Steve! The site goes on to say: "If you don't take any action here, you're leaving a subset of your potential subscribers out in the cold. Making them second class citizens, unable to participate in the mailing lists you're hosting. Be kind, and don't beat up Yahoo users because of a domain policy that Yahoo choose to implement (and that Yahoo user is stuck dealing with).=E2=80=9D I certainly agree with that sentiment. And it=E2=80=99s not the DMARC WG th= at's responsible for IETF email list support, it=E2=80=99s the admin staff at AM= S that are the ones =E2=80=9Ccaught in the middle=E2=80=9D. Cheers, Andy On Thu, Nov 3, 2016 at 2:06 PM, Steve Atkins wrote: > > > On Nov 3, 2016, at 10:56 AM, Andrew G. Malis wrote: > > > > > > On Thu, Nov 3, 2016 at 1:30 PM, Terry Zink > wrote: > > The average Internet user doesn't understand DMARC. The average person > on an Internet mailing list doesn't understand DMARC either, and even the > average tech person on a mailing list doesn't understand DMARC. All they > know is that their mailing list doesn't work, or that they have been > unsubscribed. Only people who work on DMARC understand DMARC. > > > > Asking the average person to switch their email address just so that > they can participate in mailing lists isn't a solution. > > > > Three thumbs up on the last sentiment above - could you imagine saying > to someone that you need to switch phone providers in order to reach > certain recipients? And while my current use of gmail allows me to more o= r > less get around DMARC list problems (although I need to check my incoming > spam folder at least daily since mailing list DMARC failures send > legitimate emails there), there=E2=80=99s no guarantee how long that will= continue. > > > > And regarding Terry's previous paragraph, while I=E2=80=99m by no means= an > expert on DMARC (or mailman for that matter), a bit of googling tells me > that there are more recent versions of mailman than what the IETF is > currently using that support DMARC mitigation. See, for example, > http://www.spamresource.com/2016/09/dmarc-support-in-mailman.html . > > "Mitigating the effects of the DMARC reject policy are difficult. All > known mitigation techniques break some user expectations and/or degrade t= he > user experience. Still, it's incumbent on the Mailman developers to try t= o > reduce the pain our users feel, and to provide some options for site and > list administrators who find themselves caught in the middle." > > dmarc@ietf.org, of all lists, is not one whose administrators are "caught > in the middle". > > Cheers, > Steve > --001a113cdada1e6fb3054069adec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Steve!

The site goes on to say:

"If you don't take any action here, you'r= e leaving a subset of your=20 potential subscribers out in the cold. Making them second class=20 citizens, unable to participate in the mailing lists you're hosting. Be= =20 kind, and don't beat up Yahoo users because of a domain policy that=20 Yahoo choose to implement (and that Yahoo user is stuck dealing with).=E2= =80=9D

I certainly agree with that sentiment. And = it=E2=80=99s not the DMARC WG that's responsible for IETF email list su= pport, it=E2=80=99s the admin staff at AMS that are the ones =E2=80=9Ccaugh= t in the middle=E2=80=9D.

Cheers,
Andy

On= Thu, Nov 3, 2016 at 2:06 PM, Steve Atkins <steve@wordtothewise.com<= /a>> wrote:
> On Nov 3, 2016, at 10:56 AM, Andrew G. Malis <agmalis@gmail.com> wrote:
>
>
> On Thu, Nov 3, 2016 at 1:30 PM, Terry Zink <tzink@exchange.microsoft.com> wrote:
> The average Internet user doesn't understand DMARC. The average pe= rson on an Internet mailing list doesn't understand DMARC either, and e= ven the average tech person on a mailing list doesn't understand DMARC.= All they know is that their mailing list doesn't work, or that they ha= ve been unsubscribed. Only people who work on DMARC understand DMARC.
>
> Asking the average person to switch their email address just so that t= hey can participate in mailing lists isn't a solution.
>
> Three thumbs up on the last sentiment above - could you imagine saying= to someone that you need to switch phone providers in order to reach certa= in recipients? And while my current use of gmail allows me to more or less = get around DMARC list problems (although I need to check my incoming spam f= older at least daily since mailing list DMARC failures send legitimate emai= ls there), there=E2=80=99s no guarantee how long that will continue.
>
> And regarding Terry's previous paragraph, while I=E2=80=99m by no = means an expert on DMARC (or mailman for that matter), a bit of googling te= lls me that there are more recent versions of mailman than what the IETF is= currently using that support DMARC mitigation. See, for example, http://www.spamresource.com/2016/09/= dmarc-support-in-mailman.html .

"Mitigating the effects of the DMARC reject policy are difficul= t. All known mitigation techniques break some user expectations and/or degr= ade the user experience. Still, it's incumbent on the Mailman developer= s to try to reduce the pain our users feel, and to provide some options for= site and list administrators who find themselves caught in the middle.&quo= t;

dmarc@ietf.org, of all lists, is not = one whose administrators are "caught in the middle".

Cheers,
=C2=A0 Steve

--001a113cdada1e6fb3054069adec-- From nobody Thu Nov 3 12:32:22 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9D91296F7 for ; Thu, 3 Nov 2016 12:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tana.it 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 tvWE-ZztbP3t for ; Thu, 3 Nov 2016 12:32:17 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F071296B2 for ; Thu, 3 Nov 2016 12:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1478201534; bh=b9g7oD4hA+VUqJg8cF3/SOzUTA/YPEVA9l9Q+42J68g=; l=911; h=To:References:From:Date:In-Reply-To; b=G5eiWNjuz9UHeSnzQVH0QhdH7kiWHV3wNr4+1dmGcg5622OmakcgkS856SCEoahri EnbDo+ronIRFdWtLdIXMYuz01TPDw3NThWRFPoEeDbhFQLed7H/XmJxazEpiSook1Q 0IjxXJzwWxogPlSi6PfoypmabUPKWzo6MaPaO3eE= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 03 Nov 2016 20:32:14 +0100 id 00000000005DC053.00000000581B90BE.0000317C To: dmarc@ietf.org References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <581A46FA.6040001@isdg.net> <7f79d5b1d56ab163963ae44436eafd65@junc.eu> <581B5D86.5080406@isdg.net> From: Alessandro Vesely Message-ID: <82a0525a-344c-7cfb-5a07-8cada1e544c0@tana.it> Date: Thu, 3 Nov 2016 20:32:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <581B5D86.5080406@isdg.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 19:32:20 -0000 On Thu 03/Nov/2016 16:53:42 +0100 Hector Santos wrote: > > The ietf.org list manager destroys my submission integrity by changing the > subject line, adds a footer, etc, as most list systems has done for many years, > thus destroying the first two DKIM signatures. That's the culprit, of course. Note that MLM does not change the subject if it already contains the tag. However, it adds a footer even if one exists. Since we talk of mailing list software capabilities, can't that be amended? Then, a MLM can require that p=reject domains submit "camera-ready" posts. Senders comply before signing, if they spot a ML among recipients. Isn't that solution simpler and more straightforward than ARC? It's also simpler than weak signatures. Was it aired, yet? Ale _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Nov 3 15:03:35 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04FF129861; Thu, 3 Nov 2016 15:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thunk.org 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 rLu7Oh9PSBMO; Thu, 3 Nov 2016 15:03:32 -0700 (PDT) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (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 AEAD8129717; Thu, 3 Nov 2016 15:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=bHtreXq0Ttdohh9aAkP2GHvUw93r7QM2m8k7P5ew9XU=; b=AkoIQcX6spSG8j8aQFBkD5pvfiHW3WUh3jeLjFfPH0oHlhjODRSRZ5cLISiLvhdnJoRi3WtB01/HDB75vVEpnP0jxlTYNtzRdTnmtGuDnCftX8FREzb3RO6JfHwe9/pblrQX2ZHWBtHlRlp6/chO9TOnA6Wi1GTv2UdCQW6VYQQ=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.84_2) (envelope-from ) id 1c2Q6Z-00031i-Fi; Thu, 03 Nov 2016 22:03:27 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 639BDC00072; Thu, 3 Nov 2016 18:03:26 -0400 (EDT) Date: Thu, 3 Nov 2016 18:03:26 -0400 From: Theodore Ts'o To: Terry Zink Message-ID: <20161103220326.jz2mtk6s7tvdg55v@thunk.org> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Archived-At: Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:03:34 -0000 On Thu, Nov 03, 2016 at 05:30:20PM +0000, Terry Zink wrote: > > The average Internet user doesn't understand DMARC. The average > person on an Internet mailing list doesn't understand DMARC either, > and even the average tech person on a mailing list doesn't > understand DMARC. All they know is that their mailing list doesn't > work, or that they have been unsubscribed. Only people who work on > DMARC understand DMARC. IETF contributers aren't exactly "the average Internet user"..... (Or are Linux Kernel contributors, since kernel.org is one of the other lists where your use of a domain that uses DMARC not considered the mailing list administrators' problem; and degrading everyone else's mailing list experience just for 'the average Internet user' is something they have chosen not to do.) > Asking the average person to switch their email address just so that > they can participate in mailing lists isn't a solution. It certainly isn't a long term solution; I think we all hope ARC can get successfully deployed soon. - Ted From nobody Thu Nov 3 15:39:28 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7710D129987 for ; Thu, 3 Nov 2016 15:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Mh4WIwFqCR for ; Thu, 3 Nov 2016 15:39:24 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 6C5F81294B9 for ; Thu, 3 Nov 2016 15:39:24 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id v84so116110468oie.3 for ; Thu, 03 Nov 2016 15:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I0akMsMo5Yq2tMOLvsqGEvXso8X47Nkek2KiXdvDpEk=; b=h5sNE1B5io4E0AOLsVnIt+NplAGYz6vbWwEGo6t0XJ3I6np3s+FydTrIXxnvnn3R42 sLyGrkKFqpXWy7R5dxnJztAH9cMy8kBvcuz/+OGCK5sH4in4lB+CRXwTKhKpVk7DwJB8 UDQha+1ESTt8yQPfutb7EcaES7ReMZ72+pznW448SOqsB3eIrPeR13JrDUtoAJMN8eCS xpDsA5f2IYOXtDU6KZBxW2i/kASKRy+v0g3vyLEThfVgvRm6si07YNUN7TYwMPet9Wd6 U1Srsmjfardux1g5yb7aWbQ9JrUGJjtgqzVCwpVYia+X1OnzPbmpdUJfbqR5bhJV646+ pUcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I0akMsMo5Yq2tMOLvsqGEvXso8X47Nkek2KiXdvDpEk=; b=K6ORWS++/zehHwOSB7TxQKufEXlY/QVT7Mu0/MOVzC4RGykSktCQWZfoZ3gcRcZ2ie njtEEEkH6xuqjtJi8pEq2Ffhhz9CCe6uwtZRls2LJrDAlfUo4gDjpwrU2hhAz/pcD8Sc gZwr9GN0tlWhCp7F+Q8svSe0HTk4med/VPUh9zhpXxIaGnGh7LdDuK9zNxKQr8229LD6 BkmirSZcTsHeLW4l5b02vTYi+/5MTM7UApjhBsIZo2LjX1r8cIiNUeoo4yFa5AaJemJw eIjubXpRNDF7qDvunvL5vW8KYD0O9gEkFxsb2Y5rjETTGYdQCHavZh1N6SBwo+FaLXzf TVrQ== X-Gm-Message-State: ABUngvccf7M+XI49W1g0dSi1Y9PVEnW5QWHCmNOm38JBTRPVKeZvj6XQgqZN1Q11YwVGKPDf0Eb4SgVf9qGYRxYl X-Received: by 10.157.6.7 with SMTP id 7mr8350685otn.43.1478212763634; Thu, 03 Nov 2016 15:39:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Thu, 3 Nov 2016 15:39:22 -0700 (PDT) In-Reply-To: <5c0220dd-20b6-5e8e-fe9c-b402675cc559@gmail.com> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <5c0220dd-20b6-5e8e-fe9c-b402675cc559@gmail.com> From: Brandon Long Date: Thu, 3 Nov 2016 15:39:22 -0700 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=94eb2c095f7aae743805406d3aaf Archived-At: Cc: Michael Richardson , "dmarc@ietf.org" , IETF , Cullen Jennings Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 22:39:26 -0000 --94eb2c095f7aae743805406d3aaf Content-Type: text/plain; charset=UTF-8 On Wed, Nov 2, 2016 at 3:19 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 03/11/2016 10:58, Brandon Long wrote: > > With the understanding that my email is unlikely to be received by some > of > > those having issues... > > > > Let us assume that those who specify p=REJECT have a good reason for > doing > > so, and that after 2-3 years, they are unlikely to change back. > > > > Let us also assume that the members of these organizations who are > > participating in IETF may or may not have any power over whether their > > admins have decided to be p=REJECT. > > > > And let us assume that we want these folks to participate in IETF. > > Let me stop you right there. Yes, we want everybody to be free to > participate in the IETF, and presumably those people want to participate > in the IETF. But participants have to be able to use the tools that the > IETF has chosen, which includes mailing lists. That's always been true. > (In 1992, when I started in the IETF, it meant knowing how to subscribe > to a majordomo list. Today, subscribing is a bit easier, but it means > avoiding the DMARC trap.) > > So such participants need to use an email sending address that works > with IETF mailing lists. > > yahoo.com and google.com don't work properly with IETF mailing lists. > Fortunately, very fine alternatives are available, such as gmail.com. > (gmail's spam learning is even smart enough to work around p=reject, > as it did for this very message that I'm replying too.) > > I think Michael Richardson made a very valid point. If our mailing > list software detects a sender whose domain has p=reject, we *know* > that the forwarded message will fail DMARC validation. So there's a > strong case for rejecting the message immediately, so that the sender > can be told about the problem and can choose a different sending address. > Presumably, we'd only need to do this until ARC is deployable. > If enforcement of DMARC was universal (or nearly so), sure. Except, it's not. As you said, Gmail didn't enforce it in this instance. Rejecting the messages is definitely an option. As stated down thread, I wouldn't think it's the best choice for the members. Brandon --94eb2c095f7aae743805406d3aaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 2, 2016 at 3:19 PM, Brian E Carpenter <= ;brian.e.c= arpenter@gmail.com> wrote:
= On 03/11/2016 10:58, Brandon Long wrote:
> With the understanding that my email is unlikely to be received by som= e of
> those having issues...
>
> Let us assume that those who specify p=3DREJECT have a good reason for= doing
> so, and that after 2-3 years, they are unlikely to change back.
>
> Let us also assume that the members of these organizations who are
> participating in IETF may or may not have any power over whether their=
> admins have decided to be p=3DREJECT.
>
> And let us assume that we want these folks to participate in IETF.

Let me stop you right there. Yes, we want everybody to be free to participate in the IETF, and presumably those people want to participate in the IETF. But participants have to be able to use the tools that the
IETF has chosen, which includes mailing lists. That's always been true.=
(In 1992, when I started in the IETF, it meant knowing how to subscribe
to a majordomo list. Today, subscribing is a bit easier, but it means
avoiding the DMARC trap.)

So such participants need to use an email sending address that works
with IETF mailing lists.

yahoo.com= and google.com don't work properly with IETF mailing lists.
Fortunately, very fine alternatives are available, such as gmail.com.
(gmail's spam learning is even smart enough to work around p=3Dreject,<= br> as it did for this very message that I'm replying too.)

I think Michael Richardson made a very valid point. If our mailing
list software detects a sender whose domain has p=3Dreject, we *know*
that the forwarded message will fail DMARC validation. So there's a
strong case for rejecting the message immediately, so that the sender
can be told about the problem and can choose a different sending address. Presumably, we'd only need to do this until ARC is deployable.

If enforcement of DMARC was universal (or nearl= y so), sure.=C2=A0 Except, it's not.
As you said, Gmail d= idn't enforce it in this instance.

Rejecting t= he messages is definitely an option.=C2=A0 As stated down thread, I wouldn&= #39;t
think it's the best choice for the members.
<= br>
Brandon
--94eb2c095f7aae743805406d3aaf-- From nobody Thu Nov 3 16:03:51 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB56129987 for ; Thu, 3 Nov 2016 16:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSpyIo6wjAEu for ; Thu, 3 Nov 2016 16:03:49 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 14B7A1297D0 for ; Thu, 3 Nov 2016 16:03:48 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id x4so116600287oix.2 for ; Thu, 03 Nov 2016 16:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AhrwNUtKbt7U4YIA0AWjqOsLwVb0PppDe0MuZkvvHks=; b=BxHgFjCkcg2YsN64B/nskYFKkJNqsNGoR/+XsUmTCxHgHpH7IrpeZO5xPaRQ8BfwR/ 6v9FcTXbBod5pChi+mM06SZXx5klb0cZUYBbM57njxMoO2pizKq9gkft6+2PcPeSVBxa ummxiQyG98ZAnrcdmpjPwsKV3sxgdS5N4gZGAQnulcMFKp9f6MDTYqIdbVEOCLVYIIOl 4HmkRw3GP7zHTVYW85c2e/qYpTNlnH1qlOsp9qNJEexaKmG40tlldznf0riQDIMHdBjI 0Ceg0rjz+UXOGB8oQa1TIynq0UypmOzNCMz+TXUxNBI5CY+puJI7D2L2PMspf0yzyQr4 jauw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AhrwNUtKbt7U4YIA0AWjqOsLwVb0PppDe0MuZkvvHks=; b=D7UH9KMbhBdMqGW90XoC2MxMsTCakVw7zKFk9qdgLtmyuu7qf+CShzkspL9SMBJGr3 guGa+LNGfu+MnjTS2gYozmL3H/Cw68HQpR+Dz6MhMUTpdN52JVDimZLlNqdu0ButsZQZ Znwhp8Nd9O83dKAd7sq72Nv0NFoMLH1FZEwJ8wZ7Ycafaf8VfiNr44/FkHhXLFEHwOzV ewCoNcnGJ6hAN7Zb4FNd1ExvtzHAAk8SFrgLmI9kurAbZZm8VJbXbTxvUN4HMaOTlFfM v6KJQhxdg9Zznh1MNPHZiWwK45PHRwAyEmrNMXNGkcQbyeiLgovSx3uu9kSXE7hKIwjy IxVg== X-Gm-Message-State: ABUngvd8JvxGbb+EtGiWjshOaJmu5DlJfL6qqeSEO63Sci0lTs54sExiGisQCB/HbsA3ixr6uWpYTgO/bqyKw4gp X-Received: by 10.157.7.197 with SMTP id 63mr8257203oto.177.1478214227007; Thu, 03 Nov 2016 16:03:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Thu, 3 Nov 2016 16:03:45 -0700 (PDT) In-Reply-To: <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> From: Brandon Long Date: Thu, 3 Nov 2016 16:03:45 -0700 Message-ID: To: Dave Crocker Content-Type: multipart/alternative; boundary=94eb2c043bb4e78a4005406d9190 Archived-At: Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2016 23:03:51 -0000 --94eb2c043bb4e78a4005406d9190 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 2, 2016 at 3:51 PM, Dave Crocker wrote: > On 11/2/2016 2:58 PM, Brandon Long wrote: > >> The difference is mostly cosmetic, though depending on your mail client, >> there may be other downsides. And it may violate RFC 5322. >> > > Brandon, > > You know that I know that the attacks that generated the use of DMARC, > which is causing the current situation, are serious. I'm mentioning that > here to make sure the context for what follows is clear... > > Email is communication between an author and one or more recipients. > > Everything in between them is 'overhead'. The overhead functions need to > be careful to avoid cavalierly reducing the utility of email, even as the > changes are meant to aid in the use of email. > > Identification of the author and recipients is meaningful to them. That's > not 'cosmetic'. > > And software tools employed by users take advantage of this > identification, for searching and for organizing. > Including Gmail, which doesn't handle this workaround well, either. > In a highly diverse world, one of the problems of being a very major > player is that it becomes far too easy not to see all the diversity or to > appreciate its import to others. After all, most of that diversity is seen > as such a tiny percentage of the activity. This is the essence of > ethnocentrism. > > Changing the contents of the rfc5322.From field is changing basic > statements about authorship. > > Perhaps there's no practical choice right now, but please let's not be > cavalier about its import. I think technical fans of email perhaps attach more import to the rfc5322.from field than does the average user. Certainly, downsides exist. That said, facebook notifications today all come from the same per-user address, with the actual commenter as just the display name. Various forum software, email ticketing software, the email notifications from various web based messaging systems, they all fail to apply authorship in how you say. Yes, mailing lists have existed in this form for some time, and they are a good and vital system, and the downsides are real. Note also that I imagine that mailing list software which supports EAI messages might also need to munge the From header to downgrade the message for delivery to non-EAI enabled receivers. I'm not sure if my comment was heard in the recent ARC round table, where folks were questioning the overall complexity of ARC, but I'm fairly serious in saying that all of our discussions on work arounds and technical methods for trying to make DMARC work with mailing lists, and from header munging is by far the simplest. No trust/reputation systems, no manual whitelisting, no "magic sauce", no new software to be installed by receivers. ARC will add greatly to the size of mail headers, which some folks on mailop still think should be tiny and talk about automatically marking large headers as spam. ARC will add greatly to the privacy concerns which were raised last week on the DKIM IETF list, where now not only is a message have attestation of origin, but that attestation will survive some amount of forwarding/modification, and the path it took will also be attested to. ARC will require new software to be installed by mailing list providers and any receivers who implement DMARC. Even after being installed, there is still more work in order to allow the mailing list messages through. Brandon --94eb2c043bb4e78a4005406d9190 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 2, 2016 at 3:51 PM, Dave Crocker <dcrocker@gmail.com&= gt; wrote:
On 1= 1/2/2016 2:58 PM, Brandon Long wrote:
The difference is mostly cosmetic, though depending on your mail client, there may be other downsides.=C2=A0 And it may violate RFC 5322.

Brandon,

You know that I know that the attacks that generated the use of DMARC, whic= h is causing the current situation, are serious.=C2=A0 I'm mentioning t= hat here to make sure the context for what follows is clear...

Email is communication between an author and one or more recipients.

Everything in between them is 'overhead'.=C2=A0 The overhead functi= ons need to be careful to avoid cavalierly reducing the utility of email, e= ven as the changes are meant to aid in the use of email.

Identification of the author and recipients is meaningful to them. That'= ;s not 'cosmetic'.

And software tools employed by users take advantage of this identification,= for searching and for organizing.

Incl= uding Gmail, which doesn't handle this workaround well, either.
=C2=A0
In a highl= y diverse world, one of the problems of being a very major player is that i= t becomes far too easy not to see all the diversity or to appreciate its im= port to others. After all, most of that diversity is seen as such a tiny pe= rcentage of the activity. This is the essence of ethnocentrism.

Changing the contents of the rfc5322.From field is changing basic statement= s about authorship.

Perhaps there's no practical choice right now, but please let's not= be cavalier about its import.

I think tech= nical fans of email perhaps attach more import to the rfc5322.from field th= an does the average user.=C2=A0 Certainly, downsides exist.=C2=A0 That said= , facebook notifications today all come from the same per-user address, wit= h the actual commenter as just the display name.=C2=A0 Various forum softwa= re, email ticketing software, the email notifications from various web base= d messaging systems, they all fail to apply authorship in how you say.

Yes, mailing lists have existed in this form for some = time, and they are a good and vital system, and the downsides are real.

Note also that I imagine that mailing list software w= hich supports EAI messages might also need to munge the From header to down= grade the message for delivery to non-EAI enabled receivers.

=
I'm not sure if my comment was heard in the recent ARC round= table, where folks were questioning the overall complexity of ARC, but I&#= 39;m fairly serious in saying that all of our discussions on work arounds a= nd technical methods for trying to make DMARC work with mailing lists, and = from header munging is by far the simplest.=C2=A0 No trust/reputation syste= ms, no manual whitelisting, no "magic sauce", no new software to = be installed by receivers.

ARC will add greatly to= the size of mail headers, which some folks on mailop still think should be= tiny and talk about automatically marking large headers as spam.

ARC will add greatly to the privacy concerns which were rai= sed last week on the DKIM IETF list, where now not only is a message have a= ttestation of origin, but that attestation will survive some amount of forw= arding/modification, and the path it took will also be attested to.

ARC will require new software to be installed by mailing = list providers and any receivers who implement DMARC.=C2=A0 Even after bein= g installed, there is still more work in order to allow the mailing list me= ssages through.

Brandon

=
--94eb2c043bb4e78a4005406d9190-- From nobody Thu Nov 3 17:00:55 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A9C12941A; Thu, 3 Nov 2016 17:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org 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 xYGIANSl6tVT; Thu, 3 Nov 2016 17:00:46 -0700 (PDT) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [192.198.93.228]) (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 8293E12711D; Thu, 3 Nov 2016 17:00:46 -0700 (PDT) Received: from zmcc-5-mta-1.zmailcloud.com (127.37.197.104.bc.googleusercontent.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id 9BFA6520257; Thu, 3 Nov 2016 20:00:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 411EBC271B; Thu, 3 Nov 2016 19:00:45 -0500 (CDT) Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id kHObG-XnNjcF; Thu, 3 Nov 2016 19:00:44 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 1F358C276B; Thu, 3 Nov 2016 19:00:44 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.9.2 zmcc-5-mta-1.zmailcloud.com 1F358C276B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1478217644; bh=SUcpgc7//0FqY8yucnRvLjaKX/mrPMVpeTQSq89wy+M=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=hTXJeWtUtL6iejhK7y3GKrDDa8B+y/GismYXnLBdbkcVhW1RdYgPEc/aHcRxBALTD 0fW3/n7HTOOSjT+0SWjdtN2sDKVRXRsT4etHacxZXhjVAwGEsSP7VCnuUPSm9zX2sD lBRtEmJdGJgURx0U1W59LZv3g0lp80baQ9TIDySM= X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1yjrF3m-SyPK; Thu, 3 Nov 2016 19:00:43 -0500 (CDT) Received: from zmcc-5-mailbox-1.zmailcloud.com (zmcc-5-mailbox-1.zmailcloud.com [10.240.0.12]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id EA3F4C272F; Thu, 3 Nov 2016 19:00:43 -0500 (CDT) Date: Thu, 3 Nov 2016 19:00:43 -0500 (CDT) From: Franck Martin To: Brandon Long Message-ID: <175424623.13029094.1478217643737.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <5c0220dd-20b6-5e8e-fe9c-b402675cc559@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13029093_456305042.1478217643736" X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - FF49 (Mac)/8.6.0_GA_1194) Thread-Topic: IETF Mailing Lists and DMARC Thread-Index: dhvwG3sEKAiPZaBvwC7Vv0e12GIgew== Archived-At: Cc: Michael Richardson , dmarc@ietf.org, Brian E Carpenter , Cullen Jennings , IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 00:00:49 -0000 ------=_Part_13029093_456305042.1478217643736 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit > From: "Brandon Long" > To: "Brian E Carpenter" > Cc: "Michael Richardson" , dmarc@ietf.org, "IETF" > , "Cullen Jennings" > Sent: Thursday, November 3, 2016 3:39:22 PM > Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC > On Wed, Nov 2, 2016 at 3:19 PM, Brian E Carpenter < brian.e.carpenter@gmail.com > > wrote: >> On 03/11/2016 10:58, Brandon Long wrote: >> > With the understanding that my email is unlikely to be received by some of >> > those having issues... >> > Let us assume that those who specify p=REJECT have a good reason for doing >> > so, and that after 2-3 years, they are unlikely to change back. >> > Let us also assume that the members of these organizations who are >> > participating in IETF may or may not have any power over whether their >> > admins have decided to be p=REJECT. >> > And let us assume that we want these folks to participate in IETF. >> Let me stop you right there. Yes, we want everybody to be free to >> participate in the IETF, and presumably those people want to participate >> in the IETF. But participants have to be able to use the tools that the >> IETF has chosen, which includes mailing lists. That's always been true. >> (In 1992, when I started in the IETF, it meant knowing how to subscribe >> to a majordomo list. Today, subscribing is a bit easier, but it means >> avoiding the DMARC trap.) >> So such participants need to use an email sending address that works >> with IETF mailing lists. >> yahoo.com and google.com don't work properly with IETF mailing lists. >> Fortunately, very fine alternatives are available, such as gmail.com . >> (gmail's spam learning is even smart enough to work around p=reject, >> as it did for this very message that I'm replying too.) >> I think Michael Richardson made a very valid point. If our mailing >> list software detects a sender whose domain has p=reject, we *know* >> that the forwarded message will fail DMARC validation. So there's a >> strong case for rejecting the message immediately, so that the sender >> can be told about the problem and can choose a different sending address. >> Presumably, we'd only need to do this until ARC is deployable. > If enforcement of DMARC was universal (or nearly so), sure. Except, it's not. > As you said, Gmail didn't enforce it in this instance. > Rejecting the messages is definitely an option. As stated down thread, I > wouldn't > think it's the best choice for the members. Politics of exclusion are easy but usually do not go far... us vs them is never a long term option. but I'd like to point to a new problem surfacing as security is shifting with DMARC: impersonation on mailing lists. Several large lists have been recently caught by email impersonating list members. Was it successful enough for the miscreant? Will we see more in the future? Do lists need to check DMARC on incoming mail and apply policy? Do they need to do more than DMARC and authenticate the poster? ------=_Part_13029093_456305042.1478217643736 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


From: "Brandon Long" <blong@goo= gle.com>
To: "Brian E Carpenter" <brian.e.carpenter@gmail.c= om>
Cc: "Michael Richardson" <mcr+ietf@sandelman.ca>, dm= arc@ietf.org, "IETF" <ietf@ietf.org>, "Cullen Jennings" <fluffy@ii= i.ca>
Sent: Thursday, November 3, 2016 3:39:22 PM
Subjec= t: Re: [dmarc-ietf] IETF Mailing Lists and DMARC
=
=

On Wed, Nov 2= , 2016 at 3:19 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote= :
On 0= 3/11/2016 10:58, Brandon Long wrote:
> With the understanding that m= y email is unlikely to be received by some of
> those having issues.= ..
>
> Let us assume that those who specify p=3DREJECT have a= good reason for doing
> so, and that after 2-3 years, they are unli= kely to change back.
>
> Let us also assume that the members = of these organizations who are
> participating in IETF may or may no= t have any power over whether their
> admins have decided to be p=3D= REJECT.
>
> And let us assume that we want these folks to par= ticipate in IETF.

Let me stop you right there. Yes, we want= everybody to be free to
participate in the IETF, and presumably those = people want to participate
in the IETF. But participants have to be abl= e to use the tools that the
IETF has chosen, which includes mailing lis= ts. That's always been true.
(In 1992, when I started in the IETF, it m= eant knowing how to subscribe
to a majordomo list. Today, subscribing i= s a bit easier, but it means
avoiding the DMARC trap.)

So such = participants need to use an email sending address that works
with IETF = mailing lists.

yahoo.com and google.com don't work properly with IETF mailing= lists.
Fortunately, very fine alternatives are available, such as gmail.com.
(gmail's spam learning is even sma= rt enough to work around p=3Dreject,
as it did for this very message th= at I'm replying too.)

I think Michael Richardson made a very valid = point. If our mailing
list software detects a sender whose domain has p= =3Dreject, we *know*
that the forwarded message will fail DMARC validat= ion. So there's a
strong case for rejecting the message immediately, so= that the sender
can be told about the problem and can choose a differe= nt sending address.
Presumably, we'd only need to do this until ARC is = deployable.

If enforcement of DMARC was universal = (or nearly so), sure.  Except, it's not.
As you said, Gm= ail didn't enforce it in this instance.

Rejecting the message= s is definitely an option.  As stated down thread, I wouldn't
think it's the best choice for the members.
=
Politics of exclusion are easy but usually do not go far.= .. us vs them is never a long term option.

but I'd like to point to a new problem surfacing as secur= ity is shifting with DMARC: impersonation on mailing lists.

Several large lists= have been recently caught by email impersonating list members.

Was it successf= ul enough for the miscreant? Will we see more in the future?

Do lists need to c= heck DMARC on incoming mail and apply policy? Do they need to do more than = DMARC and authenticate the poster?



------=_Part_13029093_456305042.1478217643736-- From nobody Fri Nov 4 05:22:00 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09466129512 for ; Fri, 4 Nov 2016 05:21:52 -0700 (PDT) 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_HELO_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=vuTlbv3s; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=t74dFknI 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 0Hq43r5PGbHz for ; Fri, 4 Nov 2016 05:21:45 -0700 (PDT) Received: from catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2978B1294CD for ; Fri, 4 Nov 2016 05:21:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2225; t=1478262100; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=ed+s5KOgvIHQkehVCHnyu9lQjhs=; b=vuTlbv3sUQwoH7hv2lbXhWqw8pQu4S+PhZmhVQmW6MoQR2j4yCbIMV50G+0CIZ OUTCkWVZ+dWal6PRDCQZQyLc2Ha/kTpZ2L9Segfqo64bpCISgJd21VhcJfFbN6+F EDCNJTvblo7C8rOSiGJRxNB3LFGa3a5P2rc58gLHPfqWU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Fri, 04 Nov 2016 07:21:40 -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; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 750609144.1.1496; Fri, 04 Nov 2016 07:21:39 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2225; t=1478262087; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2vRdrSK uHhydq1mqZS6TS4cGH8gkHjGPinhLRQt43/g=; b=t74dFknImR0JP6l0gvNIQMC TCrYd3NybFvLugTu54oSiweWg//uX0P+f7AX8rPdQWSlKRrGXJgkknkuAk2yf0lk cd83ng6PSzEKhLXeJpJCnufe1mzScafkCeEtTQaK+DKPvqCpHe7amNj4RF7S3CIo U5FA8q9jGnNVvORZlcfo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Fri, 04 Nov 2016 08:21:27 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 206166718.9.61888; Fri, 04 Nov 2016 08:21:26 -0400 Message-ID: <581C7D55.7080708@isdg.net> Date: Fri, 04 Nov 2016 08:21:41 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: Brian E Carpenter , Brandon Long , Michael Richardson References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <5c0220dd-20b6-5e8e-fe9c-b402675cc559@gmail.com> In-Reply-To: <5c0220dd-20b6-5e8e-fe9c-b402675cc559@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , IETF , Cullen Jennings Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 12:21:52 -0000 On 11/2/2016 6:19 PM, Brian E Carpenter wrote: > > I think Michael Richardson made a very valid point. If our mailing > list software detects a sender whose domain has p=reject, we *know* > that the forwarded message will fail DMARC validation. So there's a > strong case for rejecting the message immediately, so that the sender > can be told about the problem and can choose a different sending address. I had it in my 2006 DSAP proposal for MLM guidelines: http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3 The term DMARC can be swapped in the section since its really about a general DKIM+POLICY and it doesn't matter if it was SSP, ADSP, DSAP or DMARC: 3.3. Mailing List Servers Mailing List Servers (MLS) applications who are compliant with DKIM and DMARC operations, SHOULD adhere to the following guidelines: Subscription Controls MLS subscription processes should perform a DMARC check to determine if a subscribing email domain DMARC policy is restrictive in regards to mail integrity changes or 3rd party signatures. The MLS SHOULD only allow original domain policies who allow 3rd party signatures. Message Content Integrity Change List Servers which will alter the message content SHOULD only do so for original domains with optional DMARC signing practices and it should remove the original signature if present. If the List Server is not going to alter the message, it SHOULD NOT remove the signature, if present. Wow! 10 years and we still having this issue! Incredible. :( But I did add the subscription controls for our ML software. > Presumably, we'd only need to do this until ARC is deployable. Can ARC resolve the downlink problem for the non-ARC compliant receivers? I've always said that the MLM needs to "look up" the practices of the Author Domain. What is its expectation? Intentions? If the MLM expects the receivers to do DMARC lookups, why shouldn't the MLM do the same prior to accepting a list submission or subscriber? The MLM can also check/detect DMARC related SMTP error responses and minimize the erroneous automatic removals from list. All this requires MLM software change. -- HLS From nobody Fri Nov 4 07:55:35 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A79912951A; Fri, 4 Nov 2016 07:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pcRWRAGsrlB; Fri, 4 Nov 2016 07:55:26 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4AD1294A0; Fri, 4 Nov 2016 07:55:26 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c2fts-000DvQ-5E; Fri, 04 Nov 2016 10:55:24 -0400 Date: Fri, 04 Nov 2016 10:55:19 -0400 From: John C Klensin To: "Andrew G. Malis" , Steve Atkins Message-ID: <2EB28059074B7148F8A1443E@JcK-HP8200> In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: dmarc@ietf.org, IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 14:55:29 -0000 --On Thursday, November 03, 2016 14:24 -0400 "Andrew G. Malis" wrote: >... >> And regarding Terry's previous paragraph, while I'm by no means an >> expert on DMARC (or mailman for that matter), a bit of >> googling tells me that there are more recent versions of >> mailman than what the IETF is currently using that support >> DMARC mitigation. See, for example, >> http://www.spamresource.com/2016/09/dmarc-support-in-mailman.h >> tml . Hi Steve! > > The site goes on to say: > > "If you don't take any action here, you're leaving a subset of > your potential subscribers out in the cold. Making them second > class citizens, unable to participate in the mailing lists > you're hosting. Be kind, and don't beat up Yahoo users because > of a domain policy that Yahoo choose to implement (and that > Yahoo user is stuck dealing with)." > > I certainly agree with that sentiment. And it's not the > DMARC WG that's responsible for IETF email list support, > it's the admin staff at AMS that are the ones "caught in > the middle". Andy (and others), We are beginning to move away from protocols and toward philosophy here. Maybe that is as it should be, so, from the perspective of someone who probably belongs on John Levine's list of people who have been thinking about email for a really long time, some observations. First, we got here because a small collection of email service providers got together and developed and deployed a piece of protocol that, among other things, ignored the implications of that protocol (or some of configurations that were possible with it) for mailing lists as we have traditionally understood them. I don't have any reason to believe it was relevant to their decisions, but I note that the providers involved all run their own "groups", "forums", etc., as an alternative to traditional Internet email-based mailing lists. Second, there are a number of aspects of our email architecture that assume users have both a trust relationship with, and some control over, their email service providers. There are aspects of POP3 and IMAP4 that make no sense without that assumption and many antispam activities and actions would be serious violations of the standards in the absence of that assumption. Nothing prevents a user from agreeing with a provider that, in return for "free" email service, that provider gets the right to decide what messages the user can receive or send, to scan messages for content of interest (e.g., to determine user interests from advertising purposes), to make unilateral decisions about whether messages or message trace information should be revealed to others, and to change the rules after that user is thoroughly locked in. The IETF can't protect users from such agreements and we probably shouldn't try even if we could. That doesn't mean I am willing to agree to that -- I won't and, if I ever decide to outsource my mail services, it will be to someone to whom I pay money and from whom I can get an appropriate SLA because free lunches make me nervous. One of the things that make the IETF community (and, I assume, Ted's Linux developer community) different from the general user community is that the proportion of people with attitudes like mine is a lot higher than in that general population of Internet users. Another is that we get to assume a sufficient level of clue to at least understand the tradeoffs mentioned above. So, while "that [random] Yahoo user" has my sympathy, those who want to participate in, and contribute to, the IETF get a lot less of it if they can't figure out where to find and how to use a mail system that conforms to our standards rather than something made up by a handful of mail providers to serve their own needs, no matter how many customers/ users/ victims they have. Finally, I'd like to suggest people who have been involved in this debate think about something even if it seems far-fetched. Suppose some vendors and/or ISPs got together and agreed on an improvement to IP that would have the side effect of making things better for their customers but worse for some others. Would the IETF be scrambling around trying to modify IP to make the pain for the non-customers somewhat less, perhaps in the process helping to pressure other vendors and ISPs into conforming to the "new" protocols? We've got a partial answer with ISPs giving preference to some content providers over others with the "net neutrality" debate, something many of us have recognized as an abuse of market power fundamentally inconsistent with network principles, but the differences between that case and the DMARC one may be less significant than might appear at first glance. I'm still looking forward to ARC and any other approaches that move us forward with solutions to what I assume we all recognize as a real problem. But I think we need to be much more cautious about "solutions" that make Internet mail work less well as well as ones that mitigate problems in ways that may retard real solutions. john From nobody Fri Nov 4 08:21:53 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C809129568 for ; Fri, 4 Nov 2016 08:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQz8kS0cDFu7 for ; Fri, 4 Nov 2016 08:21:50 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 4ACD3129503 for ; Fri, 4 Nov 2016 08:21:50 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id q130so101279325qke.1 for ; Fri, 04 Nov 2016 08:21:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/khdR88Rl2oFCcyVmUdWYL40tMYjmYKcpmmveOOZKWE=; b=CokGiYqIJ9UZ2A1KXRu06DlR1/qr64ydyj+w0uY6rwmFudiBi5Tm3zRGTO1wh4oAWJ JF4/ZA6ZuN3HEqCO1MmCQCKNZ578jHU+jmMTwF86oj7WvxhJ74LxkPHpko9aefRFrhFl 8MyjpzCzxOvdXOFcSa//4COvk7oU3qMnvVSjZzDbR9XIZKOQX5ZlziyF1mcMQzZDbP9g Jo1xHkXagALVSrdKMTOLqcs9hvvbWK39qpqr5u2UJpvxllKEUG6+u7Ufz0TY1cfwSr1U CSlVOymg5V71K2il2yMGu1+GXh2qgOx1ef/47L6QNhnpdnc9sV7Ls4iAfGQTQMSB9GkW 9BHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/khdR88Rl2oFCcyVmUdWYL40tMYjmYKcpmmveOOZKWE=; b=hb6S+L9HxEfY86mJUys20YLMgvOIs+t/YWKY5F4nbBKRX/xElqe85ZTBbPBWhxNn7w tiHae6xKBPuCdUuXQQlosPMKSQ/VEdshG3lQSt15oK7Y6Mp4Jr2pibVwxZka94MGmdkm 7HAd0zGLXX/+NMc4ye6Owdi8bgv75zs2KScNny1ek0jWZ/xBeGoFsHPNeXen1bHuf3hR Ez+sjMUBuKisC/TofR0TxZBZ4HLWc+zyeOIjc1/7xY6Q5fVSJpcf4eWEej2J4juxqxxA ySJ4FSf+ZP7mXl5yIj+x414WQMMwOQvYpXpfb+xV6qzZrslyHQ7i05neInf8mPG3DRGD CPlg== X-Gm-Message-State: ABUngveQltoqRFvDvHuy2hnh7Awiq41EQ57tIS3pp1iFaZrqzEV2a0ZMcGgUPS+lghBISg== X-Received: by 10.55.183.197 with SMTP id h188mr15047296qkf.107.1478272909281; Fri, 04 Nov 2016 08:21:49 -0700 (PDT) Received: from [10.0.20.146] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id b94sm7780674qkb.16.2016.11.04.08.21.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 08:21:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Ted Lemon In-Reply-To: <2EB28059074B7148F8A1443E@JcK-HP8200> Date: Fri, 4 Nov 2016 11:21:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <958ED4C5-370B-4D64-8844-5E3D1699718B@fugue.com> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> <2EB28059074B7148F8A1443E@JcK-HP8200> To: John C Klensin X-Mailer: Apple Mail (2.3251) Archived-At: Cc: dmarc@ietf.org, IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 15:21:52 -0000 Forgive me if this isn=E2=80=99t as respectful as it could be, but your = rather long dissertation on the problem didn=E2=80=99t actually say what = would go wrong if we did something about it. Is there something = missing from the summary I wrote and sent to the mailing list yesterday? This is an operational issue, not a philosophical issue. People are = trying to get work done, and a problem created by people other than them = is preventing them from getting work done. Worse, it=E2=80=99s doing it = in a way that is difficult for third parties to detect, and that has = resulted in people unexpectedly and unknowingly not getting email they = needed to get. This is a _really serious problem_. Arguing that we shouldn=E2=80=99t = solve it because we have philosophical issues is silly. It=E2=80=99s = like arguing that we shouldn=E2=80=99t have firewalls, which break IP in = exactly the way you described, because they are bad on a philosophical = level. They _are_ bad on a philosophical level. We, the IETF, are = not going to stop people from installing them, because they are _good_ = on an ops level. The idea that we shouldn=E2=80=99t solve problems = like this regarding email went out the window when Canter and Siegel = came on the scene. That=E2=80=99s just life. So if you have a technical reason why fixing = this problem is a bad idea, please share it. And I am always = interested in your philosophy. But I do not think you have made a = valid technical argument against the IESG addressing this operational = problem. From nobody Fri Nov 4 08:38:02 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB423129424; Fri, 4 Nov 2016 08:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92rPEPcC8QKw; Fri, 4 Nov 2016 08:37:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D65129417; Fri, 4 Nov 2016 08:37:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 523EE20183; Fri, 4 Nov 2016 11:53:31 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B2039637A7; Fri, 4 Nov 2016 11:37:57 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: dmarc@ietf.org, ietf , Cullen Jennings Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 15:38:01 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: > FWIW, I use Google For Work (or whatever it's called this week) and it > doesn't automatically add DMARC headers--that's something that you have > to configure, apparently. So while I think that gmail.com is probably > a lost cause, if your org is using GfW, you don't have to use DMARC. Yes, that's true. google.com (for google employees) apparently does have DMARC enabled. That's a policy decision they made. Some places (paypal, I think), moved all their employees to corp.example.com, so they could DMARC for their official emails, without screwing their employees' work. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWByrUoCLcPvd0N1lAQKmsgf+K3OFGWRowqC46aNQOEwsEOgI9EQ+HoSj pZoJAw8Bh5GLwpsqSPSj0Rb+8H89ITcZGfMZspUTiiCIyzSbJhfm7pEXDOPwucSI KN8nkPZbt14pHInHg9cwzFqYRh503YnKrL6vxKtcLkMWHa+2LK+MD1MRmANMbGyh ZPEHFKszkEvztvUQbX2U0ooFAzzrByPrvHYd6XfPVaiGn62/s8JnTxYiA1hjDZGy cEKkjbz68JuUFhmV/Nvdo1FtBCcoePDrOKaKIMt5SOuN5N2uBhVZHuOAq19I+o5g Bhejf4AtER8NTbx7h6x4AN11aafxJoGY0D8Gc6LwPpV3Sy7fXE8qFQ== =CT8H -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 4 08:47:24 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3A212959D; Fri, 4 Nov 2016 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tojzgH4jUjS9; Fri, 4 Nov 2016 08:47:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37375129598; Fri, 4 Nov 2016 08:47:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F62C20183; Fri, 4 Nov 2016 12:02:55 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6EC1A637A7; Fri, 4 Nov 2016 11:47:21 -0400 (EDT) From: Michael Richardson To: "Andrew G. Malis" In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "dmarc@ietf.org" , IETF , Terry Zink Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 15:47:23 -0000 --=-=-= Content-Type: text/plain Andrew G. Malis wrote: > Three thumbs up on the last sentiment above - could you imagine saying > to someone that you need to switch phone providers in order to reach > certain recipients? And while my current use of gmail allows me to more yes, we lived through a decade of: "This site best viewed in Internet Explorer in 1024 x 768" (Except that "best" meant, "it won't work otherwise", and this kind of crap was ubiquitous from many governments. We fixed the end points, we didn't work around it with middle box hacks) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWBythoCLcPvd0N1lAQLZFAf9FrNPWqHMOen4t82H3QGV05Kv183rl9nI mgXbR6+HiYZxUc1ZljQXOfEul73EojbckQnQaoBszuM9/wMHYLl+yqJBYF+7loFm yNbHSusbQhvL0zFdXzMWwtycXj5yP9A7VtPcwuy8y1r7GjzxgXfpEnMEf7NMdKHd r09Wt6zl5LSeyCLimgeY9wyzIKmbk1MSKINIuxSz/7go7DsH5Brdw2V6wKgDlH8l 9nS4WIjYzClrW8PGvz+PRuG9Peu3J/OxE5WM4GxBgUxe+cWZV+EZChZbkn6wMTEK 4oIfBGKzF2LtnnupnVX9UlnD+Lv97j6trSnmlGUU992yfxkOVoFyAw== =hfDy -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 4 09:56:07 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4E129462; Fri, 4 Nov 2016 09:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR6IOOcl1mwa; Fri, 4 Nov 2016 09:56:03 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62716129469; Fri, 4 Nov 2016 09:56:03 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c2hmb-000EW4-1t; Fri, 04 Nov 2016 12:56:01 -0400 Date: Fri, 04 Nov 2016 12:55:56 -0400 From: John C Klensin To: Ted Lemon Message-ID: <983679A1E92B0F2EF6DA195A@JcK-HP8200> In-Reply-To: <958ED4C5-370B-4D64-8844-5E3D1699718B@fugue.com> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> <2EB28059074B7148F8A1443E@JcK-HP8200> <958ED4C5-370B-4D64-8844-5E3D1699718B@fugue.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: dmarc@ietf.org, IETF Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 16:56:06 -0000 Ted, I started that note before you posted your list of four options and decided to send it anyway. I think your list is correct and, since it apparently wasn't obvious from my comments, prefer your first option. The reason for the long note is that I don't accept this as "just life". I believe the IETF has an affirmative obligation to avoid breaking the Internet -- or the protocols it has chosen to standardize -- and to avoid encouraging those who choose to do so. Assuming there is no disagreement that the problem is real, one implication of that involves a very strong preference for bringing work to the IETF while it is still at (or before) the design phase rather than having something half-designed elsewhere, deployed, and them brought to the IETF on either as "standardize this as is because it is deployed" or a "you folks in the IETF can now straighten out the mess we made by developing and deploying this without thinking through the implications". Given that the problem is real, the IETF of course has some obligation to take it on in a serious way. When the breakage is bad enough (and I'm not taking a position on whether DMARC is) and is the result of an action by a dominant player or collection of them, I also believe that we (individually if not in the name of the IETF, have a professional obligation to initiate or participate in discussions with appropriate authorities about anticompetitive and/or monopolistic behavior. Finally (and here is where I demonstrate that I'm very far out in the rough), your comment about Canter and Siegel identifies a different, but to me important, issue. Suppose we have a community that as a significant problem with either domestic animals or humans defecating on the sidewalks. Obviously one option is for everyone who lives there or visits to become very careful about where they step, but that has a number of serious implications. Another is to prohibit doing that and to also have "clean up after your pets and offspring" rules. However, carrying around appropriate bags and pick-up instruments is annoying and experience indicates that, unless those rules are enforced (as either a matter of law or effective community outrage), there will still be a lot of s**t on the streets. That becomes interesting as a social problem because, if a group of well-meaning people springs up to come around the community every day and clean up previously-untended messes, any pressure to punish or otherwise deter those who are responsible for those messes disappears (and more people may be encouraged to stop going to the trouble of cleaning up after themselves and their pets). On the other hand, if those spontaneous and well-meaning efforts do not occur, then the pressures within the community to punish those who cannot be bothered to do the cleaning up rise until either such measures are taken or the community, including the non-offenders, are explicitly taxed to provide funding for claiming up the problem. There are aspects of the spam problem that are a lot like that. Many of the significant costs are incurred as soon as the messages start to cross the Internet. Solutions that involve filtering the messages so they cannot be delivered do nothing to address that problem, nor to impose costs on the message originators. Instead, by mitigating the nuisance value of the spam and the risks to the recipient of whatever comes with the spam messages, they have the side-effect of reducing the incentives to find the spammers and punish their behavior in a serious enough way to deter the practice. Indeed, if the spammer's objective is to get a certain number of messages through, actions that increase the percentage of spam messages that are blocked near the delivery point may create an incentive to increase the number of messages sent and hence the burdens on the network and the costs to those who maintain mail delivery systems. Again, I am not suggesting that the IETF (or anyone else) try to ignore the spam problem. However, it seems to me that we need to think a bit more about the whole system, evaluate questions like how much we are willing to give up for the privacy advantages of hard-to-trace message origins, and generally be careful what we wish for. best, john --On Friday, November 04, 2016 11:21 -0400 Ted Lemon wrote: > Forgive me if this isn't as respectful as it could be, but > your rather long dissertation on the problem didn't actually > say what would go wrong if we did something about it. Is > there something missing from the summary I wrote and sent to > the mailing list yesterday? > > This is an operational issue, not a philosophical issue. > People are trying to get work done, and a problem created by > people other than them is preventing them from getting work > done. Worse, it's doing it in a way that is difficult for > third parties to detect, and that has resulted in people > unexpectedly and unknowingly not getting email they needed to > get. > > This is a _really serious problem_. Arguing that we > shouldn't solve it because we have philosophical issues is > silly. It's like arguing that we shouldn't have > firewalls, which break IP in exactly the way you described, > because they are bad on a philosophical level. They _are_ > bad on a philosophical level. We, the IETF, are not going to > stop people from installing them, because they are _good_ on > an ops level. The idea that we shouldn't solve problems > like this regarding email went out the window when Canter and > Siegel came on the scene. > > That's just life. So if you have a technical reason why > fixing this problem is a bad idea, please share it. And I am > always interested in your philosophy. But I do not think you > have made a valid technical argument against the IESG > addressing this operational problem. > From nobody Fri Nov 4 13:22:08 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7D3129472; Fri, 4 Nov 2016 13:22:01 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctwlK35_1VBL; Fri, 4 Nov 2016 13:21:59 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0108.outbound.protection.outlook.com [104.47.33.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948DC1293EB; Fri, 4 Nov 2016 13:21:58 -0700 (PDT) Received: from CO2PR00MB0103.namprd00.prod.outlook.com (10.166.215.148) by CO2439225BE440.namprd00.prod.outlook.com (10.166.215.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.733.0; Fri, 4 Nov 2016 20:21:56 +0000 Received: from CO2PR00MB0103.namprd00.prod.outlook.com ([10.166.215.148]) by CO2PR00MB0103.namprd00.prod.outlook.com ([10.166.215.148]) with mapi id 15.01.0733.000; Fri, 4 Nov 2016 20:21:56 +0000 From: Terry Zink To: "dmarc@ietf.org" , IETF Thread-Topic: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) Thread-Index: AQHSNVuzHKOfGdWA1UyB+W+yk1I8ZKDH4laAgAFibQA= Date: Fri, 4 Nov 2016 20:21:56 +0000 Message-ID: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:a::5a9] x-microsoft-exchange-diagnostics: 1; CO2439225BE440; 6:hgCCSZLchUBYeZbEILBAww+r4uGaa38JjVGS6GUpTy9n+CCea2YU4kwjKtfKAEJk3YHNj9C8SM6hTsugslF7eFKBQsUI9jn0LKyl5RgsGhoyQzFefe5ccRT9msANUGi4z7Fnyk77NVHBS9QaOWqMHARgcu/Wwfr7x1fQpAO3SOMufNynIwGqHDDel/RrHleuUWfiCCEy/xTJKQgwsy/o0j87AWaScPGn2cJnctUktYye8+8fjXMqtEiBpOqB3hRSoHmKh5MbUJNcbyOkFmgvdA==; 5:QQQI8h+AmFBRchBzWQKsAF0cWUZqvW2dKUNFeRlkowqUWkMVDYYoHug/RcTAHBZFIsXjPD6PP6CA0Y8loLu9TlaEgVa7Eniq9DU53af+CcYePZ+dI4wGjAhtTGToOW04VQGeJ0Xe5vGP4p6/Eu/Ojg==; 24:ATKwLEWb+tmulUvEG2gFGaUES1WU6/2wHraoQUSxYH8tz6OqrVTcHi9W5IpdtsOu2pR0zAdqebvi3E0mFWfbsXcFwp9SMvxC27ZvwdcnBJE=; 7:VgrLbxFvoh7Djlb6Iurk5pi1CYnJhERFOLPM4iNCTE74Lx6Lno4fuJAsnej6K3ENVA9CfNRsYt9qfuDswr9b+8N35Gv/usZsYdZ5BQAV2vrfSM5Jt1JvBNLnBzePk3UhjOpj1ajR9t3OWQPxTqDRhm1TFDJxlr6a1uvoiD7nYg4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2439225BE440; x-exchange-antispam-report-cfa: BCL:0; PCL:0; RULEID:; SRVR:CO2439225BE440; BCL:0; PCL:0; RULEID:; SRVR:CO2439225BE440; x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(24454002)(11100500001)(106116001)(106356001)(19300405004)(76576001)(7736002)(74316002)(8990500004)(99286002)(105586002)(7846002)(81156014)(9686002)(33656002)(19580405001)(19625215002)(19580395003)(8676002)(68736007)(10290500002)(86362001)(5005710100001)(10400500002)(10090500001)(5002640100001)(3660700001)(2501003)(15975445007)(3280700002)(19609705001)(5890100001)(77096005)(2950100002)(7696004)(42882006)(2900100001)(586003)(450100001)(76176999)(54356999)(790700001)(6116002)(97736004)(8936002)(107886002)(102836003)(92566002)(101416001)(50986999)(5001770100001)(16236675004)(122556002)(189998001)(87936001)(5660300001)(93886004)(197153002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2439225BE440; H:CO2PR00MB0103.namprd00.prod.outlook.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: multipart/alternative; boundary="_000_CO2PR00MB0103566D260F9BFEC7166C9B96A20CO2PR00MB0103namp_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2016 20:21:56.6730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2439225BE440 Archived-At: Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 20:22:02 -0000 --_000_CO2PR00MB0103566D260F9BFEC7166C9B96A20CO2PR00MB0103namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIHRoaW5rIHRlY2huaWNhbCBmYW5zIG9mIGVtYWlsIHBlcmhhcHMgYXR0YWNoIG1vcmUgaW1w b3J0IHRvIHRoZSByZmM1MzIyLmZyb20gZmllbGQgdGhhbg0KPiBkb2VzIHRoZSBhdmVyYWdlIHVz ZXIuICBDZXJ0YWlubHksIGRvd25zaWRlcyBleGlzdC4gIFRoYXQgc2FpZCwgZmFjZWJvb2sgbm90 aWZpY2F0aW9ucw0KPiB0b2RheSBhbGwgY29tZSBmcm9tIHRoZSBzYW1lIHBlci11c2VyIGFkZHJl c3MsIHdpdGggdGhlIGFjdHVhbCBjb21tZW50ZXIgYXMganVzdCB0aGUNCj4gZGlzcGxheSBuYW1l LiAgVmFyaW91cyBmb3J1bSBzb2Z0d2FyZSwgZW1haWwgdGlja2V0aW5nIHNvZnR3YXJlLCB0aGUg ZW1haWwgbm90aWZpY2F0aW9ucw0KPiBmcm9tIHZhcmlvdXMgd2ViIGJhc2VkIG1lc3NhZ2luZyBz eXN0ZW1zLCB0aGV5IGFsbCBmYWlsIHRvIGFwcGx5IGF1dGhvcnNoaXAgaW4gaG93IHlvdSBzYXku DQoNCkkgdGhpbmsgb2YgbXlzZWxmIGFzIGEgdGVjaG5pY2FsIGVtYWlsIGd1eSwgYnV0IEnigJlt IHN1cnByaXNlZCBhdCBob3cgbXVjaCBvZiBhbiBhdmVyYWdlIHVzZXIgSSBhbS4gSWYgSSB3ZXJl IHRvIGdldCBhbiBlbWFpbCBmcm9tIHNvbWVvbmUgKG9yIEkgZ3Vlc3MgbXlzZWxmKSBvbiB0aGlz IGxpc3QgbGlrZSB0aGlzOg0KDQpGcm9tOiBUZXJyeSBaaW5rIHZpYSBJRVRGLURNQVJDIDxkbWFy Y0BpZXRmLm9yZz4NCg0KVGhpcyBhbHJlYWR5IGhhcHBlbnMgZnJvbSBvdGhlciBsaXN0cyBJIGFt IG9uLCBJIGRvbuKAmXQgdGhpbmsgdHdpY2UgYWJvdXQgaXQuIEkgc29ydCBvZiBldmVuIHRoaW5r IOKAnEhleSwgdGhhdCB3b3JrcyBiZXR0ZXIgZm9yIG1lIeKAnQ0KDQpBbmQgaWYgdGhlcmUgd2Vy ZSBzb21ldGhpbmcgbGlrZSB0aGlzIGluIG90aGVyIGhlYWRlcnMgdGhhdCByZXRhaW5zIHRoZSBv cmlnaW5hbCBzZW5kZXJzOg0KDQpSZXBseS1Ubzogb3JpZ2luYWxTZW5kZXJAZXhhbXBsZS5jb20N ClNlbmRlcjogZG1hcmMgPGRtYXJjLWJvdW5jZXNAaWV0Zi5vcmc+DQoNClRoZW4gc28gbXVjaCB0 aGUgYmV0dGVyLCBJIGRvbuKAmXQgZXZlbiBub3RpY2UgdGhlbSB1bmxlc3MgSSBoaXQgUmVwbHku IEFzIEJyYW5kb24gc2F5cywgSeKAmXZlIGFscmVhZHkgYmVlbiBjb25kaXRpb25lZCB0byBsb29r IGZvciB0aGUgc2FtZSBlbWFpbCBhZGRyZXNzLCBmb3IgZXhhbXBsZSBJIGdldCB0aGlzIGZyb20g TGlua2VkSW46DQoNCkZyb206IEV4YW1wbGUgUGVyc29uICh2aWEgTGlua2VkSW4pIDxtZXNzYWdl cy1ub3JlcGx5QGxpbmtlZGluLmNvbT4NCg0KSSBnZXQgdGhhdCBzb21lIHBlb3BsZSBkb27igJl0 IGxpa2UgaG93IHRoZSBGcm9tOiBhZGRyZXNzIG5vIGxvbmdlciByZWZsZWN0cyB0aGUg4oCccmVh bOKAnSBzZW5kZXIsIGJ1dCBJIGRvbuKAmXQganVzdCB1c2UgdGhlIGVtYWlsIGFkZHJlc3MgdG8g aWRlbnRpZnkgYSBzZW5kZXIuIEkgdXNlIHRoZSBEaXNwbGF5IE5hbWUsIHRvbywgYW5kIHB1dHRp bmcgc29tZW9uZeKAmXMgbmFtZSBhbmQgdGhlIHNvdXJjZSBpbnRvIHRoZSBEaXNwbGF5IE5hbWUg aXMgaGVscGZ1bC4NCg0KVGhhdCBkb2VzbuKAmXQgbWVhbiB0aGVyZSBhcmVu4oCZdCBiZXR0ZXIg b3B0aW9ucy4gQnV0IHRoaXMgd29ya2Fyb3VuZCDigJMgYXQgbGVhc3QgZm9yIG1lIOKAkyBpcyBu b3QgdGhhdCBwYWluZnVsLg0KDQotLVRlcnJ5DQoNCkZyb206IGRtYXJjIFttYWlsdG86ZG1hcmMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyYW5kb24gTG9uZw0KU2VudDogVGh1cnNk YXksIE5vdmVtYmVyIDMsIDIwMTYgNDowNCBQTQ0KVG86IERhdmUgQ3JvY2tlciA8ZGNyb2NrZXJA YmJpdy5uZXQ+DQpDYzogZG1hcmNAaWV0Zi5vcmc7IElFVEYgPGlldGZAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW2RtYXJjLWlldGZdIElkZW50aWZpY2F0aW9uIG9mIGFuIGVtYWlsIGF1dGhvciAo d2FzIC0gUmU6IElFVEYgTWFpbGluZyBMaXN0cyBhbmQgRE1BUkMpDQoNCg0KDQpPbiBXZWQsIE5v diAyLCAyMDE2IGF0IDM6NTEgUE0sIERhdmUgQ3JvY2tlciA8ZGNyb2NrZXJAZ21haWwuY29tPG1h aWx0bzpkY3JvY2tlckBnbWFpbC5jb20+PiB3cm90ZToNCk9uIDExLzIvMjAxNiAyOjU4IFBNLCBC cmFuZG9uIExvbmcgd3JvdGU6DQpUaGUgZGlmZmVyZW5jZSBpcyBtb3N0bHkgY29zbWV0aWMsIHRo b3VnaCBkZXBlbmRpbmcgb24geW91ciBtYWlsIGNsaWVudCwNCnRoZXJlIG1heSBiZSBvdGhlciBk b3duc2lkZXMuICBBbmQgaXQgbWF5IHZpb2xhdGUgUkZDIDUzMjIuDQoNCkJyYW5kb24sDQoNCllv dSBrbm93IHRoYXQgSSBrbm93IHRoYXQgdGhlIGF0dGFja3MgdGhhdCBnZW5lcmF0ZWQgdGhlIHVz ZSBvZiBETUFSQywgd2hpY2ggaXMgY2F1c2luZyB0aGUgY3VycmVudCBzaXR1YXRpb24sIGFyZSBz ZXJpb3VzLiAgSSdtIG1lbnRpb25pbmcgdGhhdCBoZXJlIHRvIG1ha2Ugc3VyZSB0aGUgY29udGV4 dCBmb3Igd2hhdCBmb2xsb3dzIGlzIGNsZWFyLi4uDQoNCkVtYWlsIGlzIGNvbW11bmljYXRpb24g YmV0d2VlbiBhbiBhdXRob3IgYW5kIG9uZSBvciBtb3JlIHJlY2lwaWVudHMuDQoNCkV2ZXJ5dGhp bmcgaW4gYmV0d2VlbiB0aGVtIGlzICdvdmVyaGVhZCcuICBUaGUgb3ZlcmhlYWQgZnVuY3Rpb25z IG5lZWQgdG8gYmUgY2FyZWZ1bCB0byBhdm9pZCBjYXZhbGllcmx5IHJlZHVjaW5nIHRoZSB1dGls aXR5IG9mIGVtYWlsLCBldmVuIGFzIHRoZSBjaGFuZ2VzIGFyZSBtZWFudCB0byBhaWQgaW4gdGhl IHVzZSBvZiBlbWFpbC4NCg0KSWRlbnRpZmljYXRpb24gb2YgdGhlIGF1dGhvciBhbmQgcmVjaXBp ZW50cyBpcyBtZWFuaW5nZnVsIHRvIHRoZW0uIFRoYXQncyBub3QgJ2Nvc21ldGljJy4NCg0KQW5k IHNvZnR3YXJlIHRvb2xzIGVtcGxveWVkIGJ5IHVzZXJzIHRha2UgYWR2YW50YWdlIG9mIHRoaXMg aWRlbnRpZmljYXRpb24sIGZvciBzZWFyY2hpbmcgYW5kIGZvciBvcmdhbml6aW5nLg0KDQpJbmNs dWRpbmcgR21haWwsIHdoaWNoIGRvZXNuJ3QgaGFuZGxlIHRoaXMgd29ya2Fyb3VuZCB3ZWxsLCBl aXRoZXIuDQoNCkluIGEgaGlnaGx5IGRpdmVyc2Ugd29ybGQsIG9uZSBvZiB0aGUgcHJvYmxlbXMg b2YgYmVpbmcgYSB2ZXJ5IG1ham9yIHBsYXllciBpcyB0aGF0IGl0IGJlY29tZXMgZmFyIHRvbyBl YXN5IG5vdCB0byBzZWUgYWxsIHRoZSBkaXZlcnNpdHkgb3IgdG8gYXBwcmVjaWF0ZSBpdHMgaW1w b3J0IHRvIG90aGVycy4gQWZ0ZXIgYWxsLCBtb3N0IG9mIHRoYXQgZGl2ZXJzaXR5IGlzIHNlZW4g YXMgc3VjaCBhIHRpbnkgcGVyY2VudGFnZSBvZiB0aGUgYWN0aXZpdHkuIFRoaXMgaXMgdGhlIGVz c2VuY2Ugb2YgZXRobm9jZW50cmlzbS4NCg0KQ2hhbmdpbmcgdGhlIGNvbnRlbnRzIG9mIHRoZSBy ZmM1MzIyLkZyb20gZmllbGQgaXMgY2hhbmdpbmcgYmFzaWMgc3RhdGVtZW50cyBhYm91dCBhdXRo b3JzaGlwLg0KDQpQZXJoYXBzIHRoZXJlJ3Mgbm8gcHJhY3RpY2FsIGNob2ljZSByaWdodCBub3cs IGJ1dCBwbGVhc2UgbGV0J3Mgbm90IGJlIGNhdmFsaWVyIGFib3V0IGl0cyBpbXBvcnQuDQoNCkkg dGhpbmsgdGVjaG5pY2FsIGZhbnMgb2YgZW1haWwgcGVyaGFwcyBhdHRhY2ggbW9yZSBpbXBvcnQg dG8gdGhlIHJmYzUzMjIuZnJvbSBmaWVsZCB0aGFuIGRvZXMgdGhlIGF2ZXJhZ2UgdXNlci4gIENl cnRhaW5seSwgZG93bnNpZGVzIGV4aXN0LiAgVGhhdCBzYWlkLCBmYWNlYm9vayBub3RpZmljYXRp b25zIHRvZGF5IGFsbCBjb21lIGZyb20gdGhlIHNhbWUgcGVyLXVzZXIgYWRkcmVzcywgd2l0aCB0 aGUgYWN0dWFsIGNvbW1lbnRlciBhcyBqdXN0IHRoZSBkaXNwbGF5IG5hbWUuICBWYXJpb3VzIGZv cnVtIHNvZnR3YXJlLCBlbWFpbCB0aWNrZXRpbmcgc29mdHdhcmUsIHRoZSBlbWFpbCBub3RpZmlj YXRpb25zIGZyb20gdmFyaW91cyB3ZWIgYmFzZWQgbWVzc2FnaW5nIHN5c3RlbXMsIHRoZXkgYWxs IGZhaWwgdG8gYXBwbHkgYXV0aG9yc2hpcCBpbiBob3cgeW91IHNheS4NCg0KWWVzLCBtYWlsaW5n IGxpc3RzIGhhdmUgZXhpc3RlZCBpbiB0aGlzIGZvcm0gZm9yIHNvbWUgdGltZSwgYW5kIHRoZXkg YXJlIGEgZ29vZCBhbmQgdml0YWwgc3lzdGVtLCBhbmQgdGhlIGRvd25zaWRlcyBhcmUgcmVhbC4N Cg0KTm90ZSBhbHNvIHRoYXQgSSBpbWFnaW5lIHRoYXQgbWFpbGluZyBsaXN0IHNvZnR3YXJlIHdo aWNoIHN1cHBvcnRzIEVBSSBtZXNzYWdlcyBtaWdodCBhbHNvIG5lZWQgdG8gbXVuZ2UgdGhlIEZy b20gaGVhZGVyIHRvIGRvd25ncmFkZSB0aGUgbWVzc2FnZSBmb3IgZGVsaXZlcnkgdG8gbm9uLUVB SSBlbmFibGVkIHJlY2VpdmVycy4NCg0KSSdtIG5vdCBzdXJlIGlmIG15IGNvbW1lbnQgd2FzIGhl YXJkIGluIHRoZSByZWNlbnQgQVJDIHJvdW5kIHRhYmxlLCB3aGVyZSBmb2xrcyB3ZXJlIHF1ZXN0 aW9uaW5nIHRoZSBvdmVyYWxsIGNvbXBsZXhpdHkgb2YgQVJDLCBidXQgSSdtIGZhaXJseSBzZXJp b3VzIGluIHNheWluZyB0aGF0IGFsbCBvZiBvdXIgZGlzY3Vzc2lvbnMgb24gd29yayBhcm91bmRz IGFuZCB0ZWNobmljYWwgbWV0aG9kcyBmb3IgdHJ5aW5nIHRvIG1ha2UgRE1BUkMgd29yayB3aXRo IG1haWxpbmcgbGlzdHMsIGFuZCBmcm9tIGhlYWRlciBtdW5naW5nIGlzIGJ5IGZhciB0aGUgc2lt cGxlc3QuICBObyB0cnVzdC9yZXB1dGF0aW9uIHN5c3RlbXMsIG5vIG1hbnVhbCB3aGl0ZWxpc3Rp bmcsIG5vICJtYWdpYyBzYXVjZSIsIG5vIG5ldyBzb2Z0d2FyZSB0byBiZSBpbnN0YWxsZWQgYnkg cmVjZWl2ZXJzLg0KDQpBUkMgd2lsbCBhZGQgZ3JlYXRseSB0byB0aGUgc2l6ZSBvZiBtYWlsIGhl YWRlcnMsIHdoaWNoIHNvbWUgZm9sa3Mgb24gbWFpbG9wIHN0aWxsIHRoaW5rIHNob3VsZCBiZSB0 aW55IGFuZCB0YWxrIGFib3V0IGF1dG9tYXRpY2FsbHkgbWFya2luZyBsYXJnZSBoZWFkZXJzIGFz IHNwYW0uDQoNCkFSQyB3aWxsIGFkZCBncmVhdGx5IHRvIHRoZSBwcml2YWN5IGNvbmNlcm5zIHdo aWNoIHdlcmUgcmFpc2VkIGxhc3Qgd2VlayBvbiB0aGUgREtJTSBJRVRGIGxpc3QsIHdoZXJlIG5v dyBub3Qgb25seSBpcyBhIG1lc3NhZ2UgaGF2ZSBhdHRlc3RhdGlvbiBvZiBvcmlnaW4sIGJ1dCB0 aGF0IGF0dGVzdGF0aW9uIHdpbGwgc3Vydml2ZSBzb21lIGFtb3VudCBvZiBmb3J3YXJkaW5nL21v ZGlmaWNhdGlvbiwgYW5kIHRoZSBwYXRoIGl0IHRvb2sgd2lsbCBhbHNvIGJlIGF0dGVzdGVkIHRv Lg0KDQpBUkMgd2lsbCByZXF1aXJlIG5ldyBzb2Z0d2FyZSB0byBiZSBpbnN0YWxsZWQgYnkgbWFp bGluZyBsaXN0IHByb3ZpZGVycyBhbmQgYW55IHJlY2VpdmVycyB3aG8gaW1wbGVtZW50IERNQVJD LiAgRXZlbiBhZnRlciBiZWluZyBpbnN0YWxsZWQsIHRoZXJlIGlzIHN0aWxsIG1vcmUgd29yayBp biBvcmRlciB0byBhbGxvdyB0aGUgbWFpbGluZyBsaXN0IG1lc3NhZ2VzIHRocm91Z2guDQoNCkJy YW5kb24NCg0KDQo= --_000_CO2PR00MB0103566D260F9BFEC7166C9B96A20CO2PR00MB0103namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJIHRoaW5rIHRl Y2huaWNhbCBmYW5zIG9mIGVtYWlsIHBlcmhhcHMgYXR0YWNoIG1vcmUgaW1wb3J0IHRvIHRoZSBy ZmM1MzIyLmZyb20gZmllbGQgdGhhbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyBkb2VzIHRoZSBhdmVyYWdlIHVzZXIuJm5ic3A7IENlcnRhaW5seSwgZG93bnNpZGVz IGV4aXN0LiZuYnNwOyBUaGF0IHNhaWQsIGZhY2Vib29rIG5vdGlmaWNhdGlvbnMNCjxicj4NCiZn dDsgdG9kYXkgYWxsIGNvbWUgZnJvbSB0aGUgc2FtZSBwZXItdXNlciBhZGRyZXNzLCB3aXRoIHRo ZSBhY3R1YWwgY29tbWVudGVyIGFzIGp1c3QgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsgZGlzcGxheSBuYW1lLiZuYnNwOyBWYXJpb3VzIGZvcnVtIHNvZnR3 YXJlLCBlbWFpbCB0aWNrZXRpbmcgc29mdHdhcmUsIHRoZSBlbWFpbCBub3RpZmljYXRpb25zDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgZnJvbSB2YXJpb3VzIHdl YiBiYXNlZCBtZXNzYWdpbmcgc3lzdGVtcywgdGhleSBhbGwgZmFpbCB0byBhcHBseSBhdXRob3Jz aGlwIGluIGhvdyB5b3Ugc2F5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIG9mIG15 c2VsZiBhcyBhIHRlY2huaWNhbCBlbWFpbCBndXksIGJ1dCBJ4oCZbSBzdXJwcmlzZWQgYXQgaG93 IG11Y2ggb2YgYW4gYXZlcmFnZSB1c2VyIEkgYW0uIElmIEkgd2VyZSB0byBnZXQgYW4gZW1haWwg ZnJvbSBzb21lb25lIChvciBJIGd1ZXNzIG15c2VsZikgb24gdGhpcyBsaXN0IGxpa2UgdGhpczo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJvbTogVGVycnkgWmluayB2aWEgSUVURi1ETUFSQyAm bHQ7ZG1hcmNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPlRoaXMgYWxyZWFkeSBoYXBw ZW5zIGZyb20gb3RoZXIgbGlzdHMgSSBhbSBvbiwgSSBkb27igJl0IHRoaW5rIHR3aWNlIGFib3V0 IGl0LiBJIHNvcnQgb2YgZXZlbiB0aGluayDigJxIZXksIHRoYXQgd29ya3MgYmV0dGVyIGZvciBt ZSHigJ0NCjxvOnA+PC9vOnA+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9N YWlsRW5kQ29tcG9zZSI+QW5kIGlmIHRoZXJlIHdlcmUgc29tZXRoaW5nIGxpa2UgdGhpcyBpbiBv dGhlciBoZWFkZXJzIHRoYXQgcmV0YWlucyB0aGUgb3JpZ2luYWwgc2VuZGVyczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsRW5kQ29tcG9zZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2Ui PlJlcGx5LVRvOiBvcmlnaW5hbFNlbmRlckBleGFtcGxlLmNvbTxicj4NClNlbmRlcjogZG1hcmMg Jmx0O2RtYXJjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBv c2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj5UaGVuIHNvIG11Y2ggdGhl IGJldHRlciwgSSBkb27igJl0IGV2ZW4gbm90aWNlIHRoZW0gdW5sZXNzIEkgaGl0IFJlcGx5LiBB cyBCcmFuZG9uIHNheXMsIEnigJl2ZSBhbHJlYWR5IGJlZW4gY29uZGl0aW9uZWQgdG8gbG9vayBm b3IgdGhlIHNhbWUgZW1haWwgYWRkcmVzcywgZm9yIGV4YW1wbGUgSSBnZXQgdGhpcyBmcm9tIExp bmtlZEluOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsRW5kQ29tcG9zZSI+RnJvbTogRXhhbXBsZSBQZXJzb24gKHZpYSZuYnNwO0xpbmtlZElu KSAmbHQ7bWVzc2FnZXMtbm9yZXBseUBsaW5rZWRpbi5jb20mZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj5JIGdldCB0 aGF0IHNvbWUgcGVvcGxlIGRvbuKAmXQgbGlrZSBob3cgdGhlIEZyb206IGFkZHJlc3Mgbm8gbG9u Z2VyIHJlZmxlY3RzIHRoZSDigJxyZWFs4oCdIHNlbmRlciwgYnV0IEkgZG9u4oCZdCBqdXN0IHVz ZSB0aGUgZW1haWwgYWRkcmVzcyB0byBpZGVudGlmeSBhIHNlbmRlci4gSSB1c2UgdGhlIERpc3Bs YXkgTmFtZSwgdG9vLCBhbmQgcHV0dGluZw0KIHNvbWVvbmXigJlzIG5hbWUgYW5kIHRoZSBzb3Vy Y2UgaW50byB0aGUgRGlzcGxheSBOYW1lIGlzIGhlbHBmdWwuIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxF bmRDb21wb3NlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+VGhhdCBkb2Vz buKAmXQgbWVhbiB0aGVyZSBhcmVu4oCZdCBiZXR0ZXIgb3B0aW9ucy4gQnV0IHRoaXMgd29ya2Fy b3VuZCDigJMgYXQgbGVhc3QgZm9yIG1lIOKAkyBpcyBub3QgdGhhdCBwYWluZnVsLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxFbmRDb21wb3NlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9z ZSI+LS1UZXJyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+ PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IGRtYXJjIFttYWlsdG86 ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+QnJhbmRvbiBMb25n PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAzLCAyMDE2IDQ6MDQgUE08YnI+ DQo8Yj5Ubzo8L2I+IERhdmUgQ3JvY2tlciAmbHQ7ZGNyb2NrZXJAYmJpdy5uZXQmZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBkbWFyY0BpZXRmLm9yZzsgSUVURiAmbHQ7aWV0ZkBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkbWFyYy1pZXRmXSBJZGVudGlmaWNhdGlvbiBvZiBhbiBl bWFpbCBhdXRob3IgKHdhcyAtIFJlOiBJRVRGIE1haWxpbmcgTGlzdHMgYW5kIERNQVJDKTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gV2VkLCBOb3YgMiwgMjAxNiBhdCAzOjUxIFBNLCBEYXZlIENyb2Nr ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkY3JvY2tlckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5kY3JvY2tlckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMS8yLzIwMTYgMjo1OCBQTSwgQnJhbmRv biBMb25nIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBkaWZmZXJlbmNlIGlzIG1vc3RseSBjb3NtZXRpYywgdGhvdWdoIGRlcGVuZGlu ZyBvbiB5b3VyIG1haWwgY2xpZW50LDxicj4NCnRoZXJlIG1heSBiZSBvdGhlciBkb3duc2lkZXMu Jm5ic3A7IEFuZCBpdCBtYXkgdmlvbGF0ZSBSRkMgNTMyMi48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkJyYW5kb24sPGJyPg0KPGJyPg0K WW91IGtub3cgdGhhdCBJIGtub3cgdGhhdCB0aGUgYXR0YWNrcyB0aGF0IGdlbmVyYXRlZCB0aGUg dXNlIG9mIERNQVJDLCB3aGljaCBpcyBjYXVzaW5nIHRoZSBjdXJyZW50IHNpdHVhdGlvbiwgYXJl IHNlcmlvdXMuJm5ic3A7IEknbSBtZW50aW9uaW5nIHRoYXQgaGVyZSB0byBtYWtlIHN1cmUgdGhl IGNvbnRleHQgZm9yIHdoYXQgZm9sbG93cyBpcyBjbGVhci4uLjxicj4NCjxicj4NCkVtYWlsIGlz IGNvbW11bmljYXRpb24gYmV0d2VlbiBhbiBhdXRob3IgYW5kIG9uZSBvciBtb3JlIHJlY2lwaWVu dHMuPGJyPg0KPGJyPg0KRXZlcnl0aGluZyBpbiBiZXR3ZWVuIHRoZW0gaXMgJ292ZXJoZWFkJy4m bmJzcDsgVGhlIG92ZXJoZWFkIGZ1bmN0aW9ucyBuZWVkIHRvIGJlIGNhcmVmdWwgdG8gYXZvaWQg Y2F2YWxpZXJseSByZWR1Y2luZyB0aGUgdXRpbGl0eSBvZiBlbWFpbCwgZXZlbiBhcyB0aGUgY2hh bmdlcyBhcmUgbWVhbnQgdG8gYWlkIGluIHRoZSB1c2Ugb2YgZW1haWwuPGJyPg0KPGJyPg0KSWRl bnRpZmljYXRpb24gb2YgdGhlIGF1dGhvciBhbmQgcmVjaXBpZW50cyBpcyBtZWFuaW5nZnVsIHRv IHRoZW0uIFRoYXQncyBub3QgJ2Nvc21ldGljJy48YnI+DQo8YnI+DQpBbmQgc29mdHdhcmUgdG9v bHMgZW1wbG95ZWQgYnkgdXNlcnMgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhpcyBpZGVudGlmaWNhdGlv biwgZm9yIHNlYXJjaGluZyBhbmQgZm9yIG9yZ2FuaXppbmcuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmNsdWRpbmcgR21haWws IHdoaWNoIGRvZXNuJ3QgaGFuZGxlIHRoaXMgd29ya2Fyb3VuZCB3ZWxsLCBlaXRoZXIuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IGEgaGlnaGx5IGRpdmVyc2Ugd29ybGQsIG9uZSBvZiB0aGUgcHJvYmxlbXMgb2YgYmVpbmcgYSB2 ZXJ5IG1ham9yIHBsYXllciBpcyB0aGF0IGl0IGJlY29tZXMgZmFyIHRvbyBlYXN5IG5vdCB0byBz ZWUgYWxsIHRoZSBkaXZlcnNpdHkgb3IgdG8gYXBwcmVjaWF0ZSBpdHMgaW1wb3J0IHRvIG90aGVy cy4gQWZ0ZXIgYWxsLCBtb3N0IG9mIHRoYXQgZGl2ZXJzaXR5IGlzIHNlZW4gYXMgc3VjaCBhIHRp bnkgcGVyY2VudGFnZQ0KIG9mIHRoZSBhY3Rpdml0eS4gVGhpcyBpcyB0aGUgZXNzZW5jZSBvZiBl dGhub2NlbnRyaXNtLjxicj4NCjxicj4NCkNoYW5naW5nIHRoZSBjb250ZW50cyBvZiB0aGUgcmZj NTMyMi5Gcm9tIGZpZWxkIGlzIGNoYW5naW5nIGJhc2ljIHN0YXRlbWVudHMgYWJvdXQgYXV0aG9y c2hpcC48YnI+DQo8YnI+DQpQZXJoYXBzIHRoZXJlJ3Mgbm8gcHJhY3RpY2FsIGNob2ljZSByaWdo dCBub3csIGJ1dCBwbGVhc2UgbGV0J3Mgbm90IGJlIGNhdmFsaWVyIGFib3V0IGl0cyBpbXBvcnQu PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHRoaW5rIHRlY2huaWNhbCBmYW5zIG9mIGVtYWlsIHBlcmhhcHMgYXR0YWNoIG1vcmUg aW1wb3J0IHRvIHRoZSByZmM1MzIyLmZyb20gZmllbGQgdGhhbiBkb2VzIHRoZSBhdmVyYWdlIHVz ZXIuJm5ic3A7IENlcnRhaW5seSwgZG93bnNpZGVzIGV4aXN0LiZuYnNwOyBUaGF0IHNhaWQsIGZh Y2Vib29rIG5vdGlmaWNhdGlvbnMgdG9kYXkgYWxsIGNvbWUgZnJvbSB0aGUgc2FtZSBwZXItdXNl ciBhZGRyZXNzLCB3aXRoIHRoZSBhY3R1YWwNCiBjb21tZW50ZXIgYXMganVzdCB0aGUgZGlzcGxh eSBuYW1lLiZuYnNwOyBWYXJpb3VzIGZvcnVtIHNvZnR3YXJlLCBlbWFpbCB0aWNrZXRpbmcgc29m dHdhcmUsIHRoZSBlbWFpbCBub3RpZmljYXRpb25zIGZyb20gdmFyaW91cyB3ZWIgYmFzZWQgbWVz c2FnaW5nIHN5c3RlbXMsIHRoZXkgYWxsIGZhaWwgdG8gYXBwbHkgYXV0aG9yc2hpcCBpbiBob3cg eW91IHNheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+WWVzLCBtYWlsaW5nIGxpc3RzIGhhdmUgZXhpc3RlZCBpbiB0aGlzIGZvcm0gZm9yIHNv bWUgdGltZSwgYW5kIHRoZXkgYXJlIGEgZ29vZCBhbmQgdml0YWwgc3lzdGVtLCBhbmQgdGhlIGRv d25zaWRlcyBhcmUgcmVhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Tm90ZSBhbHNvIHRoYXQgSSBpbWFnaW5lIHRoYXQgbWFpbGluZyBsaXN0 IHNvZnR3YXJlIHdoaWNoIHN1cHBvcnRzIEVBSSBtZXNzYWdlcyBtaWdodCBhbHNvIG5lZWQgdG8g bXVuZ2UgdGhlIEZyb20gaGVhZGVyIHRvIGRvd25ncmFkZSB0aGUgbWVzc2FnZSBmb3IgZGVsaXZl cnkgdG8gbm9uLUVBSSBlbmFibGVkIHJlY2VpdmVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBzdXJlIGlmIG15IGNvbW1lbnQg d2FzIGhlYXJkIGluIHRoZSByZWNlbnQgQVJDIHJvdW5kIHRhYmxlLCB3aGVyZSBmb2xrcyB3ZXJl IHF1ZXN0aW9uaW5nIHRoZSBvdmVyYWxsIGNvbXBsZXhpdHkgb2YgQVJDLCBidXQgSSdtIGZhaXJs eSBzZXJpb3VzIGluIHNheWluZyB0aGF0IGFsbCBvZiBvdXIgZGlzY3Vzc2lvbnMgb24gd29yayBh cm91bmRzIGFuZCB0ZWNobmljYWwgbWV0aG9kcyBmb3IgdHJ5aW5nDQogdG8gbWFrZSBETUFSQyB3 b3JrIHdpdGggbWFpbGluZyBsaXN0cywgYW5kIGZyb20gaGVhZGVyIG11bmdpbmcgaXMgYnkgZmFy IHRoZSBzaW1wbGVzdC4mbmJzcDsgTm8gdHJ1c3QvcmVwdXRhdGlvbiBzeXN0ZW1zLCBubyBtYW51 YWwgd2hpdGVsaXN0aW5nLCBubyAmcXVvdDttYWdpYyBzYXVjZSZxdW90Oywgbm8gbmV3IHNvZnR3 YXJlIHRvIGJlIGluc3RhbGxlZCBieSByZWNlaXZlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFSQyB3aWxsIGFkZCBncmVhdGx5IHRvIHRo ZSBzaXplIG9mIG1haWwgaGVhZGVycywgd2hpY2ggc29tZSBmb2xrcyBvbiBtYWlsb3Agc3RpbGwg dGhpbmsgc2hvdWxkIGJlIHRpbnkgYW5kIHRhbGsgYWJvdXQgYXV0b21hdGljYWxseSBtYXJraW5n IGxhcmdlIGhlYWRlcnMgYXMgc3BhbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QVJDIHdpbGwgYWRkIGdyZWF0bHkgdG8gdGhlIHByaXZhY3kg Y29uY2VybnMgd2hpY2ggd2VyZSByYWlzZWQgbGFzdCB3ZWVrIG9uIHRoZSBES0lNIElFVEYgbGlz dCwgd2hlcmUgbm93IG5vdCBvbmx5IGlzIGEgbWVzc2FnZSBoYXZlIGF0dGVzdGF0aW9uIG9mIG9y aWdpbiwgYnV0IHRoYXQgYXR0ZXN0YXRpb24gd2lsbCBzdXJ2aXZlIHNvbWUgYW1vdW50IG9mIGZv cndhcmRpbmcvbW9kaWZpY2F0aW9uLCBhbmQgdGhlDQogcGF0aCBpdCB0b29rIHdpbGwgYWxzbyBi ZSBhdHRlc3RlZCB0by48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QVJDIHdpbGwgcmVxdWlyZSBuZXcgc29mdHdhcmUgdG8gYmUgaW5zdGFsbGVk IGJ5IG1haWxpbmcgbGlzdCBwcm92aWRlcnMgYW5kIGFueSByZWNlaXZlcnMgd2hvIGltcGxlbWVu dCBETUFSQy4mbmJzcDsgRXZlbiBhZnRlciBiZWluZyBpbnN0YWxsZWQsIHRoZXJlIGlzIHN0aWxs IG1vcmUgd29yayBpbiBvcmRlciB0byBhbGxvdyB0aGUgbWFpbGluZyBsaXN0IG1lc3NhZ2VzIHRo cm91Z2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJyYW5kb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_CO2PR00MB0103566D260F9BFEC7166C9B96A20CO2PR00MB0103namp_-- From nobody Fri Nov 4 14:22:39 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCC01296B8 for ; Fri, 4 Nov 2016 14:22:36 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JTV_v0rQ4rv for ; Fri, 4 Nov 2016 14:22:34 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 CEA761296B6 for ; Fri, 4 Nov 2016 14:22:33 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id q130so113878819qke.1 for ; Fri, 04 Nov 2016 14:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IiF7gAu7laWzkCEwUTUeD5nNjTImY6IKTu7nfrtZfDc=; b=XtVD0AMes1sVUj94wjgsFkIe1K1DGa94nIjnayYqMAwQjzAp28O4Iix+LZYFLWI2KQ bAyr7a/dA2h3d79jY4ygdHhGQmJVVT2rtVLWHBLkdvQuF7f9DLS9pmluB73fEf7eeZbc kVACAgHiL8FJv2GITObK8/Tg5bh25Wzjt9AXQ++s6VAE8kt5WJthXXvfWv9iOd5TQw52 w+Qc9Xt0TxmYg0YUf1RxBs40upfOuAxgvFgkCsYLnVl4uxByvujOEcxoQbz0v1mZUSyo Gc4g73a6wetvE5k1Qr2GV11jhveoXzTN1CrUIpyOaClsjCcqJT2ux+82mUKjeXX8t2/n XMDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IiF7gAu7laWzkCEwUTUeD5nNjTImY6IKTu7nfrtZfDc=; b=mBi8NvKo3osArkicytC4shKTOJyqo9E8uXNljUWKIcgh0VHGThAwEN7KFrWvd0Uy6T Y5tHSQt78ran8+C1CrhgIqbLbr8ABe3ghRJ6z24CFLPceds9MUR0hXp7BrVWe9vCW7ok U30uD2W4BqylKLabalHK1WVcU+9YrZ4quSd29jTXc45tIVaQFMaoe9N1NR2DZWhJrEQV xxmx7kH1dbGwc69t4xhSx+behSh6LFNoDx4GjjqVjllB5yH1GVFf3qK4BANHpA3UUXE9 yWoBA1EzoR4EofQONlqcFu4aNDjP9EUQcGshn9/NZCU1m64ZTzPDXph7c+ozWCndMz43 vZPA== X-Gm-Message-State: ABUngvfs2EUqmqqPRFQ30ZPXyc/J964nsTrDJRP6vAXmExfMXk81zWMGABwppCAbzqRFsw== X-Received: by 10.55.168.139 with SMTP id r133mr16923595qke.160.1478294553009; Fri, 04 Nov 2016 14:22:33 -0700 (PDT) Received: from [10.0.20.146] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 73sm8707912qky.2.2016.11.04.14.22.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 14:22:32 -0700 (PDT) From: Ted Lemon Message-Id: <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_65898BB7-E75F-4512-8252-CC4B1FF6D69F" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Fri, 4 Nov 2016 17:22:31 -0400 In-Reply-To: To: Terry Zink References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 21:22:37 -0000 --Apple-Mail=_65898BB7-E75F-4512-8252-CC4B1FF6D69F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 4, 2016, at 4:21 PM, Terry Zink = wrote: > And if there were something like this in other headers that retains = the original senders: > =20 > Reply-To: originalSender@example.com = > Sender: dmarc > >=20 I don=E2=80=99t think this is quite right=E2=80=94I think the Reply-To = needs to include all of the senders or else every reply will be an = off-list reply (would cut down on noise, admittedly). Otherwise this = would be a great solution. But because of the way it interacts with = MUAs, I do not think it would work in a way that doesn=E2=80=99t violate = the principle of least surprise. --Apple-Mail=_65898BB7-E75F-4512-8252-CC4B1FF6D69F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Nov 4, 2016, at 4:21 PM, Terry Zink <tzink@exchange.microsoft.com> wrote:
And if = there were something like this in other headers that retains the = original senders:
 
Reply-To: originalSender@example.com
Sender: dmarc <dmarc-bounces@ietf.org>


I don=E2=80=99t = think this is quite right=E2=80=94I think the Reply-To needs to include = all of the senders or else every reply will be an off-list reply (would = cut down on noise, admittedly).   Otherwise this would be a great = solution.   But because of the way it interacts with MUAs, I do not = think it would work in a way that doesn=E2=80=99t violate the principle = of least surprise.


= --Apple-Mail=_65898BB7-E75F-4512-8252-CC4B1FF6D69F-- From nobody Fri Nov 4 14:54:51 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3F31297A5; Fri, 4 Nov 2016 14:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9ZzoKgmdtGi; Fri, 4 Nov 2016 14:54:42 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0133.outbound.protection.outlook.com [104.47.32.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00A2129866; Fri, 4 Nov 2016 14:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B1j+UQz6rv5BPijnSH6eVH7RXyELNdPAJtYi4r5l6So=; b=G7kWZ3XujZ80z+cb1G+Bkvp9O+TyIz8HGTXyn/60C9TvFea8oKfUWECSH4+n+0ltV3kBnIAOKkjmqR4KV8HoLrgwWCfUP97QRQQV/nEbhal6/e3c2TY44K8aNtixhHuUoohTpPgA4/6rXSA5tbijTx2QPprj7h5txLnicDpOA2o= Received: from CO2PR00MB0103.namprd00.prod.outlook.com (10.166.215.148) by CO2PR00MB0103.namprd00.prod.outlook.com (10.166.215.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.733.0; Fri, 4 Nov 2016 21:54:38 +0000 Received: from CO2PR00MB0103.namprd00.prod.outlook.com ([10.166.215.148]) by CO2PR00MB0103.namprd00.prod.outlook.com ([10.166.215.148]) with mapi id 15.01.0733.000; Fri, 4 Nov 2016 21:54:33 +0000 From: Terry Zink To: Ted Lemon Thread-Topic: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) Thread-Index: AQHSNVuzHKOfGdWA1UyB+W+yk1I8ZKDH4laAgAFibQCAABOfgIAACFoQ Date: Fri, 4 Nov 2016 21:54:33 +0000 Message-ID: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> In-Reply-To: <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:c::6b3] x-ms-office365-filtering-correlation-id: 2159977d-c95a-4aa8-735f-08d404fd299d x-ms-office365-filtering-ht: Tenant x-microsoft-exchange-diagnostics: 1; CO2PR00MB0103; 7:zFN/hXO8HOtoFoUZCGF2roZM/QnbuGIzcSJSOI6vzNR8qZj2m99Ng67FP6NYT8I82Pxe0lwyQ520lDdWO+noGhaslZiCoASlvlovJfyCuYyOqGy0tYwfeaU4zpOvxWrZaEb5asJd/uuPtAeSIz7tnPDf7HXEziaU6BAGmKt8Xz+oovS7UO6UdstxOYdDIjZxcvRBaeIlSpQRkd5EXbiieJayoZStJlJ3j45kG87GLAmEP+NkQPk6zn8zX4SKva3lup+N6zKZKDMpsHM+nK6WwJkpgqBUukj32MMToAU1s4pK52A648iWy6mMoQKjy4oMBItXi31wwtRVgn6eJASi22TNPz724LqQa7UqgbdhYvAVq8bPX/rDh1Wl0HnZFiBI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR00MB0103; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(224505668447827)(140211028294663)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060229)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(100007014)(6061226)(6046074)(6047074)(6072074); SRVR:CO2PR00MB0103; BCL:0; PCL:0; RULEID:; SRVR:CO2PR00MB0103; x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(199003)(189002)(377454003)(9686002)(7736002)(7846002)(8936002)(68736007)(3660700001)(93886004)(10090500001)(74316002)(10290500002)(189998001)(19609705001)(10400500002)(5005710100001)(3280700002)(92566002)(8990500004)(87936001)(97736004)(19580395003)(5002640100001)(76576001)(8676002)(19580405001)(54356999)(76176999)(19625215002)(50986999)(42882006)(2950100002)(6916009)(2906002)(33656002)(110136003)(4326007)(101416001)(99286002)(16236675004)(81166006)(81156014)(19300405004)(86362001)(122556002)(106116001)(586003)(2900100001)(790700001)(105586002)(106356001)(7696004)(5660300001)(77096005)(6116002)(102836003)(15975445007)(197153002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR00MB0103; H:CO2PR00MB0103.namprd00.prod.outlook.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CO2PR00MB01034350A8C90A1E039336F796A20CO2PR00MB0103namp_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2016 21:54:33.4651 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0103 Archived-At: Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 21:54:45 -0000 --_000_CO2PR00MB01034350A8C90A1E039336F796A20CO2PR00MB0103namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IGhpdCDigJxSZXBseS1BbGzigJ0sIGF0IGxlYXN0IHdoZW4gSSB1c2UgR21haWwsIGl0 IGluY2x1ZGVzIGJvdGggdGhlIEZyb206IGFuZCB0aGUgUmVwbHktVG8gdXNpbmcgdGhlIHNjaGVt ZSBiZWxvdyAoSSB0ZXN0ZWQgaXQgb3V0IGp1c3Qgbm93KS4gSW4gT3V0bG9vayBkZXNrdG9wIEkg aGF2ZSB0byBhbHNvIGNvcHkvcGFzdGUgdGhlIEZyb206IGFkZHJlc3MgKG1haWxpbmcgbGlzdCku IEl04oCZcyBub3QgaWRlYWwgaW4gT3V0bG9vayBkZXNrdG9wLCBidXQgSSBjYW4gbGl2ZSB3aXRo IGl0Lg0KDQpJbiB0aGlzIGVtYWlsIGRpc2N1c3Npb24sIEkgaGl0IFJlcGx5LUFsbCBhbmQgaW5j bHVkZXMgVGVkIG9uIHRoZSBUbzosIGFuZCBkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0 Zi5vcmc+IGFuZCBpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPiBvbiB0aGUgY2Mu DQoNCkZyb206IFRlZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQpTZW50OiBGcmlk YXksIE5vdmVtYmVyIDQsIDIwMTYgMjoyMyBQTQ0KVG86IFRlcnJ5IFppbmsgPHR6aW5rQGV4Y2hh bmdlLm1pY3Jvc29mdC5jb20+DQpDYzogZG1hcmNAaWV0Zi5vcmc7IElFVEYgPGlldGZAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIElkZW50aWZpY2F0aW9uIG9mIGFuIGVtYWls IGF1dGhvciAod2FzIC0gUmU6IElFVEYgTWFpbGluZyBMaXN0cyBhbmQgRE1BUkMpDQoNCk9uIE5v diA0LCAyMDE2LCBhdCA0OjIxIFBNLCBUZXJyeSBaaW5rIDx0emlua0BleGNoYW5nZS5taWNyb3Nv ZnQuY29tPG1haWx0bzp0emlua0BleGNoYW5nZS5taWNyb3NvZnQuY29tPj4gd3JvdGU6DQpBbmQg aWYgdGhlcmUgd2VyZSBzb21ldGhpbmcgbGlrZSB0aGlzIGluIG90aGVyIGhlYWRlcnMgdGhhdCBy ZXRhaW5zIHRoZSBvcmlnaW5hbCBzZW5kZXJzOg0KDQpSZXBseS1Ubzogb3JpZ2luYWxTZW5kZXJA ZXhhbXBsZS5jb208bWFpbHRvOm9yaWdpbmFsU2VuZGVyQGV4YW1wbGUuY29tPg0KU2VuZGVyOiBk bWFyYyA8ZG1hcmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9y Zz4+DQoNCg0KSSBkb27igJl0IHRoaW5rIHRoaXMgaXMgcXVpdGUgcmlnaHTigJRJIHRoaW5rIHRo ZSBSZXBseS1UbyBuZWVkcyB0byBpbmNsdWRlIGFsbCBvZiB0aGUgc2VuZGVycyBvciBlbHNlIGV2 ZXJ5IHJlcGx5IHdpbGwgYmUgYW4gb2ZmLWxpc3QgcmVwbHkgKHdvdWxkIGN1dCBkb3duIG9uIG5v aXNlLCBhZG1pdHRlZGx5KS4gICBPdGhlcndpc2UgdGhpcyB3b3VsZCBiZSBhIGdyZWF0IHNvbHV0 aW9uLiAgIEJ1dCBiZWNhdXNlIG9mIHRoZSB3YXkgaXQgaW50ZXJhY3RzIHdpdGggTVVBcywgSSBk byBub3QgdGhpbmsgaXQgd291bGQgd29yayBpbiBhIHdheSB0aGF0IGRvZXNu4oCZdCB2aW9sYXRl IHRoZSBwcmluY2lwbGUgb2YgbGVhc3Qgc3VycHJpc2UuDQoNCg0K --_000_CO2PR00MB01034350A8C90A1E039336F796A20CO2PR00MB0103namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5 b3UgaGl0IOKAnFJlcGx5LUFsbOKAnSwgYXQgbGVhc3Qgd2hlbiBJIHVzZSBHbWFpbCwgaXQgaW5j bHVkZXMgYm90aCB0aGUgRnJvbTogYW5kIHRoZSBSZXBseS1UbyB1c2luZyB0aGUgc2NoZW1lIGJl bG93IChJIHRlc3RlZCBpdCBvdXQganVzdCBub3cpLiBJbiBPdXRsb29rIGRlc2t0b3AgSSBoYXZl IHRvIGFsc28gY29weS9wYXN0ZSB0aGUgRnJvbTogYWRkcmVzcyAobWFpbGluZyBsaXN0KS4gSXTi gJlzIG5vdCBpZGVhbA0KIGluIE91dGxvb2sgZGVza3RvcCwgYnV0IEkgY2FuIGxpdmUgd2l0aCBp dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhpcyBlbWFpbCBkaXNjdXNzaW9uLCBJIGhp dCBSZXBseS1BbGwgYW5kIGluY2x1ZGVzIFRlZCBvbiB0aGUgVG86LCBhbmQNCjxhIGhyZWY9Im1h aWx0bzpkbWFyY0BpZXRmLm9yZyI+ZG1hcmNAaWV0Zi5vcmc8L2E+IGFuZCA8YSBocmVmPSJtYWls dG86aWV0ZkBpZXRmLm9yZyI+DQppZXRmQGlldGYub3JnPC9hPiBvbiB0aGUgY2MuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxv OnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxF bmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFRlZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBm dWd1ZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDQsIDIwMTYgMjoy MyBQTTxicj4NCjxiPlRvOjwvYj4gVGVycnkgWmluayAmbHQ7dHppbmtAZXhjaGFuZ2UubWljcm9z b2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGRtYXJjQGlldGYub3JnOyBJRVRGICZsdDtpZXRm QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZdIElkZW50 aWZpY2F0aW9uIG9mIGFuIGVtYWlsIGF1dGhvciAod2FzIC0gUmU6IElFVEYgTWFpbGluZyBMaXN0 cyBhbmQgRE1BUkMpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBO b3YgNCwgMjAxNiwgYXQgNDoyMSBQTSwgVGVycnkgWmluayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR6 aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb20iPnR6aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmQgaWYgdGhlcmUgd2VyZSBzb21ldGhpbmcgbGlrZSB0aGlzIGluIG90aGVy IGhlYWRlcnMgdGhhdCByZXRhaW5zIHRoZSBvcmlnaW5hbCBzZW5kZXJzOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZXBseS1Ubzo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv Om9yaWdpbmFsU2VuZGVyQGV4YW1wbGUuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5v cmlnaW5hbFNlbmRlckBleGFtcGxlLmNvbTwvc3Bhbj48L2E+PGJyPg0KU2VuZGVyOiBkbWFyYyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgZG9u4oCZdCB0aGluayB0aGlzIGlzIHF1aXRlIHJpZ2h04oCUSSB0aGluayB0aGUgUmVwbHkt VG8gbmVlZHMgdG8gaW5jbHVkZSBhbGwgb2YgdGhlIHNlbmRlcnMgb3IgZWxzZSBldmVyeSByZXBs eSB3aWxsIGJlIGFuIG9mZi1saXN0IHJlcGx5ICh3b3VsZCBjdXQgZG93biBvbiBub2lzZSwgYWRt aXR0ZWRseSkuICZuYnNwOyBPdGhlcndpc2UgdGhpcyB3b3VsZCBiZSBhIGdyZWF0IHNvbHV0aW9u LiAmbmJzcDsgQnV0IGJlY2F1c2Ugb2YNCiB0aGUgd2F5IGl0IGludGVyYWN0cyB3aXRoIE1VQXMs IEkgZG8gbm90IHRoaW5rIGl0IHdvdWxkIHdvcmsgaW4gYSB3YXkgdGhhdCBkb2VzbuKAmXQgdmlv bGF0ZSB0aGUgcHJpbmNpcGxlIG9mIGxlYXN0IHN1cnByaXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CO2PR00MB01034350A8C90A1E039336F796A20CO2PR00MB0103namp_-- From nobody Fri Nov 4 15:49:37 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325C71299CB for ; Fri, 4 Nov 2016 15:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPi4qg3FllpL for ; Fri, 4 Nov 2016 15:49:34 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E224212986B for ; Fri, 4 Nov 2016 15:49:34 -0700 (PDT) Received: from [10.128.171.151] ([217.33.228.10]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id uA4MmnDr055728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Nov 2016 15:48:55 -0700 (PDT) (envelope-from smj@crash.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 segv.crash.com uA4MmnDr055728 Authentication-Results: segv.crash.com; sender-id=permerror header.from=smj@crash.com; auth=pass (PLAIN); spf=permerror smtp.mfrom=smj@crash.com X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com uA4MmnDr055728 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1478299736; bh=51NcEW8AVajXfJ5Gk82S9pnODkIKOiUf4QMXBlN4aQY=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=4OcCdXGZwCPWX5le1roUBBkcgwsQtlOOgfidi8zsRpKrV6fsfkuaqVo2h849g/xXe CVPxynD16T4SkBFYwZkS9Pzn5MCauWTp3TRzMNcpd7dWgV1h+4pN3W0w3wKE0p/eku S4hk/0++xLS+FveYYIgDWSEKmPGnQrafj0Karel7VVSD41jnB8POcc5Vu4D7zYqyyJ ljn1+64vWXc/BpKL/xGHvd+4UHW1eh0aUfjQTt+BI1C95h7jR+WD1bA/+u7JgLLSTA qDZzCPqg/hHjt8rQzwvK6aGKSKPSVYqygmNfyWNmdWQPYKYSqihl96PnRcJyu+E4tx vaXH7eS8e2ZyA== X-Authentication-Warning: segv.crash.com: Host [217.33.228.10] claimed to be [10.128.171.151] To: dmarc@ietf.org References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <20161102232357.b55vx7est7vjrdfo@thunk.org> <20161103134909.lnndzi6feaqfskyj@thunk.org> <2EB28059074B7148F8A1443E@JcK-HP8200> <958ED4C5-370B-4D64-8844-5E3D1699718B@fugue.com> <983679A1E92B0F2EF6DA195A@JcK-HP8200> From: Steven M Jones Message-ID: Date: Fri, 4 Nov 2016 22:48:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <983679A1E92B0F2EF6DA195A@JcK-HP8200> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Fri, 04 Nov 2016 15:48:56 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] IETF Mailing Lists and DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 22:49:36 -0000 A lot of points have been raised (again) in this thread - and I was only looking at what went to the DMARC WG list, forgetting that of course somebody would continue/branch the conversation by only using the ietf@ietf list... John Klensin highlighted a fundamental issue when he mentioned "the privacy advantages of hard-to-trace message origins." The assumption/decision that we want to keep that feature of existing email protocols - but still try to identify bad actors - is what started us down the road from SPF, to DomainKeys, to DKIM/SSP/ADSP, to DMARC. Are we going to revisit that assumption/decision? If not, we'd better look at how to make DMARC something we can all live with... Are we going to try and extend DMARC with something like an ATPS that scales? Is there an intersection of ATPS and ARC that might meet the need= ? --S. From nobody Mon Nov 7 11:41:34 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85839129987; Mon, 7 Nov 2016 11:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org 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 kqp_QMRgZowh; Mon, 7 Nov 2016 11:41:24 -0800 (PST) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [192.198.93.228]) (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 72E1512997F; Mon, 7 Nov 2016 11:41:22 -0800 (PST) Received: from zmcc-5-mta-1.zmailcloud.com (127.37.197.104.bc.googleusercontent.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id 99E1A520228; Mon, 7 Nov 2016 14:41:21 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 4B742C0FC8; Mon, 7 Nov 2016 13:41:21 -0600 (CST) Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 57II3-YJTBUW; Mon, 7 Nov 2016 13:41:19 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 2671CC1F8C; Mon, 7 Nov 2016 13:41:19 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.9.2 zmcc-5-mta-1.zmailcloud.com 2671CC1F8C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1478547679; bh=ZuV8FBuCiBL/SuRoNnzkoc/sZeZDVkeL15GnI/1HL+s=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=qbC4z655IvLzD88kK4NNTNl8DdlgIHxraTLXKPC3yAPowSMX0r5AaUbr9aZuSeneb CXpbCfOMc/2VxATNSaOgbPS/b71tTt7iYZU79dS+Fgv8mVGR94lRk871ig5um/yAsM xLaR6CHT3yrXavzbMqh4uNkR2nz4SyRXEvcnxmfE= X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YV5opfKV8MB4; Mon, 7 Nov 2016 13:41:19 -0600 (CST) Received: from zmcc-5-mailbox-1.zmailcloud.com (zmcc-5-mailbox-1.zmailcloud.com [10.240.0.12]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 0284FC0FC8; Mon, 7 Nov 2016 13:41:19 -0600 (CST) Date: Mon, 7 Nov 2016 13:41:18 -0600 (CST) From: Franck Martin To: Terry Zink Message-ID: <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_18678871_280273762.1478547678820" X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - FF49 (Mac)/8.6.0_GA_1194) Thread-Topic: Identification of an email author (was - Re: IETF Mailing Lists and DMARC) Thread-Index: AQHSNVuzHKOfGdWA1UyB+W+yk1I8ZKDH4laAgAFibQCAABOfgIAACFoQGS7fkDM= Archived-At: Cc: dmarc@ietf.org, Ted Lemon , IETF Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 19:41:26 -0000 ------=_Part_18678871_280273762.1478547678820 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The EAI WG found it was fine to remove the obligation to have an email addr= ess part in the mandatory RFC5322.From header, leaving only the display par= t to assert the original author.=20 So it seems that "IETF" is not completely in agreement on how to preserve t= he original author in emails.=20 So I think the example showed by Terry is as good as what is in EAI and thi= s is a matter of taste and UI designs, UI design and functions that usually= the IETF avoids to deal with...=20 From: "Terry Zink" =20 To: "Ted Lemon" =20 Cc: dmarc@ietf.org, "IETF" =20 Sent: Friday, November 4, 2016 2:54:33 PM=20 Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF= Mailing Lists and DMARC)=20 If you hit =E2=80=9CReply-All=E2=80=9D, at least when I use Gmail, it inclu= des both the From: and the Reply-To using the scheme below (I tested it out= just now). In Outlook desktop I have to also copy/paste the From: address = (mailing list). It=E2=80=99s not ideal in Outlook desktop, but I can live w= ith it.=20 In this email discussion, I hit Reply-All and includes Ted on the To:, and = dmarc@ietf.org and ietf@ietf.org on the cc.=20 From: Ted Lemon [mailto:mellon@fugue.com]=20 Sent: Friday, November 4, 2016 2:23 PM=20 To: Terry Zink =20 Cc: dmarc@ietf.org; IETF =20 Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF= Mailing Lists and DMARC)=20 On Nov 4, 2016, at 4:21 PM, Terry Zink < tzink@exchange.microsoft.com > wro= te:=20 And if there were something like this in other headers that retains the ori= ginal senders:=20 Reply-To: originalSender@example.com=20 Sender: dmarc < dmarc-bounces@ietf.org >=20 I don=E2=80=99t think this is quite right=E2=80=94I think the Reply-To need= s to include all of the senders or else every reply will be an off-list rep= ly (would cut down on noise, admittedly). Otherwise this would be a great s= olution. But because of the way it interacts with MUAs, I do not think it w= ould work in a way that doesn=E2=80=99t violate the principle of least surp= rise.=20 _______________________________________________=20 dmarc mailing list=20 dmarc@ietf.org=20 https://www.ietf.org/mailman/listinfo/dmarc=20 ------=_Part_18678871_280273762.1478547678820 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The EAI WG found it was fine to remove the ob= ligation to have an email address part in the mandatory RFC5322.From header= , leaving only the display part to assert the original author.

So it seems that "IETF" is not comple= tely in agreement on how to preserve the original author in emails.

So I think = the  example showed by Terry is as good as what is in EAI and this is = a matter of taste and UI designs, UI design and functions that usually the = IETF avoids to deal with...

From: "Terry Zink" <tzink@exchange.microsoft.com>
To: <= /b>"Ted Lemon" <mellon@fugue.com>
Cc: dmarc@ietf.org, "IETF= " <ietf@ietf.org>
Sent: Friday, November 4, 2016 2:54:33 PM=
Subject: Re: [dmarc-ietf] Identification of an email author (was= - Re: IETF Mailing Lists and DMARC)

I= f you hit =E2=80=9CReply-All=E2=80=9D, at least when I use Gmail, it includ= es both the From: and the Reply-To using the scheme below (I tested it out = just now). In Outlook desktop I have to also copy/paste the From: address (= mailing list). It=E2=80=99s not ideal in Outlook desktop, but I can live wi= th it.

 

In this e= mail discussion, I hit Reply-All and includes Ted on the To:, and dmarc@ietf.org and ietf@ietf.org on the c= c.

 

From: Ted Lemon [mailto:mellon@fugue.com]
Sent:<= /b> Friday, November 4, 2016 2:23 PM
To: Terry Zink <tzink@ex= change.microsoft.com>
Cc: dmarc@ietf.org; IETF <ietf@ietf.= org>
Subject: Re: [dmarc-ietf] Identification of an email aut= hor (was - Re: IETF Mailing Lists and DMARC)

 

On Nov 4, 2016, at 4:21 PM, Terry = Zink <tzink@exchange.micros= oft.com> wrote:

And if there were something like this in ot= her headers that retains the original senders:

 

 

 

I don=E2=80=99t think this is quite right=E2=80=94= I think the Reply-To needs to include all of the senders or else every repl= y will be an off-list reply (would cut down on noise, admittedly).   O= therwise this would be a great solution.   But because of the way it i= nteracts with MUAs, I do not think it would work in a way that doesn=E2=80= =99t violate the principle of least surprise.

 

 


________= _______________________________________
dmarc mailing list
dmarc@ietf= .org
https://www.ietf.org/mailman/listinfo/dmarc
<= /html> ------=_Part_18678871_280273762.1478547678820-- From nobody Mon Nov 7 14:47:04 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6D129855; Mon, 7 Nov 2016 14:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rX2djnvpZZz; Mon, 7 Nov 2016 14:47:02 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 262221296DE; Mon, 7 Nov 2016 14:47:02 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id n85so96792451pfi.1; Mon, 07 Nov 2016 14:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:organization:reply-to:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=r7K/IiLBQJVRFJkoRnu1S7u3uq24hM28ia2BoSi9Ze8=; b=jOOkPL+FtqXkNtxttzeu8nLVYHRBA4RxIzqv1pvPqRbbohKzfPMumvrBJCFzXh+7Zw rWKkUjaQjrdqeN8AGP7OSh2uPCj/84Tap7LDjRFsrZ0e53TyYN2B4VCuxasx8cOn+45X wzZp23KTjc/129/mIC8aRgoAh5Rdhgchhqg3E29c+7ithqjxvrQlNHrnLScpdCgqOZc1 MQinForRmUXmEw7dvDOG9JnF0BuRK2thwVJj5bTwtKx6Ykd/Eh1CbIcFpd14TJzAikkW D9L148MbQwJQtnYzIQkcMNjKxWslClQUIcztEhvslYOiQW3lSX9Da80Khct2Jt78iE1Z Y7bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:organization :reply-to:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=r7K/IiLBQJVRFJkoRnu1S7u3uq24hM28ia2BoSi9Ze8=; b=VRrQ83a3kmHtDlKvSTOcFtTBSogsJIBtfO7VcUzCmMvdI6LshMdxJWu1Yb+6Og0vZE riFp2exje3PPu2s8ZY7Awn4a1f4yO1imJ1AZRz2AcAdqCexrrQm3qossfk7+JKZb+OiB CdKPzWjukoDxMygeCn2t9lR3tEzn/Nck6YGQ9NbT0rHo2dIuyffOjM5Q/806sRCiFype BMmuvP5bRD/rYsCpgY8+yBfWx2DiGwjxfWjSp8N54oljqNVIZWs2k6lmw1fDBdWxli+C TSqicdxSeVZNA++HNvclZdf+Zl615gJBrEf6q/BrOOyp2UaMGRhFNCgMfGoWhKXXOkxc ZorQ== X-Gm-Message-State: ABUngve9cJSwTfHiqy6xNRfVf9ltqMoXujZYCjTkS6bvk9wsmc39iVBpHjBR0mqtSV3Bjw== X-Received: by 10.98.208.131 with SMTP id p125mr17545060pfg.168.1478558821772; Mon, 07 Nov 2016 14:47:01 -0800 (PST) Received: from ?IPv6:2602:304:cda0:8800:3c9f:b94c:7e47:7e87? ([2602:304:cda0:8800:3c9f:b94c:7e47:7e87]) by smtp.gmail.com with ESMTPSA id s3sm42925581pfe.27.2016.11.07.14.47.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 14:47:01 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Franck Martin , Terry Zink References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org> Organization: Brandenburg InternetWorking Message-ID: <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> Date: Mon, 7 Nov 2016 14:46:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org, Ted Lemon , IETF Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 22:47:03 -0000 On 11/7/2016 11:41 AM, Franck Martin wrote: > The EAI WG found it was fine to remove the obligation to have an email > address part in the mandatory RFC5322.From header, leaving only the > display part to assert the original author. We had that relaxed permission for From:, in the original From/Sender/Reply-to specification of rfc733, with the requirement that there be a Sender: email address. It looks like we removed it for rfc822. And while I recall something of the EAI discussion, I'm not recalling this permission's being returned. Nor am I finding it in rfc6854: https://tools.ietf.org/html/rfc6854#section-2 So, please point to the formal specification that permits a From: field to have no email address. Absent that, there's the small question about how the EAI group would have the authority to make such a major change to such a basic email feature... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 7 14:54:45 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD68129B86; Mon, 7 Nov 2016 14:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDoDHQ4QlY7q; Mon, 7 Nov 2016 14:54:37 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 6B4C8129B7B; Mon, 7 Nov 2016 14:54:33 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id 189so97030514pfz.3; Mon, 07 Nov 2016 14:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2ARjVzDiyoQH/obHLek8GYHoYHGiQ3TngjQfeb3Ey1g=; b=lrJ1bFmOXQ5N1aem/deF+3JYQGWOX05eW8r4civ4M0MQkFAkBslzXvDd3uSu2BPjeC 7Vf7StrvzY8SSTd3ziRIbUgyWO8BQTioXicavl1K7iq6sCbwGDSG7l35Mwdg9iPm5B9y KZuQqdL7UlyZk+XEbuvHafomwaIH4g3yykw5zY4vtkBDfGj6fHSajgT1tulcxSGqmqbc OHnpxzJCgZtycwOmHec4ToS/umZv1eekMab5AdQi/B6dWjQLNwxXau6He4O7+lP5CWK5 iVIZnFyGHCfwBmCHzE+KxBZwHZ4tb0fjM8cqNGrkQwk5XDV63dp9Y1sQyAdZFo059gGi 1WIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=2ARjVzDiyoQH/obHLek8GYHoYHGiQ3TngjQfeb3Ey1g=; b=AqFENuLnjazxlyVzSfgqvpNcmct4wDspUMwHvdiM3TNEYwUEGbNvKQ2dKVcnpcVBU+ /Z6/EIA0yTwtwDgVKv+TvCH8LT2FRmd40zJKfZY8Gwy8Zyw+P7aEpXm8IeoM/BYn4KxQ Mcpr+qZZOB9zmAGoAHr8hc6HAB/6CqWysFrseA6pC6XhVq9P7foHON/tRjGEAIFBopWu W2QdOefS0atDzS/FPN9ADFluq4kUODAtLdge3ngSP0UOGJ7so3EoYxb0nViGYnxcMGGl 0yLJr6M/lvo7Uo2O7SwUiwL85uWODDaLZsT/npEFIEcBLNy163zEUud/IE7vOYgxmrQS vQAQ== X-Gm-Message-State: ABUngvdwpbiALFm95tCk1RCLhABA3xySiiQipmkQuo9H5AWbW7sAxxZ0xFy2RIlmhXgHIg== X-Received: by 10.98.196.89 with SMTP id y86mr17456448pff.172.1478559272998; Mon, 07 Nov 2016 14:54:32 -0800 (PST) Received: from ?IPv6:2602:304:cda0:8800:3c9f:b94c:7e47:7e87? ([2602:304:cda0:8800:3c9f:b94c:7e47:7e87]) by smtp.gmail.com with ESMTPSA id tx10sm43110940pab.40.2016.11.07.14.54.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 14:54:32 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Terry Zink , Ted Lemon References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <29429.1478113235@obiwan.sandelman.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> Organization: Brandenburg InternetWorking Message-ID: <4b029229-a08f-15c3-0ba4-74756e1ed1f1@bbiw.net> Date: Mon, 7 Nov 2016 14:54:25 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 22:54:39 -0000 On 11/4/2016 2:54 PM, Terry Zink wrote: > If you hit “Reply-All”, at least when I use Gmail, it includes both the > From: and the Reply-To using the scheme below (I tested it out just > now). In Outlook desktop I have to also copy/paste the From: address > (mailing list). It’s not ideal in Outlook desktop, but I can live with it. > > In this email discussion, I hit Reply-All and includes Ted on the To:, > and dmarc@ietf.org and ietf@ietf.org > on the cc. RFC5322: > When the "Reply-To:" field is present, it > indicates the address(es) to which the author of the message suggests > that replies be sent. and > In the absence of the "Reply-To:" field, > replies SHOULD by default be sent to the mailbox(es) specified in the > "From:" field unless otherwise specified by the person composing the > reply. This does not prohibit also sending to the From: address, but it makes clear that including the From: address goes against the intent of having the Reply-To: field. So such copying violates the intent of the Reply-to field. That such behavior is common doesn't make it a good choice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 7 15:16:47 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A01129BC2 for ; Mon, 7 Nov 2016 15:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4adSWalf9kYW for ; Mon, 7 Nov 2016 15:16:41 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 70E4E129BCD for ; Mon, 7 Nov 2016 15:16:41 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q71GG4Z9JK01494D@mauve.mrochek.com> for dmarc@ietf.org; Mon, 7 Nov 2016 15:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1478560349; bh=4C7h2rHadHo3jYD8ebz17cUywEDFEcLwPVIK8zhaO2c=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=Eclx2tZMG2QBtsQsSz/NpiUD0gEMJU4ogZX2KySI8tsADWo99vQvK6DVyzFdtdXaZ WMNw45uSmm9VF1gOV8j/jQ7CqH7i/eu2Xa6aEvw9rhj4ovIr/5CUaBXj/kiuGEldvT TeY3mUxI4xwuOYqipQGNjvJ2a8BqFCzq34bWJWnM= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q6VN8T9668011H9Q@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Mon, 07 Nov 2016 15:12:27 -0800 (PST) From: ned+dmarc@mrochek.com Message-id: <01Q71GG3KUM8011H9Q@mauve.mrochek.com> Date: Mon, 07 Nov 2016 15:08:08 -0800 (PST) In-reply-to: "Your message dated Mon, 07 Nov 2016 14:46:54 -0800" <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org> <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> To: Dave Crocker Archived-At: Cc: dmarc@ietf.org, Ted Lemon , IETF , Terry Zink , Franck Martin Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 23:16:43 -0000 > On 11/7/2016 11:41 AM, Franck Martin wrote: > > The EAI WG found it was fine to remove the obligation to have an email > > address part in the mandatory RFC5322.From header, leaving only the > > display part to assert the original author. > We had that relaxed permission for From:, in the original > From/Sender/Reply-to specification of rfc733, with the requirement that > there be a Sender: email address. It looks like we removed it for rfc822. > And while I recall something of the EAI discussion, I'm not recalling > this permission's being returned. Nor am I finding it in rfc6854: > https://tools.ietf.org/html/rfc6854#section-2 > So, please point to the formal specification that permits a From: field > to have no email address. RFC 6854. > Absent that, there's the small question about how the EAI group would > have the authority to make such a major change to such a basic email > feature... RFC 6854 can speak for itself as to the rationale for allowing no address. The EAI connection was, as I recall, for use in downgrade formats used to present EAI messages to non-EAI clients via POP3 and IMAP4. Ned From nobody Mon Nov 7 15:24:00 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F9E129BCD; Mon, 7 Nov 2016 15:23:54 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org 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 Dl1hHxmRwJeV; Mon, 7 Nov 2016 15:23:53 -0800 (PST) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [192.198.93.228]) (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 935EA129BC8; Mon, 7 Nov 2016 15:23:36 -0800 (PST) Received: from zmcc-5-mta-1.zmailcloud.com (127.37.197.104.bc.googleusercontent.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id B7353520212; Mon, 7 Nov 2016 18:23:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 624CFC2411; Mon, 7 Nov 2016 17:23:35 -0600 (CST) Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HMxk3E-4XRtp; Mon, 7 Nov 2016 17:23:33 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id CE14EC248A; Mon, 7 Nov 2016 17:23:33 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.9.2 zmcc-5-mta-1.zmailcloud.com CE14EC248A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1478561013; bh=Tg5YPQ/9TxDbgq83mDJz8P/5zNLBE1VlDtQ3cc82g9Q=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=GGcNHVC8Z3UoFdT6XoCQnr4ORNqxx4OQKXFSqXvwRdQUhzRACDgmlNpjtxcNQ2SUE 2WURZ4U49juRo8D40vlAE9SKkoxD0wjzKxD3b61GxtmCMZdEZJVtHdT0g0kDAn4LtI r04tCyu542hBCXIpg9b2LhnAbx05pQIgCUO2AUGc= X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WVWjMFi37n-z; Mon, 7 Nov 2016 17:23:33 -0600 (CST) Received: from zmcc-5-mailbox-1.zmailcloud.com (zmcc-5-mailbox-1.zmailcloud.com [10.240.0.12]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id A7443C23FD; Mon, 7 Nov 2016 17:23:33 -0600 (CST) Date: Mon, 7 Nov 2016 17:23:33 -0600 (CST) From: Franck Martin To: dcrocker Message-ID: <460339986.19029473.1478561013458.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org> <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - FF49 (Mac)/8.6.0_GA_1194) Thread-Topic: Identification of an email author (was - Re: IETF Mailing Lists and DMARC) Thread-Index: 64e06B0gZM2UZeRnR9+xHVStAJg6OQ== Archived-At: Cc: dmarc@ietf.org, Ted Lemon , IETF , Terry Zink Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 23:23:55 -0000 ----- Original Message ----- > From: "Dave Crocker" > To: "Franck Martin" , "Terry Zink" > Cc: dmarc@ietf.org, "Ted Lemon" , "IETF" > Sent: Monday, November 7, 2016 2:46:54 PM > Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) > On 11/7/2016 11:41 AM, Franck Martin wrote: >> The EAI WG found it was fine to remove the obligation to have an email >> address part in the mandatory RFC5322.From header, leaving only the >> display part to assert the original author. > > We had that relaxed permission for From:, in the original > From/Sender/Reply-to specification of rfc733, with the requirement that > there be a Sender: email address. It looks like we removed it for rfc822. > > And while I recall something of the EAI discussion, I'm not recalling > this permission's being returned. Nor am I finding it in rfc6854: > > https://tools.ietf.org/html/rfc6854#section-2 > > So, please point to the formal specification that permits a From: field > to have no email address. > I'm not great at ABNF, so please bear with me. My understanding is that RFC proposes the following change: from = "From:" mailbox-list CRLF TO from = "From:" (mailbox-list / address-list) CRLF They are defined by: mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list address-list = (address *("," address)) / obs-addr-list furthermore: address = mailbox / group mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr group = display-name ":" [group-list] ";" [CFWS] display-name = phrase mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list address-list = (address *("," address)) / obs-addr-list group-list = mailbox-list / CFWS / obs-group-list So if you follow the fact that the new from can contain an address list, and that an address can be either a mailbox or a group and that a group can be 'undisclosed sender:;' So you could find an email with the following header From: undisclosed sender:; and that would be ok as per rfc6854 Note the security consideration in same RFC that "discourages" the use of the group syntax, but as a receiver, I would claim, this increases the level of secret sauce to apply to evaluate an email... From nobody Mon Nov 7 15:41:08 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C713512963A; Mon, 7 Nov 2016 15:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wYudz17GFfh; Mon, 7 Nov 2016 15:41:04 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 22254129639; Mon, 7 Nov 2016 15:41:04 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id i88so96899133pfk.2; Mon, 07 Nov 2016 15:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:organization:reply-to:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=u9id0OecY/sIQli85XAwM11yk+nNmKIdl2X66mn1ch8=; b=Wb7L7jHOVhykHZoNUBL6CaI7hP3jkcUwVGVomVxWYLsyCplvmasJVk8M3tynC+sUM3 k7UTn6THH1+0l6KsmYQtP3kpxihUG6jTtWtN3yCD33Ksa2wGYMmiTphGfMQJG0hi+Ar8 jA7MafY1n26X11wfFC5ayAjfYev630tKVuHx2HbGAbg7UB3KfA8ejFa0VJK4jNpOTdmW Un0oOvsnBYeblQ0m2SJ1yo1RNDFVaIZVF0SBrgjCzgXnOh90ak1H9i4zisgE0fO9GlfD GXP9OeXK3B/CobySSPMnLmrRzuAUCjs+1DBQ9sfMts1XEabAp8sS0mwRxLfPigzpIv0S 1jqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:organization :reply-to:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=u9id0OecY/sIQli85XAwM11yk+nNmKIdl2X66mn1ch8=; b=cFmhvoQTr9ccEa470pRAlA2xzoQvkbsdTYMK6Eu1lQaqFSo7XtmdLjrjD761jS86p6 ihDr6xWvYE9HJp6Rpz8v0qkpTNVgrYwIv7+XP78PExouyCqdsoTpMQsAPBgMTx+NG/Qj S9HJp2hkdScJM53mFSV6oZy4Kt1zLKEgMj4Xi2Gl3SNXwKroymjXnUcI36ysQ1gFGVAT XHSEYwc3GLl6+BnaCCl0OsXbwW/4Zdd6VWvlEOBFXihBio37acYy6w5RGZwkxroo/bM3 X+8SOp98pnmTOh3yu9dz8pjO8d4ySKLhTrLVJ8QNES5I0h+5l4Ku9cpFXkod5s3TLsda 8szQ== X-Gm-Message-State: ABUngvf+cZXtMzbWaxF0ZpuBWXrmeXRbw1Xtx6VtpV8Vo5b7ijBFtzXqX0+lntBCeSQ68g== X-Received: by 10.99.63.135 with SMTP id m129mr2340694pga.16.1478562063729; Mon, 07 Nov 2016 15:41:03 -0800 (PST) Received: from ?IPv6:2602:304:cda0:8800:3c9f:b94c:7e47:7e87? ([2602:304:cda0:8800:3c9f:b94c:7e47:7e87]) by smtp.gmail.com with ESMTPSA id e6sm43310607pad.0.2016.11.07.15.41.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Nov 2016 15:41:03 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Ned Freed References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org> <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> <01Q71GG3KUM8011H9Q@mauve.mrochek.com> Organization: Brandenburg InternetWorking Message-ID: <2ab30c4b-d718-8ada-6689-6b7a58ea69db@dcrocker.net> Date: Mon, 7 Nov 2016 15:40:56 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <01Q71GG3KUM8011H9Q@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org, Ted Lemon , IETF Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2016 23:41:07 -0000 On 11/7/2016 3:08 PM, Ned Freed wrote: >> And while I recall something of the EAI discussion, I'm not recalling >> this permission's being returned. Nor am I finding it in rfc6854: > >> https://tools.ietf.org/html/rfc6854#section-2 > >> So, please point to the formal specification that permits a From: field >> to have no email address. > > RFC 6854. That's what I cited, too. It makes much of allowing the group construct (to permit aggregating various forms of the same addressee). I assume the 'no address' permission is based on the CWFS alternative in: group-list = mailbox-list / CFWS / obs-group-list which the document doesn't explain at all. Nor does it impose the RFC733 fall-back of requiring a Sender: field, with an email address. If there's something else permitting no addressee, I'm still missing it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 7 19:25:54 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1F9129490; Mon, 7 Nov 2016 19:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oZaMlanucHE; Mon, 7 Nov 2016 19:25:41 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AAD1126D74; Mon, 7 Nov 2016 19:25:41 -0800 (PST) Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1c3x2U-000IJN-GW; Mon, 07 Nov 2016 22:25:34 -0500 Date: Mon, 07 Nov 2016 22:25:29 -0500 From: John C Klensin To: ned+ietf@mauve.mrochek.com, Dave Crocker Message-ID: In-Reply-To: <01Q71GG3KUM8011H9Q@mauve.mrochek.com> References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org > <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> <01Q71GG3KUM8011H9Q@mauve.mrochek.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: ima@ietf.org, dmarc@ietf.org, IETF , Terry Zink , Franck Martin Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 03:25:43 -0000 (adding the EAI list to the distribution -- there are people who hang out there who need to see, and check on, this) --On Monday, November 07, 2016 15:08 -0800 ned+ietf@mauve.mrochek.com wrote: >> Absent that, there's the small question about how the EAI >> group would have the authority to make such a major change to >> such a basic email feature... > > RFC 6854 can speak for itself as to the rationale for allowing > no address. > > The EAI connection was, as I recall, for use in downgrade > formats used to > present EAI messages to non-EAI clients via POP3 and IMAP4. Yes. IIR, 6854 was written the way it was in order to avoid getting tangled up with normative dependencies on the EAI specs. However, I find the combination of its Section 3 ("Applicability Statement") and Security Considerations rather clear as to both the motivation and the "don't do this if you don't need to and especially don't originate a message with this" advice. "Limited Use" is really very restrictive. The problem (and tradeoff) are as follows: A message gets delivered and gets as far as a mailstore with a backward-pointing address that looks like: "Non ASCii Name Phrase" Note that, if the message got that far, the delivery MTA advertised itself as fully SMTPUTF8-complaint. Then a POP or IMAP client comes along that does not support non-ASCII addresses or headers. Now, there are probably three plausible choices for the IMAP server (other than just dying a horrible death): (a) Trash the message on the theory that any users who would get themselves into that situation deserve it. However, remember the important case is a backward-pointing address and, in the general case, the delivery server doesn't know what client(s) the user is going to use (and there might be more than one). (b) Figure out how to respond to any IMAP request that involves that message with some flavor of "I have this message for you, but you can't get it and I can't tell you about it until you show up with an upgraded client". (c) Convert "Non ASCii Name Phrase" to encoded words and then do something unpleasant to the address, of which using group syntax was by far the least problematic solution anyone could come up with. If the Return-path in the mailstore is the same as the address in the "From:" and/or "Sender:" header fields, it is going to be trashed, so a competent IMAP server doing this is going to figure out how to warn the user and the user, perhaps after consulting support personnel the first time one of these happens to her, is going to figure out that doing anything with the message other than broadly getting its gist is going to require using an upgraded client. IIR, these issues are discussed at some length in RFCs 6855-6858. Now, coming back to the "identification of ... author" problem and remembering the "Limited Use" bit, if I were designing a submission server and something reached me with a group name in the "From:" (or "Sender:") field, I'd probably return it to whence it came. I'd probably do the same thing if I were a relay or delivery server, noting that there is no equivalent to group syntax in SMTP. Both are entirely consistent with Limited Use -- if one uses it in a context in which it makes no sense or poses a security threat, one refuses to accept it. If anyone things that needs to be said more clearly in one of the EAI-related documents and wants to suggest language, I, and I assume others, anxiously await an I-D. john From nobody Mon Nov 7 23:30:35 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE501293FB for ; Mon, 7 Nov 2016 23:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlzOVShZ1yx9 for ; Mon, 7 Nov 2016 23:30:34 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F6D1293E4 for ; Mon, 7 Nov 2016 23:30:33 -0800 (PST) Received: (qmail 5726 invoked from network); 8 Nov 2016 07:30:34 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Nov 2016 07:30:34 -0000 Date: 6 Nov 2016 22:08:03 -0000 Message-ID: <20161106220803.7313.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: dcrocker@bbiw.net Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 07:30:35 -0000 >So, please point to the formal specification that permits a From: field >to have no email address. RFC 6854 section 2.1 allows the From: addresses to be an address-list. In RFC 5322 sec 3.4, an adresss-list can be an address, an address can be a group, and the group-list of addresses in a group is optional. The example near the bottom of page 2 of RFC 6854, after the second paragraph of section 1, should make it obvious that this expansion is not unexpected. >Absent that, there's the small question about how the EAI group would >have the authority to make such a major change to such a basic email >feature... We did this for the narrow and specific case of delivery time downgrades described in RFC 6858, when a mail system is EAI compatible all the way to the POP or IMAP server, but the MUA fetching the mail isn't. The POP or IMAP server is allowed to smash the headers into ASCII that the ASCII-only client can display and one of the options for a UTF-8 mailbox in a From: or other header is to replace it with an empty group. You can ask Barry how much he expects this to affect ASCII mail, since he wrote 6854. R's, John From nobody Tue Nov 8 01:17:04 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6303D129B77 for ; Tue, 8 Nov 2016 01:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aACkcVOuEoNf for ; Tue, 8 Nov 2016 01:17:02 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E25129448 for ; Tue, 8 Nov 2016 01:17:02 -0800 (PST) Received: (qmail 17066 invoked from network); 8 Nov 2016 09:17:02 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Nov 2016 09:17:02 -0000 Date: 6 Nov 2016 22:57:30 -0000 Message-ID: <20161106225730.7565.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: franck@peachymango.org Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 09:17:03 -0000 In article <713098835.18678872.1478547678821.JavaMail.zimbra@peachymango.org> you write: >The EAI WG found it was fine to remove the obligation to have an email address part in the >mandatory RFC5322.From header, leaving only the display part to assert the original author. Only in the very narrow situation where you have an EAI mail system and a non-EAI mail client, and the POP or IMAP server wants to give a version of an incoming message to the client. R's, John From nobody Wed Nov 9 10:29:21 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF431294C3 for ; Wed, 9 Nov 2016 10:29:19 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=peachymango.org 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 tzbqGYcNKYMe for ; Wed, 9 Nov 2016 10:29:17 -0800 (PST) Received: from zmcc-5-mx.zmailcloud.com (zmcc-5-mx.zmailcloud.com [192.198.93.228]) (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 5BCDF12947C for ; Wed, 9 Nov 2016 10:29:17 -0800 (PST) Received: from zmcc-5-mta-1.zmailcloud.com (127.37.197.104.bc.googleusercontent.com [104.197.37.127]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by zmcc-5-mx.zmailcloud.com (Postfix) with ESMTPS id 6FC68520256 for ; Wed, 9 Nov 2016 13:29:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id 245DBC25A6 for ; Wed, 9 Nov 2016 12:29:16 -0600 (CST) Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id rMzxFTLRRS8h for ; Wed, 9 Nov 2016 12:29:14 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id D34EFC256A for ; Wed, 9 Nov 2016 12:29:14 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.9.2 zmcc-5-mta-1.zmailcloud.com D34EFC256A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1478716154; bh=mBdxiBkxY0xkOvNadv1EknMKbvkRKhDWrEHzlxXt8ik=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=qoRcuBu5OEHmqpuwh/+HgzXqkrj+RQJF0KplBCgdMEhl3eNcC45LET+F8U8Noijiu MY+CRrx1+y17KTSySKaYSo2KUodwk/gnMz9qugbZ07+j7VMDgaW0LomgLNzGTXg86U 7Z8omn5p0T260ZRTXSTnQy56FgGQQ95a1v8+shNI= X-Virus-Scanned: amavisd-new at zmcc-5-mta-1.zmailcloud.com Received: from zmcc-5-mta-1.zmailcloud.com ([127.0.0.1]) by localhost (zmcc-5-mta-1.zmailcloud.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W6d98G-6Kz6W for ; Wed, 9 Nov 2016 12:29:14 -0600 (CST) Received: from zmcc-5-mailbox-1.zmailcloud.com (zmcc-5-mailbox-1.zmailcloud.com [10.240.0.12]) by zmcc-5-mta-1.zmailcloud.com (Postfix) with ESMTP id BADDDC1744 for ; Wed, 9 Nov 2016 12:29:14 -0600 (CST) Date: Wed, 9 Nov 2016 12:29:14 -0600 (CST) From: Franck Martin To: dmarc@ietf.org Message-ID: <643846140.22233385.1478716154630.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20161106220803.7313.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.6.0_GA_1194 (ZimbraWebClient - FF49 (Mac)/8.6.0_GA_1194) Thread-Topic: Identification of an email author (was - Re: IETF Mailing Lists and DMARC) Thread-Index: hZU4Sd7uDcN3mpc8QR5JuCCgakTlrw== Archived-At: Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 18:29:19 -0000 ----- Original Message ----- > From: "John Levine" > To: dmarc@ietf.org > Cc: "dcrocker" > Sent: Sunday, November 6, 2016 2:08:03 PM > Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) >>So, please point to the formal specification that permits a From: field >>to have no email address. > > RFC 6854 section 2.1 allows the From: addresses to be an address-list. > > In RFC 5322 sec 3.4, an adresss-list can be an address, an address can > be a group, and the group-list of addresses in a group is optional. > > The example near the bottom of page 2 of RFC 6854, after the second > paragraph of section 1, should make it obvious that this expansion is > not unexpected. > >>Absent that, there's the small question about how the EAI group would >>have the authority to make such a major change to such a basic email >>feature... > > We did this for the narrow and specific case of delivery time > downgrades described in RFC 6858, when a mail system is EAI compatible > all the way to the POP or IMAP server, but the MUA fetching the mail > isn't. The POP or IMAP server is allowed to smash the headers into > ASCII that the ASCII-only client can display and one of the options > for a UTF-8 mailbox in a From: or other header is to replace it with > an empty group. > > You can ask Barry how much he expects this to affect ASCII mail, since > he wrote 6854. > Yes indeed, this happened after I commented in last call that the then draft if promoted, would create much problems in identifying the author for receivers. I'm glad that much text was added to precise the boundaries of this imperfect solution. On a similar note. Calendar invites also seems to have a weird concept of author. When A sends you an invite to a meeting, and you decide to add B to the list of invitees to the meeting. The invitation to B to the meeting is not coming RFC5322.From you but RFC5322.From A. From nobody Wed Nov 9 14:18:30 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B401299BE for ; Wed, 9 Nov 2016 14:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 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, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY7kRMaU4cH2 for ; Wed, 9 Nov 2016 14:18:09 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA471299DF for ; Wed, 9 Nov 2016 14:18:03 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id q124so188840309itd.1 for ; Wed, 09 Nov 2016 14:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MRzqeRAt84MTNg2agjZsxg/Qqvj5TIVqbJZ5tv7GAuM=; b=cwXgmZt1fkO3Ls0N55rP7BLBzmlyPHg0t+LZ/Lrev92jp1MgxmQ2lr41s+vgTPtz0m Mrf1YrTChYr3gD8EFHdpVbNpVVGQBkIWpTXtNNoU3lMCrN1TadBqdDVX+w1I6/bpPqOm jZfH9B5PIxh6k4olnns9x8zDpM5cWw7krgdFiWAwiNegPxs2iPDuiwlBpMineGxnMlke rP3KUsKCNUsarxN/J35nDEWL/0nOMCd41y6tqvdjBAoSMt6jgkhYFqhURNiarMTYPSrl 0xOrpD8qT99V/A0JF0M2Zoaz2rTv5NFAFb88GclJUtjcNJp4RBYxALbbInhsrUio/xHL 9g1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MRzqeRAt84MTNg2agjZsxg/Qqvj5TIVqbJZ5tv7GAuM=; b=P8c7HEQNSA+gouxuTHL40WJNoipNXStRtfhd2EtrUQZhFUz203GcwE0nG9tVyvsBbE Mf4YltzoO7HSpG6EOf2znSUh0qoSiYhuw0/scxQWp54hn7RyLTQLp2msd4tt8T1/fJS3 +nsxFdoWrbeec1fJ9oYccWfrd8zfvdpzb4eJF/IJrTD+80TvCxK+TYyk9hApNdYfouTF 5HnbLd+MjoLeFjl69m8eG3SfnveJCPUwgtyuk0JcrNIopqIIseF4g8YnsBB6ZKqAtnqf vOjiIPgXbeF/aazezVlYEk/QHJwQmiT42Q1n3JW7COa4VK06k1ZnlKo4wubgYXDEU5LU bpjg== X-Gm-Message-State: ABUngvezSmmNg99CR0Hvk9KkYAXv13vmVmESolo9loIcellyt3GrZEPny+Ha7Ru94ieFrpJpii0oSywrjn9dEL1y X-Received: by 10.202.81.5 with SMTP id f5mr1329447oib.24.1478729882422; Wed, 09 Nov 2016 14:18:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.167 with HTTP; Wed, 9 Nov 2016 14:18:00 -0800 (PST) In-Reply-To: References: <678C2FBA-A661-4556-A300-5C08562B5F8A@iii.ca> <33b100ac-c035-8b49-22e1-edbe47f41919@dcrocker.net> <5FA03832-D38F-47F2-B974-7C903C7513FD@fugue.com> <969d43d4-78c9-6e44-e186-ca6ed6fa3445@dcrocker.net> <01Q71GG3KUM8011H9Q@mauve.mrochek.com> From: Brandon Long Date: Wed, 9 Nov 2016 14:18:00 -0800 Message-ID: To: John C Klensin Content-Type: multipart/alternative; boundary=001a113d7e885c98020540e5a11a Archived-At: Cc: Dave Crocker , IETF , Franck Martin , ned+ietf@mauve.mrochek.com, "dmarc@ietf.org" , ima@ietf.org, Terry Zink Subject: Re: [dmarc-ietf] Identification of an email author (was - Re: IETF Mailing Lists and DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 22:18:25 -0000 --001a113d7e885c98020540e5a11a Content-Type: text/plain; charset=UTF-8 I think the EAI discussion took a turn a bit, but my point was: EAI sender sends mail to an EAI capable mailing list which has members which are not EAI capable is a similar scenario to what we're discussing here for DMARC. Ie, in order to resend the message, the choices are: 1) Do nothing and maybe the receiver allows the EAI message despite it not conforming to RFC 5322 and despite the receiving mail server not advertising SMTPUTF8... or maybe it rejects it. 2) Downgrade the message such that everyone on the list receives something, even if not what we'd prefer they receive 3) Don't forward EAI messages to non-EAI capable members 4) Don't accept any EAI messages to the mailing list if there are any non-EAI capable members Now, it turns out that the majority of mail software is probably fine with #1 with some level of degradation, so we're less likely to see #2 than we are in the DMARC case. Even so, at least this is an ability one could probe, so we could know when to downgrade and when not to, theoretically... a mailing list could also interpret DMARC rejects, I guess, and learn when to downgrade and not on a per-recipient basis. I would think that both #3 and #4 are less polite choices, and ditto with applying them to DMARC. In any case, I'm sure the EAI folks discussed what to do in this scenario, but I'm not really discussing whether or not #2 is within spec as much as I'm talking about the better support for your users in an imperfect world and drawing a parallel to DMARC. Brandon On Mon, Nov 7, 2016 at 7:25 PM, John C Klensin wrote: > (adding the EAI list to the distribution -- there are people who > hang out there who need to see, and check on, this) > > --On Monday, November 07, 2016 15:08 -0800 > ned+ietf@mauve.mrochek.com wrote: > > >> Absent that, there's the small question about how the EAI > >> group would have the authority to make such a major change to > >> such a basic email feature... > > > > RFC 6854 can speak for itself as to the rationale for allowing > > no address. > > > > The EAI connection was, as I recall, for use in downgrade > > formats used to > > present EAI messages to non-EAI clients via POP3 and IMAP4. > > Yes. > IIR, 6854 was written the way it was in order to avoid getting > tangled up with normative dependencies on the EAI specs. > However, I find the combination of its Section 3 ("Applicability > Statement") and Security Considerations rather clear as to both > the motivation and the "don't do this if you don't need to and > especially don't originate a message with this" advice. > "Limited Use" is really very restrictive. > > The problem (and tradeoff) are as follows: > > A message gets delivered and gets as far as a mailstore with a > backward-pointing address that looks like: > "Non ASCii Name Phrase" > > Note that, if the message got that far, the delivery MTA > advertised itself as fully SMTPUTF8-complaint. > > Then a POP or IMAP client comes along that does not support > non-ASCII addresses or headers. Now, there are probably three > plausible choices for the IMAP server (other than just dying a > horrible death): > > (a) Trash the message on the theory that any users who would get > themselves into that situation deserve it. However, remember > the important case is a backward-pointing address and, in the > general case, the delivery server doesn't know what client(s) > the user is going to use (and there might be more than one). > > (b) Figure out how to respond to any IMAP request that involves > that message with some flavor of "I have this message for you, > but you can't get it and I can't tell you about it until you > show up with an upgraded client". > > (c) Convert "Non ASCii Name Phrase" to encoded words and then do > something unpleasant to the address, of which using group syntax > was by far the least problematic solution anyone could come up > with. If the Return-path in the mailstore is the same as the > address in the "From:" and/or "Sender:" header fields, it is > going to be trashed, so a competent IMAP server doing this is > going to figure out how to warn the user and the user, perhaps > after consulting support personnel the first time one of these > happens to her, is going to figure out that doing anything with > the message other than broadly getting its gist is going to > require using an upgraded client. > > IIR, these issues are discussed at some length in RFCs 6855-6858. > > Now, coming back to the "identification of ... author" problem > and remembering the "Limited Use" bit, if I were designing a > submission server and something reached me with a group name in > the "From:" (or "Sender:") field, I'd probably return it to > whence it came. I'd probably do the same thing if I were a > relay or delivery server, noting that there is no equivalent to > group syntax in SMTP. Both are entirely consistent with > Limited Use -- if one uses it in a context in which it makes no > sense or poses a security threat, one refuses to accept it. > > If anyone things that needs to be said more clearly in one of > the EAI-related documents and wants to suggest language, I, and > I assume others, anxiously await an I-D. > > john > > --001a113d7e885c98020540e5a11a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the EAI discussion took a turn a bit, but my point= was:

EAI sender sends mail to an EAI capable mailing li= st which has members which are not EAI capable is a similar scenario to wha= t we're discussing here for DMARC.

Ie, in orde= r to resend the message, the choices are:
1) Do nothing and maybe= the receiver allows the EAI message despite it not conforming to RFC 5322 = and despite the receiving mail server not advertising SMTPUTF8... or maybe = it rejects it.

2) Downgrade the message such that = everyone on the list receives something, even if not what we'd prefer t= hey receive

3) Don't forward EAI messages to n= on-EAI capable members

4) Don't accept any EAI= messages to the mailing list if there are any non-EAI capable members

Now, it turns out that the majority of mail software i= s probably fine with #1 with some level of degradation, so we're less l= ikely to see #2 than we are in the DMARC case.=C2=A0 Even so, at least this= is an ability one could probe, so we could know when to downgrade and when= not to, theoretically... a mailing list could also interpret DMARC rejects= , I guess, and learn when to downgrade and not on a per-recipient basis.

I would think that both #3 and #4 are less polite ch= oices, and ditto with applying them to DMARC.

In a= ny case, I'm sure the EAI folks discussed what to do in this scenario, = but I'm not really discussing whether or not #2 is within spec as much = as I'm talking about the better support for your users in an imperfect = world and drawing a parallel to DMARC.

Brandon

On Mon, N= ov 7, 2016 at 7:25 PM, John C Klensin <john-ietf@jck.com> wr= ote:
(adding the EAI list to the distribu= tion -- there are people who
hang out there who need to see, and check on, this)

--On Monday, November 07, 2016 15:08 -0800
ned+ietf@m= auve.mrochek.com wrote:

>> Absent that, there's the small question about how the EAI
>> group would have the authority to make such a major change to
>> such a basic email feature...
>
> RFC 6854 can speak for itself as to the rationale for allowing
> no address.
>
> The EAI connection was, as I recall, for use in downgrade
> formats used to
> present EAI messages to non-EAI clients via POP3 and IMAP4.

Yes.
IIR, 6854 was written the way it was in order to avoid getting
tangled up with normative dependencies on the EAI specs.
However, I find the combination of its Section 3 ("Applicability
Statement") and Security Considerations rather clear as to both
the motivation and the "don't do this if you don't need to and=
especially don't originate a message with this" advice.
"Limited Use" is really very restrictive.

The problem (and tradeoff) are as follows:

A message gets delivered and gets as far as a mailstore with a
backward-pointing address that looks like:
=C2=A0 "Non ASCii Name Phrase" <non-ascii-local-part@domain-part>

Note that, if the message got that far, the delivery MTA
advertised itself as fully SMTPUTF8-complaint.

Then a POP or IMAP client comes along that does not support
non-ASCII addresses or headers.=C2=A0 =C2=A0Now, there are probably three plausible choices for the IMAP server (other than just dying a
horrible death):

(a) Trash the message on the theory that any users who would get
themselves into that situation deserve it.=C2=A0 However, remember
the important case is a backward-pointing address and, in the
general case, the delivery server doesn't know what client(s)
the user is going to use (and there might be more than one).

(b) Figure out how to respond to any IMAP request that involves
that message with some flavor of "I have this message for you,
but you can't get it and I can't tell you about it until you
show up with an upgraded client".

(c) Convert "Non ASCii Name Phrase" to encoded words and then do<= br> something unpleasant to the address, of which using group syntax
was by far the least problematic solution anyone could come up
with.=C2=A0 If the Return-path in the=C2=A0 mailstore is the same as the address in the "From:" and/or "Sender:" header fields, = it is
going to be trashed, so a competent IMAP server doing this is
going to figure out how to warn the user and the user, perhaps
after consulting support personnel the first time one of these
happens to her, is going to figure out that doing anything with
the message other than broadly getting its gist is going to
require using an upgraded client.

IIR, these issues are discussed at some length in RFCs 6855-6858.

Now, coming back to the "identification of ... author" problem and remembering the "Limited Use" bit, if I were designing a
submission server and something reached me with a group name in
the "From:" (or "Sender:") field, I'd probably retu= rn it to
whence it came.=C2=A0 =C2=A0 I'd probably do the same thing if I were a=
relay or delivery server, noting that there is no equivalent to
group syntax in SMTP.=C2=A0 =C2=A0Both are entirely consistent with
Limited Use -- if one uses it in a context in which it makes no
sense or poses a security threat, one refuses to accept it.

If anyone things that needs to be said more clearly in one of
the EAI-related documents and wants to suggest language, I, and
I assume others, anxiously await an I-D.

=C2=A0 =C2=A0john


--001a113d7e885c98020540e5a11a-- From nobody Sat Nov 12 20:26:25 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E95129690 for ; Sat, 12 Nov 2016 20:26:23 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3clQ2OM_xxtQ for ; Sat, 12 Nov 2016 20:26:22 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DCB129667 for ; Sat, 12 Nov 2016 20:26:21 -0800 (PST) Received: from kitterma-e6430.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 5DB80C401B4 for ; Sat, 12 Nov 2016 22:30:54 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1479011454; bh=yV9rDCJ8YtG4OtMJJYiFvowsAJaZojuyEBPU5VwihEU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=O5PrLw+84zG5YjMZLAOCGIfkUNjIo1QJtSxqoJghlBaEyU27xnR6ZgrbYWM7qIFtj eQA2aHS4ZybcWeWlgu3/4gzEwZlSb4Ak7eCI76R/dLZj71YvG3xW2iRsau5IDQSoLi 8EX29w2sU/4a/DTJGx0JER9MiZIHOpwzYsMHoPWA= From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 12 Nov 2016 23:26:19 -0500 Message-ID: <29001300.x3cZ5EP1fB@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-100-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20161017191847.23124.qmail@ary.lan> References: <20161017191847.23124.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Progress of ARC documents X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 04:26:24 -0000 On Monday, October 17, 2016 07:18:47 PM John Levine wrote: > >Most of the recent work has been in regard to coordinating and testing the > >four (4) known implementations of the ARC spec (Google, AOL, dkimpy, > >OpenARC). They are each in various stages of completion/readiness for > >production. > > Any chance we could get a peek at dkimpy or OpenARC? We understand that > they're beta software. I've not had much more time to work on dkimpy and I doubt I will for the next several weeks, so I decided to go ahead and push the work in progress to the public repository [1]. It passes the provided tests in python2.7 and has less code duplication than the original submission, but still isn't where I want it to be. There is a bytes/string problem that makes it not work in python3. That needs to be fixed before I do a release. If anyone's interested in working on it, I'm definitely open to submissions. Scott K [1] https://code.launchpad.net/~dkimpy-hackers/dkimpy/trunk From nobody Sat Nov 12 22:50:12 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A833E1296C0 for ; Sat, 12 Nov 2016 22:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PUVEUISajKL for ; Sat, 12 Nov 2016 22:50:09 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 11BC1129621 for ; Sat, 12 Nov 2016 22:50:09 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id t125so39978561ywc.1 for ; Sat, 12 Nov 2016 22:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=f+aYifHPsXc1jltDuzc9lytZZN4zkAES+NwoT54R1mo=; b=Y/ANd8ef4uVe5VkDNYWpxUPU3X4eDBpuDkhjhROP5/ZgWd2LZXeW72Bz0ONzwvJR00 GHkRPgbNDhCNTFGF6xJE11LNuJRKek1sQNEJnEKTNOU0q7rzHhySOugjiNwwB1e9M0C3 zo2RD09zJ2g0yf0jFEojz0LBCMU+8zW1cgOM5A32NoRYTPTbDxsviGaj/NhWa/R5at/5 7Ez+0JDUDsVaUu3gGhf9CLePCddRPDp55cnWvoZZ3ySjylft44fz4h8edYnl6voZ27Qb A8YFA9K+UsT+ncf+GlIwxlxMxIv6YjEkEz7n3JAOb+BlZDJCUajQoiyFKf2bTarcMugE Jhig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=f+aYifHPsXc1jltDuzc9lytZZN4zkAES+NwoT54R1mo=; b=Hnk19SJXSsEzRI7152gBXBR+dVMNMFJhqd3vfsT9VosTX7rRiVlKLt1/aAok1wtU+A R/EZBg4YL7b0MW/B15vee2YlAjWylTaxiVifhnCY+BTr5y2YE9sMLiys4G6wFKR+kgiY /1YKhL+d5ln2RBo4Y0SDKsW2iX5JU6qL5wZkwFGWJBp1AACuKscjXt8knRVx1u37dPoX 4w9hyOpB14ufAWTJgqLDPOV3nuU3qD2peNLgGxJrFEvqBJXUlrWsZHv7FjDuWu6hZg8N fEHuua5DPbdI+YTMu5IOJ0JRprpoGzfWNHqLGPEjKKeLM9TDEnC9ifsF0+1atf9fold8 db0g== X-Gm-Message-State: ABUngvdmlfauO11o34H08EZAOcvFnzpC4sHw85rMZojS7bGtG0H8Aky3o53Pt4psJA9qG3Nk+38QUjK6dqaJqQ== X-Received: by 10.13.241.199 with SMTP id a190mr879536ywf.285.1479019808094; Sat, 12 Nov 2016 22:50:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Sat, 12 Nov 2016 22:50:05 -0800 (PST) From: "Murray S. Kucherawy" Date: Sun, 13 Nov 2016 15:50:05 +0900 Message-ID: To: "dmarc@ietf.org" , "ietf-dkim@mipassoc.org" Content-Type: multipart/alternative; boundary=94eb2c03272047092105412922e0 Archived-At: Subject: [dmarc-ietf] draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 06:50:10 -0000 --94eb2c03272047092105412922e0 Content-Type: text/plain; charset=UTF-8 I've posted a draft that attempts to address an attack that's begun to appear with DKIM. Interestingly, we called it out as a possible attack in RFC6376 and even RFC4871, but now it's apparently happening and being annoying enough that people (I believe from the MAAWG community) are asking if there's a protocol solution that's possible. https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ Comments welcome. -MSK --94eb2c03272047092105412922e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've posted a draft that attempts to ad= dress an attack that's begun to appear with DKIM.=C2=A0 Interestingly, = we called it out as a possible attack in RFC6376 and even RFC4871, but now = it's apparently happening and being annoying enough that people (I beli= eve from the MAAWG community) are asking if there's a protocol solution= that's possible.

https://datatracker.ietf.org/doc/draft-kuc= herawy-dkim-rcpts/

Comments welcome.

-MSK
=
--94eb2c03272047092105412922e0-- From nobody Sun Nov 13 11:40:50 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0777E129570 for ; Sun, 13 Nov 2016 11:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsT1gU11AdVZ for ; Sun, 13 Nov 2016 11:40:46 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74052129434 for ; Sun, 13 Nov 2016 11:40:46 -0800 (PST) Received: from [10.10.10.41] (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id uADJeatm094444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 13 Nov 2016 11:40:41 -0800 (PST) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com uADJeatm094444 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1479066042; bh=JD5t+F0sVjIHLLu7zJKIeYEHAnKgfer9soZra7jVTZ0=; h=Subject:To:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=B3GRhaLpHEIgbwIUkQ6NeVs6p3FEdQklFCWIhhapiZWHkOd6gvptD74L2QH5uJ34k tEDpqqTYKv9yeMGWJRS4zMl1OqbzIoxdV+PstqvlNE5AZhFgPNCIPTDy5QHhLl44c/ sA41Kiexw5x1Sue/wFT2+6TBeRIP5qe/tleW9FDEqxGP7+hdF1P8TjNqq/VDVi5JSi IVpZDj0pe861Uz+Lu8GNyrKBrrnTWQoBu0gz2vwrMe6jydXwWJuXkgEocoVbD5WA0V 1/O+IcjBb+pad+bGCTYu56Di+8mCrLpDG/+rfLCbdgc0S7pof9sA5hbB4aZ5lW9jkd uoVs1q5/uQb3w== X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be [10.10.10.41] To: dmarc@ietf.org References: From: Steven M Jones Organization: Crash Computing Message-ID: <0d075a8e-1ace-4ddf-75d1-be642572d443@crash.com> Date: Sun, 13 Nov 2016 11:40:39 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Sun, 13 Nov 2016 11:40:42 -0800 (PST) Archived-At: Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 19:40:48 -0000 On 11/12/2016 22:50, Murray S. Kucherawy wrote: > I've posted a draft that attempts to address an attack that's begun to > appear with DKIM. Interestingly, we called it out as a possible > attack in RFC6376 and even RFC4871, but now it's apparently happening > and being annoying enough that people (I believe from the MAAWG > community) are asking if there's a protocol solution that's possible. > > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ > > Comments welcome. Thanks for codifying this proposal Murray. So per Section 5, this form of DKIM signature will fail to verify at a receiver who doesn't implement the new feature, period. And in fact any forwarding - whether it alters the RFC5322 message or not - would produce a DKIM verification failure at the next/final recipient. The language in Section 5 paragraph 3 seems to cover envelope splitting. Should this be expanded to address origin ADMD infrastructure such as split signer/MTA, analogous to the note about split MTA/verifier at the receiving ADMD in paragraph 4? Are there any usage guidelines or recommendations about how and when to use the new signing feature that I missed? For example is there another draft, or a thread in a different forum/list, that speaks to this? If it doesn't exist, do we need to create one? (Ulp - did I just volunteer?) I'd be curious to get feedback from folks who aren't enamored of ARC, but understand the motivating abuse... Thanks, --Steve. From nobody Sun Nov 13 13:01:17 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0634127076 for ; Sun, 13 Nov 2016 13:01:15 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 siljxdbTInXN for ; Sun, 13 Nov 2016 13:01:12 -0800 (PST) Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6E812942F for ; Sun, 13 Nov 2016 13:01:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=sg9lNauKgoaSuB3Pn839ApODW8iYw/g1om7usbsrPoA=; b=ZGPlVq24jwxCYtJjRVMDD2PUQtBz6nmajcm3WxepD/Cjg7xEVuFE5Pi0FVOS2sQ3tQSiEH2oYmS/a0HBjDhJVJZrqvDnn7LOmA319HjaETIdQQHJLipizvqCM/YFd+tU6hwYKVnU7ZLmd6q7MXnNe8JQiXOzwMeIanwqRHH3QEE=; Received: from gate.3proxy.ru ([95.79.31.239]:60577 helo=[127.0.0.1]) by smtp32.i.mail.ru with esmtpa (envelope-from ) id 1c61tj-0007yM-Na; Mon, 14 Nov 2016 00:01:08 +0300 To: "Murray S. Kucherawy" , "dmarc@ietf.org" , "ietf-dkim@mipassoc.org" References: From: Vladimir Dubrovin Message-ID: Date: Mon, 14 Nov 2016 00:01:04 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------16B94D85C830A5A6B5D662A7" Authentication-Results: smtp32.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-E1FCDC63: A48B4BDA48F8A0331A867266180ED5702890F9C47E136152 X-E1FCDC64: 1285914656B4AA74AC26D4BEEB6E25FC50E0955F736AF62E29FD1FBA0D0D2157 X-Mailru-Sender: 556F4A9D62B16351D3F3813A3D3FF60A1BF5C2403E77AB64969FCEC26D690364E71E74A1FAFAF059 X-Mras: OK Archived-At: Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 21:01:16 -0000 This is a multi-part message in MIME format. --------------16B94D85C830A5A6B5D662A7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1. This standard is not backward compatible with existing DKIM implementations. It makes it useless. In addition, in it's current form it can not be implemented in most MTAs (see below) 2. This standard mixes transport standards (SMTP) and message standard. There are multiple issues as a result of this: 2.1 Same message may have multiple recipients on different MTAs while each MTA only sees it's own recipients. So, destination MTA can not verify signature, because it doesn't know all recipients. This can be fixed if message to every destination is signed independently, but it breaks existing mail flows, because in most cases message is signed before placing to MTA queue. 2.2 Recieving MTA may e.g. limit the number of recipients and single message may be sent to different final recipients on the same MTA in multiple session as few different messages, each message with partial list of recipients. Actually same message to same destination may be sent to different MTAs (e.g. different MXs with same weight). 2.3 Canonization must be better defined. It's usual for MTA to e.g. lowercase the domain of recipient. All problems except 2.1 may be fixed by adding additional header, like e.g. DKIM-Transport-recipients which contains salted hashes (with some random salt) of all recipient addresses, and require this header to be added to DKIM signature and existence for every recipient's address' hash to be checked in this header. It is compatible with any current DKIM implementation. 2.1 can also be solved in this case, but it disclosures BCCs of the message (even if this header is removed before delivery to mailbox) All problems may be solved by using asymmetric encryption instead of hashing, e.g. require domains with support for this standard to publish some public key (or to use special DKIM selector) via DNS record and encrypt recipient's addresses in the additional header with public key and only sign recipients for systems with this key published. P.S. I just did a quick look into standard, sorry if I missed or misunderstood something. 13.11.2016 9:50, Murray S. Kucherawy пишет: > I've posted a draft that attempts to address an attack that's begun to > appear with DKIM. Interestingly, we called it out as a possible > attack in RFC6376 and even RFC4871, but now it's apparently happening > and being annoying enough that people (I believe from the MAAWG > community) are asking if there's a protocol solution that's possible. > > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ > > Comments welcome. > > - > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------16B94D85C830A5A6B5D662A7 Content-Type: multipart/related; boundary="------------0D00EF9B3F000F4357273487" --------------0D00EF9B3F000F4357273487 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


1. This standard is not backward compatible with existing DKIM implementations. It makes it useless. In addition, in it's current form it can not be implemented in most MTAs (see below)
2. This standard mixes transport standards (SMTP) and message standard. There are multiple issues as a result of this:
2.1 Same message may have multiple recipients on different MTAs while each MTA only sees it's own recipients. So, destination MTA can not verify signature, because it doesn't know all recipients. This can be fixed if message to every destination is  signed independently, but it breaks existing mail flows, because in most cases message is signed before placing to MTA queue.
2.2 Recieving MTA may e.g. limit the number of recipients and single message may be sent to different final recipients on the same MTA in multiple session as few different messages, each message with partial list of recipients. Actually same message to same destination may be sent to different MTAs (e.g. different MXs with same weight).
2.3 Canonization must be better defined. It's usual for MTA to e.g. lowercase the domain of recipient.

All problems except 2.1 may be fixed by adding additional header, like e.g.
DKIM-Transport-recipients
which contains salted hashes (with some random salt) of all recipient addresses, and require this header to be added to DKIM signature and existence for every recipient's address' hash to be checked in this header. It is compatible with any current DKIM implementation.
2.1 can also be solved in this case, but it disclosures BCCs of the message (even if this header is removed before delivery to mailbox)

All problems may be solved by using asymmetric encryption instead of hashing, e.g. require domains with support for this standard to publish some public key (or to use special DKIM selector) via DNS record and encrypt recipient's addresses in the additional header with public key and only sign recipients for systems with this key published.

P.S. I just did a quick look into standard, sorry if I missed or misunderstood something.


13.11.2016 9:50, Murray S. Kucherawy пишет:
I've posted a draft that attempts to address an attack that's begun to appear with DKIM.  Interestingly, we called it out as a possible attack in RFC6376 and even RFC4871, but now it's apparently happening and being annoying enough that people (I believe from the MAAWG community) are asking if there's a protocol solution that's possible.

https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/

Comments welcome.

-


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


--
Vladimir Dubrovin
@Mail.Ru
--------------0D00EF9B3F000F4357273487 Content-Type: image/png; name="mpofmokihhmhgfbp.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="mpofmokihhmhgfbp.png" iVBORw0KGgoAAAANSUhEUgAAAHwAAAAZCAQAAABZLoLcAAADz0lEQVR4AeWX2XLiPBCFP3nB 7IEAWSAk4BkWg837P95UuU51WRhXjf1XcjH/8Y2EpO7+tLQQd3JM2XDgwo2CCylvDPkJOVIK PgCYknMm4YfkWJBxe/AdmPLd6ssXwL4svfAjSvhdQc3JuHjwXwR8p3ryC/CrLL/yAxpxFWDK nB6lCBiztpYjEd+pKe+Mfha8L7gzY+oKeTf0ABOOgaanT99rSRgS8lgBCQMirK+VAwa41uCO xMaF9GlmDIHID+WskxypyzspB/a8EEOpCXnZ5wNMB25s2VBok74TAAtZK9gS4WtCqt43TqwI eC57DgHHqTxQbcATPhXXDojKw7nhgcqlu97H81YOzYiBgA/vZOcsSdgxZ6yQB1AqfpgEU69+ pgdSyK7W/8wRIVpyC/4a/JXCLF2BsWw+kPxMqSjUnD0BgVzeyDja2b5QmtMEfVaTkbnNfSSr /7JdZamTwu8txIHK4V+CbyrjMxbtwZ+1VgAfKg/VNuaI1samqCDwwC/MgICdYa0IcBbYQJaV OpW+Yq1XV/C5xTXDAbQH/yp/WpjrEwGYQo4Vc59leeKBj8Grv6jutK7Pto3vz9+QvCN4oP8b vwkBOoErFSXABmtsMLfA0Ay0h6T69M7yElhrJzl8PXcEn+k4xdAdvChNoMYcx72uZm6qdWsL fipLc+7luHYC/7Q4uoMrOQBlEjs1DDpXTG9bgxfaVXXtu4ArUc7+O/gVtC4ZdZ3N3JPu8m7g MXXtuoALY4yvkZLtI2X1EZm5+6qFZ4ACX5Xlt9bgmVrqOj8ET+WnFbhFFHGvSC1Jfc6ntp5r fH1h4NqYs9bgWz1zqG/OOrj137UC96fR14sOtKdlJagDutokx9q7x7Vl24Ib4IyqQk6PwZXt C/otwV81bkhVA4pHOyjSz/0S5qKL55Ul7wpdsyWzKbQGh73d8oGdSGE/AA+5ymsVLmZC2ATu 3e85C5yW7plceSzkThvBBkCChaMv1cbTY4RxJ/CITO05KTt5aQKHhbVdSBnZZBybwKURBTeB 7km5qlYwoaZI67wnABxLDuqcMgPmlRC30AkceqpXv4JLAzisvcePtTeDSxODtY9cUTUmmaOd DkcIVk7VvsOB5Mqgr7i7k5fU06YU8OYFlTLUw2duL4ETmOZk5hdiCrusdvL0WDFbisrkbolp 1IzCnDwZtGPMkhh44qU2awkr+p7DFSMwhSxqYxxTVqyYEau+YGZJaEkPk/lfKp4RK8FG8tSs kCeWrDCWZo3JvIfegRO5Mv4/rpA3ofrfmv+BAmZsOZBbRl3g+Af1By7rr2XUY4YeAAAAAElF TkSuQmCC --------------0D00EF9B3F000F4357273487-- --------------16B94D85C830A5A6B5D662A7-- From nobody Sun Nov 13 16:15:32 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE92129400 for ; Sun, 13 Nov 2016 16:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq8BAfX74cso for ; Sun, 13 Nov 2016 16:15:28 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 CE287129411 for ; Sun, 13 Nov 2016 16:15:28 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q79WDXAXMO015B2O@mauve.mrochek.com> for dmarc@ietf.org; Sun, 13 Nov 2016 16:15:10 -0800 (PST) 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 <01Q79PXNP5HC011WUX@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Sun, 13 Nov 2016 16:15:07 -0800 (PST) From: ned+dmarc@mrochek.com Message-id: <01Q79WDUNCU0011WUX@mauve.mrochek.com> Date: Sun, 13 Nov 2016 15:40:59 -0800 (PST) In-reply-to: "Your message dated Mon, 14 Nov 2016 00:01:04 +0300" References: To: Vladimir Dubrovin Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , "ietf-dkim@mipassoc.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 00:15:30 -0000 > 1. This standard is not backward compatible with existing DKIM > implementations. It makes it useless. In addition, in it's current form > it can not be implemented in most MTAs (see below) It wouldn't work at all in our MTA without modifications because our general filter interface currently receives recipient addresses after some processing has been performed. We could add an option to change that fairly easily, but as you note, that doesn't address all the issues. > 2. This standard mixes transport standards (SMTP) and message standard. > There are multiple issues as a result of this: > 2.1 Same message may have multiple recipients on different MTAs while > each MTA only sees it's own recipients. So, destination MTA can not > verify signature, because it doesn't know all recipients. This can be > fixed if message to every destination is signed independently, but it > breaks existing mail flows, because in most cases message is signed > before placing to MTA queue. We have sufficient flexibility in this regard to sign late (and as noted above, verify early), and we can split by destination before signing each variant separately. What would be much more difficult is detecting this usage and turning off splitting where feasible to avoid breaking the signature. That would be very difficult. The bottom line is that at best this will be very fragile, at worst it will fail a significant percentage of the time. > 2.2 Recieving MTA may e.g. limit the number of recipients and single > message may be sent to different final recipients on the same MTA in > multiple session as few different messages, each message with partial > list of recipients. Actually, this quickly turns into a hairball. The minute the receiving system starts 4yz'ing some recipients the precomputed signature is going to be rendered invalid and will have to be recomputed. And how does the receiving MTA know when do this? It gets no indication that it's dealing with this particular DKIM variant until after recipients are processed. So it's only choice would be to do it unconditionally, or to try and keep track of senders who use this feature. Yuck. > Actually same message to same destination may be > sent to different MTAs (e.g. different MXs with same weight). > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > lowercase the domain of recipient. Our default is to leave the case of addresses alone by default, but sites often do configure things to "right case" their business name. That said, Early validation would avoid such issues for us. I think. > All problems except 2.1 may be fixed by adding additional header, like e.g. > DKIM-Transport-recipients > which contains salted hashes (with some random salt) of all recipient > addresses, and require this header to be added to DKIM signature and > existence for every recipient's address' hash to be checked in this > header. It is compatible with any current DKIM implementation. If you're talking about hashing all recipients together, then I don't see this solving all the problems except 2.1. And if you're talking about hashing them separately, then why would you insist that they all be present? > 2.1 can also be solved in this case, but it disclosures BCCs of the > message (even if this header is removed before delivery to mailbox) Prior to delivery the bcc's are disclosed by being present in the envelope. So as long as the sender adopts the approach of splitting by destination before signing, only including the recipients for a given copy in the signature, and the receiver removes the field prior to final delivery, I think it might work. But limiting the number of recipients to 1 when this extension is used would be a much simpler approach. Of course there's some overhead involved in doing this, but given the idiotically limited spam report mechanisms in place at some sites single copy may be a requirement already. > All problems may be solved by using asymmetric encryption instead of > hashing, e.g. require domains with support for this standard to publish > some public key (or to use special DKIM selector) via DNS record and > encrypt recipient's addresses in the additional header with public key > and only sign recipients for systems with this key published. Yes, and that's really cute. Considerable overhead though. > P.S. I just did a quick look into standard, sorry if I missed or > misunderstood something. So did I, and so do I. Finally, my biggest concern here is that this, like most proposals that involve complex linkages between the header and envelope, is complex and loaded with pitfalls. (Just look at these two messages...) And at least some of this spills over to both implementations and operational policy. Can we really expect people to get this right? Ned From nobody Sun Nov 13 21:43:36 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1612969D for ; Sun, 13 Nov 2016 21:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD8G-maNUlyy for ; Sun, 13 Nov 2016 21:43:30 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 F41331295C4 for ; Sun, 13 Nov 2016 21:43:29 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id a10so48989001ywa.3 for ; Sun, 13 Nov 2016 21:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Od1Xl9IsOVMCXTYhb8MyzarPA2WCw/jZpWhX+wv2il8=; b=scCZBqs+2AwJ2YGDtS+0RynSzWB2fXf84WsAuh9HyZcxZytVoOyL/u2o4ctGElbht/ 108FD3c2u07pIrEMvCzIRWAXeF0o17gKDNDI3N7uo3ECcEE/lyIwroryb8D71Mfpgixp 68LGPaENJf4MmOfJGsQ8WzVl9xdd/RGN4FN1Nhhtp0qWdf6zVtftrNEkzm3cnXIt2PCO NyOuDyHTg6K+I4RiypAN0WUW+Ysqar/NLhbqoMnjVaPjpOkRhzenBpY9dO/x2jAMr0HC UIPH8dCo9rbfSBPbUTCl9hfybndZjx2SB6t9lOFPwJ0tIghDdP2711y4b9q53rx4pMM1 Vegg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Od1Xl9IsOVMCXTYhb8MyzarPA2WCw/jZpWhX+wv2il8=; b=V2n/imgbkui0KItlefKV+rZQj7v1cSFlnjjRPBkuY1Lb8tkQBw3BzQRWeZogI1QrBp szAUV6lN7c6uwhtnRvHs8Nv/gj6VUzXB3zLaQ95rPSk3jIICk9Qg/hs83gqlzUl7ADOl 3SlhqsDTj5uewNqunty/D/UYdM7Rrbx50/WcpkAASdBoXyqrJf146LsfiEcEfFxL+4vs Y90stlYQjXd7FvCije7ZijJesfauN/lwvmqOhSq8l6zb4ws0n0X5k9U6nVCEWbWomF5X kvFtW0JVOCN/KugIEu7keyc+F72LWfEVz++KdeGBeJhepx5Txt4ZckE8Ai63s6HM22Ih sluw== X-Gm-Message-State: ABUngvf+R8n8jFPzb1zRyFCTs8dvXoS+1ejdbU4ZZpVzCq2t3YE5cZN87dp3YXVaw0MDsGXE7wpPVhwi1vUmgg== X-Received: by 10.129.77.68 with SMTP id a65mr14803344ywb.287.1479102209281; Sun, 13 Nov 2016 21:43:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Sun, 13 Nov 2016 21:43:28 -0800 (PST) In-Reply-To: <0d075a8e-1ace-4ddf-75d1-be642572d443@crash.com> References: <0d075a8e-1ace-4ddf-75d1-be642572d443@crash.com> From: "Murray S. Kucherawy" Date: Mon, 14 Nov 2016 14:43:28 +0900 Message-ID: To: Steven M Jones Content-Type: multipart/alternative; boundary=001a1140b770c5b05505413c51f8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 05:43:34 -0000 --001a1140b770c5b05505413c51f8 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 14, 2016 at 4:40 AM, Steven M Jones wrote: > So per Section 5, this form of DKIM signature will fail to verify at a > receiver who doesn't implement the new feature, period. And in fact any > forwarding - whether it alters the RFC5322 message or not - would > produce a DKIM verification failure at the next/final recipient. > Correct. > The language in Section 5 paragraph 3 seems to cover envelope splitting. > Should this be expanded to address origin ADMD infrastructure such as > split signer/MTA, analogous to the note about split MTA/verifier at the > receiving ADMD in paragraph 4? > Do you have a use case in mind that's not addressed by the text that's there? It seems to me the text that's there specifically covers any kind of split regardless of where in the handling chain the split occurs. Are there any usage guidelines or recommendations about how and when to > use the new signing feature that I missed? For example is there another > draft, or a thread in a different forum/list, that speaks to this? If it > doesn't exist, do we need to create one? (Ulp - did I just volunteer?) > I think this work is small enough that any such guidance can just be included here, probably in Section 5. Essentially, you use this if you want to defend against this particular type of attack and are also prepared to take on the additional cost (second signature, potential misunderstanding by verifiers and receivers). I'd be curious to get feedback from folks who aren't enamored of ARC, > but understand the motivating abuse... > I don't think there's any plan with this work to supplant or augment ARC, in case that's what you're implying. -MSK --001a1140b770c5b05505413c51f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 14, 2016 at 4:40 AM, Steven M Jones <smj@crash.c= om> wrote:
So per Section 5, this form of DKIM s= ignature will fail to verify at a
receiver who doesn't implement the new feature, period. And in fact any=
forwarding - whether it alters the RFC5322 message or not - would
produce a DKIM verification failure at the next/final recipient.

Correct.
=C2=A0
The language in Section 5 paragraph 3 seems to cover envelope splitting. Should this be expanded to address origin ADMD infrastructure such as
split signer/MTA, analogous to the note about split MTA/verifier at the
receiving ADMD in paragraph 4?

Do you have a= use case in mind that's not addressed by the text that's there?=C2= =A0 It seems to me the text that's there specifically covers any kind o= f split regardless of where in the handling chain the split occurs.

=
Are there any usage guidelines or recommendations about how and when to
use the new signing feature that I missed? For example is there another
draft, or a thread in a different forum/list, that speaks to this? If it doesn't exist, do we need to create one? (Ulp - did I just volunteer?)<= br>

I think this work is small enough that = any such guidance can just be included here, probably in Section 5.=C2=A0 E= ssentially, you use this if you want to defend against this particular type= of attack and are also prepared to take on the additional cost (second sig= nature, potential misunderstanding by verifiers and receivers).

I'd be curious to get feedback from folks who aren't enamored of AR= C,
but understand the motivating abuse...

= I don't think there's any plan with this work to supplant or augmen= t ARC, in case that's what you're implying.

-MSK<= br>
--001a1140b770c5b05505413c51f8-- From nobody Sun Nov 13 21:57:27 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA297129634 for ; Sun, 13 Nov 2016 21:57: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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFfHrU9Ny0gj for ; Sun, 13 Nov 2016 21:57:23 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::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 5CAC01294C6 for ; Sun, 13 Nov 2016 21:57:23 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id a184so21195832ybb.0 for ; Sun, 13 Nov 2016 21:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vmnFdlL2QWbBYCXLW3zA3dqDERTKyPyaO4kKCeFOrls=; b=G4pOaDoHO98vQsugZrm0d0R8zRnFr5h19stVJcVBVSmPVIaW2pj/qyz/tEf5g9zxev gyuZt8KSqUvH62onOhjgmEOhXMDvmOhW+JtzPAPlcFE8oWqs0hxoY2peHA6YXNtw60F2 /W4/GY5jMSZKri/M1plQbPlmAjfbPlnTpdC0QNi0w8mcp0jknuqi6fRJwxIhAOovObKm y9tq8AoP9gd2s4es0ab+e7qs2+J9EMubwVZQuxU/6YLztz3ZtJXDZos5NcvLjEuxn4/5 EuEYkFy32cLJm+VrK1ukWKR2WGWHDMnTbmoOIe4wGeEJ2MJyTNtlUhZse0WOTVgmzbfd i6RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vmnFdlL2QWbBYCXLW3zA3dqDERTKyPyaO4kKCeFOrls=; b=SYXc6Xvn4QMmkn9DVfWsRSP5qtEVb5RH1rpBfBa9K5nMunoWXZzYqSXcV8d0SzIp83 sMiW9QQMJxyy5d6P1m0sIgIVxNzs6xE0MlPkaVlDWot4kDKR56O8nPrJ76+G9vs1AfPw oGSvsq+9W35hmE3Le9jsujIivDQGGZb7TOcx+3ROcFmJlI7XnP6dHN5Fp2FMpQdRgK7G WsEvi+noWpuj7MPA+N3Wgf1NhzJWKpffBEnVOJ3SbZHiQRyhN6lxlBCKqYGgTE7/VG7e Fb0UfwOTZHmngeRIY7y0Kr+DSKUWF42+3cg90TaX4oqDJ6Elbeaik2F/s8feV2sdb0VR 44+A== X-Gm-Message-State: ABUngvdZ8hxvsriRy32ZFlfhhJLHIB44Ybn1TBXGw8OgqI9BUgzYr9DfNvC69C8N0p7ITsO0djFwdEgSK9U8Jw== X-Received: by 10.37.80.134 with SMTP id e128mr13450538ybb.89.1479103042663; Sun, 13 Nov 2016 21:57:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Sun, 13 Nov 2016 21:57:22 -0800 (PST) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Mon, 14 Nov 2016 14:57:22 +0900 Message-ID: To: Vladimir Dubrovin Content-Type: multipart/alternative; boundary=001a113e9b9471ba3905413c83dd Archived-At: Cc: "dmarc@ietf.org" , "ietf-dkim@mipassoc.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 05:57:25 -0000 --001a113e9b9471ba3905413c83dd Content-Type: text/plain; charset=UTF-8 On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin wrote: > 1. This standard is not backward compatible with existing DKIM > implementations. It makes it useless. In addition, in it's current form it > can not be implemented in most MTAs (see below) > 2. This standard mixes transport standards (SMTP) and message standard. > There are multiple issues as a result of this: > 2.1 Same message may have multiple recipients on different MTAs while each > MTA only sees it's own recipients. So, destination MTA can not verify > signature, because it doesn't know all recipients. This can be fixed if > message to every destination is signed independently, but it breaks > existing mail flows, because in most cases message is signed before placing > to MTA queue. > 2.2 Recieving MTA may e.g. limit the number of recipients and single > message may be sent to different final recipients on the same MTA in > multiple session as few different messages, each message with partial list > of recipients. Actually same message to same destination may be sent to > different MTAs (e.g. different MXs with same weight). > Yes the current text in the document already calls all of those issues out. > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > lowercase the domain of recipient. > That's a good point. > All problems except 2.1 may be fixed by adding additional header, like e.g. > DKIM-Transport-recipients > which contains salted hashes (with some random salt) of all recipient > addresses, and require this header to be added to DKIM signature and > existence for every recipient's address' hash to be checked in this header. > It is compatible with any current DKIM implementation. > 2.1 can also be solved in this case, but it disclosures BCCs of the message > (even if this header is removed before delivery to mailbox) > Also an interesting idea. > All problems may be solved by using asymmetric encryption instead of > hashing, e.g. require domains with support for this standard to publish > some public key (or to use special DKIM selector) via DNS record and > encrypt recipient's addresses in the additional header with public key and > only sign recipients for systems with this key published. > If you do asymmetric encryption, with or without a distinct selector, aren't you basically doing the same thing I'm proposing, other than where it gets recorded in the message? -MSK --001a113e9b9471ba3905413c83dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 14, 2016 at 6:01 AM, Vladimir Dubrovin <d= ubrovin@corp.mail.ru> wrote:
=20 =20 =20
1. This standard i= s not backward compatible with existing DKIM implementations. It makes it useless. In addition, in it's curren= t form it can not be implemented in most MTAs (see below)
2. This standard mixes transport standards (SMTP) and message standard. There are multiple issues as a result of this:
2.1 Same message may have multiple recipients on different MTAs while each MTA only sees it's own recipients. So, destination MTA can not verify signature, because it doesn't know all recipients. This can be fixed if message to every destination is=C2=A0 signed independently, but it breaks existing mail flows, because in most cases message is signed before placing to MTA queue.
2.2 Recieving MTA may e.g. limit the number of recipients and single message may be sent to different final recipients on the same MTA in multiple session as few different messages, each message with partial list of recipients. Actually same message to same destination may be sent to different MTAs (e.g. different MXs with same weight).

Ye= s the current text in the document already calls all of those issues out.=C2=A0
2.3 Canonization must be better defined. It's usual for MTA to e.g. lowercase the domain of recipient.
<= div>
That's a good point.
=C2=A0
All problems except 2.1 may be fixed by adding additiona= l header, like e.g.
DKIM-Transport-recipients
which contains salted hashes (with some random salt) of all recipient addresses, and require this header to be added to DKIM signature and existence for every recipient's address' hash t= o be checked in this header. It is compatible with any current DKIM implementation.
2.1 can also be solved in this case, but it disclosures BCCs of the message (even if this header is removed before delivery to mailbox)

Also an inte= resting idea.
=C2=A0
All problems may be solved by using asymmetric encryption instead of hashing, e.g. require domains with support for this standard to publish some public key (or to use special DKIM selector) via DNS record and encrypt recipient's addresses in the additional header with public key and only sign recipients for systems with this key published.

If you do = asymmetric encryption, with or without a distinct selector, aren't you = basically doing the same thing I'm proposing, other than where it gets = recorded in the message?

-MSK
--001a113e9b9471ba3905413c83dd-- From nobody Sun Nov 13 22:05:03 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377851294C6 for ; Sun, 13 Nov 2016 22:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeM0pRbPGFgB for ; Sun, 13 Nov 2016 22:04:59 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002: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 DA11512944D for ; Sun, 13 Nov 2016 22:04:58 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id i145so49355984ywg.2 for ; Sun, 13 Nov 2016 22:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iJTt4Nw8/TXLULCfnb488l6VX2j0dvF+Ew4swFOldVk=; b=Vh7iXkbf8+uW+3JNjSmH2aAA4meCIIJ+ALM8oWXJrlOwdcppyr3sSOCdfysFXC5q3n uXHtfEsbv8N3c4gGiCwI4WLWNLjdN7QijUHHN1Jy5EcCO7lVJ37VldSwrM/vCg1IgKOD /c1f2l8VdbxoTePxOumLNI0A5FAhu9JKnn/eQqgX8ELgqw3B3cbYrW5Uyw6imZM966E/ iFwGMpCiAZoZ0DoeWVg5suR3/G0osREohXIEBoFNkHHuB+CmDGbTmYj0K+5iM3bX3FDf CJXLWVSWbmhXQ/EAAsJDFa2TpAvYaq0BDtKliGlp459le+ArNo1kquCiR5BQVtt1YI5z N4uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iJTt4Nw8/TXLULCfnb488l6VX2j0dvF+Ew4swFOldVk=; b=W58d2u3ZexydTM6Io+1iW1J02RVau/nyx73T6CraExmrOfU4/pvW+t9CClpu1VvUjp /eVRxi3euTHxnKqkyPLxFnmUEX3ui/oZIf7h1F76A30eUAaQ4bkOcHNyStQMgUwlaB++ tOfQOvCObWw4C+xf6ngW7jUyMfqiZrnfz6iDTMANGK12REbe9x7hiJg08K3VSukYCWjV cSH5M6PSFxEr1dQ4TBPNTDdAHlvM+SXRtLQOj3pBsxRtdYpobrtbiDdvBRbUR5XiS24J PLo0N8jZopUyIuRPKskh0MX539Hg9br6iTjYt65SiCC0VtC00q6HU7d+HPTs7w79ChZ6 M+zg== X-Gm-Message-State: ABUngvcKvUouQ3VgGiay5MlcXXlQNMic9mBlNDqJUETuUuZsqQk0+F/fHH98R5YOxL9SkSB2WrwEl1K2RClnkQ== X-Received: by 10.129.99.132 with SMTP id x126mr14813687ywb.313.1479103498199; Sun, 13 Nov 2016 22:04:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Sun, 13 Nov 2016 22:04:57 -0800 (PST) In-Reply-To: <01Q79WDUNCU0011WUX@mauve.mrochek.com> References: <01Q79WDUNCU0011WUX@mauve.mrochek.com> From: "Murray S. Kucherawy" Date: Mon, 14 Nov 2016 15:04:57 +0900 Message-ID: To: Ned Freed Content-Type: multipart/alternative; boundary=001a1141cd3e98a86f05413c9e21 Archived-At: Cc: "dmarc@ietf.org" , Vladimir Dubrovin , "ietf-dkim@mipassoc.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 06:05:01 -0000 --001a1141cd3e98a86f05413c9e21 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed wrote: > > Actually same message to same destination may be > > sent to different MTAs (e.g. different MXs with same weight). > > 2.3 Canonization must be better defined. It's usual for MTA to e.g. > > lowercase the domain of recipient. > > Our default is to leave the case of addresses alone by default, but sites > often > do configure things to "right case" their business name. That said, Early > validation would avoid such issues for us. I think. > Long ago some MTAs use to mess with the case of the domain names in the envelope. Assuming some of them are still out there, wouldn't we want to fold everything to lowercase (or uppercase; pick one) before doing the sort? > All problems except 2.1 may be fixed by adding additional header, like > e.g. > > DKIM-Transport-recipients > > which contains salted hashes (with some random salt) of all recipient > > addresses, and require this header to be added to DKIM signature and > > existence for every recipient's address' hash to be checked in this > > header. It is compatible with any current DKIM implementation. > > If you're talking about hashing all recipients together, then I don't see > this > solving all the problems except 2.1. > > And if you're talking about hashing them separately, then why would you > insist that they all be present? > I think he's trying to avoid being clobbered by an envelope that gets split downstream. If you as a verifier have the full original recipient set, then all you care about is that your recipient set is a subset of the original set. > But limiting the number of recipients to 1 when this extension is used > would be > a much simpler approach. Of course there's some overhead involved in doing > this, but given the idiotically limited spam report mechanisms in place at > some > sites single copy may be a requirement already. > It's also the most common use case in threat space, as I understand it. > Finally, my biggest concern here is that this, like most proposals that > involve complex linkages between the header and envelope, is complex > and loaded with pitfalls. (Just look at these two messages...) And at least > some of this spills over to both implementations and operational policy. > Indeed; I don't think that's avoidable if we want to try to tackle this problem versus punting it back up to layers 8 and 9. But maybe that's the best thing one can do. Can we really expect people to get this right? > I wonder that every time I write a draft anymore. :-) -MSK --001a1141cd3e98a86f05413c9e21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 14, 2016 at 8:40 AM, Ned Freed <ned.freed= @mrochek.com> wrote:
> Actua= lly same message to same destination may be
> sent to different MTAs (e.g. different MXs with same weight).
> 2.3 Canonization must be better defined. It's usual for MTA to e.g= .
> lowercase the domain of recipient.

Our default is to leave the case of addresses alone by default, but = sites often
do configure things to "right case" their business name. That sai= d, Early
validation would avoid such issues for us. I think.
Long ago some MTAs use to mess with the case of the domain nam= es in the envelope.=C2=A0 Assuming some of them are still out there, wouldn= 't we want to fold everything to lowercase (or uppercase; pick one) bef= ore doing the sort?

> All problems except 2.1 may be fixed by adding additi= onal header, like e.g.
> DKIM-Transport-recipients
> which contains salted hashes (with some random salt) of all recipient<= br> > addresses, and require this header to be added to DKIM signature and > existence for every recipient's address' hash to be checked in= this
> header. It is compatible with any current DKIM implementation.

If you're talking about hashing all recipients together, then I = don't see this
solving all the problems except 2.1.

And if you're talking about hashing them separately, then why would you=
insist that they all be present?

I thin= k he's trying to avoid being clobbered by an envelope that gets split d= ownstream.=C2=A0 If you as a verifier have the full original recipient set,= then all you care about is that your recipient set is a subset of the orig= inal set.
=C2=A0
But limiting the number of recipients to 1 when this extension is used woul= d be
a much simpler approach. Of course there's some overhead involved in do= ing
this, but given the idiotically limited spam report mechanisms in place at = some
sites single copy may be a requirement already.

It's also the most common use case in threat space, as I under= stand it.
=C2=A0
Finally, my biggest concern here is that this, like most proposals that
involve complex linkages between the header and envelope, is complex
and loaded with pitfalls. (Just look at these two messages...) And at least=
some of this spills over to both implementations and operational policy.

Indeed; I don't think that's avoi= dable if we want to try to tackle this problem versus punting it back up to= layers 8 and 9.=C2=A0 But maybe that's the best thing one can do.
<= br>
Can we really expect people to get this right?

I wonder that every time I write a dr= aft anymore.=C2=A0 :-)

-MSK
--001a1141cd3e98a86f05413c9e21-- From nobody Mon Nov 14 01:25:50 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12B612979D for ; Mon, 14 Nov 2016 01:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 v30iKx9dVmE0 for ; Mon, 14 Nov 2016 01:25:47 -0800 (PST) Received: from smtp24.mail.ru (smtp24.mail.ru [94.100.181.179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6513412978C for ; Mon, 14 Nov 2016 01:25:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=toDJ0DWBZKctKsWWCS9U/15D0bIlXcJ3WUVnnySGhOI=; b=lQmjjqTtv/LdM8NkzGFtHsm92pJ1o+Q8CP4BHYPEkItsgFEmxwr9IK/RHW4O1tRNxvaNjRZ6l6+x//pw4No+7WC5DNCKaz0L2xoOvMMvr5Q01qgLhurwLxMaCjB/6DeUrRRw6xh3BCm1H+LQUdA2VR413qLw43bxMzo4AOBo4PE=; Received: from [178.22.89.88] (port=23286 helo=[127.0.0.1]) by smtp24.mail.ru with esmtpa (envelope-from ) id 1c6DWK-0001Xs-LI for dmarc@ietf.org; Mon, 14 Nov 2016 12:25:44 +0300 To: dmarc@ietf.org References: From: Vladimir Dubrovin Message-ID: <9155198d-45bf-c348-d91e-29026d2f9ac3@corp.mail.ru> Date: Mon, 14 Nov 2016 12:25:43 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------86DA3E06054ECABB1CF0D462" Authentication-Results: smtp24.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-Mras: Ok X-SRW: 606F30325CFA050CC377C1B8681F88D98419425693AA7C2B444F29AD5E9F04E2 X-Mru-Trust-IP: 1 Archived-At: Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 09:25:50 -0000 This is a multi-part message in MIME format. --------------86DA3E06054ECABB1CF0D462 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 14.11.2016 8:57, Murray S. Kucherawy пишет: > > > If you do asymmetric encryption, with or without a distinct selector, > aren't you basically doing the same thing I'm proposing, other than > where it gets recorded in the message? > Consider e.g. random_salt = crypt_random() recipient_sig = as_enc(recipient_pubkey, as_enc(sender_privkey, random_salt + hash(recipient_address))) DKIM-Transport-Sig: recipient_sig(recipient_address1), recipient_sig(recipient_address2), ... only receiving MTA can check the presence of it's own address in the header (salt must be different for every address in the header), so it solves all Bcc leakage issues except every recipient is aware of the number of recipients, and there is no need for recipient to know ALL recipients, that is it solves all transport issues. In addition, because it uses header, it's compatible with current DKIM implementations. Validation: for every recipient_address in envelope (or in local delivery, it doesn't matter) calculate hash(recipient_address) for every recipient_sig in DKIM-Transport-Sig decrypt random_salt+hash(recipient_address) from recipient_sig with as_enc(recipient_privkey, as_enc(sender_pubkey(recipient_sig)) remove random_salt to get hash(recipient_address) for every recipient_address in envelope compare calculated and decrypted hash(recipient_address), if matches mark recipient_address as valid -- Vladimir Dubrovin @Mail.Ru --------------86DA3E06054ECABB1CF0D462 Content-Type: multipart/related; boundary="------------385CCF08955501D28C31DE1A" --------------385CCF08955501D28C31DE1A Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
14.11.2016 8:57, Murray S. Kucherawy пишет:


If you do asymmetric encryption, with or without a distinct selector, aren't you basically doing the same thing I'm proposing, other than where it gets recorded in the message?



 Consider e.g.

random_salt = crypt_random()
recipient_sig = as_enc(recipient_pubkey, as_enc(sender_privkey, random_salt + hash(recipient_address)))

DKIM-Transport-Sig: recipient_sig(recipient_address1), recipient_sig(recipient_address2), ...

only receiving MTA  can check the presence of it's own address in the header (salt must be different for every address in the header), so it solves all Bcc leakage issues except every recipient is aware of the number of recipients,  and there is no need for recipient to know ALL recipients, that is it solves all transport issues. In addition, because it uses header, it's compatible with current DKIM implementations.

Validation:

for every recipient_address in envelope (or in local delivery, it doesn't matter)
    calculate hash(recipient_address)
 for every recipient_sig in DKIM-Transport-Sig
    decrypt random_salt+hash(recipient_address) from recipient_sig with as_enc(recipient_privkey,                       as_enc(sender_pubkey(recipient_sig))
    remove random_salt to get hash(recipient_address)
    for every recipient_address in envelope
        compare calculated and decrypted hash(recipient_address), if matches mark recipient_address as valid



--
Vladimir Dubrovin
@Mail.Ru
--------------385CCF08955501D28C31DE1A Content-Type: image/png; name="ejcaoabbicjnofdp.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ejcaoabbicjnofdp.png" iVBORw0KGgoAAAANSUhEUgAAAHwAAAAZCAQAAABZLoLcAAADz0lEQVR4AeWX2XLiPBCFP3nB 7IEAWSAk4BkWg837P95UuU51WRhXjf1XcjH/8Y2EpO7+tLQQd3JM2XDgwo2CCylvDPkJOVIK PgCYknMm4YfkWJBxe/AdmPLd6ssXwL4svfAjSvhdQc3JuHjwXwR8p3ryC/CrLL/yAxpxFWDK nB6lCBiztpYjEd+pKe+Mfha8L7gzY+oKeTf0ABOOgaanT99rSRgS8lgBCQMirK+VAwa41uCO xMaF9GlmDIHID+WskxypyzspB/a8EEOpCXnZ5wNMB25s2VBok74TAAtZK9gS4WtCqt43TqwI eC57DgHHqTxQbcATPhXXDojKw7nhgcqlu97H81YOzYiBgA/vZOcsSdgxZ6yQB1AqfpgEU69+ pgdSyK7W/8wRIVpyC/4a/JXCLF2BsWw+kPxMqSjUnD0BgVzeyDja2b5QmtMEfVaTkbnNfSSr /7JdZamTwu8txIHK4V+CbyrjMxbtwZ+1VgAfKg/VNuaI1samqCDwwC/MgICdYa0IcBbYQJaV OpW+Yq1XV/C5xTXDAbQH/yp/WpjrEwGYQo4Vc59leeKBj8Grv6jutK7Pto3vz9+QvCN4oP8b vwkBOoErFSXABmtsMLfA0Ay0h6T69M7yElhrJzl8PXcEn+k4xdAdvChNoMYcx72uZm6qdWsL fipLc+7luHYC/7Q4uoMrOQBlEjs1DDpXTG9bgxfaVXXtu4ArUc7+O/gVtC4ZdZ3N3JPu8m7g MXXtuoALY4yvkZLtI2X1EZm5+6qFZ4ACX5Xlt9bgmVrqOj8ET+WnFbhFFHGvSC1Jfc6ntp5r fH1h4NqYs9bgWz1zqG/OOrj137UC96fR14sOtKdlJagDutokx9q7x7Vl24Ib4IyqQk6PwZXt C/otwV81bkhVA4pHOyjSz/0S5qKL55Ul7wpdsyWzKbQGh73d8oGdSGE/AA+5ymsVLmZC2ATu 3e85C5yW7plceSzkThvBBkCChaMv1cbTY4RxJ/CITO05KTt5aQKHhbVdSBnZZBybwKURBTeB 7km5qlYwoaZI67wnABxLDuqcMgPmlRC30AkceqpXv4JLAzisvcePtTeDSxODtY9cUTUmmaOd DkcIVk7VvsOB5Mqgr7i7k5fU06YU8OYFlTLUw2duL4ETmOZk5hdiCrusdvL0WDFbisrkbolp 1IzCnDwZtGPMkhh44qU2awkr+p7DFSMwhSxqYxxTVqyYEau+YGZJaEkPk/lfKp4RK8FG8tSs kCeWrDCWZo3JvIfegRO5Mv4/rpA3ofrfmv+BAmZsOZBbRl3g+Af1By7rr2XUY4YeAAAAAElF TkSuQmCC --------------385CCF08955501D28C31DE1A-- --------------86DA3E06054ECABB1CF0D462-- From nobody Mon Nov 14 05:00:55 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801551296C0 for ; Mon, 14 Nov 2016 05:00:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=xcNXjB9/; dkim=pass (1536-bit key) header.d=taugh.com header.b=IAVDcXym 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 GoV3DK-VmPzc for ; Mon, 14 Nov 2016 05:00:52 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3EE612966F for ; Mon, 14 Nov 2016 05:00:51 -0800 (PST) Received: (qmail 63304 invoked from network); 14 Nov 2016 13:00:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=f747.5829b584.k1611; bh=D2nRvT2NLuHPhqoeu+yY7a4gRFgMGswq75we01/Rdcs=; b=xcNXjB9/bKpRtU0o4ev7ChSGbdPqiG2y34ANz2D9n7islB9RMgoN/x1BsE203F9UggRjE7wbaJQsotjNPUZphBd+OU6ygZBLAjTqAS8eK8+s+2MiQVxNQuHJlTkTXOH7HSrjT29MCUFCfCyiTBXFUHCRE8wB8XzDSBekt5z4lc9XRqKUV8hcMGatP9rBE48Mys/9LZM3H0BMdyCWG+AZrgxCAF8BTvWsGHR1dtaSNtvLn9Uqzh7Xiq6vybRaQCl9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=f747.5829b584.k1611; bh=D2nRvT2NLuHPhqoeu+yY7a4gRFgMGswq75we01/Rdcs=; b=IAVDcXymxf+8RqNusiJgr1TWcKNneCMWMNy/86R4dQTF4ZFNZYKB5+Mo/gfy3zcghaqv/Hx7CAUQmshiM+ctGGv5rDsA33hVZmHFgrzAGuBmCgBEGT86Vznt2+rC8fYMVm72N0LOTuu1wTvit1T1IWnjmuXFw6BmZANHfzbhUXVw9LLZ9kz/vKK9ycWZKfsd0RiVIQgXqjgHP1WYjbhIkXgF8cKArHtBOesArFQDuEHViWtfKAB24+In7lqrUkvn 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; 14 Nov 2016 13:00:52 -0000 Date: 14 Nov 2016 22:00:45 +0900 Message-ID: From: "John R Levine" To: ietf-dkim@mipassoc.org, dmarc@ietf.org 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: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 13:00:53 -0000 [ resent with a reasonably correct date header ] I can write this up as a draft if people think it's interesting. Murray's draft puts the envelope recipients into the DKIM hash, which means that the message sent to multiple MTAs be signed separately for each target MTA. My version puts the recipient addresses into the DKIM-Signature header in an r= tag, separated by colons, using the usual quoted printable to quote colons, semicolons or any other inconvenient characters, e.g., DKIM-Signature: v=1; ... r=foo@example.com:bar@plugh.example; ... The signature is valid if all of the envelope recipient addresses are present in the list of r= addresses. It's OK if the r= list has addresses not in the envelope, which fixes the signature per MTA problem. To prevent data leakages, only addresses that appear in To:, Cc:, Resent-To:, Resent-Cc: should appear in the r= header. If you are worried about replay of mail sent to Bcc: addresses, this approach is not for you, but see below. The reason I copy the addresses into the DKIM header rather than just having a tag that means the recipients have to be in a To/Cc header is that it avoids having to add the full glory of a 5322 header parser into a DKIM verifier. (Murray pointed out this problem.) The reasonable way to make recipients pay attention to the r= tag is to bump the DKIM version number to 2, and perhaps use the mandatory tag indicator trick I suggested ages ago. But since some people insist that a version bump would cause horrible problems* we use the same trick Murray did, and add the string "recipients\r\n" to the end of the text included in the header hash if the signature contains a r= tag. Bonus hack for BCC users: instead of putting the recipients into the r= tag, put in colon separated hex or base32 MD5 hashes of the recipients. To avoid rainbow table attacks, the new rs= tag includes a variable length random salt string that is prefixed to each address before hashing. So to verify the signature, salt and hash the actual recipients and see if all the hashes are in the r= list. This leaks the number of recipients but not their addresses. R's, John * - They are wrong, but there's not much we can do about it. From nobody Mon Nov 14 05:11:29 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70491296C8 for ; Mon, 14 Nov 2016 05:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fB_JOBp3a08 for ; Mon, 14 Nov 2016 05:11:26 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 731D61296C6 for ; Mon, 14 Nov 2016 05:11:26 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id p66so54198763pga.2 for ; Mon, 14 Nov 2016 05:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=GH/W98M+cEidglcKlsdMT3IYsWuHwMQ++62wZAz0bhQ=; b=0Htmm/sgGTkbgNP1pqu4CKul660ea7w+kQ+sEju0rB6EyqBUKraYsGtIDeflrSZykz 4BwvkZ6r7tALBPMf1e57yxAh0Q0kPMPfPatr7jo7gcFXtgkMzzIODX5e6xoru5xg8KGH 5xTUlvBJhBt+mc4G4Z6Wmr378X8bUJcSvCXqJr1nq3r2aN6svOdTW1GyDfiu0RUHUS1f DyQmluASAVvBM0zqcbA0H9jooJHgwQd/9NEzS6PzFRc7eYptr5WwUSVUMuVb7P8IRzMm uswG1TOtNevwOPYjjiGYpItT2KXu91LZhZb8RCFB+LWX55bOHMSVPtncnqfhJ7aK3AtR acXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=GH/W98M+cEidglcKlsdMT3IYsWuHwMQ++62wZAz0bhQ=; b=VzWZ+Zx/Sw0VWiqxdFiofViQcOmqM5SZh+4yzTxaGM6S1QJ6bi46zZ62u5y/Iir2Sz Sc00GryOVJtwNcFkZqE8H8REBY9fruYG2StjZkb0m5VnBjr+4vvMMGpn/Jn22SAlFT7y Yzus5JGR7KP0T3gxkne2DyVKA3ozfyU0tSt5FCeMwi8S8AQaq6EYS7QiO07qGBBjtAFQ Ud4E/NMRgmPrMIaEy03Ef3sI6O4ap6Xx8z08P5H+AdOax0CCv6LVDLsFPnsog94d5nCA kXFuwR47qi2m3ZFBDKay/oNecsfECHW7A7Kz3VZMeE5FJ9PcuZ+O3UwneZd+tG2GoFJ+ JeZA== X-Gm-Message-State: ABUngvfWttpDdj1F3tUnm9fKFF7DBeTg6K/6F04UTMENTY8hTkjwCo5YDmZRryMcsccJ2Q== X-Received: by 10.98.28.79 with SMTP id c76mr35875740pfc.8.1479129086127; Mon, 14 Nov 2016 05:11:26 -0800 (PST) Received: from [172.30.1.54] ([175.193.196.5]) by smtp.gmail.com with ESMTPSA id p79sm41847pfj.51.2016.11.14.05.11.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 05:11:25 -0800 (PST) To: John R Levine , dmarc@ietf.org References: From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Mon, 14 Nov 2016 22:11:09 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: ietf-dkim@mipassoc.org Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 13:11:28 -0000 On 11/14/2016 10:00 PM, John R Levine wrote: > My version puts the recipient addresses into the DKIM-Signature header Privacy violation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 14 05:14:07 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCBD1295BF for ; Mon, 14 Nov 2016 05:14:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=mhWtaKFE; dkim=pass (1536-bit key) header.d=taugh.com header.b=0pv4Z3F2 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 588foEm41Xex for ; Mon, 14 Nov 2016 05:14:05 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB323129418 for ; Mon, 14 Nov 2016 05:14:04 -0800 (PST) Received: (qmail 65320 invoked from network); 14 Nov 2016 13:14:05 -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=ff20.5829b89d.k1611; bh=Nb0HphmnNJKXVyJViDduSDJmpf3CMaiLEZ3NEP+zyl4=; b=mhWtaKFErxHANOLd6A2B7NjKGmAHZrCh9QFUluPDo6ifJGol/rQprFK36aqdZS9dcvokMoIDjXly06EPokICSmdGRx0q6+ab29lBfuxYIJQ9QHWD9sK8dYR/OJEDUxUgPwuN0sA8xHAWbiLTSDYKoTHtRmN8A/jkiQyKPxl5VPhsQaVyaIDep1C9q8I7Lk/4cc0rfqXc89VOf+C9BMAdPxzVHDm7vUFM3tn4YM3vcIxfEpXpy9C21QysQpguHjwK 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=ff20.5829b89d.k1611; bh=Nb0HphmnNJKXVyJViDduSDJmpf3CMaiLEZ3NEP+zyl4=; b=0pv4Z3F2blfgFTR7zeu+Iy8ydr66mAw6YYcR6L0nd3zAY/ghCDnutYsd3zd0TA5bjiKOHr579Nh7tunpSbTWJyGRuNnvV9A1C5XAE0jK633DkcVPDXpQKkpwAKnzxOCmtAETupOHrbw5yiU//RMoQA1pb012fq4QREZ4jjhcIGRnhVPZ+moHnI0Nm4UZ+aFFSLJdjFbmUwicX7T8jQfpsSuhGUaFsTtW8lucBV8CrBGTwRfCMW3Bs/EXCoxp/R2Z 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; 14 Nov 2016 13:14:04 -0000 Date: 14 Nov 2016 22:13:59 +0900 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: References: 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, ietf-dkim@mipassoc.org Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 13:14:06 -0000 > On 11/14/2016 10:00 PM, John R Levine wrote: >> My version puts the recipient addresses into the DKIM-Signature header > > Privacy violation. You might want to read the rest of the message before responding. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Nov 14 06:11:33 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B69129418 for ; Mon, 14 Nov 2016 06:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=teamaol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpYOynh_N3V9 for ; Mon, 14 Nov 2016 06:11:29 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 AF9C71293EC for ; Mon, 14 Nov 2016 06:11:28 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id n21so96273482qka.3 for ; Mon, 14 Nov 2016 06:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamaol.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0LaMdk9QyJdogHl91UyYTrKW4drF5lunq45/bloQ4KA=; b=bQg4JZdxfrktAJHBqt7+6wjEXH/Bhkw7MgXRt1xgncK9wQeP32w02xEDU5Y9ND8IQt 0sI1JQsCEV+tRZKSw7sPUeUsj7SOxOfLPmgZhIX/l2hDl4W+ATOes9pIrEEM+vCXP0gg 6+fteK6hZLUdPook62sbQxG/bJ6qxxsnksAzepjhjSLclollQeO96lqbIKYFd2cjqeOt ofndhUk8QWuK82f72z5n2VWGgZLCxXzifraXJ6IyCaAOZeMKjeWcLAhWDLIf9nc5A3Xh FV/W/nASEqPhEpKFZeGmw243LfqpxXp9CApnOJ3dLLZUFcDyj4efrQ7Lz2e+T/qgO38d /wJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0LaMdk9QyJdogHl91UyYTrKW4drF5lunq45/bloQ4KA=; b=SDVkTIgvgW/npMUG+roMbKrNRH263Pgtu7EJjv40vWMBl29T3mw1/azztWQtc9Tmg2 Ky6w6AMV5g/Sqv24/s6ZlageZjxibPblftCeejopeEE4/F/efU0Y3xO08WnqFFTSMarg lLzoqQKk1HLsU598f2Jngv6TUVv2ffEHMBUZrJ5yNXNL/apxgDR3e72gAY2ejP/UgAAz gq9PRk6tMa3yK033zIc4U+MMGX3k54j025BVoaL4Z7Y3aS0l1ygT4YdiwJBcQP7f4z29 4qyos7u6O63vPMyV2r3N77OkFYWFV1OCf4L/4yvo3eVk2zSKSpkAwCms5vRcEL6CPB1G VTmA== X-Gm-Message-State: ABUngvd/Ncum57i7FwZ+8uxcjlf/s8Zo66+6emRQIoz9I3XjBQBNAsJLzOrqXFIYCMvromNO1SE1mR61UByAG5WN X-Received: by 10.55.42.34 with SMTP id q34mr16527805qkh.283.1479132687413; Mon, 14 Nov 2016 06:11:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.57.135 with HTTP; Mon, 14 Nov 2016 06:11:26 -0800 (PST) In-Reply-To: References: From: Paul Rock Date: Mon, 14 Nov 2016 09:11:26 -0500 Message-ID: To: dmarc Content-Type: multipart/alternative; boundary=001a114938e668fb260541436a17 Archived-At: Cc: ietf-dkim@mipassoc.org Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 14:11:31 -0000 --001a114938e668fb260541436a17 Content-Type: text/plain; charset=UTF-8 I like it at first glance, but some qq- I think you're going to have some major problems with internationalized addresses an/or bad guys generally screwing with you if you try to use the raw addresses in this header. Rather than having to deal with potentially RFC2047 encoded strings or silly quoted string email addresses in this field, why not just go full salt/hash? I assume you're trying to avoid processing overhead? Also, what about cases where the number of recipients make this header insanely long? On Mon, Nov 14, 2016 at 8:13 AM, John R Levine wrote: > On 11/14/2016 10:00 PM, John R Levine wrote: >> >>> My version puts the recipient addresses into the DKIM-Signature header >>> >> >> Privacy violation. >> > > You might want to read the rest of the message before responding. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- PAUL ROCK Principal Software Engineer | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305 --001a114938e668fb260541436a17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like it at first glance, but some qq-
I think you're going to have some major problems with internatio= nalized addresses an/or bad guys generally screwing with you if you try to = use the raw addresses in this header. Rather than having to deal with poten= tially RFC2047 encoded strings or silly quoted string email addresses in th= is field, why not just go full salt/hash? I assume you're trying to avo= id processing overhead? Also, what about cases where the number of recipien= ts make this header insanely long?

On Mon, Nov 14, 2016 at 8:13 AM, John R Levine <johnl= @taugh.com> wrote:
On 11/14/2016 10:00 PM, John R Levine wrote:
My version puts the recipient addresses into the DKIM-Signature header

Privacy violation.

 You might want to read the rest of the message before responding.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


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



--
=
= PAUL ROCK
Principal Software Engineer = | AOL Mail
P: 703-265-5734 | C: 703-980-8380
AIM: paulsrock
22070 Broderick D= r.| Dulles, VA | 20166-9305
--001a114938e668fb260541436a17-- From nobody Mon Nov 14 07:36:13 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95AE12941E for ; Mon, 14 Nov 2016 07:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-JZcCKTEcDT for ; Mon, 14 Nov 2016 07:36:10 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 1FDEE1293F8 for ; Mon, 14 Nov 2016 07:36:10 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q7ASE18NY8011M1K@mauve.mrochek.com> for dmarc@ietf.org; Mon, 14 Nov 2016 07:31:32 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q79PXNP5HC011WUX@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Mon, 14 Nov 2016 07:31:28 -0800 (PST) From: ned+dmarc@mrochek.com Message-id: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> Date: Mon, 14 Nov 2016 05:36:33 -0800 (PST) In-reply-to: "Your message dated Mon, 14 Nov 2016 22:00:45 +0900" References: To: John R Levine Archived-At: Cc: dmarc@ietf.org, ietf-dkim@mipassoc.org Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 15:36:12 -0000 Let's break this down. If we're going to include recipients in the DKIM signature, it seems we have at least three key design decisions to make: (1) Whether or not to (a) Enumerate the recipients, or some representation of them, outside the DKIM hash, and sign that, or (b) Include the recipients, or some representation of them, under the DKIM hash only and don't expose them otherwise. (2) Whether we enumerate recipients as: (a) Cleartext (b) Hashes (c) Encrypted form (d) Some combination of forms Note that (2)(b)-(d) are still choices even in the case of (1)(b). (3) Whether or not the recipient check is an (a) mandatory or (b) optional part of the validation operation. (If you change what's signed in some way it's effectively mandatory, if you add a header containing either the hash of the recipients or a representation of the recipients and include it in the DKIM signature in the normal way it's optional.) Now, in regards (1), I have to say I regard (1)(b) as a complete nonstarter, for all the reasons previously given. The complete lack of control the sender has over how recipient lists get split along the way has the potential to cause all sorts of subtle failures. And given past behavior I don't trust senders using this feature to use mitigations like single recipient messages when necessary. In fact I skeptical most senders will even understand the issues in play well enough to do the right thing. I also categorically reject arguments along the lines of "this problem only happens outside the intended use cases for this capability so we don't need to worry about it". Given the way DMARC has deployed it would be utter folly to base our design decisions on limited use case claims. This is especially true since this mechanism can be employed, albeit in a crude way, to try and prevent people from forwarding messages the message sender doesn't want them to forward. And I absolutely can see people noticing this capability and trying to use it. In fact given the history here it's going to be seriously tempting to view (1)(b) as yet another attack on existing email infrastructure, with all that implies. I'll also note that the implicit claim that the (1)(b)/(2)(a) combination avoids exposing recipient information is in fact false. A simple counterexample would be a message to a single Bcc: recipient in addition to the whoever is listed in the various headers. If I receive such a message I can simply perform the DKIM operation on the recipients listed in the headers, and if it doesn't match I know there's a Bcc:. I then try inserting possible Bcc: recipients into the list until I get a match. And in many cases I'll have a pretty good idea what addresses to try, so in those cases this attack will be many, many, many orders of magnitude more effective than brute force. I believe this last point makes (2)(a) a nonstarter regardless of how (1) is answered. As for whether or not (2)(b) or (2)(c) makes the most sense, the fact that in many cases a recipient can come up with a list of likely addresses to try as noted above is a really serious problem for any hash-based scheme. I'm not exactly wild about the idea of all the public key operations (2)(c) calls for, but I'm even less enthusiastic about adding to the reicpient leakage problem in any way. As for (2)(d), I see little point in using it in conjuction with (2)(b) - it's much simpler to hash them all and be done with it. The combination of (2)(c) and (2)(d), however, has the potential of eliminating some/most of the public key overhead. (Another variation would be to use (2)(c) when a public key is available and (2)(b) when it isn't.) And that brings us to (3). It's important to note that making recipient checks a mandatory part of validation doesn't make enforcement mandatory - a reciever can simply detect and ignore DKIM signatures that require recipient checks. The capability optional recipient validation provides is that a receiver has the option of using the signature in the usual way. (That, and backwards compatibility.) Finally, I note that there is in fact a (0): (0) This scheme can be applied to (a) Any message (b) Single recipient. Requiring separate copies for each recipient in order to cover the recipient with a signature renders (1) and (2) moot. In fact this scheme is so simple that it merits serious consideration. The big problem I see with (0)(b) is the overhead it imposes downstream. But as I noted previously, so many messages are already sent separately to different recipients it's unclear to what extent this is a factor. Ned From nobody Mon Nov 14 07:46:56 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2957F129860 for ; Mon, 14 Nov 2016 07:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.609 X-Spam-Level: X-Spam-Status: No, score=-1.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 c3QZHC2A42cp for ; Mon, 14 Nov 2016 07:46:28 -0800 (PST) Received: from smtp43.i.mail.ru (smtp43.i.mail.ru [94.100.177.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EC7212985C for ; Mon, 14 Nov 2016 07:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=yttnMiuDQQ69/gCh8u3wkjYvq6Omc/4R9cMDjkskKP0=; b=JWUzvzGnVhgZinNLQMHF0pkEZHkMqpnGKMR0LAXZHDreSbTIMF07NalJB6cU8JHKFvmDIMO9ukeL1fGegMrONZp8WKhSSaK+N5q5rSMV+LqNiGYG4iF4K3g3ZgILdKawQle2zECtaw7kLoxDBhDBmLOu2sTiM1L769vU67cMH+I=; Received: from [178.22.89.88] (port=21263 helo=[127.0.0.1]) by smtp43.i.mail.ru with esmtpa (envelope-from ) id 1c6JS5-000613-Vl; Mon, 14 Nov 2016 18:45:46 +0300 To: John R Levine , ietf-dkim@mipassoc.org, dmarc@ietf.org References: From: Vladimir Dubrovin Message-ID: <67a47332-7e29-857d-855a-d24d67eb49d2@corp.mail.ru> Date: Mon, 14 Nov 2016 18:45:40 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A3E62BCBDDA7538063424029" Authentication-Results: smtp43.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-Mras: Ok X-SRW: 606F30325CFA050CC377C1B8681F88D9E106CE1925243086079C12A912BF22FD X-Mru-Trust-IP: 1 Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 15:46:30 -0000 This is a multi-part message in MIME format. --------------A3E62BCBDDA7538063424029 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 14.11.2016 16:00, John R Levine пишет: > > Bonus hack for BCC users: instead of putting the recipients into the > r= tag, put in colon separated hex or base32 MD5 hashes of the > recipients. To avoid rainbow table attacks, the new rs= tag includes > a variable length random salt string that is prefixed to each address > before hashing. So to verify the signature, salt and hash the actual > recipients and see if all the hashes are in the r= list. This leaks > the number of recipients but not their addresses. It doesn't protect against BCC discovery. If Alice alice@example.com wants to check Bob bob@example is a recipients of Bcc, she can directly get a hash of Bob's address with salt without the need to use any rainbow tables. Asymmetric cryptography is requires with both sender's and recipient's key to avoid this possibility. -- Vladimir Dubrovin @Mail.Ru --------------A3E62BCBDDA7538063424029 Content-Type: multipart/related; boundary="------------781670008AD5C59B1381D8D0" --------------781670008AD5C59B1381D8D0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
14.11.2016 16:00, John R Levine пишет:

Bonus hack for BCC users: instead of putting the recipients into the
r= tag, put in colon separated hex or base32 MD5 hashes of the
recipients.  To avoid rainbow table attacks, the new rs= tag includes
a variable length random salt string that is prefixed to each address
before hashing.  So to verify the signature, salt and hash the actual
recipients and see if all the hashes are in the r= list.  This leaks
the number of recipients but not their addresses.

It doesn't protect against BCC discovery. If Alice alice@example.com wants to check Bob bob@example is a recipients of Bcc, she can directly get a hash of Bob's address with salt without the need to use any rainbow tables. Asymmetric cryptography is requires with both sender's and recipient's key to avoid this possibility.


--
Vladimir Dubrovin
@Mail.Ru
--------------781670008AD5C59B1381D8D0 Content-Type: image/png; name="iacedmjndadcglif.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="iacedmjndadcglif.png" iVBORw0KGgoAAAANSUhEUgAAAHwAAAAZCAQAAABZLoLcAAADz0lEQVR4AeWX2XLiPBCFP3nB 7IEAWSAk4BkWg837P95UuU51WRhXjf1XcjH/8Y2EpO7+tLQQd3JM2XDgwo2CCylvDPkJOVIK PgCYknMm4YfkWJBxe/AdmPLd6ssXwL4svfAjSvhdQc3JuHjwXwR8p3ryC/CrLL/yAxpxFWDK nB6lCBiztpYjEd+pKe+Mfha8L7gzY+oKeTf0ABOOgaanT99rSRgS8lgBCQMirK+VAwa41uCO xMaF9GlmDIHID+WskxypyzspB/a8EEOpCXnZ5wNMB25s2VBok74TAAtZK9gS4WtCqt43TqwI eC57DgHHqTxQbcATPhXXDojKw7nhgcqlu97H81YOzYiBgA/vZOcsSdgxZ6yQB1AqfpgEU69+ pgdSyK7W/8wRIVpyC/4a/JXCLF2BsWw+kPxMqSjUnD0BgVzeyDja2b5QmtMEfVaTkbnNfSSr /7JdZamTwu8txIHK4V+CbyrjMxbtwZ+1VgAfKg/VNuaI1samqCDwwC/MgICdYa0IcBbYQJaV OpW+Yq1XV/C5xTXDAbQH/yp/WpjrEwGYQo4Vc59leeKBj8Grv6jutK7Pto3vz9+QvCN4oP8b vwkBOoErFSXABmtsMLfA0Ay0h6T69M7yElhrJzl8PXcEn+k4xdAdvChNoMYcx72uZm6qdWsL fipLc+7luHYC/7Q4uoMrOQBlEjs1DDpXTG9bgxfaVXXtu4ArUc7+O/gVtC4ZdZ3N3JPu8m7g MXXtuoALY4yvkZLtI2X1EZm5+6qFZ4ACX5Xlt9bgmVrqOj8ET+WnFbhFFHGvSC1Jfc6ntp5r fH1h4NqYs9bgWz1zqG/OOrj137UC96fR14sOtKdlJagDutokx9q7x7Vl24Ib4IyqQk6PwZXt C/otwV81bkhVA4pHOyjSz/0S5qKL55Ul7wpdsyWzKbQGh73d8oGdSGE/AA+5ymsVLmZC2ATu 3e85C5yW7plceSzkThvBBkCChaMv1cbTY4RxJ/CITO05KTt5aQKHhbVdSBnZZBybwKURBTeB 7km5qlYwoaZI67wnABxLDuqcMgPmlRC30AkceqpXv4JLAzisvcePtTeDSxODtY9cUTUmmaOd DkcIVk7VvsOB5Mqgr7i7k5fU06YU8OYFlTLUw2duL4ETmOZk5hdiCrusdvL0WDFbisrkbolp 1IzCnDwZtGPMkhh44qU2awkr+p7DFSMwhSxqYxxTVqyYEau+YGZJaEkPk/lfKp4RK8FG8tSs kCeWrDCWZo3JvIfegRO5Mv4/rpA3ofrfmv+BAmZsOZBbRl3g+Af1By7rr2XUY4YeAAAAAElF TkSuQmCC --------------781670008AD5C59B1381D8D0-- --------------A3E62BCBDDA7538063424029-- From nobody Mon Nov 14 10:27:52 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987241295BC for ; Mon, 14 Nov 2016 10:27:51 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=CxK3CfuB; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=sWR2KIAU 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 w34_Bh-oX9Fh for ; Mon, 14 Nov 2016 10:27:50 -0800 (PST) Received: from mail.santronics.com (mail.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7F756129970 for ; Mon, 14 Nov 2016 10:19:43 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2063; t=1479147582; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=9s8yu9Nb7t5F3Ym4mPHrCoSpoOI=; b=CxK3CfuBVN24HKN2nk1vquwNK1ICaoHDLZZysR7J53P87xPAqm9jtg3XUPMMNK 01qXciMlGCQdD45X4bGO70XweSaa4JMbqJVVGBSKL3R9HSRCfkWJZu2Gx9Hq80UY 4sJ3GeBFfbGS99N90vNi9mBtCimvZdL0RUlNEUuUx9Fcw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Mon, 14 Nov 2016 13:19:42 -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; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 686545580.1.2612; Mon, 14 Nov 2016 13:19:41 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2063; t=1479147548; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=dpSVf2H BAD0MjB8GPlIWfXEcFO2aeeDIUJsiQ5amua0=; b=sWR2KIAUFs7zVap9sAjy0D7 /ORmkWKXlAdz1IS0l1+HNj5RM5ko7yWOA7gKj+QRkDtv7c91Fb4khPT9HuOfSxMy x05I44qcbPNyEd0Hbp+ZuSWKDq2HcPKnDwhSjzfrqauOsZZx+gHVU4ir4lPl5ZMC er3iNvaMrhrVcRaAo1PM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Mon, 14 Nov 2016 13:19:08 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 683012500.10.152860; Mon, 14 Nov 2016 13:19:07 -0500 Message-ID: <582A0037.4090206@isdg.net> Date: Mon, 14 Nov 2016 13:19:35 -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.8.1 MIME-Version: 1.0 To: "dmarc@ietf.org" , "ietf-dkim@mipassoc.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 18:27:51 -0000 On 11/13/2016 1:50 AM, Murray S. Kucherawy wrote:> I've posted a draft that attempts to address an attack that's begun to > appear with DKIM. Interestingly, we called it out as a possible > attack in RFC6376 and even RFC4871, but now it's apparently happening > and being annoying enough that people (I believe from the MAAWG > community) are asking if there's a protocol solution that's possible. > > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-rcpts/ > Thanks for the write up. I'm just now reading this (a quick review) and I have several points to make about this effort: From what I read so far, this is 1::MANY distribution issue and less of a 1::1 direct, private email path issue but the 1::1 path is being exploited to prepare a 1::many distribution at some systems? Not excluding another possible tech solutions/proposals to close this "security loophole," the code changes required are significant, both at the signer and verify. With integrated systems, passing the distribution list to the signer is required. There is much change to be considered. If it promotes code changes, then we should consider other DKIM related situations as well to be included in what is essentially an DKIM Update. For example, John's double signature proposal can be considere, and in addition, we could also review the "i=" AUID identity to see if it can help. Our package can the i= for list distributions. But this here bothers me: 9. Implementation Status The next release of OpenDKIM will implement this proposal. OpenDKIM is in widespread use, including at very large installations, so use and utility of this extension can be easily observed. Since this is a security loophole, I'm concern that this proposal needs a very thorough review, including reviewing other proposals and solutions. You could be jumping the gun to implement something that will be harder to pull back and once again, the IETF needs to remember that not everyone uses OpenDKIM. Thanks for your consideration -- HLS From nobody Mon Nov 14 14:32:35 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF0FD12963C for ; Mon, 14 Nov 2016 14:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmy4f4MR6jVK for ; Mon, 14 Nov 2016 14:32:33 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 8052512962F for ; Mon, 14 Nov 2016 14:32:33 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id x23so55908148pgx.1 for ; Mon, 14 Nov 2016 14:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MQcDyHWMDFFxqQOmJ7hBJTdmZ9d0KpqHO+GExFszVCE=; b=as05p0dJpFBGOkHtEqKXEUy8tZB256kCzea+0o1s/h3Y6vPXXKoYT+6jUC3f7JhpEn J/imf+Z3x4xa6KhG4kEh1t6JDpFqe+Gaxmsc5FfX2+ykR0w6Pfm4t7mE5RyZYgPZV4gT EktfSP9zgizw2B/vfoTSwVwbwqFho95i8tE4/4NbYH5HJ/pdFfaBG4175QONE/bIKfQL yIf51GXwFV+uskiv/sVMPi86gUusVdCh6cqgtfijKKY3nbBMsHADKw79xcELqo2bBeSS ciG8lIRwyhO3oUIu4g6dwce0xH7yxj+KE9gj1Z2UymKX65lWUYVyIEfEaBaTIRrx2OX7 AXlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:reply-to :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=MQcDyHWMDFFxqQOmJ7hBJTdmZ9d0KpqHO+GExFszVCE=; b=P4wGNKOq1v8dK1WD4n+Y0RBvNS35lsd81UDTviXMxFmMja+NMRirPdGszjzWuGC1O3 B0nqgaLEK/C7rvyJwIWbT9dpaAw0NG+QgKjRy0DUhfGmLYDiUMfJ84vWmLGdO6CzQRcI 7r+MJrEEDM4FnnGAkRlN2FQ2Ql/zjEChcHUkRuQk2vGnewPHUpKYT2dFjbxiZ+G+g0xD ycPXKi0iaPtLEVrDT/PCVoQRRZpxvj/40iMXxglI2b+v+IrqYrMgbEjV8Z8QYeXCa/Dl wLBe5HvWae2vXm02mBL3UrGQq1DXHBIxtRd90JWriMlklXBAnPu4jv1WDbzx7jGKVkQU dG1g== X-Gm-Message-State: ABUngve2i594cKtE69XR6waHmjBsC1lT/RQoBOWdtc/zBot1GpXlh+MVxm0FtprAYKcJBQ== X-Received: by 10.99.152.25 with SMTP id q25mr5114154pgd.152.1479162753151; Mon, 14 Nov 2016 14:32:33 -0800 (PST) Received: from [172.30.1.34] ([175.193.196.5]) by smtp.gmail.com with ESMTPSA id d15sm37480655pfl.46.2016.11.14.14.32.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 14:32:32 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: John R Levine References: Organization: Brandenburg InternetWorking Message-ID: <72417fea-50f6-e79c-3201-c4d5911909e5@dcrocker.net> Date: Tue, 15 Nov 2016 07:32:17 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org, ietf-dkim@mipassoc.org Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net 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, 14 Nov 2016 22:32:35 -0000 On 11/14/2016 10:13 PM, John R Levine wrote: >> On 11/14/2016 10:00 PM, John R Levine wrote: >>> My version puts the recipient addresses into the DKIM-Signature header >> >> Privacy violation. > > You might want to read the rest of the message before responding. No, I didn't want to. But I did anyhow. The proposal creates redundant information and an especially awkward usage restriction. Invoking the privacy concern is meant to move the focus back to the reason the full, original rfc5321 envelope is not (necessarily) the same as the (aggregate) rfc5322 address header field contents. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 14 14:37:13 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA20F12941A for ; Mon, 14 Nov 2016 14:37:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Olqh/QbO; dkim=pass (1536-bit key) header.d=taugh.com header.b=2FADPz4m 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 PlBBvXu4qvTi for ; Mon, 14 Nov 2016 14:37:11 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BB4127076 for ; Mon, 14 Nov 2016 14:37:10 -0800 (PST) Received: (qmail 36483 invoked from network); 14 Nov 2016 22:37:12 -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=8e82.582a3c98.k1611; bh=n76ikBwXaT1fDrETF1eIGk7mLJpX9Hvd2e0rXRMbCl0=; b=Olqh/QbO2GQLffEnq/HX3MT+kJoaCbaSyI7I/PcadoFKn75awJCHF65IQQ8GWiamTYf2Oj9TKc7rQoyZWQeAAZhg9Kr6xpeUaftKK6L4iWgydtd5wDa8pBEIPSHmRqv6BTEl71dItQ+spBjJ+pNpSad/NYMb6vKYa+1dXpaslJ6NXZtW2j2sDGDmqBG/ZtwUX246RYLc2fyJzM9cIa/IBPlZ3sg3SGJ6iXLZdTh+Pn+5afXI18fsQBV9I/ewvmW8 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=8e82.582a3c98.k1611; bh=n76ikBwXaT1fDrETF1eIGk7mLJpX9Hvd2e0rXRMbCl0=; b=2FADPz4mrhTtplvWP5Wnl9WhSd9L39Hf3KrMDPgQ5jep4G0Jsgip9/ao+i0ASEqqHce3sTg78E+lx+PKrHGN5YDRum+gnID+OKRmLzbnl/e9gN1hYR6YHDSgx30qJhFI62KlevCt9x5pIlZPhLpjsPvH+RABno66yqGVFxmLFol7Mj17CIeGYr4OWWRcHK3Av7DGaoEdR1acJJSsvgGDV4YBbTF9rpjFw5xUTlt880pR2avJ6zF+IX3bo11Sk1mQ 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; 14 Nov 2016 22:37:11 -0000 Date: 15 Nov 2016 07:37:06 +0900 Message-ID: From: "John R Levine" To: dcrocker@bbiw.net In-Reply-To: <72417fea-50f6-e79c-3201-c4d5911909e5@dcrocker.net> References: <72417fea-50f6-e79c-3201-c4d5911909e5@dcrocker.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: Cc: dmarc@ietf.org, ietf-dkim@mipassoc.org Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 22:37:13 -0000 > The proposal creates redundant information and an especially awkward usage > restriction. I entirely agree. Along with Ned's analysis of the various options, I hope this is enough to persuade people that the correct solution to the problem of signing spam for people to resend is Scott's: Don't Do That. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Nov 14 14:41:22 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1131293E9 for ; Mon, 14 Nov 2016 14:41:20 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl 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 22sjGp7ltsYm for ; Mon, 14 Nov 2016 14:41:18 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id BB746129417 for ; Mon, 14 Nov 2016 14:41:18 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3tHlqc6Z86z1LBKm; Mon, 14 Nov 2016 23:41:16 +0100 (CET) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3tHlqc4yKsz1LBKk; Mon, 14 Nov 2016 23:41:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 7539642192A; Mon, 14 Nov 2016 23:41:16 +0100 (CET) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id veepxoBwvKMG; Mon, 14 Nov 2016 23:41:16 +0100 (CET) Received: from [192.168.40.49] (unknown [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id 4201E421929; Mon, 14 Nov 2016 23:41:16 +0100 (CET) To: John R Levine , ietf-dkim@mipassoc.org, dmarc@ietf.org References: From: "Rolf E. Sonneveld" Organization: Sonnection B.V. Message-ID: <85ff7505-dbeb-3bdf-528d-46133d60c516@sonnection.nl> Date: Mon, 14 Nov 2016 23:41:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: 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=1479163276; bh=d6z3s6TlXnygtwFs+QjrYRJSi6wxYQCWTBGvXjclxKQ=; h=Subject:To:From:Message-ID:Date:From; b=epp3/yVgSuqHR3Lry+L0YYvJ0NQ9omufjoqY3bBNI6tbOuazFAfLFCVzgBijwvv5W jlisa4IykE5srdR6jAt2dqJTUjvjwaOuJ8YoOsm6FgxH3fP1SIFudWCIKJ/gDKbeQV nAI4BYX8TfL2pNsFfz3xworU7+xNUMyoj3OB5118= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3tHlqc6Z86z1LBKm Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 22:41:21 -0000 On 14-11-16 14:00, John R Levine wrote: > [ resent with a reasonably correct date header ] > > I can write this up as a draft if people think it's interesting. > > Murray's draft puts the envelope recipients into the DKIM hash, which > means that the message sent to multiple MTAs be signed separately for > each target MTA. > > My version puts the recipient addresses into the DKIM-Signature header > in an r= tag, separated by colons, using the usual quoted printable > to quote colons, semicolons or any other inconvenient characters, e.g., > > DKIM-Signature: v=1; ... r=foo@example.com:bar@plugh.example; ... At the time SenderID was proposed, back in 2004 or something, the act of propagating header information into the transport stream was seen by many as a layering violation. The proposal of Murray and Johns suggested kludge alternative do the reverse: propagating envelope information to the header. In my view this is, again, a layering violation. The downside of crossing layer borders is that transport and header information are (too) tightly coupled, which makes that the flexibility of the original mail design (RFC821/RFC822) is lost. Another aspect, in addition to (3) in Ned's answer, is that changing the way DKIM works brings a huge risk with it, now that DMARC is widely deployed and DMARC heavily relies on DKIM. So any change that is proposed for DKIM must have zero impact on the DKIM verification that is used by DMARC implementations currently in use. /rolf From nobody Mon Nov 14 14:51:10 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FE41294DC for ; Mon, 14 Nov 2016 14:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StCnmZ9aumxW for ; Mon, 14 Nov 2016 14:51:06 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF803127076 for ; Mon, 14 Nov 2016 14:51:05 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id i145so81397712ywg.2 for ; Mon, 14 Nov 2016 14:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9DKx0KO3tt0raIfwkbDLowWB/kiV80mBwb7Dmltx/1I=; b=NeKvYQ9lB10A6u/ioSASR5hGPZdEgXiHeJ4BVvDEY0isLs+y0reHJWY/sEXKBcEl08 pc1CVtTuah7L99g38orw4TgFq5xVHwVq9RskUJgqufzGxPwPecAcbTusgsgxh1h18rdQ Qj4CQqVVcSD9zyoBXzi84SfjAILGHzsE712WSK9/sooRp+FZacvuUv2st/IadeKOjSI1 Nzd2CQuG0NuR+hFVQcPZFF2xZpRLsiPZ36rStNpVhDUGK0cgJfdh17DOHrtZzvkLbmq3 a38YhrgJ2ciX//IZSZ6cEuJiFvBGZdFmsJIIq6qgQnrVcY1o+XyFVhtwCQHEOYkl7WDj 1QPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9DKx0KO3tt0raIfwkbDLowWB/kiV80mBwb7Dmltx/1I=; b=Jn/6tLZyDlMDzxRguzovx4T9CRe+lMDOEth2iyrpsruzW7y/uDMzdelY+xqdjoH2l6 Ilocfs3ZwaYc6oYyNK+b9y92TNlqwTKWKYOU7JS8IAOoTAIe7wGC6khtNVlMVTQPa2M/ pe6N0VBUgqwZSfjzJOTNPF1fxBoGj4SXA3QleGc1/qfOKkLFtEe2HgsyKZAahluhtVrC A+XtgorcaZ+rfTWxgGkJms1+A4n34C9fEJS7BFVi8MaSd0YGPkbua/H5SUPVpROwuifc 9i46SAZTqHU2IT7qTY6l/p4/oAt0+h3f9tP/djZFfvLJ2PSMF/jdF1YOj+QNBMyagLsV lBMA== X-Gm-Message-State: ABUngveesxTizjcI2pLfgYKxelal45G6rgub5t6OnnDlOF3673+0iFv8jMu2EJz4UbumvtBQOig2KZB6C3fnxQ== X-Received: by 10.129.77.68 with SMTP id a65mr19371130ywb.287.1479163865178; Mon, 14 Nov 2016 14:51:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Mon, 14 Nov 2016 14:51:01 -0800 (PST) In-Reply-To: <85ff7505-dbeb-3bdf-528d-46133d60c516@sonnection.nl> References: <85ff7505-dbeb-3bdf-528d-46133d60c516@sonnection.nl> From: "Murray S. Kucherawy" Date: Tue, 15 Nov 2016 07:51:01 +0900 Message-ID: To: "Rolf E. Sonneveld" Content-Type: multipart/alternative; boundary=001a1140b770bfa8ea05414aac3a Archived-At: Cc: "dmarc@ietf.org" , John R Levine , "ietf-dkim@mipassoc.org" Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 22:51:09 -0000 --001a1140b770bfa8ea05414aac3a Content-Type: text/plain; charset=UTF-8 Hi Rolf, On Tue, Nov 15, 2016 at 7:41 AM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > At the time SenderID was proposed, back in 2004 or something, the act of > propagating header information into the transport stream was seen by many > as a layering violation. The proposal of Murray and Johns suggested kludge > alternative do the reverse: propagating envelope information to the header. > In my view this is, again, a layering violation. The downside of crossing > layer borders is that transport and header information are (too) tightly > coupled, which makes that the flexibility of the original mail design > (RFC821/RFC822) is lost. > There's obviously some truth to this, but there's also truth to the fact that humans, the ones this community seeks to serve, routinely cross layers in both directions whether or not we do so in protocols. End user education has never been a viable answer to protocol limitations as far as I'm aware, much as we all wish it were so. I'm willing to hold my nose -- a little -- at a reach across a layer boundary if there's potentially a large win. Whether this proposal or some variant of it qualifies is why I brought the question to this group. -MSK --001a1140b770bfa8ea05414aac3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Rolf,

On Tue, Nov 15, 2016 at 7:41 AM, Rolf E. S= onneveld <R.E.Sonneveld@sonnection.nl> wrote:
At the time SenderID was proposed, back in 2004 or something, the act of pr= opagating header information into the transport stream was seen by many as = a layering violation. The proposal of Murray and Johns suggested kludge alt= ernative do the reverse: propagating envelope information to the header. In= my view this is, again, a layering violation. The downside of crossing lay= er borders is that transport and header information are (too) tightly coupl= ed, which makes that the flexibility of the original mail design (RFC821/RF= C822)=C2=A0 is lost.

There's obviou= sly some truth to this, but there's also truth to the fact that humans,= the ones this community seeks to serve, routinely cross layers in both dir= ections whether or not we do so in protocols.=C2=A0 End user education has = never been a viable answer to protocol limitations as far as I'm aware,= much as we all wish it were so.

I'm willing to hold = my nose -- a little -- at a reach across a layer boundary if there's po= tentially a large win.=C2=A0 Whether this proposal or some variant of it qu= alifies is why I brought the question to this group.

-MSK
--001a1140b770bfa8ea05414aac3a-- From nobody Mon Nov 14 15:07:43 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D57D129528 for ; Mon, 14 Nov 2016 15:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ho70DjWt-Wug for ; Mon, 14 Nov 2016 15:07:39 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 C8B4A1293E9 for ; Mon, 14 Nov 2016 15:07:39 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id t125so80885992ywc.1 for ; Mon, 14 Nov 2016 15:07:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ydK//dqIvwlLFg6+5ZXbogjKL1FZgqszO+cKeH7DW4w=; b=U4VmHt4pcBYAYnwVlsuD0+kIMBWRTe6b5MJV70nPuP6NCV8jXhdTiqeqDUripZv3LB 2Z9CwR/6f8Kuw2y7M8KxvVSFdEoG/6jKe1dDfyrZV4R7yo3lx3HviRDRNSvKUEFaeRj8 +NnU5SahdLIc13+CfYFnJV9lrUQ24u/VRmD8487/WC5dLTgKnEM6Y3OzQJhq6fwo7Vda NzDANg+Jm0M5+uV+Xz3qpTNSpYuYgs3TBJDOXd8jAQtbw4CEyHjtGQZp1QOb2JJ6AHbd SCV27tmuOomY7Xl/bxq/hw9j2HAMCfPjtMNpTdRsMeb6KbgXDJW0VGtC12jT+UPp2JrY Asbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ydK//dqIvwlLFg6+5ZXbogjKL1FZgqszO+cKeH7DW4w=; b=crLdNmRfTpBLT5BvN5ZUb4uLS8e5DZuo2wS2sLOKmqQUPBNB21NNekgdWEe1F0niOm FsDMNAmr1XQgWoCQ14AKzOcoMqoTAOBYHDWSXLoqY/MiG+NTlM5Okp9Trx3LyL4OR1Xu R/z2TnZ/M82TL/uO6IA0GFBFSwp2dpZFVODUCTS1ckgECg6eYFmf7Bap52P9fV1ycD95 jlmW0OUq24xzzkxmJIaszuPFIjsKYvgU67z6F6c5X/zPJghzuLrHYi8BmA97rJVMW5OR cYjQihZ0LEYyhUOA/UKcV3AqyFPn9W7lviu67g7vds4I8Y5HmSe3kwhQSc+UwRcQ1ofg oEew== X-Gm-Message-State: ABUngveQBkr1xfkLJoRjk0Z6l6bkTy+8fxjV+eRD+lgAcD0lCgNcS2uL7GvGllPnUMhwbbe1kCct+LsNbKfKrQ== X-Received: by 10.129.99.132 with SMTP id x126mr19329622ywb.313.1479164859075; Mon, 14 Nov 2016 15:07:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Mon, 14 Nov 2016 15:07:38 -0800 (PST) In-Reply-To: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> From: "Murray S. Kucherawy" Date: Tue, 15 Nov 2016 08:07:38 +0900 Message-ID: To: Ned Freed Content-Type: multipart/alternative; boundary=001a1141cd3efd90b505414ae7b7 Archived-At: Cc: "dmarc@ietf.org" , John R Levine , "ietf-dkim@mipassoc.org" Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 23:07:41 -0000 --001a1141cd3efd90b505414ae7b7 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 14, 2016 at 10:36 PM, wrote: > Let's break this down. If we're going to include recipients in the DKIM > signature, it seems we have at least three key design decisions to make: > [...] > That's a pretty excellent summary. A couple of points: I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being the ideal choices. Is that correct? If so, we would just need to determine the algorithm for generating the signed content that would be included in the augmented signature. If we do something like the random salt suggestion, is this sufficient? - pick a random string S of length L using only printable ASCII characters (I like 8 for L but that's arbitrary) - SHA the string produced by prepending S to the recipient address, and express the result in base64 string R - include R in a new "er" (envelope recipient) tag and the salt S in an "rs" (recipient salt) tag This is not reversible so nothing is leaked, but as we've all conceded by now it's not hard to attack this to recover the hashed address especially since one might have good guesses as to what that address would be. I can't see the point of actually encrypting the hashed content, because anybody can decrypt it with the public key. What am I missing? -MSK --001a1141cd3efd90b505414ae7b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 14, 2016 at 10:36 PM, <<= a href=3D"mailto:ned+dmarc@mrochek.com" target=3D"_blank">ned+dmarc@mrochek= .com> wrote:
Let's break this down. If we= 9;re going to include recipients in the DKIM
signature, it seems we have at least three key design decisions to make: [...]

That's a pretty excellent sum= mary.=C2=A0 A couple of points:

I think you narrowed it down t= o (0)(b), (1)(a), (2)(d), and (3)(b) being the ideal choices.=C2=A0 Is that= correct?=C2=A0 If so, we would just need to determine the algorithm for ge= nerating the signed content that would be included in the augmented signatu= re.=C2=A0 If we do something like the random salt suggestion, is this suffi= cient?

- pick a random string S of = length L using only printable ASCII characters (I like 8 for L but that'= ;s arbitrary)
- SHA the string produced= by prepending S to the recipient address, and express the result in base64= string R
- include R in a new "er= " (envelope recipient) tag and the salt S in an "rs" (recipi= ent salt) tag

This is not reversibl= e so nothing is leaked, but as we've all conceded by now it's not h= ard to attack this to recover the hashed address especially since one might= have good guesses as to what that address would be.

I can't see the point of actually encrypting th= e hashed content, because anybody can decrypt it with the public key.
What am I missing?

-MSK
--001a1141cd3efd90b505414ae7b7-- From nobody Mon Nov 14 15:41:00 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A36128874 for ; Mon, 14 Nov 2016 15:40:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=p4Xzbiwi; dkim=pass (1536-bit key) header.d=taugh.com header.b=zbIJJ1ja 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 xJN3IEJvHEBR for ; Mon, 14 Nov 2016 15:40:54 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C01129426 for ; Mon, 14 Nov 2016 15:40:54 -0800 (PST) Received: (qmail 46158 invoked from network); 14 Nov 2016 23:40:55 -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=b44d.582a4b87.k1611; bh=XnqVrTjRYc1fna3KPR2jrszdCY4PP6Tfy97kFfG2ZCk=; b=p4XzbiwiaO+wzku60bdWHWDNx/ITyWygdjjhzY8wzuU6+gU6ndBwbZnHDKdD6Jgnq2M4Rbwym+uZjTqwDRV3PxRS4YvEyTmJn5xW2gl4qiuaVjXTFrMtplG4EfGaTuV35CK97fd2JIUf1E79qz/jlc9B6clpBKFC93l/8O6yKKW9Fkoo+IEqfOkPfGg6Mwg8XQSQIe/ufrlavfYPEFt84pCqPJobUiGl80deKQdLmKWtg7IjsZYytSt7682kjj3m 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=b44d.582a4b87.k1611; bh=XnqVrTjRYc1fna3KPR2jrszdCY4PP6Tfy97kFfG2ZCk=; b=zbIJJ1jaihEYl0DjXoYNSjQZT/shRwpeELruoh2XCSoPIDmlOs5DHsHIz8FNB36q0V4JuPOov8mIQychuRqy1mSIXv9ei005idfr1NpRGetoKzEuvNa8bwY2kMVh5Umi0SJLJ3x5cGimLBt9Y1tLzn63rBIRPDHrRxzayJIBNeECTHW9dc7GRkgaRKc/SP5CPdPkA9c/PS/7DOljCdtXg6rTe7+WfIt2LHnpNbZWS5xeH/FcTWmPyhQPm4zdRiBk 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; 14 Nov 2016 23:40:55 -0000 Date: 15 Nov 2016 08:40:50 +0900 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> 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" , "ietf-dkim@mipassoc.org" Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 23:40:56 -0000 > - pick a random string S of length L using only printable ASCII characters > (I like 8 for L but that's arbitrary) > - SHA the string produced by prepending S to the recipient address, and > express the result in base64 string R > - include R in a new "er" (envelope recipient) tag and the salt S in an > "rs" (recipient salt) tag I'd use base32 so it's not case sensitive but that's a very small nit. > What am I missing? Nothing I can see. This seems to be the least bad implementation of this fundamentally bad idea. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Nov 14 17:00:47 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05A4129632 for ; Mon, 14 Nov 2016 17:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8pw2scKgWpB for ; Mon, 14 Nov 2016 17:00:45 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 80845129605 for ; Mon, 14 Nov 2016 17:00:45 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id x23so57169474pgx.1 for ; Mon, 14 Nov 2016 17:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:cc:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=deEAqe/VRWslssyvACRxwc+j3CmyhqtnolOyA04q6r8=; b=ezxo/gKZFp+IzVfBQl1XbTemYb8Sy1f7et/lh/HpQOxLM0DiZ6hYwaFJPI21czdz8S 4KgmJIsufP8v0Ul2NnU8AoWwtLBys4MLHvGjTUN52X9gYZae0Ifwia+BdDX2bsX0WilY KPtNFlMtqgeb29rn5BtyFA411vZwo6+wrlo2FIUtOWciDRsPI5UMNzIwdT70XewkKqKo llSkIgCjlovpIGXAcQOiQo+Dtby9LOILG0m3Eb7Wr5c3flHnybAH6mp7tNztclTVNvlB FTLG98YJTq+YKZHhvQjQorir/xzxWv39WCGJLv2JrO8i09ElJ9W9qFpVUHUV1Ok6LAig fiQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:cc:reply-to :organization:message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=deEAqe/VRWslssyvACRxwc+j3CmyhqtnolOyA04q6r8=; b=RYR7XUn7cQ0nN7MVmSXAUX6ubqZapV0zSg/1X9rw80ZjiIb+s7NHpx7QjpgOH2lsry Ahg5+H8FTyBTsZhuojZ4IydO/q54l33O1XczeT1PUe7i1RPYOoiwl0KvZHDLJXJhXsto Bwkw3nEM4KSpXxY49gUrbI5dBPnXYjFuDXi4EGfLfsSuhy+ZLDrG5OKc4qjBb78TgM4W 1JieqkFAps0IdKL/+n4QU4oavq5PEle15pN36OnuXOClshixXDpPHVVlQoY8CJeFEuj1 KNqXEOO5tnjITUOcdHe6viwcWqyb80fmLNznQ6Qsc9bTLMMi5veoSlSWILzwZFdS0KxM PHgA== X-Gm-Message-State: ABUngveqJXHUVphLwk0oDjhhHadQJD0EtBfNKJlWF0rBtFtBzlrcigfzXOE5qsWoTbp5xQ== X-Received: by 10.98.72.129 with SMTP id q1mr41354048pfi.169.1479171645151; Mon, 14 Nov 2016 17:00:45 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:9486:368:6380:37df? ([2001:67c:370:128:9486:368:6380:37df]) by smtp.gmail.com with ESMTPSA id u127sm37879961pfu.21.2016.11.14.17.00.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 17:00:44 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: "Murray S. Kucherawy" , "Rolf E. Sonneveld" References: <85ff7505-dbeb-3bdf-528d-46133d60c516@sonnection.nl> Organization: Brandenburg InternetWorking X-Priority: 2 (High) Message-ID: <05adaf85-35d8-bcd3-a9f2-710f3dd34d86@dcrocker.net> Date: Tue, 15 Nov 2016 10:00:25 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , John R Levine , "ietf-dkim@mipassoc.org" Subject: [dmarc-ietf] DKIM ONLY PLEASE! (was: Re: [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net 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, 15 Nov 2016 01:00:46 -0000 Annyeong haseyo, While this thread is relevant to dmarc, it doesn't cover dmarc work. So can we please stop copying the dmarc mailing list and just send to the dkim mailing list, where it belongs? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 15 01:01:35 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637B4129A5B for ; Tue, 15 Nov 2016 01:01:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 C9-dVfL38HOF for ; Tue, 15 Nov 2016 01:01:26 -0800 (PST) Received: from smtp2.mail.ru (smtp2.mail.ru [94.100.179.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107AB129A6B for ; Tue, 15 Nov 2016 01:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=LE2yQIBF7btqmNAyHDKeMcJ/8Yxbeq+iazaupBTEo3U=; b=Ts8Z7uUQp/yvtUyTW99IxZ6ccilYSVhQb2fNYBbEOWlUpsGfETnLYLQKqdppsoZ7goepkPS0MXiKkz5WMsyF9TTAFfFw/tNfpGAyRFD6zfopzigpD4BbVVMKScGkX8bTjTsDwteHCrwt9mh0JiCryoANv5CP/b2wJ9R7Uvxqas4=; Received: from [178.22.89.88] (port=6568 helo=[127.0.0.1]) by smtp2.mail.ru with esmtpa (envelope-from ) id 1c6Zc9-0000Ry-62; Tue, 15 Nov 2016 12:01:13 +0300 To: "Murray S. Kucherawy" , Ned Freed References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> From: Vladimir Dubrovin Message-ID: <3995e97c-a89a-88ca-8d2d-5c41471edff1@corp.mail.ru> Date: Tue, 15 Nov 2016 12:01:09 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DB992B5D3C4E58F9922D8B96" Authentication-Results: smtp2.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-Mras: Ok X-SRW: 606F30325CFA050CC377C1B8681F88D974E17C639F1AF4B2BF12E579EB771E66 X-Mru-Trust-IP: 1 Archived-At: Cc: "dmarc@ietf.org" , John R Levine , "ietf-dkim@mipassoc.org" Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 09:01:33 -0000 This is a multi-part message in MIME format. --------------DB992B5D3C4E58F9922D8B96 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 15.11.2016 2:07, Murray S. Kucherawy пишет: > On Mon, Nov 14, 2016 at 10:36 PM, > wrote: > > Let's break this down. If we're going to include recipients in the > DKIM > signature, it seems we have at least three key design decisions to > make: > [...] > > > That's a pretty excellent summary. A couple of points: > > I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) > being the ideal choices. Is that correct? If so, we would just need > to determine the algorithm for generating the signed content that > would be included in the augmented signature. If we do something like > the random salt suggestion, is this sufficient? > > - pick a random string S of length L using only printable ASCII > characters (I like 8 for L but that's arbitrary) > - SHA the string produced by prepending S to the recipient address, > and express the result in base64 string R > - include R in a new "er" (envelope recipient) tag and the salt S in > an "rs" (recipient salt) tag > > This is not reversible so nothing is leaked, but as we've all conceded > by now it's not hard to attack this to recover the hashed address > especially since one might have good guesses as to what that address > would be. > > I can't see the point of actually encrypting the hashed content, > because anybody can decrypt it with the public key. > > What am I missing? > There is no need to reverse if you know e-mail address. Alice can check Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail and check if he is in 'er'. > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- Vladimir Dubrovin @Mail.Ru --------------DB992B5D3C4E58F9922D8B96 Content-Type: multipart/related; boundary="------------85E7A7BED421334808C38FC9" --------------85E7A7BED421334808C38FC9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
15.11.2016 2:07, Murray S. Kucherawy пишет:
On Mon, Nov 14, 2016 at 10:36 PM, <ned+dmarc@mrochek.com> wrote:
Let's break this down. If we're going to include recipients in the DKIM
signature, it seems we have at least three key design decisions to make:
[...]

That's a pretty excellent summary.  A couple of points:

I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being the ideal choices.  Is that correct?  If so, we would just need to determine the algorithm for generating the signed content that would be included in the augmented signature.  If we do something like the random salt suggestion, is this sufficient?

- pick a random string S of length L using only printable ASCII characters (I like 8 for L but that's arbitrary)
- SHA the string produced by prepending S to the recipient address, and express the result in base64 string R
- include R in a new "er" (envelope recipient) tag and the salt S in an "rs" (recipient salt) tag

This is not reversible so nothing is leaked, but as we've all conceded by now it's not hard to attack this to recover the hashed address especially since one might have good guesses as to what that address would be.

I can't see the point of actually encrypting the hashed content, because anybody can decrypt it with the public key.

What am I missing?


There is no need to reverse if you know e-mail address. Alice can check Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail and check if he is in 'er'.


-MSK


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


--
Vladimir Dubrovin
@Mail.Ru
--------------85E7A7BED421334808C38FC9 Content-Type: image/png; name="ojmbmmgeaicmmjec.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ojmbmmgeaicmmjec.png" iVBORw0KGgoAAAANSUhEUgAAAHwAAAAZCAQAAABZLoLcAAADz0lEQVR4AeWX2XLiPBCFP3nB 7IEAWSAk4BkWg837P95UuU51WRhXjf1XcjH/8Y2EpO7+tLQQd3JM2XDgwo2CCylvDPkJOVIK PgCYknMm4YfkWJBxe/AdmPLd6ssXwL4svfAjSvhdQc3JuHjwXwR8p3ryC/CrLL/yAxpxFWDK nB6lCBiztpYjEd+pKe+Mfha8L7gzY+oKeTf0ABOOgaanT99rSRgS8lgBCQMirK+VAwa41uCO xMaF9GlmDIHID+WskxypyzspB/a8EEOpCXnZ5wNMB25s2VBok74TAAtZK9gS4WtCqt43TqwI eC57DgHHqTxQbcATPhXXDojKw7nhgcqlu97H81YOzYiBgA/vZOcsSdgxZ6yQB1AqfpgEU69+ pgdSyK7W/8wRIVpyC/4a/JXCLF2BsWw+kPxMqSjUnD0BgVzeyDja2b5QmtMEfVaTkbnNfSSr /7JdZamTwu8txIHK4V+CbyrjMxbtwZ+1VgAfKg/VNuaI1samqCDwwC/MgICdYa0IcBbYQJaV OpW+Yq1XV/C5xTXDAbQH/yp/WpjrEwGYQo4Vc59leeKBj8Grv6jutK7Pto3vz9+QvCN4oP8b vwkBOoErFSXABmtsMLfA0Ay0h6T69M7yElhrJzl8PXcEn+k4xdAdvChNoMYcx72uZm6qdWsL fipLc+7luHYC/7Q4uoMrOQBlEjs1DDpXTG9bgxfaVXXtu4ArUc7+O/gVtC4ZdZ3N3JPu8m7g MXXtuoALY4yvkZLtI2X1EZm5+6qFZ4ACX5Xlt9bgmVrqOj8ET+WnFbhFFHGvSC1Jfc6ntp5r fH1h4NqYs9bgWz1zqG/OOrj137UC96fR14sOtKdlJagDutokx9q7x7Vl24Ib4IyqQk6PwZXt C/otwV81bkhVA4pHOyjSz/0S5qKL55Ul7wpdsyWzKbQGh73d8oGdSGE/AA+5ymsVLmZC2ATu 3e85C5yW7plceSzkThvBBkCChaMv1cbTY4RxJ/CITO05KTt5aQKHhbVdSBnZZBybwKURBTeB 7km5qlYwoaZI67wnABxLDuqcMgPmlRC30AkceqpXv4JLAzisvcePtTeDSxODtY9cUTUmmaOd DkcIVk7VvsOB5Mqgr7i7k5fU06YU8OYFlTLUw2duL4ETmOZk5hdiCrusdvL0WDFbisrkbolp 1IzCnDwZtGPMkhh44qU2awkr+p7DFSMwhSxqYxxTVqyYEau+YGZJaEkPk/lfKp4RK8FG8tSs kCeWrDCWZo3JvIfegRO5Mv4/rpA3ofrfmv+BAmZsOZBbRl3g+Af1By7rr2XUY4YeAAAAAElF TkSuQmCC --------------85E7A7BED421334808C38FC9-- --------------DB992B5D3C4E58F9922D8B96-- From nobody Tue Nov 15 05:31:18 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D5012962C for ; Tue, 15 Nov 2016 05:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNvUBYgL7NP1 for ; Tue, 15 Nov 2016 05:31:15 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 2334E129460 for ; Tue, 15 Nov 2016 05:31:15 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id i145so94673022ywg.2 for ; Tue, 15 Nov 2016 05:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kaqr2UTlNHDZYyzQHnk1+jxCEVHKEIaJRETfoGenitA=; b=0RNqYL3Sa8VErWAN/TR/kimSi4t+45RutW+UuEvX6sVaAXFJy/Z7Hn5SOOp+MbG0Ii STFo95Yn9SXKz6KDACLz+4oAS4uv6XkstDMuymgxjxwZmcm2LOqgWGvStbchb/AxeFHP FhOj7OapdJA3p82sUeGGO72prCTQ+DWO5nt2KzSnu8XYVoOJsVzbicZNeg4lEvl929rI 90Yo2ofz6DndOA1dErSt2pcQGoFLHo3AbM/wumD+g3v79rkifgl1qIQj2UqYgZ0A0LJf /eN3qoYMs7VkJD/i5ZUWgvHTLCUcNLYFOTbYHtMUwsavustqnWIiWQ4jBebSsW2g0tUs iENA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kaqr2UTlNHDZYyzQHnk1+jxCEVHKEIaJRETfoGenitA=; b=I1p3TyzEKkUCMcrZJh4OQvSIdPs7oszHw5qCKCu45PlCGU6KZi4YzXWMtiVOg9XROE wPd108hW3Z4Sf1vaAfhvnBK9dO4YlYrSeRDQTq/Bv7Kc10aa5/D4+P1Vg/M2jHSbEImY m6PbdOFk0N3WDlKIExWxNkJ+r+KBI1g4KLzVibFHwNr4e932D7fC5J6kRPJcV+BEe7u/ KAhBA2gXFN8rfaFeU/e1t3RZN6pbATMls5qSyO2Jc+aTpcvFjLmU0HuRFlV6NgSuXzNf V+NG4DGch2joMDKYUxMseNbugTTIGB6CJj5fLQ5RZFqJGi4VGfxyu4kFgG5EhlTT0/Ma d4aw== X-Gm-Message-State: ABUngvcodocjbyBUDcplvesuDTQgAz4KXY80/zLjQP3xtnOwF4qjxTaL3A/1k64//xDWwMo45ufSaADLot1Hvg== X-Received: by 10.13.243.134 with SMTP id c128mr19096350ywf.182.1479216674365; Tue, 15 Nov 2016 05:31:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Tue, 15 Nov 2016 05:31:13 -0800 (PST) In-Reply-To: <3995e97c-a89a-88ca-8d2d-5c41471edff1@corp.mail.ru> References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> <3995e97c-a89a-88ca-8d2d-5c41471edff1@corp.mail.ru> From: "Murray S. Kucherawy" Date: Tue, 15 Nov 2016 22:31:13 +0900 Message-ID: To: Vladimir Dubrovin Content-Type: multipart/alternative; boundary=94eb2c0311586c0589054156f8c8 Archived-At: Cc: "dmarc@ietf.org" , John R Levine , "ietf-dkim@mipassoc.org" , Ned Freed Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 13:31:17 -0000 --94eb2c0311586c0589054156f8c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin wrote: > 15.11.2016 2:07, Murray S. Kucherawy =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Mon, Nov 14, 2016 at 10:36 PM, wrote: > >> Let's break this down. If we're going to include recipients in the DKIM >> signature, it seems we have at least three key design decisions to make: >> [...] >> > > That's a pretty excellent summary. A couple of points: > > I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being > the ideal choices. Is that correct? If so, we would just need to > determine the algorithm for generating the signed content that would be > included in the augmented signature. If we do something like the random > salt suggestion, is this sufficient? > > - pick a random string S of length L using only printable ASCII character= s > (I like 8 for L but that's arbitrary) > - SHA the string produced by prepending S to the recipient address, and > express the result in base64 string R > - include R in a new "er" (envelope recipient) tag and the salt S in an > "rs" (recipient salt) tag > > This is not reversible so nothing is leaked, but as we've all conceded by > now it's not hard to attack this to recover the hashed address especially > since one might have good guesses as to what that address would be. > > I can't see the point of actually encrypting the hashed content, because > anybody can decrypt it with the public key. > > What am I missing? > > > There is no need to reverse if you know e-mail address. Alice can check > Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail a= nd > check if he is in 'er'. > Yes. I wasn't identifying "not reversible" as a shortcoming, but rather as a benefit. -MSK --94eb2c0311586c0589054156f8c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 15, 2016 at 6:01 PM, Vladimir Dubrovin <d= ubrovin@corp.mail.ru> wrote:
=20 =20 =20
15.11.2016 2:07, Mu= rray S. Kucherawy =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
On Mon, Nov 14, 2016 at 10:36 PM, = <ned+dmarc@mr= ochek.com> wrote:
Let's break this down. If we're going to include recipients in the DKIM
signature, it seems we have at least three key design decisions to make:
[...]

That's a pretty excellent summary.=C2=A0 A couple of p= oints:

I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being the ideal choices.=C2=A0 Is that correct?=C2=A0 If= so, we would just need to determine the algorithm for generating the signed content that would be included in the augmented signature.=C2=A0 If we do something like the random salt suggestion, is this sufficient?

- pick a random string S of length L using only printable ASCII characters (I like 8 for L but that's arbitrary)
- SHA the string produced by prepending S to the recipient address, and express the result in base64 string R
- include R in a new "er" (e= nvelope recipient) tag and the salt S in an "rs" (recipient s= alt) tag

This is not reversible so nothing is leaked, but as we've all conceded by now it's not hard = to attack this to recover the hashed address especially since one might have good guesses as to what that address would be.

I can't see the point of actually encrypting the hashed content, because anybody can decrypt it with the public key.

What am I missing?


 There is no need to reverse if you know e-mail address. Alice can check Bob received Bcc if Alice knows Bob's e-mail. She can hash Bob's e-mail and check if he is in 'er'.

Yes.=C2=A0 I wasn't identifying "not rever= sible" as a shortcoming, but rather as a benefit.

-M= SK
--94eb2c0311586c0589054156f8c8-- From nobody Tue Nov 15 17:45:57 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3E7129479 for ; Tue, 15 Nov 2016 17:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imckxl-h9zWK for ; Tue, 15 Nov 2016 17:45:53 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 8E401129405 for ; Tue, 15 Nov 2016 17:45:53 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id a10so115243273ywa.3 for ; Tue, 15 Nov 2016 17:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SpD0TpFBLqyMrHXbLEWZvKQJkMVjPUV9TSwArlx306c=; b=PVBPJ0LS6yNryohf/38gXPb8Ddtx2YhYRKHU8KETPqlzhi9E633evbCrOdJdwuFZDy 01KlH8pf0ZUYiryI2betqinkb59Wh5EpYkMrIQCslx2IBOVdhlK1F537Si3qLhPoCB7Z EWpZnInsbttMagbeOrXrG3jYEEQFiFknqtmXzr98cEsYdnkfMC91R30RDic2zU1Ct4GP 1qI77/L2tgp4e2t4z9WcRyf3080Av7d3jBnWOYwgLIhO8DB20i6woyY8vpqjEvumNhlO 6rOnbI1YomPFO0JjaBgwr5yH8tY58Zc6th5mBnoZV11k+RFG4jMzdJvsSsbtEfOQN/Ee Kalg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SpD0TpFBLqyMrHXbLEWZvKQJkMVjPUV9TSwArlx306c=; b=JFOfSaxor/K8PL9/sdThwC7Tp0WI1EIgwnqZ/Spv3aPeDHSEugexleQrCzjcx4b3+v 9Zwug9L0fVsO5ciNMvJXRSAu7BrpEIIjhH4+UmNizDtin2Ac9zHyE32tUavY6DbLl0uw Bw2De3Qbx4lwClbiWQB3aT4dfd7o5CVGo2CCVESnitMAzXFes+G7nCi8jXe6N9zxowyU bJU/JIpRBDxbjje5pKq24MYrfd7mg9FeKb1tol/m+oAGx0iaVystc48z6GrZpTnlq1gk fKtSfo6p3JF76O16deJCp7g64vvV1Qu42PqVYloa7o99YEbyzBPAu4a0nSGNLkt07S8V EPrA== X-Gm-Message-State: ABUngvdekgUv12sdcv182s7HJ8g/qJRNX+VwZFe6vB4eCEx6nYXlTEzPfUXdbcQ34RFiRpBII5umMpBZMLAjHw== X-Received: by 10.129.77.68 with SMTP id a65mr276018ywb.287.1479260752848; Tue, 15 Nov 2016 17:45:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Tue, 15 Nov 2016 17:45:52 -0800 (PST) In-Reply-To: References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> From: "Murray S. Kucherawy" Date: Wed, 16 Nov 2016 10:45:52 +0900 Message-ID: To: Ned Freed Content-Type: multipart/alternative; boundary=001a1140b770b42feb0541613bcd Archived-At: Cc: "dmarc@ietf.org" , John R Levine , "ietf-dkim@mipassoc.org" Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:45:56 -0000 --001a1140b770b42feb0541613bcd Content-Type: text/plain; charset=UTF-8 There's been a lot of great feedback here. I just cranked out an update based on the discussion so far: https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01 I forgot to update the title of Section 3, but other than that I think I captured what's been discussed. Please let me know what I've missed. -MSK On Tue, Nov 15, 2016 at 8:07 AM, Murray S. Kucherawy wrote: > On Mon, Nov 14, 2016 at 10:36 PM, wrote: > >> Let's break this down. If we're going to include recipients in the DKIM >> signature, it seems we have at least three key design decisions to make: >> [...] >> > > That's a pretty excellent summary. A couple of points: > > I think you narrowed it down to (0)(b), (1)(a), (2)(d), and (3)(b) being > the ideal choices. Is that correct? If so, we would just need to > determine the algorithm for generating the signed content that would be > included in the augmented signature. If we do something like the random > salt suggestion, is this sufficient? > > - pick a random string S of length L using only printable ASCII characters > (I like 8 for L but that's arbitrary) > - SHA the string produced by prepending S to the recipient address, and > express the result in base64 string R > - include R in a new "er" (envelope recipient) tag and the salt S in an > "rs" (recipient salt) tag > > This is not reversible so nothing is leaked, but as we've all conceded by > now it's not hard to attack this to recover the hashed address especially > since one might have good guesses as to what that address would be. > > I can't see the point of actually encrypting the hashed content, because > anybody can decrypt it with the public key. > > What am I missing? > > -MSK > --001a1140b770b42feb0541613bcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's been a lot of great feedback here.= =C2=A0 I just cranked out an update based on the discussion so far:

= https://www.ietf.org/rfcdiff?url2=3Ddraft-kucherawy-dkim-rcpts-01
I forgot to update the title of Section 3, but other than that I= think I captured what's been discussed.=C2=A0 Please let me know what = I've missed.

-MSK

=
On Tue, Nov 15, 2016 at 8:07 AM, Murray S. K= ucherawy <superuser@gmail.com> wrote:
On Mon, Nov 14, 2016 at 10:= 36 PM, <ned+dmarc@mrochek.com> wrote:
Let's break this down. If we're going to includ= e recipients in the DKIM
signature, it seems we have at least three key design decisions to make: [...]

That's a pretty excellent sum= mary.=C2=A0 A couple of points:

I think you narrowed it down t= o (0)(b), (1)(a), (2)(d), and (3)(b) being the ideal choices.=C2=A0 Is that= correct?=C2=A0 If so, we would just need to determine the algorithm for ge= nerating the signed content that would be included in the augmented signatu= re.=C2=A0 If we do something like the random salt suggestion, is this suffi= cient?

- pick a random string S of = length L using only printable ASCII characters (I like 8 for L but that'= ;s arbitrary)
- SHA the string produced= by prepending S to the recipient address, and express the result in base64= string R
- include R in a new "er= " (envelope recipient) tag and the salt S in an "rs" (recipi= ent salt) tag

This is not reversibl= e so nothing is leaked, but as we've all conceded by now it's not h= ard to attack this to recover the hashed address especially since one might= have good guesses as to what that address would be.

I can't see the point of actually encrypting th= e hashed content, because anybody can decrypt it with the public key.
What am I missing?

-MSK

--001a1140b770b42feb0541613bcd-- From nobody Tue Nov 15 17:51:08 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E881129587 for ; Tue, 15 Nov 2016 17:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH8bLV2Qs5NO for ; Tue, 15 Nov 2016 17:51:00 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0112.outbound.protection.outlook.com [104.47.38.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32D4129411 for ; Tue, 15 Nov 2016 17:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Pq7biULubBU9y+Asu/7HCu4vBOCT6U/PJAZE0lKMReY=; b=XAg9L4/amqJGnSc/8ViKoQDdpZYUUZLwZzz9bzlnrVwzAxOx2p9SVdXPPogOgnKaGC/I44En9yAn69Virjd6pfd5dsoiuZDmBxg0HM3DWSI/f7fjhfamjH6R/9Rhvk/f2JsrDCYA+WkREHCxdBmvnQDPxVB6Nq9KZ2Ff7paziD0= Received: from CY1PR00MB0107.namprd00.prod.outlook.com (10.167.9.141) by CY1PR00MB0105.namprd00.prod.outlook.com (10.167.9.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.755.0; Wed, 16 Nov 2016 01:50:57 +0000 Received: from CY1PR00MB0107.namprd00.prod.outlook.com ([10.167.9.141]) by CY1PR00MB0107.namprd00.prod.outlook.com ([10.167.9.141]) with mapi id 15.01.0755.000; Wed, 16 Nov 2016 01:50:57 +0000 From: Terry Zink To: "dmarc@ietf.org" , "ietf-dkim@mipassoc.org" Thread-Topic: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts Thread-Index: AQHSPnclbHSEJxQHVkKpc3/b7SYIuKDYnMA8gAB+GgCAAb6LAIAAAOyA Date: Wed, 16 Nov 2016 01:50:56 +0000 Message-ID: References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:7::66e] x-ms-office365-filtering-correlation-id: c0c6551c-61ba-458d-a776-08d40dc30219 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR00MB0105; x-microsoft-exchange-diagnostics: 1; CY1PR00MB0105; 7:Ti8G1/ScfERAIgGk1U8J4l8nFvHLXJUeyCwjH5MYo2/oTqxXQ+NwFGjK7Nhhn9b4o6HjYJF4GQdCv8UzF5qKx5sKd6g19LVKDUlI7UlLN4r51k2y2In8w198tTuzt2lVp8DV+AmmHJ1oL57iPkqAIrsYvtAjG4tHT9pRk9dnELUjqxkCn4/EYO8YASuYQjP6WOxSt3pWx+tDRGMV+3/+ST9bgRnu8c4E2/gegB/EfpIt/r4vOrmFuN8ES3dAPzMbt7xsKOlNnZezmLLoxTR8ktrdW2w0yCQa8FtOdRGJbZzG/SqtXGV8b4iDmPOuEgdJYxncee4W+wQw6wjWOEHLudE0CVOBSsNwkEFeCgB5L0jFMAbWGl68kGdyGnxbVUp1v5yRF5m48YIU0lB6RLG9Gy7ikoLnB5o6SIeCmoZfZN8RmggdWJCo+fU/5JsX491RER4TTNnenobkcF5XYxeKNGB/doi+TrETYq2qQH+kYYA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6061324)(6046074)(6072148)(6047074); SRVR:CY1PR00MB0105; BCL:0; PCL:0; RULEID:; SRVR:CY1PR00MB0105; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(377454003)(189002)(3905003)(50986999)(92566002)(229853002)(54356999)(76176999)(99286002)(106116001)(76576001)(105586002)(106356001)(5005710100001)(2906002)(107886002)(10290500002)(8990500004)(101416001)(790700001)(6116002)(102836003)(3660700001)(5660300001)(86362001)(3280700002)(2501003)(7906003)(81156014)(8676002)(7736002)(74316002)(7846002)(42882006)(19609705001)(2950100002)(87936001)(81166006)(7696004)(606004)(8936002)(77096005)(68736007)(93886004)(5001770100001)(9686002)(230783001)(97736004)(10090500001)(122556002)(189998001)(2900100001)(33656002)(6506003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR00MB0105; H:CY1PR00MB0107.namprd00.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR00MB0107389F8FE73F140849A19996BE0CY1PR00MB0107namp_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2016 01:50:56.9030 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0105 Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:51:03 -0000 --_000_CY1PR00MB0107389F8FE73F140849A19996BE0CY1PR00MB0107namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBtYXkgYmUgYSBkdW1iIHF1ZXN0aW9uLCBidXQgaWYgYSBES0lNLXNpZ25hdHVyZSBpbmNs dWRlcyB0aGUgb3JpZ2luYWwgcmVjaXBpZW50LCB0aGVuIHdvdWxkbuKAmXQgdGhhdCBicmVhayB0 aGUgREtJTSBzaWduYXR1cmUgaWYgdGhlIG9yaWdpbmFsIE1UQSBmb3J3YXJkcyBpdCB0byBhbm90 aGVyIHJlY2VpdmVyIGV2ZW4gaWYgdGhleSBkb27igJl0IG1vZGlmeSBhbnkgcGFydHMgb2YgdGhl IG1lc3NhZ2U/DQoNCkhvdyB3b3VsZCBwZW9wbGUgZm9yd2FyZCB0aGVpciBlbWFpbD8NCg0KRnJv bTogZG1hcmMgW21haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTXVy cmF5IFMuIEt1Y2hlcmF3eQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTUsIDIwMTYgNTo0NiBQ TQ0KVG86IE5lZCBGcmVlZCA8bmVkK2RtYXJjQG1yb2NoZWsuY29tPg0KQ2M6IGRtYXJjQGlldGYu b3JnOyBKb2huIFIgTGV2aW5lIDxqb2hubEB0YXVnaC5jb20+OyBpZXRmLWRraW1AbWlwYXNzb2Mu b3JnDQpTdWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIFtpZXRmLWRraW1dIGEgc2xpZ2h0bHkgbGVz cyBrbHVkZ2UgYWx0ZXJuYXRpdmUgdG8gZHJhZnQta3VjaGVyYXd5LWRtYXJjLXJjcHRzDQoNClRo ZXJlJ3MgYmVlbiBhIGxvdCBvZiBncmVhdCBmZWVkYmFjayBoZXJlLiAgSSBqdXN0IGNyYW5rZWQg b3V0IGFuIHVwZGF0ZSBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBzbyBmYXI6DQoNCmh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rdWNoZXJhd3ktZGtpbS1yY3B0cy0wMTxo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRnd3dy5pZXRmLm9yZyUyRnJmY2RpZmYlM0Z1cmwyJTNEZHJhZnQta3VjaGVyYXd5LWRr aW0tcmNwdHMtMDEmZGF0YT0wMiU3QzAxJTdDdHppbmslNDBleGNoYW5nZS5taWNyb3NvZnQuY29t JTdDMDgxZDU3OTljODk5NGE2M2VhZmQwOGQ0MGRjMjUwM2UlN0M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MTQ4NTc1NjAyNDU0ODQ5JnNkYXRhPUxyaDIlMkZU am9WTUQ0VjZ4dGxMJTJGcTJ2M25heCUyRkxTdEUyV1lRamtXYk93TEklM0QmcmVzZXJ2ZWQ9MD4N CkkgZm9yZ290IHRvIHVwZGF0ZSB0aGUgdGl0bGUgb2YgU2VjdGlvbiAzLCBidXQgb3RoZXIgdGhh biB0aGF0IEkgdGhpbmsgSSBjYXB0dXJlZCB3aGF0J3MgYmVlbiBkaXNjdXNzZWQuICBQbGVhc2Ug bGV0IG1lIGtub3cgd2hhdCBJJ3ZlIG1pc3NlZC4NCi1NU0sNCg0KT24gVHVlLCBOb3YgMTUsIDIw MTYgYXQgODowNyBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbTxt YWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gTW9uLCBOb3YgMTQsIDIwMTYg YXQgMTA6MzYgUE0sIDxuZWQrZG1hcmNAbXJvY2hlay5jb208bWFpbHRvOm5lZCtkbWFyY0Btcm9j aGVrLmNvbT4+IHdyb3RlOg0KTGV0J3MgYnJlYWsgdGhpcyBkb3duLiBJZiB3ZSdyZSBnb2luZyB0 byBpbmNsdWRlIHJlY2lwaWVudHMgaW4gdGhlIERLSU0NCnNpZ25hdHVyZSwgaXQgc2VlbXMgd2Ug aGF2ZSBhdCBsZWFzdCB0aHJlZSBrZXkgZGVzaWduIGRlY2lzaW9ucyB0byBtYWtlOg0KWy4uLl0N Cg0KVGhhdCdzIGEgcHJldHR5IGV4Y2VsbGVudCBzdW1tYXJ5LiAgQSBjb3VwbGUgb2YgcG9pbnRz Og0KSSB0aGluayB5b3UgbmFycm93ZWQgaXQgZG93biB0byAoMCkoYiksICgxKShhKSwgKDIpKGQp LCBhbmQgKDMpKGIpIGJlaW5nIHRoZSBpZGVhbCBjaG9pY2VzLiAgSXMgdGhhdCBjb3JyZWN0PyAg SWYgc28sIHdlIHdvdWxkIGp1c3QgbmVlZCB0byBkZXRlcm1pbmUgdGhlIGFsZ29yaXRobSBmb3Ig Z2VuZXJhdGluZyB0aGUgc2lnbmVkIGNvbnRlbnQgdGhhdCB3b3VsZCBiZSBpbmNsdWRlZCBpbiB0 aGUgYXVnbWVudGVkIHNpZ25hdHVyZS4gIElmIHdlIGRvIHNvbWV0aGluZyBsaWtlIHRoZSByYW5k b20gc2FsdCBzdWdnZXN0aW9uLCBpcyB0aGlzIHN1ZmZpY2llbnQ/DQotIHBpY2sgYSByYW5kb20g c3RyaW5nIFMgb2YgbGVuZ3RoIEwgdXNpbmcgb25seSBwcmludGFibGUgQVNDSUkgY2hhcmFjdGVy cyAoSSBsaWtlIDggZm9yIEwgYnV0IHRoYXQncyBhcmJpdHJhcnkpDQotIFNIQSB0aGUgc3RyaW5n IHByb2R1Y2VkIGJ5IHByZXBlbmRpbmcgUyB0byB0aGUgcmVjaXBpZW50IGFkZHJlc3MsIGFuZCBl eHByZXNzIHRoZSByZXN1bHQgaW4gYmFzZTY0IHN0cmluZyBSDQotIGluY2x1ZGUgUiBpbiBhIG5l dyAiZXIiIChlbnZlbG9wZSByZWNpcGllbnQpIHRhZyBhbmQgdGhlIHNhbHQgUyBpbiBhbiAicnMi IChyZWNpcGllbnQgc2FsdCkgdGFnDQpUaGlzIGlzIG5vdCByZXZlcnNpYmxlIHNvIG5vdGhpbmcg aXMgbGVha2VkLCBidXQgYXMgd2UndmUgYWxsIGNvbmNlZGVkIGJ5IG5vdyBpdCdzIG5vdCBoYXJk IHRvIGF0dGFjayB0aGlzIHRvIHJlY292ZXIgdGhlIGhhc2hlZCBhZGRyZXNzIGVzcGVjaWFsbHkg c2luY2Ugb25lIG1pZ2h0IGhhdmUgZ29vZCBndWVzc2VzIGFzIHRvIHdoYXQgdGhhdCBhZGRyZXNz IHdvdWxkIGJlLg0KDQpJIGNhbid0IHNlZSB0aGUgcG9pbnQgb2YgYWN0dWFsbHkgZW5jcnlwdGlu ZyB0aGUgaGFzaGVkIGNvbnRlbnQsIGJlY2F1c2UgYW55Ym9keSBjYW4gZGVjcnlwdCBpdCB3aXRo IHRoZSBwdWJsaWMga2V5Lg0KV2hhdCBhbSBJIG1pc3Npbmc/DQotTVNLDQoNCg== --_000_CY1PR00MB0107389F8FE73F140849A19996BE0CY1PR00MB0107namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5h bWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIG1heSBiZSBhIGR1bWIgcXVl c3Rpb24sIGJ1dCBpZiBhIERLSU0tc2lnbmF0dXJlIGluY2x1ZGVzIHRoZSBvcmlnaW5hbCByZWNp cGllbnQsIHRoZW4gd291bGRu4oCZdCB0aGF0IGJyZWFrIHRoZSBES0lNIHNpZ25hdHVyZSBpZiB0 aGUgb3JpZ2luYWwgTVRBIGZvcndhcmRzIGl0IHRvIGFub3RoZXIgcmVjZWl2ZXIgZXZlbiBpZiB0 aGV5IGRvbuKAmXQgbW9kaWZ5IGFueSBwYXJ0cyBvZiB0aGUgbWVzc2FnZT88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SG93IHdvdWxkIHBlb3BsZSBmb3J3YXJkIHRoZWlyIGVtYWlsPzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48 bzpwPiZuYnNwOzwvbzpwPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls RW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IGRt YXJjIFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+ TXVycmF5IFMuIEt1Y2hlcmF3eTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAx NSwgMjAxNiA1OjQ2IFBNPGJyPg0KPGI+VG86PC9iPiBOZWQgRnJlZWQgJmx0O25lZCYjNDM7ZG1h cmNAbXJvY2hlay5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkbWFyY0BpZXRmLm9yZzsgSm9obiBS IExldmluZSAmbHQ7am9obmxAdGF1Z2guY29tJmd0OzsgaWV0Zi1ka2ltQG1pcGFzc29jLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZdIFtpZXRmLWRraW1dIGEgc2xpZ2h0 bHkgbGVzcyBrbHVkZ2UgYWx0ZXJuYXRpdmUgdG8gZHJhZnQta3VjaGVyYXd5LWRtYXJjLXJjcHRz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+VGhlcmUncyBiZWVuIGEgbG90IG9mIGdyZWF0IGZlZWRiYWNrIGhl cmUuJm5ic3A7IEkganVzdCBjcmFua2VkIG91dCBhbiB1cGRhdGUgYmFzZWQgb24gdGhlIGRpc2N1 c3Npb24gc28gZmFyOjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG cmZjZGlmZiUzRnVybDIlM0RkcmFmdC1rdWNoZXJhd3ktZGtpbS1yY3B0cy0wMSZhbXA7ZGF0YT0w MiU3QzAxJTdDdHppbmslNDBleGNoYW5nZS5taWNyb3NvZnQuY29tJTdDMDgxZDU3OTljODk5NGE2 M2VhZmQwOGQ0MGRjMjUwM2UlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM2MTQ4NTc1NjAyNDU0ODQ5JmFtcDtzZGF0YT1McmgyJTJGVGpvVk1ENFY2eHRsTCUy RnEydjNuYXglMkZMU3RFMldZUWprV2JPd0xJJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQta3VjaGVyYXd5LWRraW0tcmNwdHMtMDE8L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+SSBmb3Jnb3QgdG8gdXBkYXRlIHRoZSB0aXRsZSBvZiBTZWN0aW9u IDMsIGJ1dCBvdGhlciB0aGFuIHRoYXQgSSB0aGluayBJIGNhcHR1cmVkIHdoYXQncyBiZWVuIGRp c2N1c3NlZC4mbmJzcDsgUGxlYXNlIGxldCBtZSBrbm93IHdoYXQgSSd2ZSBtaXNzZWQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+LU1TSzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBOb3YgMTUsIDIwMTYgYXQgODowNyBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3 eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5zdXBlcnVzZXJAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTm92IDE0LCAyMDE2 IGF0IDEwOjM2IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5lZCYjNDM7ZG1hcmNAbXJvY2hlay5j b20iIHRhcmdldD0iX2JsYW5rIj5uZWQmIzQzO2RtYXJjQG1yb2NoZWsuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5MZXQncyBicmVhayB0aGlzIGRvd24uIElmIHdlJ3JlIGdvaW5nIHRvIGluY2x1 ZGUgcmVjaXBpZW50cyBpbiB0aGUgREtJTTxicj4NCnNpZ25hdHVyZSwgaXQgc2VlbXMgd2UgaGF2 ZSBhdCBsZWFzdCB0aHJlZSBrZXkgZGVzaWduIGRlY2lzaW9ucyB0byBtYWtlOjxicj4NClsuLi5d PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYXQncyBhIHByZXR0eSBleGNlbGxl bnQgc3VtbWFyeS4mbmJzcDsgQSBjb3VwbGUgb2YgcG9pbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkg dGhpbmsgeW91IG5hcnJvd2VkIGl0IGRvd24gdG8gKDApKGIpLCAoMSkoYSksICgyKShkKSwgYW5k ICgzKShiKSBiZWluZyB0aGUgaWRlYWwgY2hvaWNlcy4mbmJzcDsgSXMgdGhhdCBjb3JyZWN0PyZu YnNwOyBJZiBzbywgd2Ugd291bGQganVzdCBuZWVkIHRvIGRldGVybWluZSB0aGUgYWxnb3JpdGht IGZvciBnZW5lcmF0aW5nIHRoZSBzaWduZWQgY29udGVudCB0aGF0IHdvdWxkDQogYmUgaW5jbHVk ZWQgaW4gdGhlIGF1Z21lbnRlZCBzaWduYXR1cmUuJm5ic3A7IElmIHdlIGRvIHNvbWV0aGluZyBs aWtlIHRoZSByYW5kb20gc2FsdCBzdWdnZXN0aW9uLCBpcyB0aGlzIHN1ZmZpY2llbnQ/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHBpY2sgYSBy YW5kb20gc3RyaW5nIFMgb2YgbGVuZ3RoIEwgdXNpbmcgb25seSBwcmludGFibGUgQVNDSUkgY2hh cmFjdGVycyAoSSBsaWtlIDggZm9yIEwgYnV0IHRoYXQncyBhcmJpdHJhcnkpPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFNIQSB0aGUgc3RyaW5n IHByb2R1Y2VkIGJ5IHByZXBlbmRpbmcgUyB0byB0aGUgcmVjaXBpZW50IGFkZHJlc3MsIGFuZCBl eHByZXNzIHRoZSByZXN1bHQgaW4gYmFzZTY0IHN0cmluZyBSPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPi0gaW5jbHVkZSBSIGluIGEgbmV3ICZxdW90O2VyJnF1b3Q7IChlbnZlbG9wZSByZWNpcGll bnQpIHRhZyBhbmQgdGhlIHNhbHQgUyBpbiBhbiAmcXVvdDtycyZxdW90OyAocmVjaXBpZW50IHNh bHQpIHRhZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyBpcyBub3QgcmV2ZXJzaWJsZSBzbyBub3RoaW5nIGlzIGxlYWtlZCwgYnV0IGFzIHdl J3ZlIGFsbCBjb25jZWRlZCBieSBub3cgaXQncyBub3QgaGFyZCB0byBhdHRhY2sgdGhpcyB0byBy ZWNvdmVyIHRoZSBoYXNoZWQgYWRkcmVzcyBlc3BlY2lhbGx5IHNpbmNlIG9uZSBtaWdodCBoYXZl IGdvb2QgZ3Vlc3NlcyBhcyB0byB3aGF0IHRoYXQgYWRkcmVzcyB3b3VsZCBiZS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPkkgY2FuJ3Qgc2VlIHRoZSBwb2ludCBvZiBhY3R1YWxseSBlbmNyeXB0aW5nIHRo ZSBoYXNoZWQgY29udGVudCwgYmVjYXVzZSBhbnlib2R5IGNhbiBkZWNyeXB0IGl0IHdpdGggdGhl IHB1YmxpYyBrZXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPldoYXQgYW0gSSBtaXNzaW5nPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPi1NU0s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR00MB0107389F8FE73F140849A19996BE0CY1PR00MB0107namp_-- From nobody Tue Nov 15 17:53:02 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E8D129544 for ; Tue, 15 Nov 2016 17:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjFtMiL5FGLW for ; Tue, 15 Nov 2016 17:52:58 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 44AE212957C for ; Tue, 15 Nov 2016 17:52:57 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id f188so72847835pgc.3 for ; Tue, 15 Nov 2016 17:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:references:reply-to:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=JG1C4bO9PchF6pdipcqsu6cPb2Iq2QWdDLIy4xLJq/Q=; b=YpNUUWYjoN7hoT0CGxbpHr+x7LSUi4CDbaR6XdksARlsfVEZgOdc/JkEuVA0EBH/6k cp9zO0kVTBnwNYEJ8A0G6SzwUgcseZhOSHsSLQNljR0O1dSW5PZa8TI5wzu5I6ABHUg3 UljYqCnjziuznidorRTtTXmjUbEjaATfsuCWnf5H+0mUU95ZDaWA4pdAiOiXHb1Be0xE o659gFvkWAGmAw03l/wQoi8Mpgrzz2QDBLyG6NeVNwj1FyDV7ua2XOBLQTqBNtJulf/8 /1sdabDFy1ykCmkQ00I2If3gUAiophcQw6hE3FqFyWNf53O5mI01aG9t3DKbtjYHhWKV NKNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:reply-to:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=JG1C4bO9PchF6pdipcqsu6cPb2Iq2QWdDLIy4xLJq/Q=; b=IiUDghCdiYSO7vRx7z0ejaMv8IOfJvBnn2XC9pdecVEDjbNO7DCQniPf4RCenjlURg D2D2cJZSvxyXKASqM5jn/WIvioukvkGGo5si9Jvp0ZYSGSOoqfLncD6Uua+IF21v/5gH ScwaDVJZbfZB9qxesmpJuGqyY4XwQcEuzheyUoQl849pikRtAcSr1a92mRSIsR12GMqV aBqPsR78OFGoAZRQ1EdRde6NIalomYB74NLJTRXwP3hZKQiRUwMctzyGu6IN0bTsfxi5 AbV9JHjaSgJF/GIKkrEnjF5JxRsjuUnbpn/Dmcwp0V3e90zdGqsQhaN02fIQURbjawq+ jNXA== X-Gm-Message-State: ABUngvf3hPS5/DBKmDJI2xqPxp+Tbd8gs+7wqiS99OhpPfu0VOmFijmFOEwtQ8EbMsohZg== X-Received: by 10.98.158.155 with SMTP id f27mr955804pfk.165.1479261176954; Tue, 15 Nov 2016 17:52:56 -0800 (PST) Received: from [172.30.1.59] ([175.193.196.5]) by smtp.gmail.com with ESMTPSA id x90sm46927492pfk.73.2016.11.15.17.52.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 17:52:56 -0800 (PST) From: Dave Crocker X-Google-Original-From: Dave Crocker To: Terry Zink , "dmarc@ietf.org" , "ietf-dkim@mipassoc.org" References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> Organization: Brandenburg InternetWorking Message-ID: <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> Date: Wed, 16 Nov 2016 10:52:35 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:53:01 -0000 On 11/16/2016 10:50 AM, Terry Zink wrote: > This may be a dumb question, but if a DKIM-signature includes the > original recipient, then wouldnt that break the DKIM signature if the > original MTA forwards it to another receiver even if they dont modify > any parts of the message? the proposal is to add the envelope rcpt-to to the signature. change the rcpt-to and yes the signature will break. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 15 17:57:06 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEF412963D for ; Tue, 15 Nov 2016 17:57: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=OJAEZWo9; dkim=pass (1536-bit key) header.d=taugh.com header.b=gECSH9LH 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 ufKL6kr6CVGl for ; Tue, 15 Nov 2016 17:57:03 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F717129544 for ; Tue, 15 Nov 2016 17:57:03 -0800 (PST) Received: (qmail 45079 invoked from network); 16 Nov 2016 01:57: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=b016.582bbcf0.k1611; bh=rd86FCSdn5sTZBQUj9g1vszVx1yJQMW4MCHfg0PXeZQ=; b=OJAEZWo9S+TfO7RvotwLB5Mi64luqCOabZ/UV0QYIzq2vB8WhS1UHl1NbjJPOE11Xf3MshlIctt3OEbOq4CKnGJxWiz+Razbj429sRwflbrFfwTmDW2o+hZ7qA2pFJex2Dc4WARkXtoHpL7Vnau9OBdnSPguXaL1e/bzWJNpvGrxnrgXkur5MCw6koB9r3xYGkgc5zk0u97RJ55VBI1CGHorl50k9RkzguDkWqgIonkyDchinYhhnV1E4EMpRtG0 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=b016.582bbcf0.k1611; bh=rd86FCSdn5sTZBQUj9g1vszVx1yJQMW4MCHfg0PXeZQ=; b=gECSH9LHbcgbXdisTnscrZ7c+fIjjJoKgP6bfEPd7jG75bBvLDW2VvhFAt5LjwSkv/H4nXibKVOC7EjXAVwoNDblE13KEpjxPqBe2re2GzwUGEngs31Hsk44GU13FEiexntoQ5xWgBPZrzaISeNrvTOpexvR3QW9nr5ovwcL5oC1BgXpeUBIsVaw5kKN6uqfCsxdz2TZessXFVSkvz2A+GOq8oBoEQZPxy6vLztGZtnQRNdPXTIpqCjTneQ4zP9W 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; 16 Nov 2016 01:57:04 -0000 Date: 16 Nov 2016 10:56:57 +0900 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> 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" , John R Levine , "ietf-dkim@mipassoc.org" , Ned Freed Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:57:05 -0000 > https://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-rcpts-01 > > I forgot to update the title of Section 3, but other than that I think I > captured what's been discussed. Please let me know what I've missed. How come rh= has one hash instead of several? You can put all the addresses in the To: and Cc: headers in one header without leaking, then do separate single hash if there are bcc's. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Nov 15 17:59:20 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE392129538 for ; Tue, 15 Nov 2016 17:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfRcnO5lFq8A for ; Tue, 15 Nov 2016 17:59:16 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0115.outbound.protection.outlook.com [104.47.34.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57751293FC for ; Tue, 15 Nov 2016 17:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yIKr1EALXXAl2d61qP8nCB6bQdxSbD+FX+mv1HbaEGc=; b=OKmS66CvRSQCokpSvvu/IUeibow6rtQU4VDMI1LKrr0Wb8Mxt5EKT8MJmiSszdbZC8OP4InxK/QiFW31tymWAOOjA3NJEqsfuO4RabGf/NSOq2UGsKLgZR7afLvWOiqOY74ppgrunaZG6vHDQhtsGvp5O9oUgXGN/p9jmuxfH2w= Received: from CY1PR00MB0107.namprd00.prod.outlook.com (10.167.9.141) by CY1PR00MB0105.namprd00.prod.outlook.com (10.167.9.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.755.0; Wed, 16 Nov 2016 01:59:15 +0000 Received: from CY1PR00MB0107.namprd00.prod.outlook.com ([10.167.9.141]) by CY1PR00MB0107.namprd00.prod.outlook.com ([10.167.9.141]) with mapi id 15.01.0755.000; Wed, 16 Nov 2016 01:59:15 +0000 From: Terry Zink To: "dmarc@ietf.org" , "ietf-dkim@mipassoc.org" Thread-Topic: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts Thread-Index: AQHSPnclbHSEJxQHVkKpc3/b7SYIuKDYnMA8gAB+GgCAAb6LAIAAAOyAgAAA9ICAAADzMA== Date: Wed, 16 Nov 2016 01:59:15 +0000 Message-ID: References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> In-Reply-To: <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:7::66e] x-ms-office365-filtering-correlation-id: 8abec7bf-9413-4f0b-d944-08d40dc42b24 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR00MB0105; x-microsoft-exchange-diagnostics: 1; CY1PR00MB0105; 7:MysIl1Fkv+V4hnO3oNDUeu4RC7k08B+7ex7rndSvG14MSYupmnBM7GYUY9L6rOV4x7aHqtUkp3nlr2ULUaQhWL+yVlXQDnHkuJ8DOATUy+wItglGfshxXWVVEq9dydzK20Cz40BpoAzu+odRYoGJiqqMjb2afKhgVy9bTYAhpUxdDS3G+Kfh28LWkCJy7Ct15NWzB8cBVJ0KLeUMFJrZqkfJrxzprkJ8el54JaOLcsIKwRhqc0GJCkk+ulhoqI1nNRVE5LRvnevZQA5mZOS/3suX1ey7ARHEYYl3MlV45HEYDpyPUWU3AvALzvNFWZdO7UiCX4Ui+I18R9fgTLnQR10Fl9Y6KQclLYFbwYf9sDE6v0Dng2OmhtjeoU47Kv97ga1gOs3zBwHRqby8TOsXf5iUFRZoajcS2FL/CohPO6hfmSAJSR8s41xHkRkJWwXzHARqwcbYj2FNGJ4LxypnUrmUdXhzhP94ynShrCJYnZw= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(224505668447827)(140211028294663); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6061324)(6046074)(6072148)(6047074); SRVR:CY1PR00MB0105; BCL:0; PCL:0; RULEID:; SRVR:CY1PR00MB0105; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(377454003)(189002)(24454002)(8936002)(81166006)(7696004)(77096005)(68736007)(81156014)(7736002)(8676002)(2501003)(87936001)(2950100002)(305945005)(74316002)(7846002)(42882006)(189998001)(122556002)(10090500001)(561944003)(33656002)(6506003)(2900100001)(93886004)(5001770100001)(9686002)(97736004)(230783001)(5005710100001)(2906002)(8990500004)(10290500002)(107886002)(229853002)(54356999)(92566002)(50986999)(106116001)(76576001)(105586002)(106356001)(76176999)(99286002)(86362001)(3660700001)(5660300001)(3280700002)(101416001)(102836003)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR00MB0105; H:CY1PR00MB0107.namprd00.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 16 Nov 2016 01:59:15.2577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0105 Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:59:19 -0000 Thanks, that's what I thought. Large email receivers forward tons of email. This proposal causes email fro= m DMARC-passing messages to be incapable of forwarding. As a large email re= ceiver who gets tons of complaints about breakage of DKIM signatures on for= warded messages which causes DMARC failures [1], this proposal is not all t= hat appealing. :-\ -- Terry [1] We are working on a fix for this. -----Original Message----- From: Dave Crocker [mailto:dcrocker@gmail.com]=20 Sent: Tuesday, November 15, 2016 5:53 PM To: Terry Zink ; dmarc@ietf.org; ietf-dkim@mi= passoc.org Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to= draft-kucherawy-dmarc-rcpts On 11/16/2016 10:50 AM, Terry Zink wrote: > This may be a dumb question, but if a DKIM-signature includes the=20 > original recipient, then wouldn't that break the DKIM signature if the=20 > original MTA forwards it to another receiver even if they don't modify=20 > any parts of the message? the proposal is to add the envelope rcpt-to to the signature. change the r= cpt-to and yes the signature will break. d/ --=20 Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Nov 15 18:28:12 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4448128874 for ; Tue, 15 Nov 2016 18:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGntSb8uzLb7 for ; Tue, 15 Nov 2016 18:28:10 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7114D129409 for ; Tue, 15 Nov 2016 18:28:10 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id r204so115614625ywb.0 for ; Tue, 15 Nov 2016 18:28: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:from:date:message-id:subject:to :cc; bh=r3NW/yU0UUHVZ4Yu5WQ9VLAKMO5uB5aPcTvMBAVm9UY=; b=ux8R48h2lsoN4qfKvAURfJTc1ksz2T3XmwgCoPieh5NTQ3aVxV5EFmcaRR1//F2S5N c8a3EubchzpN3JBnQU25WRfmkxaGdtE/Bman0ydUpZxnDzXQ7wdb00B0FDPqPI0VAXlT lCUFWd8uhMfm/SAQ+YkjGsXRpRV4NR2LICOteyLhvNwdYIG4/me7wvYDO2xr2psuT1BS jllJJwPdincBN3696ApDX87UoPEK6ENVI0+fU4Dsipn2ipdx8Fxvrw+lfIr7ZlTB/A1u lA9bFv1KnoXStxE+DNg+2s6c8Q+07QjzXFmMaTiYWLQSFUFfBiJMWdg65PCCf3NJ6VW8 GXRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r3NW/yU0UUHVZ4Yu5WQ9VLAKMO5uB5aPcTvMBAVm9UY=; b=Zzju0o6ePSTEYuXOeAZlhbnqNqlTu51pp+TP4WlSFiMUQDtmmBHXd9cnBkyic+wIFE hfSV27tTS13VQtiu3sNljwAejuos9nN27TivudMtEQYEG+C8CiR0COj7AU2zRnbLCB8b RfYGvk8KswEJu1PtRbCkfJ2afsfpj8uPf4RxXHKnaP339ILHeQTqjWzCX04BO8jRJvQz WwTpAqI47smPbmrfBYeejWYSxEGGsxeF4j9ZuT26/7qjCF1B1lq7FCY3j86GsNNI3StD NhcHxkZ8EcMf53R33cewC44vWO8CMuN3NwiYHlMBoatKAq+ezSb0e/qsLmJIUosb72XB 9Cag== X-Gm-Message-State: ABUngvfPNLpNZF9Chzk765OJUMNkaqkycmCuwkI4bXzLi8/YPeWH54KG94t9Wjw1j2xYLNH20rGB2SD3xfMjnQ== X-Received: by 10.13.202.13 with SMTP id m13mr372029ywd.251.1479263289770; Tue, 15 Nov 2016 18:28:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.111.130 with HTTP; Tue, 15 Nov 2016 18:28:08 -0800 (PST) In-Reply-To: References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> From: "Murray S. Kucherawy" Date: Wed, 16 Nov 2016 11:28:08 +0900 Message-ID: To: Terry Zink Content-Type: multipart/alternative; boundary=001a114f1e54eac5e9054161d217 Archived-At: Cc: "dmarc@ietf.org" , "ietf-dkim@mipassoc.org" Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:28:12 -0000 --001a114f1e54eac5e9054161d217 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink wrote: > Large email receivers forward tons of email. This proposal causes email > from DMARC-passing messages to be incapable of forwarding. As a large email > receiver who gets tons of complaints about breakage of DKIM signatures on > forwarded messages which causes DMARC failures [1], this proposal is not > all that appealing. > Version 01 is purely incremental, meaning you can just ignore the new tags if you're more worried about breakage of forwarding than the attack it's trying to address. -MSK --001a114f1e54eac5e9054161d217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink <= tzink@exchange.microsoft.com> wrote:
Large email= receivers forward tons of email. This proposal causes email from DMARC-pas= sing messages to be incapable of forwarding. As a large email receiver who = gets tons of complaints about breakage of DKIM signatures on forwarded mess= ages which causes DMARC failures [1], this proposal is not all that appeali= ng.

Version 01 is purely incremental, m= eaning you can just ignore the new tags if you're more worried about br= eakage of forwarding than the attack it's trying to address.

-MSK
--001a114f1e54eac5e9054161d217-- From nobody Wed Nov 16 04:57:54 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A8C1295C6 for ; Wed, 16 Nov 2016 04:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lrz.de 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 CFKm7D2qY4kL for ; Wed, 16 Nov 2016 04:57:51 -0800 (PST) Received: from postout2.mail.lrz.de (postout2.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff8a]) (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 9E4A71296AC for ; Wed, 16 Nov 2016 04:51:45 -0800 (PST) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout2.mail.lrz.de (Postfix) with ESMTP id 3tJkfR3grvzygx; Wed, 16 Nov 2016 13:51:43 +0100 (CET) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=lrz.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lrz.de; h= user-agent:message-id:references:in-reply-to:subject:subject :from:from:date:date:content-transfer-encoding:content-type :content-type:mime-version:received:received:received; s= postout; t=1479300703; bh=T9gzJKxoKKInlpMpLiCiqdWaE1iAws3jAGwwAH h50o0=; b=GKSjVkJ0NkKn2dvz6tm0JTbEMidlrO4Qlk8FJ6ya0tVmp1665QGd0b VnX8xHJunb/bvRuIHpk1xJdbkOARl57FP/ZmH++oLBOyzhx2EKw4gTuJTy01AhN6 W360zChsacXamrnCJocLZz5WYFtE0C2r2HRNiPOA3t6rJkWFc1vbLtga5xq/vUhL Fqqu0K583gSiWGjCSTy4/qGCtb46lzWZn8ft+mMI07Bsp5qWwOib3elXczljZLZf S2mMArKCrj2ELJwMFvgD47eW3ZQD81wJ+O4avw6w2wDtYEmNsyvvRGn6LepAt4Q/ PJkWQMgWB31yh0dttGhrJj0s2PY0CEbg== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de Received: from postout2.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id VYZiIAt7hONv; Wed, 16 Nov 2016 13:51:43 +0100 (CET) Received: from roundcube.lrz.de (roundcube.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by postout2.mail.lrz.de (Postfix) with ESMTPSA id 3tJkfQ6pqYzySM; Wed, 16 Nov 2016 13:51:42 +0100 (CET) Received: from 2001:4ca0:0:f000:74dd:78:27f7:ccf0 by roundcube.lrz.de with HTTP (HTTP/1.1 POST); Wed, 16 Nov 2016 13:51:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 16 Nov 2016 13:51:42 +0100 From: Michael Storz To: dmarc@ietf.org, Ietf Dkim In-Reply-To: References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> Message-ID: <3009defcc6dc9043823618dbc338460d@xmail.mwn.de> X-Sender: Michael.Storz@lrz.de User-Agent: Roundcube Webmail/1.2.0 Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 12:57:52 -0000 Am 2016-11-16 03:28, schrieb Murray S. Kucherawy: > On Wed, Nov 16, 2016 at 10:59 AM, Terry Zink > wrote: > >> Large email receivers forward tons of email. This proposal causes >> email from DMARC-passing messages to be incapable of forwarding. As >> a large email receiver who gets tons of complaints about breakage of >> DKIM signatures on forwarded messages which causes DMARC failures >> [1], this proposal is not all that appealing. > > Version 01 is purely incremental, meaning you can just ignore the new > tags if you're more worried about breakage of forwarding than the > attack it's trying to address. > > -MSK Optional for the sender, yes, but not for the receiving MTA. If the sender decides to use the new Anti-Replay-DKIM-Signature and has published a DMARC policy with reject or quarantine, then this policy is implicitly extended with "ooh, and btw reject/quarantine ALL indirect emails, even if a normal DKIM signature could be verified" This means ARC will be needed not only for mailing lists which modify the header or body of an email, but for EVERY mailing list and EVERY forwarded email or EVERYTIME the recipient has been modified and the email leaves the ADMD boundary. From a DMARC point of view DKIM will not be needed anymore because it has now the same function as SPF - verifiying the origin of direct emails - and SPF is easier to implement for most administrators. Michael From nobody Wed Nov 16 10:09:19 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03A31294EF for ; Wed, 16 Nov 2016 10:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilchJG0zgrHk for ; Wed, 16 Nov 2016 10:09:15 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0105.outbound.protection.outlook.com [104.47.34.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A950F12943E for ; Wed, 16 Nov 2016 10:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7tKpW05a5fbH3B2bx9DBY9QNuLh/DMcvH9qJXbqqd68=; b=Sx4kPvSoyczVJD+A4AtssUiRvzK08I4cNu1XVonCZpJ6D+nn8Qz0aqEQWhf6qddE1IqP8Z5Lgercocw9y3laZu+aoLvqMNlpVZ/bBCjHyrjPWBM+jmCX0EJGh664t0aZezxKJGCrsA7pGPbBIgX6kHHngEg95pAK4FAcezR7LC8= Received: from CY1PR00MB0107.namprd00.prod.outlook.com (10.167.9.141) by CY1PR00MB0105.namprd00.prod.outlook.com (10.167.9.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.755.0; Wed, 16 Nov 2016 18:09:05 +0000 Received: from CY1PR00MB0107.namprd00.prod.outlook.com ([10.167.9.141]) by CY1PR00MB0107.namprd00.prod.outlook.com ([10.167.9.141]) with mapi id 15.01.0755.000; Wed, 16 Nov 2016 18:09:03 +0000 From: Terry Zink To: "dmarc@ietf.org" , Ietf Dkim Thread-Topic: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts Thread-Index: AQHSPnclbHSEJxQHVkKpc3/b7SYIuKDYnMA8gAB+GgCAAb6LAIAAAOyAgAAA9ICAAADzMIAACPwAgACuOQCAAFgiYA== Date: Wed, 16 Nov 2016 18:09:03 +0000 Message-ID: References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> <3009defcc6dc9043823618dbc338460d@xmail.mwn.de> In-Reply-To: <3009defcc6dc9043823618dbc338460d@xmail.mwn.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [2001:4898:80e8:5::c1] x-ms-office365-filtering-correlation-id: 18088320-0912-464b-0d64-08d40e4ba5b6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR00MB0105; x-microsoft-exchange-diagnostics: 1; CY1PR00MB0105; 7:cpqOe9dytR6Bj1w7+d6/sWbUHfY7P6bC9JlM6cb/t6nN1F3CSy2IXYK81UH7cBNymodNPtSulsIzvxO+HSiAFjeOhuuaDg/Vpc06t38+BASKXDnwFuXZBSXpoB0R4pyK9dd4UnQbcvgMsmaesfWn8zPAnRCACEeRlPX+6TkLEkFx6+2s8xztKYLPL2yK6lIQLtVcCmJmR7R3tBzgXDQt9Q+ErkT90tlsWrZpNe7cPMjs+xOEycgadvoCWRLXEziNXT7bGamfeB5n+Fgl9zL/q9EcFf6SpO2g54kRruFfZvS3WwQq9391i3h0fy0OJmBX/6b+s9t11bW2hWuGmn4/lYm4OuzmQzw3tpy22Y0mUg+r3UpaBma6kPRac/nNcCDn+7KG0T3GMWJpaNeaMDlO7TuYGTqxKTQhWsVat12KdyUdz1en+D/lrhm3WsYWIBOMFJ00zRV2VUzmnjCGkFigAUkpxhbk9H6jvDXAsoIU7qI= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060326)(6040281)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6061324)(6041223)(6072148)(6047074)(6042181); SRVR:CY1PR00MB0105; BCL:0; PCL:0; RULEID:; SRVR:CY1PR00MB0105; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(7696004)(74316002)(77096005)(7736002)(7846002)(8676002)(81156014)(2501003)(81166006)(68736007)(42882006)(87936001)(305945005)(8936002)(189998001)(10090500001)(122556002)(6506003)(33656002)(2900100001)(93886004)(5001770100001)(9686002)(230783001)(97736004)(2906002)(5005710100001)(107886002)(10290500002)(229853002)(54356999)(106116001)(76576001)(99286002)(76176999)(106356001)(105586002)(3660700001)(86362001)(5660300001)(3280700002)(2950100002)(92566002)(50986999)(8990500004)(101416001)(6116002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR00MB0105; H:CY1PR00MB0107.namprd00.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 16 Nov 2016 18:09:03.0579 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0105 Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 18:09:18 -0000 > This means ARC will be needed not only for mailing lists which modify the= header or > body of an email, but for EVERY mailing list and EVERY forwarded email or= EVERYTIME=20 > the recipient has been modified and the email leaves the ADMD boundary. F= rom a=20 > DMARC point of view DKIM will not be needed anymore because it has now th= e same=20 > function as SPF - verifiying the origin of direct emails - and SPF is eas= ier to implement=20 > for most administrators. +1. It basically (almost) turns DKIM into SPF. That's not that appealing a solu= tion. --Terry From nobody Thu Nov 17 06:30:28 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0BB129972 for ; Thu, 17 Nov 2016 06:30:25 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=sMc8I2uH; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=eV18YVvR 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 r6trQOhJPi0c for ; Thu, 17 Nov 2016 06:30:22 -0800 (PST) Received: from ntbbs.santronics.com (winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0B70E1297ED for ; Thu, 17 Nov 2016 06:30:21 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=912; t=1479393019; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=f3WjISZXtSAIaKayOiDoLbKoLTE=; b=sMc8I2uHh+znVqb8pnnDYbF/ohvYNXi+GRrBWAadWUc55ICW8s36kTaQqw2cUb DPcbK9ojjjggeOwQVgvS1oM4JJ93Wk4u1HwZt5COxbv2Qt4PAMpKDou/wZ4RB5bm luBOZ8HExXGEHYBsMNzv0nSMxJvA5X9t9G99RCVTgF0bE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Thu, 17 Nov 2016 09:30:19 -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; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 931979628.1.2760; Thu, 17 Nov 2016 09:30:18 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=912; t=1479392979; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qDk79vm v0rkEeqxIhztQ3z0NYUr6Xcacr3ojjXDLXnk=; b=eV18YVvRY4C8fc/NakPeUWp 1t3EntyapZMrQN5xD50ZQ/WVi29dflYCmuiDGASFET8f3uYnP/JfivJ9j6QEZk+K TJKxeCtCrSNrtHHG5FyDmvPDC5TdN7j+mxsAD//cMtWzfO3Neq8wmiCI8r6ihRir NZm5pAXVg4IqDzLBoktI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Thu, 17 Nov 2016 09:29:39 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 928443968.10.213028; Thu, 17 Nov 2016 09:29:39 -0500 Message-ID: <582DBEF5.5010101@isdg.net> Date: Thu, 17 Nov 2016 09:30:13 -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.8.1 MIME-Version: 1.0 To: "dmarc@ietf.org" , Ietf Dkim References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> <3009defcc6dc9043823618dbc338460d@xmail.mwn.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 14:30:25 -0000 On 11/16/2016 1:09 PM, Terry Zink wrote: >> This means ARC will be needed not only for mailing lists which modify the header or >> body of an email, but for EVERY mailing list and EVERY forwarded email or EVERYTIME >> the recipient has been modified and the email leaves the ADMD boundary. From a >> DMARC point of view DKIM will not be needed anymore because it has now the same >> function as SPF - verifiying the origin of direct emails - and SPF is easier to implement >> for most administrators. > > +1. > > It basically (almost) turns DKIM into SPF. That's not that appealing a solution. For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC or ARC for that matter since the receiver (at least ours) will never accept the payload anyway, i.e. it never gets to the SMTP "DATA" state. SPF does not require you to accept the mail for the hard reject policy (-ALL). -- HLS From nobody Thu Nov 17 06:34:31 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF267129888 for ; Thu, 17 Nov 2016 06:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYZf8FBEL8Wm for ; Thu, 17 Nov 2016 06:34:28 -0800 (PST) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E681112985B for ; Thu, 17 Nov 2016 06:34:27 -0800 (PST) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0266.001; Thu, 17 Nov 2016 09:34:26 -0500 From: "MH Michael Hammer (5304)" To: "dmarc@ietf.org" , Ietf Dkim Thread-Topic: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts Thread-Index: AQHSPnckuJCJ1acMWkKMNo4p3tGS/aDYnMB3gADR7ACAAb6KAIAAAWsAgAAAdoCAAAHdgIAACBIAgACuOQCAAFiqgIABVTGA//+szWA= Date: Thu, 17 Nov 2016 14:34:26 +0000 Message-ID: References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> <3009defcc6dc9043823618dbc338460d@xmail.mwn.de> <582DBEF5.5010101@isdg.net> In-Reply-To: <582DBEF5.5010101@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.6.79] x-kse-attachmentfiltering-interceptor-info: protection disabled x-kse-serverinfo: USCLES533.agna.amgreetings.com, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 11/17/2016 12:36:00 PM x-kse-dlp-scaninfo: Skipped Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 14:34:30 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos > Sent: Thursday, November 17, 2016 9:30 AM > To: dmarc@ietf.org; Ietf Dkim > Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative = to draft- > kucherawy-dmarc-rcpts >=20 > On 11/16/2016 1:09 PM, Terry Zink wrote: > >> This means ARC will be needed not only for mailing lists which modify > >> the header or body of an email, but for EVERY mailing list and EVERY > >> forwarded email or EVERYTIME the recipient has been modified and the > >> email leaves the ADMD boundary. From a DMARC point of view DKIM will > >> not be needed anymore because it has now the same function as SPF - > >> verifiying the origin of direct emails - and SPF is easier to implemen= t for > most administrators. > > > > +1. > > > > It basically (almost) turns DKIM into SPF. That's not that appealing a > solution. >=20 > For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC or A= RC > for that matter since the receiver (at least ours) will never accept the = payload > anyway, i.e. it never gets to the SMTP "DATA" > state. SPF does not require you to accept the mail for the hard reject p= olicy > (-ALL). >=20 Hector, the reality is that most mailbox providers do not reject on SPF -al= l because so many senders don't understand what they are "saying" with -all= and the mailbox providers are the ones who get the complaints about mail n= ot getting delivered. THAT is reality. Mike From nobody Thu Nov 17 15:05:10 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BCF129408 for ; Thu, 17 Nov 2016 15:05:09 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=EYpLtmfi; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=x77spL3z 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 F45iMvByM2df for ; Thu, 17 Nov 2016 15:05:07 -0800 (PST) Received: from mail.winserver.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5164F1293E1 for ; Thu, 17 Nov 2016 15:05:07 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1560; t=1479423905; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=mWdMUJTVEssyjw74Bpbb0g5UqGc=; b=EYpLtmfikoaQygqLK3j8NrRjI3nIy9xKZyGlJBHdxdg5ij57YGgEtXHWmMJ452 ZeELkVNMOIayjiT4AeBbE0VFtVdh53pOlJeKZ0bgjJ6x8cvRgRhoP4yYSadG3JBh 6VsMFUGAPmzx0MxgBBTWrM6rRF330PPzPUR+v84uG4Evc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Thu, 17 Nov 2016 18:05:05 -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; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 962865190.1.2212; Thu, 17 Nov 2016 18:05:04 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1560; t=1479423866; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=P3zQ0dm +uinbCW5Zt3i3jD1m2h3Z5HtjVUoRdf+NN8g=; b=x77spL3zPNO/cz7BUl1iB0M BIrIQXukOOrtVnmSGQdTnlm4Bdvw0VLOps3tuIFpElvG4TaPBR8RPown4hl68Xu5 OBTQ6YDa3trmettEkPGvMdLzAoS/dAJXr8Cz8kc6+9CBT65QYLujO8vVtsv+IhGk WoFAJ7KvAZRYiw6CQ/xs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Thu, 17 Nov 2016 18:04:26 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 959330343.10.219076; Thu, 17 Nov 2016 18:04:25 -0500 Message-ID: <582E379C.4040302@isdg.net> Date: Thu, 17 Nov 2016 18:05:00 -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.8.1 MIME-Version: 1.0 To: "dmarc@ietf.org" , Ietf Dkim References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> <3009defcc6dc9043823618dbc338460d@xmail.mwn.de> <582DBEF5.5010101@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 23:05:09 -0000 On 11/17/2016 9:34 AM, MH Michael Hammer (5304) wrote: >> >> For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC or ARC >> for that matter since the receiver (at least ours) will never accept the payload >> anyway, i.e. it never gets to the SMTP "DATA" >> state. SPF does not require you to accept the mail for the hard reject policy >> (-ALL). >> > > Hector, the reality is that most mailbox providers do not reject on SPF -all because so many senders don't understand what they are "saying" with -all and the mailbox providers are the ones who get the complaints about mail not getting delivered. THAT is reality. > Is "MOST" 100%, 90%, 80%, 70%, 51%? The fact is there are receivers that do reject on -ALL. Its doesn't matter if its 1%. The specs has always allowed to be done and it is done. That's the reality. All systems need to be ready to handle that situation. The payload isn't even transferred. In the 13 years implementing it, I can't even recall one false positive. Another point is that many domains have switched their early SoftFail or Neutral setup to Hardfail for the primary purpose of rejection despite how a receiver will actually do rejection. A good majority of high value domains are Hard Fails and have been for a number of years. I just don't buy that the notion that senders don't know what they are doing. In any case, my main point is that if you use SPF -ALL, you can bypass lots of unnecessary overhead processing in DKIM/DMARC or any related payload technology. -- HLS From nobody Mon Nov 21 01:48:18 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC977129981 for ; Mon, 21 Nov 2016 01:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.317 X-Spam-Level: X-Spam-Status: No, score=0.317 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru 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 cC__2W6V98Hq for ; Mon, 21 Nov 2016 01:48:13 -0800 (PST) Received: from smtp48.i.mail.ru (smtp48.i.mail.ru [94.100.177.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EB712997C for ; Mon, 21 Nov 2016 01:48:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=H4bTUisY/hB57xf4WRFRriUnz+xPJ4m751AayqmN3RI=; b=ZRxJ/x2QunwNMaE2MqA6vvsAQVxkfp3apeXcZICqky4qHDd4rTA9zavT7OH/we3vc7o7rhgjFy/3m0g1HjZ6T6OC9nPsC6uHNa4xEV2WoBE94TxhdNtzvPnxSat+f1QU+QRg61xYHYrR8CQHBAV/POxqqikiI7B7+GFJqHNSDiU=; Received: from [178.22.89.88] (port=22492 helo=[127.0.0.1]) by smtp48.i.mail.ru with esmtpa (envelope-from ) id 1c8lCs-0000Kc-66; Mon, 21 Nov 2016 12:48:10 +0300 To: Hector Santos , "dmarc@ietf.org" , Ietf Dkim , "Murray S. Kucherawy" References: <01Q7ASDZFS6C011WUX@mauve.mrochek.com> <2736ea21-69e6-83b1-3b59-377c032290b5@dcrocker.net> <3009defcc6dc9043823618dbc338460d@xmail.mwn.de> <582DBEF5.5010101@isdg.net> From: Vladimir Dubrovin Message-ID: <5ad68235-1007-26ef-cf08-056df5263167@corp.mail.ru> Date: Mon, 21 Nov 2016 12:48:06 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <582DBEF5.5010101@isdg.net> Content-Type: multipart/alternative; boundary="------------A0BB1905CBE749C70461D0FC" Authentication-Results: smtp48.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru X-Mras: Ok X-SRW: 606F30325CFA050CC377C1B8681F88D9D097C1E2207D8AD4090598096E5E7227 X-Mru-Trust-IP: 1 Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 09:48:16 -0000 This is a multi-part message in MIME format. --------------A0BB1905CBE749C70461D0FC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 17.11.2016 17:30, Hector Santos пишет: > On 11/16/2016 1:09 PM, Terry Zink wrote: >>> This means ARC will be needed not only for mailing lists which >>> modify the header or >>> body of an email, but for EVERY mailing list and EVERY forwarded >>> email or EVERYTIME >>> the recipient has been modified and the email leaves the ADMD >>> boundary. From a >>> DMARC point of view DKIM will not be needed anymore because it has >>> now the same >>> function as SPF - verifiying the origin of direct emails - and SPF >>> is easier to implement >>> for most administrators. >> >> +1. >> >> It basically (almost) turns DKIM into SPF. That's not that appealing >> a solution. > > For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC > or ARC for that matter since the receiver (at least ours) will never > accept the payload anyway, i.e. it never gets to the SMTP "DATA" > state. SPF does not require you to accept the mail for the hard > reject policy (-ALL). > SPF "-all" doesn't protect against spoofing attack, SPF only protects SMTP envelope which is normally not visible to user. DMARC does. P.S. Murray, may be it's better to add an option to DKIM-Signature or to _dmarc DNS record to indicate some mechanism (DKIM or SPF) should not be used for DMARC verification? It will work in absolutely same way. draft-kucherawy-dmarc-rcpts is an equivalent to DMARC with disabled DKIM authentication. -- Vladimir Dubrovin @Mail.Ru --------------A0BB1905CBE749C70461D0FC Content-Type: multipart/related; boundary="------------A0D5D5AAF64100868281F41C" --------------A0D5D5AAF64100868281F41C Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
17.11.2016 17:30, Hector Santos пишет:
On 11/16/2016 1:09 PM, Terry Zink wrote:
This means ARC will be needed not only for mailing lists which modify the header or
body of an email, but for EVERY mailing list and EVERY forwarded email or EVERYTIME
the recipient has been modified and the email leaves the ADMD boundary. From a
DMARC point of view DKIM will not be needed anymore because it has now the same
function as SPF - verifiying the origin of direct emails - and SPF is easier to implement
for most administrators.

+1.

It basically (almost) turns DKIM into SPF. That's not that appealing a solution.

For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC or ARC for that matter since the receiver (at least ours) will never accept the payload anyway, i.e. it never gets to the SMTP "DATA" state.  SPF does not require you to accept the mail for the hard reject policy (-ALL).


SPF "-all" doesn't protect against spoofing attack, SPF only protects SMTP envelope which is normally not visible to user. DMARC does.

P.S. Murray, may be it's better to add an option to DKIM-Signature or to _dmarc DNS record to indicate some mechanism (DKIM or SPF) should not be used for DMARC verification? It will work in absolutely same way.
draft-kucherawy-dmarc-rcpts  is an equivalent to DMARC with disabled DKIM authentication.

--
Vladimir Dubrovin
@Mail.Ru
--------------A0D5D5AAF64100868281F41C Content-Type: image/png; name="ojjjghhmiolfdhbm.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ojjjghhmiolfdhbm.png" iVBORw0KGgoAAAANSUhEUgAAAHwAAAAZCAQAAABZLoLcAAADz0lEQVR4AeWX2XLiPBCFP3nB 7IEAWSAk4BkWg837P95UuU51WRhXjf1XcjH/8Y2EpO7+tLQQd3JM2XDgwo2CCylvDPkJOVIK PgCYknMm4YfkWJBxe/AdmPLd6ssXwL4svfAjSvhdQc3JuHjwXwR8p3ryC/CrLL/yAxpxFWDK nB6lCBiztpYjEd+pKe+Mfha8L7gzY+oKeTf0ABOOgaanT99rSRgS8lgBCQMirK+VAwa41uCO xMaF9GlmDIHID+WskxypyzspB/a8EEOpCXnZ5wNMB25s2VBok74TAAtZK9gS4WtCqt43TqwI eC57DgHHqTxQbcATPhXXDojKw7nhgcqlu97H81YOzYiBgA/vZOcsSdgxZ6yQB1AqfpgEU69+ pgdSyK7W/8wRIVpyC/4a/JXCLF2BsWw+kPxMqSjUnD0BgVzeyDja2b5QmtMEfVaTkbnNfSSr /7JdZamTwu8txIHK4V+CbyrjMxbtwZ+1VgAfKg/VNuaI1samqCDwwC/MgICdYa0IcBbYQJaV OpW+Yq1XV/C5xTXDAbQH/yp/WpjrEwGYQo4Vc59leeKBj8Grv6jutK7Pto3vz9+QvCN4oP8b vwkBOoErFSXABmtsMLfA0Ay0h6T69M7yElhrJzl8PXcEn+k4xdAdvChNoMYcx72uZm6qdWsL fipLc+7luHYC/7Q4uoMrOQBlEjs1DDpXTG9bgxfaVXXtu4ArUc7+O/gVtC4ZdZ3N3JPu8m7g MXXtuoALY4yvkZLtI2X1EZm5+6qFZ4ACX5Xlt9bgmVrqOj8ET+WnFbhFFHGvSC1Jfc6ntp5r fH1h4NqYs9bgWz1zqG/OOrj137UC96fR14sOtKdlJagDutokx9q7x7Vl24Ib4IyqQk6PwZXt C/otwV81bkhVA4pHOyjSz/0S5qKL55Ul7wpdsyWzKbQGh73d8oGdSGE/AA+5ymsVLmZC2ATu 3e85C5yW7plceSzkThvBBkCChaMv1cbTY4RxJ/CITO05KTt5aQKHhbVdSBnZZBybwKURBTeB 7km5qlYwoaZI67wnABxLDuqcMgPmlRC30AkceqpXv4JLAzisvcePtTeDSxODtY9cUTUmmaOd DkcIVk7VvsOB5Mqgr7i7k5fU06YU8OYFlTLUw2duL4ETmOZk5hdiCrusdvL0WDFbisrkbolp 1IzCnDwZtGPMkhh44qU2awkr+p7DFSMwhSxqYxxTVqyYEau+YGZJaEkPk/lfKp4RK8FG8tSs kCeWrDCWZo3JvIfegRO5Mv4/rpA3ofrfmv+BAmZsOZBbRl3g+Af1By7rr2XUY4YeAAAAAElF TkSuQmCC --------------A0D5D5AAF64100868281F41C-- --------------A0BB1905CBE749C70461D0FC-- From nobody Mon Nov 21 05:10:32 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3358129445 for ; Mon, 21 Nov 2016 05:10:30 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEZMYBEo8eL3 for ; Mon, 21 Nov 2016 05:10:29 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537521299FD for ; Mon, 21 Nov 2016 05:10:29 -0800 (PST) Received: from kitterma-e6430.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 74DCAC4036A for ; Mon, 21 Nov 2016 07:10:27 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1479733827; bh=+rcJ5lU7L3DhzOwcMwIxAyZ71XY6co7wYRdGSKdifPs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VGO58+stdPtgOJlZFZcouviJ10R9n6+KN6mfdHwjSbMxwWcvRrZqLYWGU2RayKVOF KaLTcIbPZQNybEjhPNY6t6AWdZwxYhJTFqr7wgTNhVXvLgmLMa81Im8hiEGrrR6JEL DA7f9mbuoDiyGK8tzSwUB5qX9T7Ky5AKJf24qm2M= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 21 Nov 2016 08:10:23 -0500 Message-ID: <1953678.JQRY6mivmH@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-101-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5ad68235-1007-26ef-cf08-056df5263167@corp.mail.ru> References: <582DBEF5.5010101@isdg.net> <5ad68235-1007-26ef-cf08-056df5263167@corp.mail.ru> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [dmarc-ietf] [ietf-dkim] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 13:10:31 -0000 On Monday, November 21, 2016 12:48:06 PM Vladimir Dubrovin wrote: > 17.11.2016 17:30, Hector Santos =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On 11/16/2016 1:09 PM, Terry Zink wrote: > >>> This means ARC will be needed not only for mailing lists which > >>> modify the header or > >>> body of an email, but for EVERY mailing list and EVERY forwarded > >>> email or EVERYTIME > >>> the recipient has been modified and the email leaves the ADMD > >>> boundary. From a > >>> DMARC point of view DKIM will not be needed anymore because it ha= s > >>> now the same > >>> function as SPF - verifiying the origin of direct emails - and SP= F > >>> is easier to implement > >>> for most administrators. > >>=20 > >> +1. > >>=20 > >> It basically (almost) turns DKIM into SPF. That's not that appeali= ng > >> a solution. > >=20 > > For exclusive policies (SPF -ALL), you really don't need DKIM, DMAR= C > > or ARC for that matter since the receiver (at least ours) will neve= r > > accept the payload anyway, i.e. it never gets to the SMTP "DATA" > > state. SPF does not require you to accept the mail for the hard > > reject policy (-ALL). >=20 > SPF "-all" doesn't protect against spoofing attack, SPF only protects= > SMTP envelope which is normally not visible to user. DMARC does. >=20 > P.S. Murray, may be it's better to add an option to DKIM-Signature or= to > _dmarc DNS record to indicate some mechanism (DKIM or SPF) should not= be > used for DMARC verification? It will work in absolutely same way. > draft-kucherawy-dmarc-rcpts is an equivalent to DMARC with disabled > DKIM authentication. Or, if you don't want people to use DKIM for DMARC, don't sign the mess= age. Scott K From nobody Thu Nov 24 01:51:54 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3F3129F6B for ; Thu, 24 Nov 2016 01:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 LN75lUXlX7mN for ; Thu, 24 Nov 2016 01:51:50 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBA1129F77 for ; Thu, 24 Nov 2016 01:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=to:from:subject:message-id:date:user-agent:mime-version:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=nfA2irIZ10VjrpgtIxkRLmwmjsxquW2hXjA+K5NI8H8=; b=NO11x66Ljp6ugwk+KQICmepAWh1oh+FybQiy378W0xTUTvod4UEsCE90VbZZZpH9ANvhblwnJB+vgDCprbynD7/d1QP5PF7q6AKXYcVDc0Q7QJx3TWkgRjsXEMETvlSCIeqBIe4v48XtXZxQsay6HPcJb/teOjVL4YkR0GvkxnwClxFMCrt7IJvDUlrtivqlEnL7US+Rb5ZeR9KfTA3NLvbVGuXE9xzM7k9afMQRZpE2CTcGp1YPNWZnsVQYdVaLhmGp7Sw0MAfFCqFUY/LTMvOWgJ5PqBF2mJ2fVD/bd0sVu1afR7/nGVjMKhXIYsZacyii2cXWg0zG+XMtdhdBzw== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAO9piJR022773-uAO9piJT022773 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Thu, 24 Nov 2016 10:51:44 +0100 Received: from dhcp162.sidnlabs.nl (94.198.159.162) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Nov 2016 10:51:44 +0100 To: From: "Marco Davids (IETF IMAP)" Message-ID: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> Date: Thu, 24 Nov 2016 10:51:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.162] X-ClientProxiedBy: ka-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.162, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.162 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Subject: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 09:51:52 -0000 Dear community, I hereby request feedback and support for draft-davids-dmarc-fi-tag. Problem: Per-message failure reports as requested by the "ruf" tag are a useful source of information when debugging deployments or in analyzing attacks. However, under certain circumstances this property can potentially lead to an undesirably high volume of reports. Especially when a Domain Owner's name is spoofed and abused in a large-scale phishing or other impersonation attack. RFC7489 offers only a very limited solution to this problem (in section 7.3). The lack of a mechanism for a Domain Owner to influence the volume of reports constitutes an obstacle to deployment of the "ruf" tag feature. Solution: In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It provides a Domain Owner with a simple way of requesting limitation of the rate at which such reports are sent. Please let me know what you think of it. I'm looking forward to a fruitful discussion on the design choices I made and I also hope for support of the idea. Thanks. The draft can be found here: https://datatracker.ietf.org/doc/draft-davids-dmarc-fi-tag/ -- Marco Davids SIDN Labs From nobody Thu Nov 24 02:59:15 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7998129B0F for ; Thu, 24 Nov 2016 02:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=crash.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6j23aMVDuoh for ; Thu, 24 Nov 2016 02:59:11 -0800 (PST) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD27E12953A for ; Thu, 24 Nov 2016 02:57:58 -0800 (PST) Received: from [172.16.120.99] (fp76f0d93d.tkyc506.ap.nuro.jp [118.240.217.61]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id uAOAvDwf070748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Nov 2016 02:57:20 -0800 (PST) (envelope-from smj@crash.com) X-SenderID: Sendmail Sender-ID Filter v1.0.0 segv.crash.com uAOAvDwf070748 Authentication-Results: segv.crash.com; sender-id=permerror header.from=smj@crash.com; auth=pass (PLAIN); spf=permerror smtp.mfrom=smj@crash.com X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com uAOAvDwf070748 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=201506-2k; t=1479985040; bh=F3hJqtTH4FwMH1+XPgwOtiLSlR2bCQi4dBmXpl9V/qU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=E4GTty5zo2QOJFk/3RTLgkRxqcq2Ti7yUA5In5F5WOYoFfTy7Q+nMEqLJ1sAyQ5kP fVfmuntVHK/1RK2qzVHWj3eYrcmfaPM9aYGYyk10LvBXXuiS2JccgbrAYY5D76T9J8 2cFDaWJPj5TcS/t11O1ebocZVwJylNWmhqFJR6XTLtGlZfFLO1AYKYXbXZRfr/Y1+A UZEJx45Tmr1DG/E5FWqztufrrZj0Nw7uvdoGNV5yDLBs1EqJ+TauJYRq6eVEkK0pcN oHlRRIAuY1YQmNpcDqWmReejukBW57kDpPL/9imY4Im57f+v+3clMBu/GV3WTdh+xf hlpm/xO14FvXg== X-Authentication-Warning: segv.crash.com: Host fp76f0d93d.tkyc506.ap.nuro.jp [118.240.217.61] claimed to be [172.16.120.99] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Steven M Jones X-Mailer: iPhone Mail (14B150) In-Reply-To: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> Date: Thu, 24 Nov 2016 19:57:15 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <57EB74F3-9326-478C-88BD-01D5B8FCFE5D@crash.com> References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> To: "Marco Davids (IETF IMAP)" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Thu, 24 Nov 2016 02:57:20 -0800 (PST) Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 10:59:14 -0000 Hello Marco, Interesting proposal, from a five minute skim via cell phone. Have any mailb= ox providers or report generators shared their views on the incremental over= head of having to track this kind if interval timer for each sending domain t= hat experiences an authentication failure, versus what may currently be a "f= ire and forget" arrangement now? I look forward to a longer review on a larger screen. :) --Steve.=20 Sent from my iPhone > On Nov 24, 2016, at 18:51, Marco Davids (IETF IMAP) = wrote: >=20 > Dear community, >=20 > I hereby request feedback and support for draft-davids-dmarc-fi-tag. >=20 > Problem: >=20 > Per-message failure reports as requested by the "ruf" tag are a useful > source of information when debugging deployments or in analyzing attacks. >=20 > However, under certain circumstances this property can potentially lead > to an undesirably high volume of reports. Especially when a Domain > Owner's name is spoofed and abused in a large-scale phishing or other > impersonation attack. >=20 > RFC7489 offers only a very limited solution to this problem (in section > 7.3). >=20 > The lack of a mechanism for a Domain Owner to influence the volume of > reports constitutes an obstacle to deployment of the "ruf" tag feature. >=20 > Solution: >=20 > In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It > provides a Domain Owner with a simple way of requesting limitation of > the rate at which such reports are sent. >=20 > Please let me know what you think of it. I'm looking forward to a > fruitful discussion on the design choices I made and I also hope for > support of the idea. >=20 > Thanks. >=20 > The draft can be found here: >=20 > https://datatracker.ietf.org/doc/draft-davids-dmarc-fi-tag/ >=20 > --=20 > Marco Davids > SIDN Labs >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Nov 24 04:48:55 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C341295B4 for ; Thu, 24 Nov 2016 04:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 7uLnCKCok0J0 for ; Thu, 24 Nov 2016 04:48:52 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE931293E9 for ; Thu, 24 Nov 2016 04:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=5+Li1pseTGinMzDFJ4eZgp3EdSj5ZIO0Yhk83h3Ud8M=; b=CrdvqDABfv9BRMHvcOp7nF8dwm5IBxkNAsGTHHKKgta3NDKG4wOgIhB065gSa+R97MniE5X+cyQgSqu4WlNB2pbLsGRRiHNdjWoRH92zy5B6oIu5lszQjSkSpow8tPsPkEkk2ifSFEqpeXO4JMEHpqtfTsGh1LNQNxcnEcJjmgzAR7a/cejKWIqkUIyLMC7oddLV/kMkCEESeWxEucnOM3+otz1KHXCtg96wI7pyzxbeXAAuIbDLQyUIyc/msV5vJtSM3EQNTtYQvnL9w+Dg0pw+uI44o8ZDGutL4FOJcLXDbhIb4/TlqMpUI7PqXdMDaIREpcus70eCpgPB9NimAQ== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAOCmpVf010249-uAOCmpVh010249 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Thu, 24 Nov 2016 13:48:51 +0100 Received: from dhcp162.sidnlabs.nl (94.198.159.162) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Nov 2016 13:48:50 +0100 To: References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> <57EB74F3-9326-478C-88BD-01D5B8FCFE5D@crash.com> From: "Marco Davids (IETF IMAP)" Message-ID: Date: Thu, 24 Nov 2016 13:48:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: <57EB74F3-9326-478C-88BD-01D5B8FCFE5D@crash.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.162] X-ClientProxiedBy: ka-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.162, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.162 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 12:48:54 -0000 On 24/11/2016 11:57, Steven M Jones wrote: > Have any mailbox providers or report generators shared their views on > the incremental overhead of having to track this kind if interval > timer for each sending domain that experiences an authentication > failure, versus what may currently be a "fire and forget" arrangement > now? And "fire and forget" it seems to be (in at least one case), according to a recent experience I had with a large mailbox provider. In fact, it was that event that inspired me to write this draft (after having spend a great part of the morning cleaning up flooded mail queues here at the office). -- Marco From nobody Thu Nov 24 10:41:14 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B92129C01 for ; Thu, 24 Nov 2016 10:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl 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 Hc0m1hou_ug9 for ; Thu, 24 Nov 2016 10:41:11 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4121296B6 for ; Thu, 24 Nov 2016 10:34:14 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3tPnsx0dTQz1LBKq; Thu, 24 Nov 2016 19:34:13 +0100 (CET) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3tPnsw6M74z1L8dC; Thu, 24 Nov 2016 19:34:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id CFE8042192E; Thu, 24 Nov 2016 19:34:11 +0100 (CET) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1TRWVg0Iyked; Thu, 24 Nov 2016 19:34:11 +0100 (CET) Received: from [192.168.40.49] (unknown [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id B2B7D4210C5; Thu, 24 Nov 2016 19:34:11 +0100 (CET) To: "Marco Davids (IETF IMAP)" References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> From: "Rolf E. Sonneveld" Organization: Sonnection B.V. Message-ID: Date: Thu, 24 Nov 2016 19:34:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> Content-Type: multipart/alternative; boundary="------------E92B08CD638A6648A53A65D0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1480012453; bh=EjcWv7i2ee1SVsYMiFSoYOmBkhNG0qj6IiToW4DhzDk=; h=Subject:To:From:Message-ID:Date:From; b=XeuTdG2BSk9gnY6I+1GSOfVhplGuxP97haIhOxGd25OJVcs9DTs+4TkXoSAIKE81i jwZFm0x4zRSiuhBiclI+pY8FS+XmQEttZ5oBriF6ubG3SlCNatKsR7KIT+0ale8sYy KzqFoDPLOUR84mmr8SHIa22aqAuhHys3TU5z8IF0= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3tPnsx0dTQz1LBKq Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 18:41:13 -0000 This is a multi-part message in MIME format. --------------E92B08CD638A6648A53A65D0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, Marco, On 24-11-16 10:51, Marco Davids (IETF IMAP) wrote: > Dear community, > > I hereby request feedback and support for draft-davids-dmarc-fi-tag. > > Problem: > > Per-message failure reports as requested by the "ruf" tag are a useful > source of information when debugging deployments or in analyzing attacks. > > However, under certain circumstances this property can potentially lead > to an undesirably high volume of reports. Especially when a Domain > Owner's name is spoofed and abused in a large-scale phishing or other > impersonation attack. > > RFC7489 offers only a very limited solution to this problem (in section > 7.3). > > The lack of a mechanism for a Domain Owner to influence the volume of > reports constitutes an obstacle to deployment of the "ruf" tag feature. > > Solution: > > In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It > provides a Domain Owner with a simple way of requesting limitation of > the rate at which such reports are sent. > > Please let me know what you think of it. I'm looking forward to a > fruitful discussion on the design choices I made and I also hope for > support of the idea. two things, after having had a quick look at the draft: 1. it seems to me that, with this proposal, you move the burden of implementing a rate limiting function from the domain owner to the reporting organization. This seems not right to me, as it's primarily in the interest of the sending domain to receive feedback via these reports, not the reporting domains interest. For the large ESPs this may be no big deal, they may have means to implement such a reporting interval without much pain, but for smaller organizations this may cause problems (in terms of resources that must be allocated for queuing these reports). To exaggerate a bit: the attack vector introduced with 'ruf' is now more or less moved from the sending to the reporting domain. Furthermore, most modern mail systems have rate limiting technology on board, which can be deployed by the sending domain to protect against floodings with reports (granted, this shifts the burden also in the direction of the reporting domain); 2. I wonder why you have chosen a 32-bit integer, when the unit of interval is 'second'. On one hand this provides not enough granularity, as the shortest interval (apart from zero) is 1 report per second, which may cause significant queues on the side of the reporting domain. On the other hand, a 32-bit integer means reports can be sent up to 136 years after the moment of an DMARC authentication failure, which is way too long to be useful. So I'd suggest you make the unit milliseconds, to make it better fit for its intended use? Regards, /rolf --------------E92B08CD638A6648A53A65D0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Hi, Marco,

On 24-11-16 10:51, Marco Davids (IETF IMAP) wrote:
Dear community,

I hereby request feedback and support for draft-davids-dmarc-fi-tag.

Problem:

Per-message failure reports as requested by the "ruf" tag are a useful
source of information when debugging deployments or in analyzing attacks.

However, under certain circumstances this property can potentially lead
to an undesirably high volume of reports.  Especially when a Domain
Owner's name is spoofed and abused in a large-scale phishing or other
impersonation attack.

RFC7489 offers only a very limited solution to this problem (in section
7.3).

The lack of a mechanism for a Domain Owner to influence the volume of
reports constitutes an obstacle to deployment of the "ruf" tag feature.

Solution:

In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It
provides a Domain Owner with a simple way of requesting limitation of
the rate at which such reports are sent.

Please let me know what you think of it. I'm looking forward to a
fruitful discussion on the design choices I made and I also hope for
support of the idea.

two things, after having had a quick look at the draft:

  1. it seems to me that, with this proposal, you move the burden of implementing a rate limiting function from the domain owner to the reporting organization. This seems not right to me, as it's primarily in the interest of the sending domain to receive feedback via these reports, not the reporting domains interest. For the large ESPs this may be no big deal, they may have means to implement such a reporting interval without much pain, but for smaller organizations this may cause problems (in terms of resources that must be allocated for queuing these reports). To exaggerate a bit: the attack vector introduced with 'ruf' is now more or less moved from the sending to the reporting domain. Furthermore, most modern mail systems have rate limiting technology on board, which can be deployed by the sending domain to protect against floodings with reports (granted, this shifts the burden also in the direction of the reporting domain);
  2. I wonder why you have chosen a 32-bit integer, when the unit of interval is 'second'. On one hand this provides not enough granularity, as the shortest interval (apart from zero) is 1 report per second, which may cause significant queues on the side of the reporting domain. On the other hand, a 32-bit integer means reports can be sent up to 136 years after the moment of an DMARC authentication failure, which is way too long to be useful. So I'd suggest you make the unit milliseconds, to make it better fit for its intended use?

Regards,
/rolf


--------------E92B08CD638A6648A53A65D0-- From nobody Thu Nov 24 11:43:47 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5941129A7F for ; Thu, 24 Nov 2016 11:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMY2qDO-IHcE for ; Thu, 24 Nov 2016 11:43: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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431FE129A9A for ; Thu, 24 Nov 2016 11:43:44 -0800 (PST) Received: (qmail 16367 invoked from network); 24 Nov 2016 19:43:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 24 Nov 2016 19:43:47 -0000 Date: 24 Nov 2016 17:35:39 -0000 Message-ID: <20161124173539.1321.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: marco.davids@sidn.nl Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 19:43:46 -0000 >However, under certain circumstances this property can potentially lead >to an undesirably high volume of reports. Especially when a Domain >Owner's name is spoofed and abused in a large-scale phishing or other >impersonation attack. I gather that this was inspired by some sort of phish or spoof that caused people to send you a lot of failure reports. Can you give us an idea of the report volume and rate that raised the concern? R's, John From nobody Thu Nov 24 12:08:29 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286E0129C7E for ; Thu, 24 Nov 2016 12:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 cHlQA7bN_txL for ; Thu, 24 Nov 2016 12:08:26 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05041129C9B for ; Thu, 24 Nov 2016 12:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:cc:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=xIaI0sbR8DR3TS1kD1hAaqrtTpxxVbsjqfB3b+d3mnA=; b=n5/ORLP3v7bTcR8x7DNH+utumwR1XYxRCdz9ISFsUf3rxjFX+e4I886XZCC8jlfDI8qk4crnmpdyH4UVLPrgJ5KKvUBvkYxy7t1FfjlUHqti2SqHO5XuGFAZw75JrMgzUq99nwe1UNev/AhiyeB49khbUkzt+i4CskTa8wXjhKE0p5v9E9TFy/IqGdjWRHHWMXlilzMgFWapVrCvLOuj5YqiLLYW63+Twl1tA5m4eJhh7EOrV98n072/tdIeJTDfoHkVdROsWV4KHaNThe4Q4UZK5mR/mWnNZavasW1wZCytdqn9vtjZTX4QwOfVv3KNBUEN6bw0LP9qdWr7oXy9TA== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAOK7lb5012777-uAOK7lb7012777 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 24 Nov 2016 21:07:47 +0100 Received: from MAC-01-09.local (94.198.159.130) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Nov 2016 21:07:46 +0100 To: "Rolf E. Sonneveld" References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> From: "Marco Davids (IETF IMAP)" Message-ID: Date: Thu, 24 Nov 2016 21:07:41 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.130] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.130, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.130 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 20:08:28 -0000 Hi Rolf, Thank you for taking the time to respond. Allow me to elaborate a little. On 24/11/2016 19:34, Rolf E. Sonneveld wrote: > 1. it seems to me that, with this proposal, you move the burden of > implementing a rate limiting function from the domain owner to the > reporting organization. True, but it doesn't have to be that much of a burden in practice, as is explained in section 5 of the draft: "A report generator in this example would typically honour the "fi" tag by sending out a report, storing a 'last report sent' timestamp for example.com in memory and maintaining it as a 'do not sent' flag for a minimum of $interval seconds during which period no consecutive reports are to be sent. After the flag has cleared, a report may again be sent. The cycle then repeats." Also, please note: intermediate reports are not generated and not queued. They only add to the statistics of aggregated "rua" reports. Compared to the kind of housekeeping a report generator already has to do for sending "rua" aggregated reports, this minor extra step of maintaing a simple timestamp flag seems very lightweight to me. Also, the draft is lenient on the intervals. It is all pretty loosely defined as: "approximately the requested number of seconds". The example in section 5 defines it a bit more precise by suggesting to at least maintain a minimum of $fi-interval seconds between reports. But a bit longer is certainly acceptable as well. No microseconds granularity as far as I am concerned. I also would like to draw your attention of section 7.3 of RFC7489, the DMARC RFC: "An obvious consideration is the denial-of-service attack that can be perpetrated by an attacker who sends numerous messages purporting to be from the intended victim Domain Owner but that fail both SPF and DKIM; this would cause participating Mail Receivers to send failure reports to the Domain Owner or its delegate in potentially huge volumes." So, the potential problem was already identified in the DMARC RFC7489. But it leaves it to the discretion of the report generator to do something about is, or not. That's a somewhat debatable, maybe even unfair approach, since it might be possible that the report generator can produce much bigger volumes than the Domain Owner at the receiving end can ever handle. My draft intends to give the receiving end of ruf-reports some means to restrict the volume from their perspective. > For the large ESPs this may be no big deal, they may have means to > implement such a reporting interval without much pain, but for > smaller organizations this may cause problems (in terms of resources > that must be allocated for queuing these reports). Let me emphasize this important aspect once more: reports SHOULD NOT be queued, but discarded instead. The draft is very explicit in this (or at least it should be). So yes, every intermediate report is skipped (not even generated) for as long as the fi-interval has not passed. No queuing please. ;-) This is also in the interest of the report generator, because the advantage of skipping reports probably outweighs the suggested 'burden' of maintaining some 'timestamp state'. > 2. I wonder why you have chosen a 32-bit integer, when the unit of > interval is 'second'. Simple: I wanted to have at least room for one day of seconds (86400), and that number does not fit in a 16 bit integer ;-) > On the other hand, a 32-bit integer means reports > can be sent up to 136 years after the moment of an DMARC > authentication failure, which is way too long to be useful. Fully agree! That is why the draft states: "Report generators that implement this feature MUST be able to support the entire interval range from 0-86400 and MAY support longer intervals." I expect nobody to ever support a 136 years of interval ;-) > So I'd suggest you make the unit milliseconds, to make it better fit > for its intended use? I am not really in favor of that kind of granularity, but maybe things are more clear now with my explanation above. Thank you once more for your valued feedback. Let me know what you think after reading this reply. Cheers, -- Marco From nobody Thu Nov 24 12:32:31 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E1E129C77 for ; Thu, 24 Nov 2016 12:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7X4Z7jjjloW for ; Thu, 24 Nov 2016 12:32:28 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C4B129C4F for ; Thu, 24 Nov 2016 12:32:28 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id x186so32297210vkd.1 for ; Thu, 24 Nov 2016 12:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6CwlMQpfE3AlefLKc91znkST3PqwxL+otYAapYypHR8=; b=f50OnG3TNypnNe3ds2ifT9JA3xOOUj27KjJBnlmNeTgTDiCipRVBm6VY+zn6OLdXVT MKNKvigst52SKAjrZb49WlLeRO20jZ5VuxRNP1MmSA4EpCnNn3gfXPFUn+SkNwrMteCN 8zHeRK6CSDtotkPNGznQNgJ8oszZcrWi0u52zmtAoNC31sl75TO39LsUlRZTrjRrGFXE +O4ncTMEMjRKzxQjVgzgpIdsw1vDHrnvBF7UYoK9cV8J0FXy/KLyrsPrWqFq2nQd/goi 4E+xelKHNHO582Trco3ZK4FXyDDwir5G+PtyRuTgzxliLzO9lsonttSgnTdrYOuP4Snc FUOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6CwlMQpfE3AlefLKc91znkST3PqwxL+otYAapYypHR8=; b=eM8eRsEt5auS2qtPbr4hZIR+wpnbZxBpO1H8uZUlVFNi//ojlasQJjTtjJrONI3GPW rzAyv0sB82bt+zYqPA5r8Ii/6TsKTnKfcIxyIxCzLe0RrPQpYlp4xcAxEnOz6zdUbFNN 4njNm+0BcpOGkeRV/OAknzZXrLTuUa/3e7T7k5Tij8AWLFKBc03os6V+eRoM1UA3F0j3 PywWiJxfKe/rcWf8dUOI1vFEhEo7rF9gc92MuYTe7v4iG3g1wrUlr77YArr0Nop7aIMb 9GxAMYBsMtdPJ60JUuRzHgNVb5ui68ILgNbhc1cLGqYQ71tOirzaReoAu3siSMwi5msQ b78w== X-Gm-Message-State: AKaTC00XZC4VreUujVy7ktejsF6v4V87kytYwrzC5TpaEXoECbwFYh6EDyU07oL5FWqFZARfzicS8KEm3G9gpA== X-Received: by 10.31.11.145 with SMTP id 139mr1746404vkl.141.1480019547447; Thu, 24 Nov 2016 12:32:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.21 with HTTP; Thu, 24 Nov 2016 12:32:26 -0800 (PST) In-Reply-To: References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> From: "Murray S. Kucherawy" Date: Thu, 24 Nov 2016 12:32:26 -0800 Message-ID: To: "Rolf E. Sonneveld" Content-Type: multipart/alternative; boundary=001a11410bfc62e8e3054211e7e5 Archived-At: Cc: "dmarc@ietf.org" , "Marco Davids \(IETF IMAP\)" Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 20:32:30 -0000 --001a11410bfc62e8e3054211e7e5 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 24, 2016 at 10:34 AM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > > > 1. it seems to me that, with this proposal, you move the burden of > implementing a rate limiting function from the domain owner to the > reporting organization. This seems not right to me, as it's primarily in > the interest of the sending domain to receive feedback via these reports, > not the reporting domains interest. For the large ESPs this may be no big > deal, they may have means to implement such a reporting interval without > much pain, but for smaller organizations this may cause problems (in terms > of resources that must be allocated for queuing these reports). To > exaggerate a bit: the attack vector introduced with 'ruf' is now more or > less moved from the sending to the reporting domain. Furthermore, most > modern mail systems have rate limiting technology on board, which can be > deployed by the sending domain to protect against floodings with reports > (granted, this shifts the burden also in the direction of the reporting > domain); > > I'm not sure there's another way. If the domain receiving the reports were to be burdened with imposing the limit, it has only a few choices: * size up to withstand whatever load the greater Internet will throw at it (expensive); * build queueing infrastructure to accept anything the greater Internet throws at it so it can be processed as quickly as possible (also requires infrastructure); * return 4xx error codes when you're at capacity (which means pushing it back on senders or intermediaries anyway). Am I missing something? > > 1. I wonder why you have chosen a 32-bit integer, when the unit of > interval is 'second'. On one hand this provides not enough granularity, as > the shortest interval (apart from zero) is 1 report per second, which may > cause significant queues on the side of the reporting domain. On the other > hand, a 32-bit integer means reports can be sent up to 136 years after the > moment of an DMARC authentication failure, which is way too long to be > useful. So I'd suggest you make the unit milliseconds, to make it better > fit for its intended use? > > 32-bit integers make sense to me here. A 16-bit integer is the only other size that makes sense, which limits one to saying something under a day. Is the suggested time granularity useful? -MSK --001a11410bfc62e8e3054211e7e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 24, 2016 at 10:34 AM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:
=20 =20 =20

  1. it seems to me that, with this proposal, you move the burden of implementing a rate limiting function from the domain owner to the reporting organization. This seems not right to me, as it's primarily in the interest of the sending domain to receive feedback via these reports, not the reporting domains interest. For the large ESPs this may be no big deal, they may have means to implement such a reporting interval without much pain, but for smaller organizations this may cause problems (in terms of resources that must be allocated for queuing these reports). To exaggerate a bit: the attack vector introduced with 'ruf' i= s now more or less moved from the sending to the reporting domain. Furthermore, most modern mail systems have rate limiting technology on board, which can be deployed by the sending domain to protect against floodings with reports (granted, this shifts the burden also in the direction of the reporting domain);

I'm not sure there's anothe= r way.=C2=A0 If the domain receiving the reports were to be burdened with i= mposing the limit, it has only a few choices:

* size up t= o withstand whatever load the greater Internet will throw at it (expensive)= ;
* build queueing infrastructure to accept anything the grea= ter Internet throws at it so it can be processed as quickly as possible (al= so requires infrastructure);
* return 4xx error codes when yo= u're at capacity (which means pushing it back on senders or intermediar= ies anyway).

Am I missing something?
  1. I wonder why you have chosen a 32-bit integer, when the unit of interval is 'second'. On one hand this provides not enou= gh granularity, as the shortest interval (apart from zero) is 1 report per second, which may cause significant queues on the side of the reporting domain. On the other hand, a 32-bit integer means reports can be sent up to 136 years after the moment of an DMARC authentication failure, which is way too long to be useful. So I'd suggest you make the unit milliseconds, to make it better fit for its intended use?

32-bit integers make sense to me here.=C2=A0 A 16-bit= integer is the only other size that makes sense, which limits one to sayin= g something under a day.

Is the suggested time granularity use= ful?

-MSK
--001a11410bfc62e8e3054211e7e5-- From nobody Thu Nov 24 12:32:49 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38915129C86 for ; Thu, 24 Nov 2016 12:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 z9fWyoc9HBu8 for ; Thu, 24 Nov 2016 12:32:44 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A9D2129C4F for ; Thu, 24 Nov 2016 12:32:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=/dR8kKnd08mDP4dM/8nSZqMCGc7QNt11pc8qJHxGdeA=; b=VXtrZda2P4TD2m8Zo9EnHXlv/BpQJbWcCi6SHOIrmw+tgr42rBonRF470A18X7O9ZBr/infnBsLrwSGyFA26kn9rg/oLJS8gUI2HLHVKSdM01SF0o9h8UxC4OBYIdV1qJMPtFQzhycBVnkVc5JUO2FQJWjsZF/ZZyH0yNo0gCpQDmmGYh/ZlD3bmHQxhsT5NfV6hZn2CFsCF3OWg2lONBGPZPWASN5XISetJjNb5cljQ/KJtDCVeGQpKLZbxCHhQE5zpEoB1WCNYjE98rRiwoP3a7pKLsBwh60kPTFErSdyQrHLd8MhtptYwpklYT2w8i93BbYtwKFsnXCrSz0xs6g== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAOKWgHG014763-uAOKWgHI014763 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 24 Nov 2016 21:32:42 +0100 Received: from MAC-01-09.local (94.198.159.130) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Nov 2016 21:32:41 +0100 To: John Levine , References: <20161124173539.1321.qmail@ary.lan> From: "Marco Davids (IETF IMAP)" Message-ID: Date: Thu, 24 Nov 2016 21:32:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: <20161124173539.1321.qmail@ary.lan> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.130] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.130, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.130 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 20:32:48 -0000 On 24/11/2016 18:35, John Levine wrote: >> However, under certain circumstances this property can potentially >> lead to an undesirably high volume of reports. Especially when a >> Domain Owner's name is spoofed and abused in a large-scale phishing >> or other impersonation attack. > > I gather that this was inspired by some sort of phish or spoof that > caused people to send you a lot of failure reports. That's correct John. Some malicious party abused our domain name in a phishing campaign. Which is by the way precisely why we appreciate and configured the "ruf" tag; to discover this kind of abuse the moment it happens. > Can you give us an idea of the report volume and rate that raised the > concern? And that is the downside of the nice "ruf" option: we were informed of an attack just a little too often... We received roughly 275.000 per-message "ruf" reports of the same incident in less than a day. Comeing from one (large) ESP. That filled some queues here and there in our modest office environment and slowed down the e-mail for almost the entire day. Pretty frustrating. Almost made me want to turn of the "ruf" option. -- Marco From nobody Thu Nov 24 12:33:56 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E838E129CA3 for ; Thu, 24 Nov 2016 12:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EnccfxNSySN for ; Thu, 24 Nov 2016 12:33:52 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0093.outbound.protection.outlook.com [104.47.36.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B46612952E for ; Thu, 24 Nov 2016 12:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WwBeuJGj6YGijoF6S24AjFw4LOQBAec8UzfPgMJCTMY=; b=gH2VgF/lb1FLsC7wGtvyYZUSu3xFQN+zsi9PqAtOOtfcfrCZ5DBcaapM+sGdpcCMzjDM+jULtvneRxOi7axJ61wVx9EAi0pqizqtRtmdYgkfLfvsbTACD1Eg7MBKZlaFTwimM6Egkxf/6KxxoQBLv548Uo+WqFt+E+ogeOruJ80= Received: from CY1PR00MB0106.namprd00.prod.outlook.com (10.167.9.136) by CY1PR00MB0106.namprd00.prod.outlook.com (10.167.9.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.0; Thu, 24 Nov 2016 20:33:48 +0000 Received: from CY1PR00MB0106.namprd00.prod.outlook.com ([fe80::b876:b086:65a5:16ea]) by CY1PR00MB0106.namprd00.prod.outlook.com ([fe80::b876:b086:65a5:16ea%17]) with mapi id 15.01.0771.000; Thu, 24 Nov 2016 20:33:48 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag Thread-Index: AQHSRjhmOyK4iHfDEk2eItrPzdys4qDolCVw Date: Thu, 24 Nov 2016 20:33:48 +0000 Message-ID: References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> In-Reply-To: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [71.35.161.17] x-ms-office365-filtering-correlation-id: 61ca4c71-0301-42ca-c980-08d414a93218 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR00MB0106; x-microsoft-exchange-diagnostics: 1; CY1PR00MB0106; 7:mnk4Y5Qco1AoaSP9/V61yGPBVlJiPSeE3smTagEmkesWuDGwifsQ+9jWt/b7o3PZuI/BJAi7PVF1moYehH6B0Knnb9kCbPVqPDN7sKd3rMAKI5KDD8FH9XCB7nKcXF0q1D2vY4i7bWB/c24FfpboH6M5KT07feYsdsJM7E3Ul4rROITaASsIezgVD5JJzcKDPhLHwb7ad1+kVkjcPF7RKe6F7vJX0UHZT33gXxoX+WMCsX+x9+jAMjIvcz8gAayQLAfolQWFRwd5uUntFxKNMH8JS/xQ1G629cC8l5wcZ41LQRaeG5zajlNT7OvFSgDnno+ubufmHE0FXdOQDu6I7C3HJMX5bwBtXb01f4BdaNAT2Mzk2zkAT4boZSPYNMEZD7TdVIfN8wmfQHBOQ0iAS9vsWMKglNgS74mPrJEZnHuNlT80oL0Jj5HVSdLrhgjU/K8yIhqlAzKnOXqBIHEIaVUfBmXz9XTCI94XYTOUV3o= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506)(189930954265078)(219752817060721)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6045199)(6040361)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6041248)(6061324)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558021)(6047074)(6042181)(6072148); SRVR:CY1PR00MB0106; BCL:0; PCL:0; RULEID:; SRVR:CY1PR00MB0106; x-forefront-prvs: 0136C1DDA4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(76104003)(13464003)(199003)(3905003)(189002)(6506003)(3280700002)(76176999)(38730400001)(5640700001)(54356999)(81166006)(6916009)(5660300001)(50986999)(42882006)(7696004)(2906002)(105586002)(106116001)(2351001)(229853002)(2950100002)(8936002)(1730700003)(8676002)(101416001)(81156014)(450100001)(33656002)(99286002)(66066001)(106356001)(3660700001)(92566002)(68736007)(189998001)(9686002)(107886002)(8990500004)(230783001)(10090500001)(110136003)(305945005)(5005710100001)(5890100001)(10290500002)(3846002)(74316002)(7846002)(97736004)(102836003)(2501003)(6116002)(2900100001)(86362001)(5250100002)(7736002)(575784001)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR00MB0106; H:CY1PR00MB0106.namprd00.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM 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: 24 Nov 2016 20:33:48.6844 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0106 Archived-At: Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 20:33:55 -0000 As a representative of a large email receiver, here's what I think: 1. This is basically an attempt to solve the capacity problem - a burst of = email can overwhelm a DMARC reporting mechanism, and therefore proposes a w= ay to tell the DMARC-report generator to "wait a few seconds, minutes, or h= ours." Yet dealing with capacity issues is something that email receivers h= ave been dealing with for years, and not just DMARC-related. A spam run gen= erated by a spammer can overwhelm capacity; an on-prem mail server gone wil= d can overwhelm capacity; a burst of large attachments can overwhelm capaci= ty; and so forth. To account for that, email receivers use load balancers, = have rate limiting and throttling, segregate customers into different parti= tions, and build out capacity such that the average load is only 40% of net= work capacity (to handle failover in case one data center goes out). We don= 't put the responsibility on the sender other than for them to handle 4xx l= evel errors when we start throttling them. 2. From the draft: >>> The request implies that the Domain Owner is willing to accept no more than one message-specific failure report every 5 minutes from any report generator. A report generator in this example would typically honour the "fi" tag by sending out a report, storing a 'last report sent' timestamp for example.com in memory and maintaining it as a 'do not sent' flag for a minimum of 300 seconds during which period no consecutive reports are to be sent. After the flag has cleared, a report may again be sent. The cycle then repeats. <<< This won't work as well as you hope. Modern day large email receivers are g= lobally load-balanced with hundreds or thousands of mail servers. If a spam= mer sends a massive spam run spoofing your domain, and each of those server= s (e.g., 1000 of them) get one of those messages and sends a DMARC report, = you're still overwhelmed with volume because each one of those mail servers= has to know that the other one just sent a DMARC report back. The "fix" fo= r this is - "Well, each of those mail servers in the network should share t= hat that 'last DMARC report time' with everyone else", which means that we = have to build infrastructure to send that information across to all servers= in real time, perhaps on the order of seconds (after all, the fi may be as= small as 1 second). Why would a large email receiver build out its infrastructure this way to s= upport DMARC, when the DMARC-requester could build out *their* email infras= tructure to support bursts of email, which they need anyway per my first po= int? -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Marco Davids (IETF= IMAP) Sent: Thursday, November 24, 2016 1:52 AM To: dmarc@ietf.org Subject: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag Dear community, I hereby request feedback and support for draft-davids-dmarc-fi-tag. Problem: Per-message failure reports as requested by the "ruf" tag are a useful sour= ce of information when debugging deployments or in analyzing attacks. However, under certain circumstances this property can potentially lead to = an undesirably high volume of reports. Especially when a Domain Owner's na= me is spoofed and abused in a large-scale phishing or other impersonation a= ttack. RFC7489 offers only a very limited solution to this problem (in section 7.3= ). The lack of a mechanism for a Domain Owner to influence the volume of repor= ts constitutes an obstacle to deployment of the "ruf" tag feature. Solution: In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It pr= ovides a Domain Owner with a simple way of requesting limitation of the rat= e at which such reports are sent. Please let me know what you think of it. I'm looking forward to a fruitful = discussion on the design choices I made and I also hope for support of the = idea. Thanks. The draft can be found here: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatrac= ker.ietf.org%2Fdoc%2Fdraft-davids-dmarc-fi-tag%2F&data=3D02%7C01%7Ctzink%40= exchange.microsoft.com%7Cd61a1490f62e42ac435208d4144f8675%7C72f988bf86f141a= f91ab2d7cd011db47%7C1%7C0%7C636155779175120151&sdata=3Dt92Zw9m%2BCkqcY7%2B2= mgY5%2BvuzGd2zN6OUwyoRiq7L%2F10%3D&reserved=3D0 -- Marco Davids SIDN Labs _______________________________________________ dmarc mailing list dmarc@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Fdmarc&data=3D02%7C01%7Ctzink%40exchange.microso= ft.com%7Cd61a1490f62e42ac435208d4144f8675%7C72f988bf86f141af91ab2d7cd011db4= 7%7C1%7C0%7C636155779175120151&sdata=3DucH%2B%2BjwgdOlAuOJdh5z47x%2Bu%2BDVP= 2%2FZR5H0W7YTqU7w%3D&reserved=3D0 From nobody Thu Nov 24 12:40:29 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2F0129CF5 for ; Thu, 24 Nov 2016 12:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBpdUcJTQvH5 for ; Thu, 24 Nov 2016 12:40:26 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 3E531129CE3 for ; Thu, 24 Nov 2016 12:40:15 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id w194so32352860vkw.2 for ; Thu, 24 Nov 2016 12:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E6uH4M0/pbu0vsULx4e5ZwQADbBoMB0A1XJMQLKL9r4=; b=BbRl6p55GKma2antxOitSsgBiw9d27su/QAv+khVtVOXDn/5NDd3HiWdnDuSCh7dSe p6Gm2IqnSFxggvkzXuSy1RoMse0J4S9EvN+ggjf8P9DvoKdIRbkaXQqAPoz1LSd6N89t ckMy2OlBoPJs23lw3SMUCsrzLbbPeukVek4S43GZsoUVDwk64338e8MgewpH3/f7JvV+ RhDQP2ebtVjyeFMxoI4KkIQsQhJA8bZXEW7Wd6TZu4SNi5xp0Ypjwx8CNDeP6nCgGf4R tlfxLbBm+WQmZMy+j1yTbVPTPi4OC4Ln9AZtSWrpC6Lzco59vrvxCT2BtpRJ6FNh04Vt EPmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E6uH4M0/pbu0vsULx4e5ZwQADbBoMB0A1XJMQLKL9r4=; b=iTpA6NADdAon3P3DXKh8NUnbG9Ai7oylE3FPKAWf3c5JifAgOmng6RYswJYP2jUkoN /NgOIobD9PI3HLSStkgHW7zZIi42dxLQxeMhau/11EON+P0Bxgn+nVj/C3KYCLx8mFYL 8w9cSEDmrTgHuhTFKBywaUMFUHe70iHkLSNhfq5tuIsgLi088qpsv+zsf0v1KnjpdfH5 ca4UvLj7589JY5podt/jccG3MCdOC5tmmv3DcczTpD7aJM9JQEcQIVL8S8/AJVROfb2R jsU30ixfKeEk5luemYNDCIJj+c33JyluB0SNMHX80KuTO/n0AGwdmZ1qDXCnzzuYzo8x FSHw== X-Gm-Message-State: AKaTC01N4+3A33Rbx33+1pReXGYcily8KxX6m/GVedjsMOSZJnvPrLHsLg/g9BeQRRUz+NwYaZq6avHmxR2K7Q== X-Received: by 10.31.11.145 with SMTP id 139mr1758053vkl.141.1480020014339; Thu, 24 Nov 2016 12:40:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.21 with HTTP; Thu, 24 Nov 2016 12:40:13 -0800 (PST) In-Reply-To: References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> From: "Murray S. Kucherawy" Date: Thu, 24 Nov 2016 12:40:13 -0800 Message-ID: To: Terry Zink Content-Type: multipart/alternative; boundary=001a11410bfc371cae0542120317 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 20:40:28 -0000 --001a11410bfc371cae0542120317 Content-Type: text/plain; charset=UTF-8 +1 to Terry's points. On the other hand, "fi" is described mainly as a request (modulo the SHOULD NOT, which is debatable in my opinion) which means DMARC verifiers are free to ignore it. On Thu, Nov 24, 2016 at 12:33 PM, Terry Zink wrote: > Why would a large email receiver build out its infrastructure this way to > support DMARC, when the DMARC-requester could build out *their* email > infrastructure to support bursts of email, which they need anyway per my > first point? > Terry: Would it be helpful at all for a large operator to get signal that this small operator will be easily overwhelmed, or does it really make a difference? Marco: I don't agree with the use of ARF's "Incidents" count in this way, because that field is intended to indicate the number of identical incidents that were aggregated into a single report. If you want to use that mechanism, it should be clear that only identical attack incidents should be reported that way. -MSK --001a11410bfc371cae0542120317 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to Terry's points.=C2=A0 On the other hand, "f= i" is described mainly as a request (modulo the SHOULD NOT, which is d= ebatable in my opinion) which means DMARC verifiers are free to ignore it.<= br>
On Thu, Nov 24, 2016 at 12:33 PM, Terry Zink = <tzink= @exchange.microsoft.com> wrote:
Why would a large email receiver build out its infrastructure this way to s= upport DMARC, when the DMARC-requester could build out *their* email infras= tructure to support bursts of email, which they need anyway per my first po= int?

Terry: Would it be helpful at all = for a large operator to get signal that this small operator will be easily = overwhelmed, or does it really make a difference?

Marco: = I don't agree with the use of ARF's "Incidents" count in = this way, because that field is intended to indicate the number of identica= l incidents that were aggregated into a single report.=C2=A0 If you want to= use that mechanism, it should be clear that only identical attack incident= s should be reported that way.

-MSK
=
--001a11410bfc371cae0542120317-- From nobody Thu Nov 24 12:47:16 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0D2129CD5 for ; Thu, 24 Nov 2016 12:47:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RHJUzeQG6rj for ; Thu, 24 Nov 2016 12:47:14 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 AFD0C129AD0 for ; Thu, 24 Nov 2016 12:47:12 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id b35so57727990uaa.3 for ; Thu, 24 Nov 2016 12:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tulr9mEqmokqNAQoU4dqLbe4wrK4xdYAH40VrKgpOQk=; b=P9M/PC4bkxPLYuMeAa6ouo3qMoKzujHpKMQ5nIysOKNl8OrDQM4YzfakJLshdpMZAY ltstukr4dI9LhRHaYZPyB6I3lHUwhgz9x+9asF2j+PGmN5HJ2/c8L24LEm2UrbiUY2Ur QBDSYnZYWLFFzkx9+G29BffQoPCnHw+yab006lpAKK0GbxJ0zfBboclLh1dVhhWRBBhF kcTzzLZTtIxjGvsslGgbXVJ0Kw61948/Sawi2HyTdVZBmjtjMnBXK4ZoaiO/yBBCQM5Q NEe1UoZCvgSa1h4HL8Ih/adtsfCvKj28leHOMxO0C0Vrfk5XeeCbRde1s7NUrTUfuHCZ r5NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tulr9mEqmokqNAQoU4dqLbe4wrK4xdYAH40VrKgpOQk=; b=kC+7OJN8lG6sO2NQNx/XD3Afow1hUK8sAAbiQ6e3gIz4YLZ+sR379fDGpSG9uLrZQn 8nUqvrHhCIW0FslB7HMa/g6R5167DZNddav1eg/Cl7+BLQ9KDDdDY6pudMjk49p30KPG 6cV4CTCtmBHkV6caPgtVjFJ2N6bLpdRh4/VUEjySEn2nwlYW3sBnST3A8vvys/FXK8oi i6TqqvlGATEJztjbP84djhGeMVT+EkGojmltlFQoicnPxIItak968FaKRaP9zPXFSnRa vEXWDk5dvXq4acM2lhPvF1qjQaARjPA7GjGxI5Ua8WtKOG0hmTxs0V4zSLenDxRNYmpf sZZA== X-Gm-Message-State: AKaTC03f53RqS3E4efcSQq6L5R+9cjrjj5msditph79kgvrhvS81Fnf1g+/xTkDFbBarQp1n4zpKqAas64pT+Q== X-Received: by 10.159.39.104 with SMTP id a95mr2929921uaa.104.1480020431839; Thu, 24 Nov 2016 12:47:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.21 with HTTP; Thu, 24 Nov 2016 12:47:11 -0800 (PST) In-Reply-To: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> From: "Murray S. Kucherawy" Date: Thu, 24 Nov 2016 12:47:11 -0800 Message-ID: To: "Marco Davids (IETF IMAP)" Content-Type: multipart/alternative; boundary=94eb2c12409019a8620542121cb4 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 20:47:15 -0000 --94eb2c12409019a8620542121cb4 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 24, 2016 at 1:51 AM, Marco Davids (IETF IMAP) < marco.davids@sidn.nl> wrote: > Dear community, > > I hereby request feedback and support for draft-davids-dmarc-fi-tag. > [...] > I seem to recall debating this idea during the pre-IETF work on DMARC. I also seem to recall it being removed from what became the final specification, probably for reasons already mentioned on this thread. Another point is that this will only help an overwhelmed receiver if the DMARC failures are all being reported by one source or a small number of sources. The reports generated by a highly distributed phishing campaign, for example, will not be seriously controlled by this feature. -MSK --94eb2c12409019a8620542121cb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 24, 2016 at 1:51 AM, Marco Davids (IETF IMAP) = <marco.davids@sidn.nl> wrote:
Dear community= ,

I hereby request feedback and support for draft-davids-dmarc-fi-tag.
[...]

I seem to recall debating this id= ea during the pre-IETF work on DMARC.=C2=A0 I also seem to recall it being = removed from what became the final specification, probably for reasons alre= ady mentioned on this thread.

Another point is that this = will only help an overwhelmed receiver if the DMARC failures are all being = reported by one source or a small number of sources.=C2=A0 The reports gene= rated by a highly distributed phishing campaign, for example, will not be s= eriously controlled by this feature.

-MSK
<= /div>
--94eb2c12409019a8620542121cb4-- From nobody Thu Nov 24 13:01:36 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E96129D1E for ; Thu, 24 Nov 2016 13:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 405TMuzQSH3J for ; Thu, 24 Nov 2016 13:01:33 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0FE129C96 for ; Thu, 24 Nov 2016 13:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=XCmMTf9XbyhppakbyKWwOqqEBCcyZNcRjNf7/Yk7sn8=; b=wZzs2RG8PtfFMXscsuMeT94rGv+BSd1CVX4pT/EqLFo/y/UZqGFciF0F5KYmoJbSgN4GIDpA6gCu0MdpuBq4GpHHUyN+KJvq+yBy8GfPOY7Rs08Nh7AeD7dctMXbO6SeTFzd0CJi65z7o0gZrjtDReEHdUU5hu0F7hhzwAXn0rGWsxDJ3lD0ePAYcE6b5c+UgZHaZnL5w47ctbPOt2UXtSNXfQHc7NAjBunNdp4rwzCYmErVT5F6YGu9hgMKXCy7hEfjiydwGRNWBCy+4XIfIZvE5Wb6rXPhJKQz+ZxGe00/QMWF2b+3Eje7AyTod45tjnX8aRhdpPEXo2aT5cXJLA== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAOL1K46017067-uAOL1K48017067 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 24 Nov 2016 22:01:20 +0100 Received: from MAC-01-09.local (94.198.159.130) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Nov 2016 22:01:19 +0100 To: Terry Zink , "dmarc@ietf.org" References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> From: "Marco Davids (IETF IMAP)" Message-ID: <0e196f18-9056-37a7-36aa-9b674352b465@sidn.nl> Date: Thu, 24 Nov 2016 22:01:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.130] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.130, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.130 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 21:01:35 -0000 Hi Terry, On 24/11/2016 21:33, Terry Zink wrote: > As a representative of a large email receiver, here's what I think: Much appreciated. > 2. From the draft: > The cycle then repeats. > This won't work as well as you hope. Modern day large email receivers > are globally load-balanced with hundreds or thousands of mail servers. I realized and tried to address it with this part in the security considerations section: "Mail Receivers with a farm or cluster of several report generators might choose to synchronise the 'last sent' timestamp value accross their machines in order to better comply with the wishes of Domain Owners and to reduce the risk described above." Even if this goal is only partly achieved, it is still better then nothing not having rate limiting at all. > Why would a large email receiver build out its infrastructure this way > to support DMARC, when the DMARC-requester could build out *their* > email infrastructure to support bursts of email, which they need > anyway per my first point? Certainly a valid question. My answer would be: Huge amounts of spam towards our domain are dealt with quite nicely nowadays, by simply blocking the e-mail at our front door with the well known means. However, the per-message "ruf" reports is no spam and was qualified as legitimate e-mail. So that makes it a bit of a different story. Now, I see three possible solutions: - Disable the "ruf" tag altogether, in our DMARC record, - Invest in more e-mail capacity, basically only for these rare events of "ruf" mailbombs, - Come up with a solution like the one I proposed. Now, my proposed solution is not anywhere near a complete 'holy grail' kind of solution for everything. But it seemed like the most pragmatic option of all the above. -- Marco From nobody Thu Nov 24 13:14:58 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9AB129D49 for ; Thu, 24 Nov 2016 13:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 42MNUgLE8Pa4 for ; Thu, 24 Nov 2016 13:14:55 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7908F1296DF for ; Thu, 24 Nov 2016 13:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:cc:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=sT7+rM5clYx793oIRQycUUTOQXXVyIFXwNDOAxmtllo=; b=0O1qaoHe+P1kYF9pmLcge+ezo98aClgC6Ge4k5rxhGIscwz0IRBYaTkjrG/7pzzXPoEhz/Js7ZCTNnZ/60FQDQl4tNTleGlAfr52iyQEoAwS3QXMPUfMddRxXan7km9/96Fys6atY2EN5Aq7o5SBEbD9aOoY61YfYlhPB24rwoFWmhQPhPbkMvAux+5sNQNOmSPgAeLNq2x0j3O0Wz7ugPdNP77heoTO/YmcrbsybnoAxSExOZ7GMaNylVsjYy+ELaXy8q6FzOBemesN1xCVASVluLaiWsmENhyAWJ51U0q/B0x1etfmDWcQGjyHJ0JVemoHwEd1Ui99Usp5Web2Dw== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAOLElF6018118-uAOLElF8018118 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Thu, 24 Nov 2016 22:14:47 +0100 Received: from MAC-01-09.local (94.198.159.130) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 24 Nov 2016 22:14:45 +0100 To: "Murray S. Kucherawy" , Terry Zink References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> From: "Marco Davids (IETF IMAP)" Message-ID: <80d4f4b5-3f82-2abd-728a-485373a6c8a8@sidn.nl> Date: Thu, 24 Nov 2016 22:14:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.130] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.130, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.130 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 21:14:56 -0000 On 24/11/2016 21:40, Murray S. Kucherawy wrote: > +1 to Terry's points. On the other hand, "fi" is described mainly as > a request (modulo the SHOULD NOT, which is debatable in my opinion) > which means DMARC verifiers are free to ignore it. It's a request, but my intend was it MUST be supported when the "ruf" tag is honored. Only if there is no "ruf", or a report generator ignores the "ruf", than the "fi" may be ignored. (I know some report generators don't implement "ruf", for reasons of privacy). But it's a draft, so everything is debatable as far as I am concerned. I welcome any suggestion. > Terry: Would it be helpful at all for a large operator to get signal > that this small operator will be easily overwhelmed, or does it really > make a difference? That's what is is: nothing more than a signal and/or a request? Just like the "ri" tag, basically. > Marco: I don't agree with the use of ARF's "Incidents" count in this > way, because that field is intended to indicate the number of > identical incidents that were aggregated into a single report. If you > want to use that mechanism, it should be clear that only identical > attack incidents should be reported that way. Good point. It's probably gonna be hard to define what exactly an identical incident is. Does an identical 'from', identical 'subject' but different 'to' count as the same incident for example? If this is getting too complicated, I don't mind leaving this part out of the draft altogether. What do you think? Shall I leave it out? Or do you like to propose some alternative text? -- Marco From nobody Thu Nov 24 18:02:57 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB5B12A1FC for ; Thu, 24 Nov 2016 18:02:55 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUnaT08Sg5JM for ; Thu, 24 Nov 2016 18:02:53 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CC4D1294AB for ; Thu, 24 Nov 2016 18:02:53 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 51so63303734uai.1 for ; Thu, 24 Nov 2016 18:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U23JHuTsKWOZ/njMYYDZCR5BcwVAAooT5t6PIbqtKo4=; b=rduB2tLcY2ebqks7XTIzxxwFuZuR9UVdo1CqRU3MM9XKxbq8wH/KvN9p2AUWZOCBer GiYxBv1ikDFVkSFaz2qTM5KRKE99m3qr+cHXRBd1EK+6X3zqGdV9f8csZC8VtnzaoaW3 D/4n+tKWUVmVW6Cqq10Na1NBxjWnkEMPyG2wz4dvmTsDDD6587HWxtrbTW5/t3XmjoeF /4EqZ7j7YatgOYXNyG0nQ2SlIY6XDH/HVe/toDaQO94/KHtCEXIXtwA7YQYj6v1biQJ4 HPXZukmBPP5ITi8byZx9OclunmHLN2O97lzZKUDEOgEDxlWpZqjR16KcgE0GgbCkVuib 2Q5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U23JHuTsKWOZ/njMYYDZCR5BcwVAAooT5t6PIbqtKo4=; b=k9d5kyYxb8cxoU0Du5lFw0wMVAjPaDoOKUulOw+6HVxi8dsB/aufqSbU9WKsU3gWmk LWlRqEEVhKw823fs145ypHIgLmFidYvmd7/RzBNDNE2SfLcfsCffd4a1vNvT7nejF3a2 APFqC4MozJNsxvNynemxXCH47iyexH9c1k7QNIxbCEEkBXs3VRabBZI+LdbhiePVi9wn hwxqM05Ncwcl4s2uZ2GljrfT48W7CZajaQ6sBdE6jskfk1l8EaA7PYLAfPSJsFLLJfd0 Hg5LW/yKnt/N8a/hRM6X4XjVy3YEYRo5qetzTx1rKyTZY3x4oBfqjKwVaeQoOWC6Apeq Bi1w== X-Gm-Message-State: AKaTC01u65tZsZam//HxwUS99Dl98AjWhuYBIUGVNDNOyl+b+UCxe+vEcbpeqg1MwYayueelEg/MZ+CxHDmccw== X-Received: by 10.176.81.18 with SMTP id e18mr3449882uaa.5.1480039372686; Thu, 24 Nov 2016 18:02:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.91.21 with HTTP; Thu, 24 Nov 2016 18:02:51 -0800 (PST) In-Reply-To: <80d4f4b5-3f82-2abd-728a-485373a6c8a8@sidn.nl> References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> <80d4f4b5-3f82-2abd-728a-485373a6c8a8@sidn.nl> From: "Murray S. Kucherawy" Date: Thu, 24 Nov 2016 18:02:51 -0800 Message-ID: To: "Marco Davids (IETF IMAP)" Content-Type: multipart/alternative; boundary=94eb2c1918bc100a0f05421685c1 Archived-At: Cc: "dmarc@ietf.org" , Terry Zink Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 02:02:55 -0000 --94eb2c1918bc100a0f05421685c1 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 24, 2016 at 1:14 PM, Marco Davids (IETF IMAP) < marco.davids@sidn.nl> wrote: > On 24/11/2016 21:40, Murray S. Kucherawy wrote: > > +1 to Terry's points. On the other hand, "fi" is described mainly as > > a request (modulo the SHOULD NOT, which is debatable in my opinion) > > which means DMARC verifiers are free to ignore it. > > It's a request, but my intend was it MUST be supported when the "ruf" > tag is honored. Only if there is no "ruf", or a report generator ignores > the "ruf", than the "fi" may be ignored. (I know some report generators > don't implement "ruf", for reasons of privacy). > Making it a MUST imposes infrastructure costs on report generators, as we've been describing. There's not much incentive for them to comply, and I imagine you'd have a hard time reaching consensus to support such a change. > > Marco: I don't agree with the use of ARF's "Incidents" count in this > > way, because that field is intended to indicate the number of > > identical incidents that were aggregated into a single report. If you > > want to use that mechanism, it should be clear that only identical > > attack incidents should be reported that way. > > Good point. It's probably gonna be hard to define what exactly an > identical incident is. Does an identical 'from', identical 'subject' but > different 'to' count as the same incident for example? If this is > getting too complicated, I don't mind leaving this part out of the draft > altogether. What do you think? Shall I leave it out? Or do you like to > propose some alternative text? > Actually now that I re-read it, the ARF RFCs you cite just say "similar" without specifying what that means exactly, so I guess that means it's up to report generators to decide what sort of grouping they want to use with "Incidents", understanding that any imprecise grouping is inherently lossy and the receiver of such a report is free to infer what it actually means. I suggest you take a crack at defining what you have in mind for "identical" here. How would you use it? -MSK --94eb2c1918bc100a0f05421685c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 24, 2016 at 1:14 PM, Marco Davids (IETF IMAP) = <marco.davids@sidn.nl> wrote:
On 24/11/2016 21:40, Murray S. Kucherawy wrote:
> +1 to Terry's points.=C2=A0 On the other hand, "fi" is d= escribed mainly as > a request (modulo the SHOULD NOT, which is debatabl= e in my opinion)
> which means DMARC verifiers are free to ignore it.

It's a request, but my intend was it MUST be supported when the = "ruf"
tag is honored. Only if there is no "ruf", or a report generator = ignores
the "ruf", than the "fi" may be ignored. (I know some r= eport generators
don't implement "ruf", for reasons of privacy).

Making it a MUST imposes infrastructure costs on rep= ort generators, as we've been describing.=C2=A0 There's not much in= centive for them to comply, and I imagine you'd have a hard time reachi= ng consensus to support such a change.
=C2=A0
> Marco: I don't agree with the use o= f ARF's "Incidents" count in this
> way, because that field is intended to indicate the number of
> identical incidents that were aggregated into a single report.=C2=A0 I= f you
> want to use that mechanism, it should be clear that only identical
> attack incidents should be reported that way.

Good point. It's probably gonna be hard to define what exactly a= n
identical incident is. Does an identical 'from', identical 'sub= ject' but
different 'to' count as the same incident for example? If this is getting too complicated, I don't mind leaving this part out of the draf= t
altogether. What do you think? Shall I leave it out? Or do you like to
propose some alternative text?

Actually now that I re-read it, the ARF RFCs you cite just say &qu= ot;similar" without specifying what that means exactly, so I guess tha= t means it's up to report generators to decide what sort of grouping th= ey want to use with "Incidents", understanding that any imprecise= grouping is inherently lossy and the receiver of such a report is free to = infer what it actually means.

I suggest you take a crack at defining= what you have in mind for "identical" here.=C2=A0 How would you = use it?

-MSK
--94eb2c1918bc100a0f05421685c1-- From nobody Thu Nov 24 23:35:46 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1ED12A22D for ; Thu, 24 Nov 2016 23:35:45 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl 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 BYKG0GPr6pib for ; Thu, 24 Nov 2016 23:35:44 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id D5DA212A22B for ; Thu, 24 Nov 2016 23:35:43 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3tQ7Cd17cSz1L8dC; Fri, 25 Nov 2016 08:35:41 +0100 (CET) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3tQ7Cc736jz1L8d5; Fri, 25 Nov 2016 08:35:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id E241A42192D; Fri, 25 Nov 2016 08:35:39 +0100 (CET) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hvr1Dl6hJyzD; Fri, 25 Nov 2016 08:35:39 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [192.168.30.2]) by tiger.sonnection.nl (Postfix) with ESMTP id CDDBF4210C5; Fri, 25 Nov 2016 08:35:39 +0100 (CET) Date: Fri, 25 Nov 2016 08:35:39 +0100 (CET) From: "Rolf E. Sonneveld" To: "Marco Davids (IETF IMAP)" Message-ID: <321210309.43638.1480059339598.JavaMail.zimbra@sonnection.nl> In-Reply-To: References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.20.2] X-Mailer: Zimbra 8.6.0_GA_1182 (ZimbraWebClient - FF44 (Linux)/8.6.0_GA_1182) Thread-Topic: Feedback requested: draft-davids-dmarc-fi-tag Thread-Index: t7q6sKEQ1I+YC31YTVszVDmi/aL06g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1480059341; bh=B0r/Ztp4cN1zgIJnCkgttYnzOrguCGisybw6IFvaQlg=; h=Date:From:To:Message-ID:Subject:From; b=S68j/hN8M06ngierFRf4Dcb8wrqPiUF41u9h+a/MdXYtq8q0LxdyW6WQtyXiCvArw vQylqYl4I1EPeEhtg3yjGM4OmgyJgTM245EPKVZFF5n4fhyrkFgiEhC+jgu1wWQr7Z NvTy6CbsATdH9Ji39uNmxlQFYBg0O5UPQDybj+Ms= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3tQ7Cd17cSz1L8dC Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 07:35:45 -0000 Hi, Marco, > Thank you for taking the time to respond. Allow me to elaborate a little. > > On 24/11/2016 19:34, Rolf E. Sonneveld wrote: > >> 1. it seems to me that, with this proposal, you move the burden of >> implementing a rate limiting function from the domain owner to the >> reporting organization. > > True, but it doesn't have to be that much of a burden in practice, as is > explained in section 5 of the draft: > > "A report generator in this example would typically honour the "fi" tag > by sending out a report, storing a 'last report sent' timestamp for > example.com in memory and maintaining it as a 'do not sent' flag for a > minimum of $interval seconds during which period no consecutive reports > are to be sent. After the flag has cleared, a report may again be sent. > The cycle then repeats." > > Also, please note: intermediate reports are not generated and not > queued. They only add to the statistics of aggregated "rua" reports. I'm sorry, missed that one (just scanned (too) quickly through the draft). As it's pretty essential to the draft you may want to add one line to the end of section 1 on this. /rolf From nobody Thu Nov 24 23:44:18 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5394C129458 for ; Thu, 24 Nov 2016 23:44:17 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonnection.nl 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 iJxA4bc9XmlH for ; Thu, 24 Nov 2016 23:44:16 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 61ACC1294B4 for ; Thu, 24 Nov 2016 23:44:16 -0800 (PST) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3tQ7PW4BVqz1L8d5; Fri, 25 Nov 2016 08:44:15 +0100 (CET) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3tQ7PW2s7cz5MggG; Fri, 25 Nov 2016 08:44:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id 3ED4A42192D; Fri, 25 Nov 2016 08:44:15 +0100 (CET) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id orIPz5Qcvk-Y; Fri, 25 Nov 2016 08:44:15 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [192.168.30.2]) by tiger.sonnection.nl (Postfix) with ESMTP id 27D7B4210C5; Fri, 25 Nov 2016 08:44:15 +0100 (CET) Date: Fri, 25 Nov 2016 08:44:14 +0100 (CET) From: "Rolf E. Sonneveld" To: "Marco Davids (IETF IMAP)" Message-ID: <1979927554.43668.1480059854964.JavaMail.zimbra@sonnection.nl> In-Reply-To: <80d4f4b5-3f82-2abd-728a-485373a6c8a8@sidn.nl> References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> <80d4f4b5-3f82-2abd-728a-485373a6c8a8@sidn.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.20.2] X-Mailer: Zimbra 8.6.0_GA_1182 (ZimbraWebClient - FF44 (Linux)/8.6.0_GA_1182) Thread-Topic: Feedback requested: draft-davids-dmarc-fi-tag Thread-Index: Yj8Ow82Cfxd2kYlB4ApNsRUUAzBHZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1480059855; bh=NDS3R0e7ZU64pwQM6xRQDojLJXtI7OUDS1gOlWRynxk=; h=Date:From:To:Message-ID:Subject:From; b=nEb5SQBDpjEANaTN79TCglf8pv2Q/iAvHUwh+UN2WK3lYEkAqY1S/2dU8ip8xgmjj I/ZjidqH+1wpxMZpRu7tYFa11hJFhcWKbUihXGA4zoPsaG8rnbMr+ANrFE4nr4GZct Y8O77HuQRTT37o8urLJADdGebzXYme5w9IRvfiuc= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3tQ7PW4BVqz1L8d5 Archived-At: Cc: dmarc@ietf.org, "Murray S. Kucherawy" , Terry Zink Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 07:44:17 -0000 > On 24/11/2016 21:40, Murray S. Kucherawy wrote: [...] >> Terry: Would it be helpful at all for a large operator to get signal >> that this small operator will be easily overwhelmed, or does it really >> make a difference? > > That's what is is: nothing more than a signal and/or a request? Just > like the "ri" tag, basically. Rate limiting on the sender domain side, providing an SMTP 4.x.y response when the server is overwhelmed solves this problem in a natural way. /rolf From nobody Fri Nov 25 01:09:45 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04FE129583 for ; Fri, 25 Nov 2016 01:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 v9AcCdT1-yfW for ; Fri, 25 Nov 2016 01:09:43 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAE3A1294A4 for ; Fri, 25 Nov 2016 01:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:cc:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=C/GrObHIE0vXyc1YjncSjq8l2AilVpKDqT1YMIk5KA4=; b=K4RFgLKCnFtFro5aLmo9G/WE/IbRfPuluklrgpk6Nci6i4r2TAg1fJzGhNc2x1CJp2d+f6jFnVOsftUAVUE47POsLjzFtcJRySujqwntSDcrByZ15/vx6X1kbItkqk6/mIcJK1W+VJ0tUgpVGm3GC4ln37ey17J9IKqVH/QeFO4ztIjiiL6mGgn51dWrSLU16DeG7iRnhm0PGozhbyp1zojgKLyRuQrrzJp3dFvsOdn+x7SxaR0JMbFzytM20RWxX+CBH8nx2l7ubainM14BnMuggd68yp1q3VznJx+yarRNNdWre34DD0B9YO/txWQZwxeS5z3Tr/BtcmbSHnU5Sw== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAP99bgO014284-uAP99bgQ014284 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Fri, 25 Nov 2016 10:09:37 +0100 Received: from dhcp162.sidnlabs.nl (94.198.159.162) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 25 Nov 2016 10:09:37 +0100 To: "Murray S. Kucherawy" References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> <80d4f4b5-3f82-2abd-728a-485373a6c8a8@sidn.nl> From: "Marco Davids (IETF IMAP)" Message-ID: Date: Fri, 25 Nov 2016 10:09:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.162] X-ClientProxiedBy: ka-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.162, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.162 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Cc: "dmarc@ietf.org" , Terry Zink Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 09:09:45 -0000 On 25/11/2016 03:02, Murray S. Kucherawy wrote: >> my intend was it MUST be supported when the "ruf" tag is honored. > > Making it a MUST imposes infrastructure costs on report generators, as > we've been describing. There's not much incentive for them to comply, > and I imagine you'd have a hard time reaching consensus to support > such a change. I prefer a more positive approach: implementing support for the "fi" tag is a concrete and well defined way of doing some rate limiting as was already more vaguely suggested in the last paragraph of RFC7489 section 7.3, third and possibly even second bullet. Sending only a sample of per-message reports, instead of all of them might be in the benefit of report generators as well. That is also why I considered to set the default value for the "fi" tag to for example something like 10 seconds (a value of 0 would than mean: send all reports, do not rate limit). With a value of 10 (or 30 or even 60), report generators can save resources. That is why it is also in their interest. The default is now: '0'. But thinking of this, maybe '60' would be a better default? >> I don't agree with the use of ARF's "Incidents" count in this >> way, > Actually now that I re-read it, the ARF RFCs you cite just say > "similar" without specifying what that means exactly > I suggest you take a crack at defining what you have in mind for > "identical" here. How would you use it? Let me think about that. I'll make a note and draw up some text. Thanks! -- Marco From nobody Fri Nov 25 01:15:20 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050D912962E for ; Fri, 25 Nov 2016 01:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 x62PG-KAfxSC for ; Fri, 25 Nov 2016 01:15:17 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660E71295BC for ; Fri, 25 Nov 2016 01:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:cc:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=EGy/cWDsP22cnzD1fO4LWGpvsm2OAIZVS1nQnKd4kQU=; b=xTBBjFPJhB1QmC2BXYyVUHVcM+avll3piQYMzVbxccHttlU1mVrDzXYnpaw5C1WDMf+X1Pm5l5+Qk6CNqzOdpx7e2ivp3ZuXaN9HVuI0Z3052iuA+88jnQn6ohIH3TvZlsTqWNVL155z6vGtJ+Mf2BA0AdSW+queQBgebu/802z6BVB8v/1rRafTxq6y63xu7PjyNAPvPgKX3M5T1WRzSpQh4ls35z9FnDqXddwL+X7adSdrlcwMEnyPrxppk86PuZKTIa0Xhh1ugX6HrFI46fIkMJ6pIihJJuMiFcQXwQmPdvpE+psB3vem1CiXZhaWkjLEnT/P8Hz7q5ki8XVaOg== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAP9FFLw014537-uAP9FFM0014537 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Fri, 25 Nov 2016 10:15:15 +0100 Received: from dhcp162.sidnlabs.nl (94.198.159.162) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 25 Nov 2016 10:15:15 +0100 To: "Rolf E. Sonneveld" References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> <321210309.43638.1480059339598.JavaMail.zimbra@sonnection.nl> From: "Marco Davids (IETF IMAP)" Message-ID: Date: Fri, 25 Nov 2016 10:15:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: <321210309.43638.1480059339598.JavaMail.zimbra@sonnection.nl> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.162] X-ClientProxiedBy: ka-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.162, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.162 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 09:15:19 -0000 On 25/11/2016 08:35, Rolf E. Sonneveld wrote: >> Also, please note: intermediate reports are not generated and not >> queued. They only add to the statistics of aggregated "rua" reports. > > I'm sorry, missed that one (just scanned (too) quickly through the > draft). As it's pretty essential to the draft you may want to add one > line to the end of section 1 on this. Done. Thanks. -- Marco From nobody Fri Nov 25 01:33:33 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B351294EB for ; Fri, 25 Nov 2016 01:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 SCRdBttewcID for ; Fri, 25 Nov 2016 01:33:29 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDD212946D for ; Fri, 25 Nov 2016 01:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:cc:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=PgzqlhbUyAhq+czFQGTKtGMYsSnbJ21bwz17F5ZSKPg=; b=14foODEiIqs9MJq7VrZlcUI3q97uzTp2ufn2Gh0QWqMrILXCVBiPZgvbxNtezuhmujs/BN1qM7LeiBSqZUQmCIKPfzahcwyADC3rJ/yJy9qIFdvqVpr4uBgf8IKFOiFl5ZgR1FF33Tv0hSlUobxdlgDiscHbml7kOCutiz7ADi6csnmhCnYyc+kWTIFQTsXLh/MndPv1PwXXkJ3UbV5O6tIQMVFvSBGifNjzM7F7XdIRD22rICXkxLzYu+cDa8zVk1O9zfiAKAeP1gXSf6PeNXRc04CfNIvcYfXjB1jHYRDVUQc6FluWviyrehN/WjutFC/HJ2QZNEtYn+7f2VjMGg== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAP9XPQL015790-uAP9XPQN015790 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Fri, 25 Nov 2016 10:33:25 +0100 Received: from dhcp162.sidnlabs.nl (94.198.159.162) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 25 Nov 2016 10:33:25 +0100 To: "Rolf E. Sonneveld" References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> <80d4f4b5-3f82-2abd-728a-485373a6c8a8@sidn.nl> <1979927554.43668.1480059854964.JavaMail.zimbra@sonnection.nl> From: "Marco Davids (IETF IMAP)" Message-ID: <3ae357d1-470e-bc34-f829-78a286a78626@sidn.nl> Date: Fri, 25 Nov 2016 10:33:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: <1979927554.43668.1480059854964.JavaMail.zimbra@sonnection.nl> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [94.198.159.162] X-ClientProxiedBy: ka-hubcasn02.SIDN.local (192.168.2.172) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.162, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.162 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Cc: dmarc@ietf.org, "Murray S. Kucherawy" , Terry Zink Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 09:33:31 -0000 On 25/11/2016 08:44, Rolf E. Sonneveld wrote: >> On 24/11/2016 21:40, Murray S. Kucherawy wrote: > > [...] >>> Terry: Would it be helpful at all for a large operator to get signal >>> that this small operator will be easily overwhelmed, or does it >>> really make a difference? >> >> That's what is is: nothing more than a signal and/or a request. Just >> like the "ri" tag, basically. > > Rate limiting on the sender domain side, providing an SMTP 4.x.y > response when the server is overwhelmed solves this problem in a > natural way. Not really; there is a significant difference. Pushing back mailbombs with a temporary 4.xxx.yyy code will still cause the per-message reports being delivered at long last, it will simply take more time. And that would only solve part of the problem. What I perhaps should I mentioned earlier: the biggest problem wasn't our mail servers being overwhelmed, but rather some underlying IPS-kind of devices and, ultimately, the e-mail client on my laptop that didn't handle the amount of 275,000 e-mails very well. Probably because of antivirus software kicking in. And a permanent 5.xxx.yyy isn't an option either. We cannot expect a mail environment to do that for something that looks like a perfectly legitimate e-mail. There may easily be situations where you do want to receive 275,000 e-mails regarding X (unless X is: 'per-message ruf reports'). Hard to define that at the receiving end. For example: you only find out that you received 275,000 mails that you didn't really wanted... after you have received them... At least that's my take on this matter. -- Marco From nobody Fri Nov 25 07:32:29 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB2F1298BB for ; Fri, 25 Nov 2016 07:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZ7AZIChiSvf for ; Fri, 25 Nov 2016 07:32:27 -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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CF512A2D1 for ; Fri, 25 Nov 2016 07:20:03 -0800 (PST) Received: (qmail 87817 invoked from network); 25 Nov 2016 15:20:06 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 25 Nov 2016 15:20:06 -0000 Date: 25 Nov 2016 15:19:40 -0000 Message-ID: <20161125151940.2363.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] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 15:32:28 -0000 >I'm not sure there's another way. If the domain receiving the reports were >to be burdened with imposing the limit, it has only a few choices: > >* size up to withstand whatever load the greater Internet will throw at it >(expensive); >* build queueing infrastructure to accept anything the greater Internet >throws at it so it can be processed as quickly as possible (also requires >infrastructure); >* return 4xx error codes when you're at capacity (which means pushing it >back on senders or intermediaries anyway). > >Am I missing something? If you're worried about capacity problems from DMARC reports, use a separate subdomain and a separate MTA so if it gets overwhelmed, the rest of your mail isn't affected. If you really want to isolate it, spin it up in a VPS of the $10/mo variety. On today's Internet, 275K messages/day is not a lot, and should not need a lot of infrastructure to handle or discard. If the reports all come from the same place, it is not rocket science to block the source. As you note, if the junk comes from all over the place, you'll need to deal with it all anyway, so a limit in ruf wouldn't help. Also, if you use a separate MTA, you can skip all the content based spam filtering since it's easier to look and see if a message contains the failure ARF report or the summary XML attachment and throw it away otherwise than to see if it looks spammy. R's, John From nobody Fri Nov 25 07:33:16 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B6C1299D2 for ; Fri, 25 Nov 2016 07:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pQdR7RldxIt for ; Fri, 25 Nov 2016 07:33: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-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C47D12967C for ; Fri, 25 Nov 2016 07:21:27 -0800 (PST) Received: (qmail 88611 invoked from network); 25 Nov 2016 15:21:30 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 25 Nov 2016 15:21:30 -0000 Date: 25 Nov 2016 15:21:04 -0000 Message-ID: <20161125152104.2384.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <80d4f4b5-3f82-2abd-728a-485373a6c8a8@sidn.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: marco.davids@sidn.nl Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 15:33:13 -0000 >It's a request, but my intend was it MUST be supported when the "ruf" >tag is honored. Only if there is no "ruf", or a report generator ignores >the "ruf", than the "fi" may be ignored. (I know some report generators >don't implement "ruf", for reasons of privacy). Remember that MUST only means "do this if you want to interoperate reliably." This is the Internet, where anyone can do anything, including ignoring rate limits. R's, John From nobody Fri Nov 25 09:53:45 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C320012967C for ; Fri, 25 Nov 2016 09:53: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=exchange.microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEd04NvL65Tb for ; Fri, 25 Nov 2016 09:53:41 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0138.outbound.protection.outlook.com [104.47.36.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491B81294F2 for ; Fri, 25 Nov 2016 09:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exchange.microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q8NcUA5C7uOvLMbKBBJCnANtZwvssxcx3NZPCE4k3BE=; b=caAFVy6I4WWRmD55Gd+B4SBkDA0NKlGYMvQZttVdRrZ5oPd+Bp5+tvm3oen7jM5FT7vGFuuK85uu4k1SHcgbsg7/6JDHY4GQ2aKeeuBdWq+ZBYqRNnkulgvsaBNLZ+RRQVfidzkGs6nKxOCUK1Abn1tTNM9iXcwDUt1I28gpUWY= Received: from CY1PR00MB0106.namprd00.prod.outlook.com (10.167.9.136) by CY1PR00MB0106.namprd00.prod.outlook.com (10.167.9.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.0; Fri, 25 Nov 2016 17:53:39 +0000 Received: from CY1PR00MB0106.namprd00.prod.outlook.com ([fe80::b876:b086:65a5:16ea]) by CY1PR00MB0106.namprd00.prod.outlook.com ([fe80::b876:b086:65a5:16ea%17]) with mapi id 15.01.0771.000; Fri, 25 Nov 2016 17:53:36 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag Thread-Index: AQHSRjhmOyK4iHfDEk2eItrPzdys4qDolCVwgAAFU4CAAWJDcA== Date: Fri, 25 Nov 2016 17:53:36 +0000 Message-ID: References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; x-originating-ip: [71.35.161.17] x-ms-office365-filtering-correlation-id: 21f359bf-945a-4685-4e3c-08d4155bfb40 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR00MB0106; x-microsoft-exchange-diagnostics: 1; CY1PR00MB0106; 7:I+/K/wJbL68ZDk9I+ssv8QnEnJUOWE/m+2R8v7NH4rnTe904vrC5ZI3jny2xI5yo8EocBFLxMsmScmeEWOhWTp+MB2szbnwXut6OLVzU1hA46dADXgqFkM1vmqch9f7Fkoo753UMcaeEDB8jZ9fQAqdGTSceTOuvDevDJiuSwF743o1xX3xccnKcB3f+5DzYzZXSMc6SU3R/nVNjL4293SP5auLnItPAqswZUtDs99HHLctxADG7oDl8kmKgXy/CNNiQys6+MOGl9uHquSRwUU/kZcB5hSvc5Tib21oftKX/vhLLW7z+Bc8HvdkRo4CEwZCQ3UrEWaH1z5yEWdXLSN9NTl2BeX5ay6lIp9UfqRlnOxvvu35gqbiXz2N1uljinMfpPo8eWpdJsazQ4XEvi7gwwg03h2M1b20Mc9MAgsbxkJeJ/c85hDs+YDcB51PJzqq5mlA+PlR1zy/jYfqBIBBKDD9HlGEPbi1lkrzDYfY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(224505668447827)(140211028294663)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6045199)(6040361)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6041248)(6061324)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558021)(6047074)(6072148); SRVR:CY1PR00MB0106; BCL:0; PCL:0; RULEID:; SRVR:CY1PR00MB0106; x-forefront-prvs: 01371B902F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(199003)(377454003)(5660300001)(39400400001)(230783001)(8990500004)(5005710100001)(10090500001)(189998001)(68736007)(10290500002)(3660700001)(92566002)(107886002)(9686002)(3846002)(86362001)(2900100001)(5250100002)(76576001)(7736002)(102836003)(790700001)(7846002)(2501003)(74316002)(6116002)(110136003)(5640700001)(38730400001)(6916009)(50986999)(7696004)(42882006)(97736004)(6506003)(54356999)(39410400001)(3280700002)(8936002)(39380400001)(2906002)(81166006)(81156014)(106356001)(33656002)(66066001)(606004)(105586002)(106116001)(101416001)(450100001)(5630700001)(99286002)(8676002)(229853002)(2351001)(2950100002)(1730700003)(39450400002)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR00MB0106; H:CY1PR00MB0106.namprd00.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR00MB0106803B17D2E1033F6EEB8496890CY1PR00MB0106namp_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2016 17:53:36.6214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0106 Archived-At: Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 17:53:44 -0000 --_000_CY1PR00MB0106803B17D2E1033F6EEB8496890CY1PR00MB0106namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUZXJyeTogV291bGQgaXQgYmUgaGVscGZ1bCBhdCBhbGwgZm9yIGEgbGFyZ2Ugb3BlcmF0b3Ig dG8gZ2V0IHNpZ25hbCB0aGF0IHRoaXMNCj4gc21hbGwgb3BlcmF0b3Igd2lsbCBiZSBlYXNpbHkg b3ZlcndoZWxtZWQsIG9yIGRvZXMgaXQgcmVhbGx5IG1ha2UgYSBkaWZmZXJlbmNlPw0KSSBkb27i gJl0IHRoaW5rIGl0IHdvdWxkIG1ha2UgYSBkaWZmZXJlbmNlLCBhbHRob3VnaCBpdOKAmXMgaGFy ZCB0byBzYXkuIFdl4oCZdmUgaGFkIHByb2JsZW1zIGRlbGl2ZXJpbmcgRE1BUkMgcmVwb3J0cyB0 byBETUFSQyBhZ2dyZWdhdG9ycyBiZWZvcmU7IHRoZSBxdWV1ZXMgYnVpbGQgdXAgb24gb3VyIHNp ZGUgYW5kIGdlbmVyYXRlIGFsZXJ0cy4gV2UgdHJ5IGhhcmQgdG8gZGVsaXZlciBldmVyeSBlbWFp bCwgYnV0IGluIHRoaXMgY2FzZSB3ZSB3b3VsZCBkZWxldGUgdGhlIGVtYWlsIGFuZCBub3QgcmV0 cnkuDQoNCkRlbGl2ZXJ5IHByb2JsZW1zIGFyZSBub3RoaW5nIG5ldywgd2UgaGF2ZSB0byBkZWFs IHdpdGggdGhlbSBhbGwgdGhlIHRpbWUuIFdoYXQgd2UgbGlrZWx5IHdvdWxkbuKAmXQgZG8gaXMg cmVzcGVjdCB0aGUgZmk9IHRhZyB0aGUgd2F5IGl04oCZcyB3cml0dGVuIGluIHRoZSBzcGVjLg0K DQpGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5IFttYWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNvbV0N ClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyNCwgMjAxNiAxMjo0MCBQTQ0KVG86IFRlcnJ5IFpp bmsgPHR6aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb20+DQpDYzogZG1hcmNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gRmVlZGJhY2sgcmVxdWVzdGVkOiBkcmFmdC1kYXZpZHMt ZG1hcmMtZmktdGFnDQoNCisxIHRvIFRlcnJ5J3MgcG9pbnRzLiAgT24gdGhlIG90aGVyIGhhbmQs ICJmaSIgaXMgZGVzY3JpYmVkIG1haW5seSBhcyBhIHJlcXVlc3QgKG1vZHVsbyB0aGUgU0hPVUxE IE5PVCwgd2hpY2ggaXMgZGViYXRhYmxlIGluIG15IG9waW5pb24pIHdoaWNoIG1lYW5zIERNQVJD IHZlcmlmaWVycyBhcmUgZnJlZSB0byBpZ25vcmUgaXQuDQpPbiBUaHUsIE5vdiAyNCwgMjAxNiBh dCAxMjozMyBQTSwgVGVycnkgWmluayA8dHppbmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbTxtYWls dG86dHppbmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KV2h5IHdvdWxkIGEgbGFy Z2UgZW1haWwgcmVjZWl2ZXIgYnVpbGQgb3V0IGl0cyBpbmZyYXN0cnVjdHVyZSB0aGlzIHdheSB0 byBzdXBwb3J0IERNQVJDLCB3aGVuIHRoZSBETUFSQy1yZXF1ZXN0ZXIgY291bGQgYnVpbGQgb3V0 ICp0aGVpciogZW1haWwgaW5mcmFzdHJ1Y3R1cmUgdG8gc3VwcG9ydCBidXJzdHMgb2YgZW1haWws IHdoaWNoIHRoZXkgbmVlZCBhbnl3YXkgcGVyIG15IGZpcnN0IHBvaW50Pw0KDQpUZXJyeTogV291 bGQgaXQgYmUgaGVscGZ1bCBhdCBhbGwgZm9yIGEgbGFyZ2Ugb3BlcmF0b3IgdG8gZ2V0IHNpZ25h bCB0aGF0IHRoaXMgc21hbGwgb3BlcmF0b3Igd2lsbCBiZSBlYXNpbHkgb3ZlcndoZWxtZWQsIG9y IGRvZXMgaXQgcmVhbGx5IG1ha2UgYSBkaWZmZXJlbmNlPw0KTWFyY286IEkgZG9uJ3QgYWdyZWUg d2l0aCB0aGUgdXNlIG9mIEFSRidzICJJbmNpZGVudHMiIGNvdW50IGluIHRoaXMgd2F5LCBiZWNh dXNlIHRoYXQgZmllbGQgaXMgaW50ZW5kZWQgdG8gaW5kaWNhdGUgdGhlIG51bWJlciBvZiBpZGVu dGljYWwgaW5jaWRlbnRzIHRoYXQgd2VyZSBhZ2dyZWdhdGVkIGludG8gYSBzaW5nbGUgcmVwb3J0 LiAgSWYgeW91IHdhbnQgdG8gdXNlIHRoYXQgbWVjaGFuaXNtLCBpdCBzaG91bGQgYmUgY2xlYXIg dGhhdCBvbmx5IGlkZW50aWNhbCBhdHRhY2sgaW5jaWRlbnRzIHNob3VsZCBiZSByZXBvcnRlZCB0 aGF0IHdheS4NCi1NU0sNCg== --_000_CY1PR00MB0106803B17D2E1033F6EEB8496890CY1PR00MB0106namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRv bTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsgVGVycnk6 IFdvdWxkIGl0IGJlIGhlbHBmdWwgYXQgYWxsIGZvciBhIGxhcmdlIG9wZXJhdG9yIHRvIGdldCBz aWduYWwgdGhhdCB0aGlzDQo8YnI+DQomZ3Q7IHNtYWxsIG9wZXJhdG9yIHdpbGwgYmUgZWFzaWx5 IG92ZXJ3aGVsbWVkLCBvciBkb2VzIGl0IHJlYWxseSBtYWtlIGEgZGlmZmVyZW5jZT88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB0aGluayBpdCB3b3VsZCBt YWtlIGEgZGlmZmVyZW5jZSwgYWx0aG91Z2ggaXTigJlzIGhhcmQgdG8gc2F5LiBXZeKAmXZlIGhh ZCBwcm9ibGVtcyBkZWxpdmVyaW5nIERNQVJDIHJlcG9ydHMgdG8gRE1BUkMgYWdncmVnYXRvcnMg YmVmb3JlOyB0aGUgcXVldWVzIGJ1aWxkIHVwIG9uIG91ciBzaWRlIGFuZCBnZW5lcmF0ZSBhbGVy dHMuIFdlIHRyeSBoYXJkIHRvIGRlbGl2ZXIgZXZlcnkgZW1haWwsIGJ1dCBpbg0KIHRoaXMgY2Fz ZSB3ZSB3b3VsZCBkZWxldGUgdGhlIGVtYWlsIGFuZCBub3QgcmV0cnkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRlbGl2ZXJ5IHByb2JsZW1zIGFyZSBub3RoaW5nIG5ldywgd2UgaGF2ZSB0byBk ZWFsIHdpdGggdGhlbSBhbGwgdGhlIHRpbWUuIFdoYXQgd2UgbGlrZWx5IHdvdWxkbuKAmXQgZG8g aXMgcmVzcGVjdCB0aGUgZmk9IHRhZyB0aGUgd2F5IGl04oCZcyB3cml0dGVuIGluIHRoZSBzcGVj LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48bzpwPiZuYnNwOzwvbzpwPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2tt YXJrOl9NYWlsRW5kQ29tcG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IE11cnJheSBTLiBLdWNoZXJhd3kgW21haWx0bzpzdXBlcnVzZXJAZ21haWwuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3ZlbWJlciAyNCwgMjAxNiAxMjo0MCBQTTxi cj4NCjxiPlRvOjwvYj4gVGVycnkgWmluayAmbHQ7dHppbmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IGRtYXJjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbZG1hcmMtaWV0Zl0gRmVlZGJhY2sgcmVxdWVzdGVkOiBkcmFmdC1kYXZpZHMtZG1hcmMt ZmktdGFnPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPiYjNDM7MSB0byBUZXJyeSdzIHBvaW50cy4mbmJzcDsgT24gdGhlIG90aGVyIGhh bmQsICZxdW90O2ZpJnF1b3Q7IGlzIGRlc2NyaWJlZCBtYWlubHkgYXMgYSByZXF1ZXN0IChtb2R1 bG8gdGhlIFNIT1VMRCBOT1QsIHdoaWNoIGlzIGRlYmF0YWJsZSBpbiBteSBvcGluaW9uKSB3aGlj aCBtZWFucyBETUFSQyB2ZXJpZmllcnMgYXJlIGZyZWUgdG8gaWdub3JlIGl0LjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgTm92IDI0LCAyMDE2IGF0 IDEyOjMzIFBNLCBUZXJyeSBaaW5rICZsdDs8YSBocmVmPSJtYWlsdG86dHppbmtAZXhjaGFuZ2Uu bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR6aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoeSB3b3VsZCBhIGxhcmdlIGVtYWlsIHJlY2VpdmVy IGJ1aWxkIG91dCBpdHMgaW5mcmFzdHJ1Y3R1cmUgdGhpcyB3YXkgdG8gc3VwcG9ydCBETUFSQywg d2hlbiB0aGUgRE1BUkMtcmVxdWVzdGVyIGNvdWxkIGJ1aWxkIG91dCAqdGhlaXIqIGVtYWlsIGlu ZnJhc3RydWN0dXJlIHRvIHN1cHBvcnQgYnVyc3RzIG9mIGVtYWlsLCB3aGljaCB0aGV5IG5lZWQg YW55d2F5IHBlciBteSBmaXJzdCBwb2ludD88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+VGVycnk6IFdvdWxkIGl0IGJlIGhlbHBmdWwgYXQgYWxsIGZvciBhIGxhcmdlIG9wZXJhdG9y IHRvIGdldCBzaWduYWwgdGhhdCB0aGlzIHNtYWxsIG9wZXJhdG9yIHdpbGwgYmUgZWFzaWx5IG92 ZXJ3aGVsbWVkLCBvciBkb2VzIGl0IHJlYWxseSBtYWtlIGEgZGlmZmVyZW5jZT88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+TWFyY286IEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGUgdXNlIG9mIEFSRidz ICZxdW90O0luY2lkZW50cyZxdW90OyBjb3VudCBpbiB0aGlzIHdheSwgYmVjYXVzZSB0aGF0IGZp ZWxkIGlzIGludGVuZGVkIHRvIGluZGljYXRlIHRoZSBudW1iZXIgb2YgaWRlbnRpY2FsIGluY2lk ZW50cyB0aGF0IHdlcmUgYWdncmVnYXRlZCBpbnRvIGEgc2luZ2xlIHJlcG9ydC4mbmJzcDsgSWYg eW91IHdhbnQNCiB0byB1c2UgdGhhdCBtZWNoYW5pc20sIGl0IHNob3VsZCBiZSBjbGVhciB0aGF0 IG9ubHkgaWRlbnRpY2FsIGF0dGFjayBpbmNpZGVudHMgc2hvdWxkIGJlIHJlcG9ydGVkIHRoYXQg d2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LU1TSzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR00MB0106803B17D2E1033F6EEB8496890CY1PR00MB0106namp_-- From nobody Fri Nov 25 10:21:12 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8DB1297ED for ; Fri, 25 Nov 2016 10:21: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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=f//3GtxH; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=zld00Rmj 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 IGJK3Y-Wdiue for ; Fri, 25 Nov 2016 10:21:03 -0800 (PST) Received: from secure.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 79610129544 for ; Fri, 25 Nov 2016 10:21:03 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2658; t=1480098052; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=SiBljgzb+w5lyylWgYlzpy55Wa0=; b=f//3GtxHMwngzmmrBJjhIjF88WwDpsbPoH7mutNXR9+LNwglrXNfUBSv6S86qb airduz14QmXo4Wc7XCoLYJvBFHT4sd9KlX89tY53W2bV2UPEDq6pU5tH9apKlalS imFu6NU0cciXQKv08+WfbwcQFpIFwavWrixJQVAH9v/RE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Fri, 25 Nov 2016 13:20: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; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1637004946.1.3532; Fri, 25 Nov 2016 13:20:51 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2658; t=1480097998; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zm+zZiD Ev9tuo2JRB5sewpNfOAy8+ZzSe5k3e81V9/4=; b=zld00RmjDi7DjCUrc9GgYFO zhURvLebW0bWVIbGPybm0+NlUzqd4IzZEOzgmVgGlFBl06g5zy70zFAFiwX1HEaq Avktq5UQzmsnAMP6gFrEXO9vRexXpC2B6YlWW9ts+bm57txkji3aUok7FDdGZFXQ kg5o4eWxwMOSTftrdkt8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dmarc@ietf.org; Fri, 25 Nov 2016 13:19:58 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1633461953.10.312428; Fri, 25 Nov 2016 13:19:57 -0500 Message-ID: <58388107.3020809@isdg.net> Date: Fri, 25 Nov 2016 13:20:55 -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.8.1 MIME-Version: 1.0 To: "Marco Davids (IETF IMAP)" , dmarc@ietf.org References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> In-Reply-To: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 18:21:10 -0000 My comments. First, DMARC (RFC7489) is not a standard. Its an informational document. This needs to change. In my view, DMARC is far from complete. There are a number of unsolved issues that are forcing less than adequate "kludges" to be done. The fact this new proposal illustrates yet another "kludge" to fix a non-IETF standard, is testament of my point. Second, DMARC "should" not required any reporting to be done by implementors. It is wasted, redundant overhead that was well known to be an exploitable concept. (Reporting was rejected ny earlier DKIM WG POLICY proposals). It should be an option and not a protocol mandate. The proof of concept was well long established that exclusive policies are very possible for the purpose of deterministic rejections. Perhaps, DMARC should be split into two protocols. Overall, Lets not create additional kludges for what still remains as an "informational" IETF document. We might call it a "pseudo-standard" because of wide usage but in reality it is an informational status document -- not officially a standard. I support an IETF standardization effort of DMARC with a charter that includes development of additional options we need in order to support 3rd party Authorization method, expansion of policy options and plus relaxation of any reporting requirement. -- HLS On 11/24/2016 4:51 AM, Marco Davids (IETF IMAP) wrote: > Dear community, > > I hereby request feedback and support for draft-davids-dmarc-fi-tag. > > Problem: > > Per-message failure reports as requested by the "ruf" tag are a useful > source of information when debugging deployments or in analyzing attacks. > > However, under certain circumstances this property can potentially lead > to an undesirably high volume of reports. Especially when a Domain > Owner's name is spoofed and abused in a large-scale phishing or other > impersonation attack. > > RFC7489 offers only a very limited solution to this problem (in section > 7.3). > > The lack of a mechanism for a Domain Owner to influence the volume of > reports constitutes an obstacle to deployment of the "ruf" tag feature. > > Solution: > > In draft-davids-dmarc-fi-tag I propose a new DMARC tag, the "fi" tag. It > provides a Domain Owner with a simple way of requesting limitation of > the rate at which such reports are sent. > > Please let me know what you think of it. I'm looking forward to a > fruitful discussion on the design choices I made and I also hope for > support of the idea. > > Thanks. > > The draft can be found here: > > https://datatracker.ietf.org/doc/draft-davids-dmarc-fi-tag/ > From nobody Fri Nov 25 11:30:41 2016 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB10129867 for ; Fri, 25 Nov 2016 11:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 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_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 utCA8gnAPYjC for ; Fri, 25 Nov 2016 11:30:37 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5378129485 for ; Fri, 25 Nov 2016 11:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type:content-language:content-transfer-encoding:x-originating-ip:x-clientproxiedby; bh=+dIh0Eo8vzDWg+ahE3hi7+pXHkMkm0E7mqd4SjlXeaM=; b=OLcLoFVy0UeqvrY+n8zNFEKNWASRGM8r4zUBfAHyLiY+an6IkYgJ9XBhIrdHERGscGJGyIsBHKhtBeHh/WnOY/V+0sUCRdsoZbST/z86uZ+4tkNJm/kE+1//oFIYasiDBuMEIA3LqFqrQmhRnLO2Ei9V+QY5s3izEUNHSqJNq/dNizcUCmCIUMC9xBq47Qwp1quYi0hdxCwvrln3T1xgNT9WgC2/rPotszs8cXl9mWBAnGNmocTW7sacn8PegZJeR3ZhDIxymvvDrEkmDVwiT2Z3z/db/y4jkijJy8bX7ySqdEq7yclLFzqo1WHNj2SwznDgUlJWo0BKRcBGEgVQjA== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id uAPJUXEk030195-uAPJUXEm030195 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Fri, 25 Nov 2016 20:30:33 +0100 Received: from MAC-01-09.local (94.198.159.130) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 25 Nov 2016 20:30:32 +0100 To: Terry Zink , "dmarc@ietf.org" References: <046ab671-0f3d-3389-d2fe-1876dcf7557f@sidn.nl> From: "Marco Davids (IETF IMAP)" Message-ID: <706940c8-1b77-700b-5e16-cbfd88ad9b92@sidn.nl> Date: Fri, 25 Nov 2016 20:30:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [94.198.159.130] X-ClientProxiedBy: ka-hubcasn01.SIDN.local (192.168.2.171) To ka-mbx01.SIDN.local (192.168.2.177) X-FEAS-SPF: 2 / 2, ip=94.198.159.130, helo=, mailFrom=marco.davids@sidn.nl, headerFrom=marco.davids@sidn.nl Authentication-Results: arn2-kamx.sidn.nl; spf=pass (sidn.nl: domain of marco.davids@sidn.nl designates 94.198.159.130 as permitted sender) smtp.mailfrom=marco.davids@sidn.nl Archived-At: Subject: Re: [dmarc-ietf] Feedback requested: draft-davids-dmarc-fi-tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 19:30:40 -0000 Hi Terry, On 25/11/2016 18:53, Terry Zink wrote: > We’ve had problems delivering DMARC reports to DMARC aggregators > before; the queues build up on our side and generate alerts. We try > hard to deliver every email, but in this case we would delete the > email and not retry. > > What we likely wouldn’t do is respect the fi= tag the way it’s > written in the spec. Let me see if I get this right: You are pushing the limits of the receiving end of DMARC reports to the point where queues start building up on your side and then delete within your discretion? While at the same time you would renounce a kind request from the receiving end that could have prevented you from sending that excess of reports in the first place? Dunno but... -- Marco