From nobody Sat Nov 1 00:53:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79311A8852 for ; Sat, 1 Nov 2014 00:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Heb69UvN4QGl for ; Sat, 1 Nov 2014 00:53:02 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D96631A884E for ; Sat, 1 Nov 2014 00:53:01 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id DDA341C3B65 for ; Sat, 1 Nov 2014 16:52:58 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CCFAE1A27CF; Sat, 1 Nov 2014 16:52:58 +0900 (JST) From: "Stephen J. Turnbull" To: dmarc@ietf.org In-Reply-To: <545416D7.6050601@dcrocker.net> References: <3154FB1A540749FBA374F7F4DB9CEEB5@fgsr.local> <5454118B.9030706@dcrocker.net> <545416D7.6050601@dcrocker.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 01 Nov 2014 16:52:58 +0900 Message-ID: <87sii31hnp.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/M6jIOvxIMVldWLJCpppXOVC-myM Subject: [dmarc-ietf] wiki vs. list redux [was: Extending DMARC: managing failure cases...] X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 07:53:04 -0000 Dave Crocker writes: > Simple view: > > When a topic is being discussed, the list is the best place to > expose a new idea [...] for discussion. > > But when it is off-topic, the wiki is the best place to record it > for later reference. +1 > Anyhow, just my opinion. Too bad. :-) From nobody Sat Nov 1 02:09:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE4D1A87A9 for ; Sat, 1 Nov 2014 02:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2AQjb1oBtO6 for ; Sat, 1 Nov 2014 02:09:55 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id BB57C1A6EF4 for ; Sat, 1 Nov 2014 02:09:55 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9ACD81C396C; Sat, 1 Nov 2014 18:09:54 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8CE231A27CF; Sat, 1 Nov 2014 18:09:54 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 01 Nov 2014 18:09:54 +0900 Message-ID: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_fpnRibptXYLTm6HT-IDHx22GJ8 Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 09:09:58 -0000 Douglas Otis writes: > As such, using the terms authenticates and authentication should > not be used when referring to DKIM or SPF results. Nothing is > being authenticated. I'm confused. The sending domain is being authenticated, as well as as much content as is signed (none for SPF, at least the From and DKIM-Signature fields for DKIM). Otherwise there's no point to either protocol. Of course, DKIM does NOT ensure that the use of the Author Domain is *authorized* (unless the author domain is the signing domain, it which case it seems reasonable to presume authorization), but it is *authentic* in the sense of being used as the sending domain intended. Or are you referring to the fact that these protocols don't put any requirements on the security of the DNS? > The real function is verification of an authorization. I think you are overcomplicating things here, and I don't understand why. We *identify* a terminal of a channel (here by using the IP address for SPF and the DKIM-Signature for DKIM), then *authenticate* that identity, and finally accept its communications as *authorized* when accompanied by an appropriate (secure) token from an "authority". In many cases the identity is the token (as when a user is authorized to access a file because she is the owner). In the case of a domain publishing an SPF "policy", the nature of the protocol is essentially that "anything from these hosts is authentic and authorized" (the identity == sending IP is the authorization token). If you don't want to say that, don't publish any hosts with your restrictive SPF policy. Analogously for DKIM, as far as I can see. The signed part of a message is similarly self-authorizing if the signature is valid, and if you don't like that, don't sign anything and use some other protocol. I suppose here you also need DMARC or other policy protocol to actually announce that you aren't sending any authentic mail with DKIM signatures. Agreed, there are good reasons to demand From alignment. This can be is authenticated by DKIM (assuming the DNS and MTA have not been subverted), and I suppose SPF (but in a world of virtualization and shared resources I'm not so sure about SPF). Again agreed, these don't identify users. But nobody in the mailbox provider game seems to care about that anyway. > Section 2, > > Was: > However, there has been > no single widely accepted or publicly available mechanism to > communicate domain-specific message authentication policies, or to > request reporting of authentication and disposition of received mail. > > Should be: > However, there has been > no single widely accepted or publicly available mechanism to > communicate domain-specific message verification policies, or to > request reporting of verification and disposition of received mail. This is also inaccurate, however. Nothing about the message is verified by any of these protocols, except the sending domain (and in the case of DKIM, the integrity of the signed portion of message can be verified). If you want to be more specific, you could write "authentication of the sending domain and the signed portion of the message, if any." (Again, unless you want to question the use of the DNS as a source of authentication information. But I think that is outside of the scope of these protocol documents, let alone of the WG.) > Was: > As a result, senders who have implemented email authentication have > had difficulty determining how effective their authentication is, and > use of authentication failures to filter mail has not been a success > > Should be: > As a result, senders implementing email authorization schemes have > had difficulty determining how effective their authorization is, and > use of authorization failures to filter mail has not been a success. I think this is exactly correct as "was". I think that in the case where *authentic* communications are *authorized* implicitly, we should use the weaker term. > Section 2.2 > Was: > o authentication of entities other than domains, since DMARC is > built upon SPF and DKIM which authenticate domains; and > Should be: > o authorizations of entities other than domains, since DMARC is > built upon SPF and DKIM which authorizes domains; and These and following changes are clearly incorrect, because "authorization of domains" is done by domain registrars, not by the domains. Do you mean "authentication" -> "verification" as above? (I still think this is better as "was", but I'm trying to understand your intent here.) Regards, Steve From nobody Sun Nov 2 01:42:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CED1A7113 for ; Sun, 2 Nov 2014 01:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VBvQI50rS1N for ; Sun, 2 Nov 2014 01:42:51 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4B31A7016 for ; Sun, 2 Nov 2014 01:42:50 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id q5so4229139wiv.4 for ; Sun, 02 Nov 2014 01:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ic74GP28Eu9YH4MlSEhDMlt1t43T9G4IEJ5QcEe68rA=; b=E1nD32IcXA4DzQ6GhboP/so7fkMvsLYjyFul3EUU44poEWqGhEU5vvf3VvGwsV4z1/ brefts13MW7xkNe7eVTXrm+NmCvB9Yq1nCeX9UxaS7aoehuPuwvLmXkEIW0g1ZP37JKe toSF6Por/wy2H06naqltm8tzF9WMq9J2P/cJ9ROMN20Rn43Fn176Axjt6k6Fn1wrFR27 Ce1kbkv5b0NXeEAlI+oZGotMhvr6EnaaoL13xjbd4VOqw6phbpt17hb9uswIeXt9lgBT gggVJ6q0w0dsBrfG60+PAXmd849UK0ca99dpdcTg+nnRxdvX6AP4bh6/LAJr1B3H5AfT feLw== MIME-Version: 1.0 X-Received: by 10.180.14.226 with SMTP id s2mr8308273wic.61.1414917769709; Sun, 02 Nov 2014 01:42:49 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Sun, 2 Nov 2014 01:42:49 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 Nov 2014 01:42:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Douglas Otis Content-Type: multipart/alternative; boundary=f46d04138c9f0ccb980506dc3748 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_QjF-3-pSMmWdNBO0aOCo6CNxRQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 08:42:54 -0000 --f46d04138c9f0ccb980506dc3748 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 31, 2014 at 4:45 PM, Douglas Otis wrote= : > Was: > However, there has been > no single widely accepted or publicly available mechanism to > communicate domain-specific message authentication policies, or to > request reporting of authentication and disposition of received mail. > > Should be: > However, there has been > no single widely accepted or publicly available mechanism to > communicate domain-specific message verification policies, or to > request reporting of verification and disposition of received mail. > This is dangerously misleading, because the message (as a whole) is most assuredly not being verified by any of the three mechanisms in play here. At this late stage in this document's life cycle, I would rather refer to or even copy Section 1.5.2 of RFC7001 if this is actually a point of confusion, but I don't have any evidence in hand that it is. > Although DMARC requires subsequent format checks of the From header > field, it does not do this with the Subject line which often permits > injectable clickable URLs. > The base document is not open for dealing new technical issues. The only edits being considered at this point are purely editorial or presentation improvements, or minor corrections to existing technical stuff. If the working group wants to take a run at reopening the base document later and possibly put that version on the Standards Track, it is chartered to do so (Phase III), but that milestone is a long way off. Tim said back in August that such issues can be collected in the WG's tracker and revisited at that time. If you wish to have this listed in that way, let him know. As was done with the DKIM deployment RFCs, the same has been done for DMARC. It seems neither DKIM nor DMARC follow the path of least astonishment. > > If history is any sort of predictor, DMARC will be gamed whenever receive= rs follow the path of least resistance and trust the *Authentication* resul= ts contained within messages. > > It seems unfortunate that Internet Identified Mail was not adopted becaus= e it passed the public key within the message which was seen as causing too= much message overhead. Now, rather than correcting the DKIM validation pr= ocess, domains are now expected to list all the headers used twice in each = and every message. As such, it seems IIM would now have been the better ch= oice. > > It is very dangerous to over sell the function of SPF and DKIM. Both of = these mechanisms are experiencing increased exploitation in highly critical= areas. It is unfortunate it took until May of 2014 for a major provider t= o finally acknowledge the nature of these exploits, although they had been = explained much earlier in appeals and magazine articles. > > Unless DKIM is repaired, both the DKIM Deployment and DMARC BCPs drafts a= re sorely lacking much needed guidance. Guidance many are likely to find a= stonishing. > > I suggest that this is an entirely inappropriate time and venue to be resurrecting these same old claims, especially the ones about breakage in other protocols as "fixing" them is nowhere near our charter. -MSK --f46d04138c9f0ccb980506dc3748 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 31, 2014 at 4:45 PM, Douglas Otis <doug.m= tview@gmail.com> wrote:
=
Was:
=C2=A0 = =C2=A0However, there has been
=C2=A0 =C2=A0no single widely accep= ted or publicly available mechanism to
=C2=A0 =C2=A0communicate d= omain-specific message authentication policies, or to
=C2=A0 =C2= =A0request reporting of authentication and disposition of received mail.

Should be:
=C2=A0 = =C2=A0However, there has been
=C2=A0 =C2=A0no single widely accep= ted or publicly available mechanism to
=C2=A0 =C2=A0communicate d= omain-specific message verification policies, or to
=C2=A0 =C2=A0= request reporting of verification and disposition of received mail.

This is dangerously mislea= ding, because the message (as a whole) is most assuredly not being verified= by any of the three mechanisms in play here.

At this lat= e stage in this document's life cycle, I would rather refer to or even = copy Section 1.5.2 of RFC7001 if this is actually a point of confusion, but= I don't have any evidence in hand that it is.
=C2=A0
=C2=A0Although DMARC requires subsequent format checks of the From he= ader field, it does not do this with the Subject line which often permits i= njectable clickable URLs.

The base do= cument is not open for dealing new technical issues.=C2=A0 The only edits b= eing considered at this point are purely editorial or presentation improvem= ents, or minor corrections to existing technical stuff.

If the worki= ng group wants to take a run at reopening the base document later and possi= bly put that version on the Standards Track, it is chartered to do so (Phas= e III), but that milestone is a long way off.=C2=A0 Tim said back in August= that such issues can be collected in the WG's tracker and revisited at= that time.=C2=A0 If you wish to have this listed in that way, let him know= .

As was done with th=
e DKIM deployment RFCs, the same has been done for DMARC. It seems neither =
DKIM nor DMARC follow the path of least astonishment.
If history =
is any sort of predictor, DMARC will be gamed whenever receivers follow the=
 path of least resistance and trust the Authentication results conta=
ined within messages.
It seems unfortunate that Internet Identifi=
ed Mail was not adopted because it passed the public key within the message=
 which was seen as causing too much message overhead.  Now, rather than cor=
recting the DKIM validation process, domains are now expected to list all t=
he headers used twice in each and every message.  As such, it seems IIM wou=
ld now have been the better choice.
It is very dangerous to over =
sell the function of SPF and DKIM.  Both of these mechanisms are experienci=
ng increased exploitation in highly critical areas.  It is unfortunate it t=
ook until May of 2014 for a major provider to finally acknowledge the natur=
e of these exploits, although they had been explained much earlier in appea=
ls and magazine articles.
Unless DKIM is repaired, both the DKIM =
Deployment and DMARC BCPs drafts are sorely lacking much needed guidance.  =
Guidance many are likely to find astonishing.
=

I suggest that this is an entirely inappr= opriate time and venue to be resurrecting these same old claims, especially= the ones about breakage in other protocols as "fixing" them is n= owhere near our charter.

-MSK
<= br>
--f46d04138c9f0ccb980506dc3748-- From nobody Sun Nov 2 01:44:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF8F1A7D83 for ; Sun, 2 Nov 2014 01:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxK6lk96ZqNI for ; Sun, 2 Nov 2014 01:44:18 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E6C1A7113 for ; Sun, 2 Nov 2014 01:44:18 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id n3so4227971wiv.0 for ; Sun, 02 Nov 2014 01:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jP38JMj4zBm7xANlhJwRj5cKTXvx6/r/flPif4/YtFg=; b=ugswSph4tRwqv0IxMVaZjgY2lAJAgnzivUqtWjwA4OCz+BHJR/cBs69g9CIohz65FO Fx65z4B0fFb6UClP8eNnox4TMFbSsZK+ZXDZBZqE3m0hUKNM4lOy+/M0lrCiDEsWBqi5 NN0yVJY5rCqw/+ue2fm7sunIkTFJ3owJFkjzSuz5vbYfsKFWdJkSodYVfsrnZwMVtgHa IWo+J7Z2s4ajxsUzhgG6X2qp33BymT+FfEzJwXRsQHH/bxf2MCrsmUPJDOtAwq2yet7y C6f78xOjtgxHqvLfIXlYOXoMzJk/KdZRKwqKa35vwHLA4C4r6ucxR50EI6RDml5offSu F48A== MIME-Version: 1.0 X-Received: by 10.180.75.179 with SMTP id d19mr8579025wiw.21.1414917856855; Sun, 02 Nov 2014 01:44:16 -0700 (PDT) Received: by 10.27.76.134 with HTTP; Sun, 2 Nov 2014 01:44:16 -0700 (PDT) In-Reply-To: <5640766.9itaAbt4HU@scott-latitude-e6320> References: <5640766.9itaAbt4HU@scott-latitude-e6320> Date: Sun, 2 Nov 2014 01:44:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043895133e8c170506dc3c9a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/x8xWYCoeHcUFDEFIiV43qKzixdI Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 08:44:21 -0000 --f46d043895133e8c170506dc3c9a Content-Type: text/plain; charset=UTF-8 Just noticed that I never replied to this: On Fri, Aug 29, 2014 at 8:39 PM, Scott Kitterman wrote: > Since this is the WG list, I'm not sure if this is still the right list for > issues with the base spec or not, but here goes ... > > The definition of "fo" in Section 5.2, General Record Format, allows both > values of "0" and "1" to be specified. It was suggested to me offlist > that this > might not be appropriate, so I thought it worth a discussion. > > Does anyone who's implemented "fo" have a problem with both "0" and "1" > being > specified? If it is somehow problematic, then the base spec ought to say > so. > How about this? 1: Generate a DMARC failure report if any underlying authentication mechanism produced something other than an aligned "pass" result. --f46d043895133e8c170506dc3c9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just noticed that I never replied to this:

On Fri, = Aug 29, 2014 at 8:39 PM, Scott Kitterman <sklist@kitterman.com><= /span> wrote:
Since this is the WG list, I&= #39;m not sure if this is still the right list for
issues with the base spec or not, but here goes ...

The definition of "fo" in Section 5.2, General Record Format, all= ows both
values of "0" and "1" to be specified.=C2=A0 It was sug= gested to me offlist that this
might not be appropriate, so I thought it worth a discussion.

Does anyone who's implemented "fo" have a problem with both &= quot;0" and "1" being
specified?=C2=A0 If it is somehow problematic, then the base spec ought to = say so.

How about this?
      1: Generate a DMARC failure report if any underlying
         authentication mechanism produced something other
         than=
 an aligned "pass" result.
--f46d043895133e8c170506dc3c9a-- From nobody Sun Nov 2 06:29:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9342E1A87C3 for ; Sun, 2 Nov 2014 06:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8XR3zdWzrCR for ; Sun, 2 Nov 2014 06:29:01 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C771A86EA for ; Sun, 2 Nov 2014 06:29:00 -0800 (PST) Received: from scott-latitude-e6320.localnet (unknown [72.128.40.159]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B06FAC4011E; Sun, 2 Nov 2014 08:28:59 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1414938539; bh=9249lV2wflC1OSz7jVn18V904VRY5mlqTf1/L10kyCo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aX11KLAvDwtBBp5z1t8OxyFURWAWMOq3Es1RRaLIt7qmiMnhGSKRC/xko9WX+2Q9H hZ1fych7oNeHmKqcS9goE/ZtEQnPYvQzYl55201JXrjDefoce2b8ZjUe3W7zOaSaT2 6UU8SVxOVy//FvooFiNj0TffuRAhpTC9WYPvAXVA= From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 02 Nov 2014 09:28:58 -0500 Message-ID: <2772219.NfCipyHrkn@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/sVSRNTkB_i3eM6fFGQBWmsDrc4Q Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2014 14:29:02 -0000 On Sunday, November 02, 2014 01:42:49 Murray S. Kucherawy wrote: ... > As was done with the DKIM deployment RFCs, the same has been done for > DMARC. It seems neither DKIM nor DMARC follow the path of least > astonishment. Not quite. There was an actual DKIM working group that produced standards track documents that, due to an actual technical issue they found, broke backward compatibility with existing DK key records. DMARC was developed outside the IETF and submitted via the ISE. Not at all the same (nor the least astonishing from my PoV). Not that it's going to change at this point, but let's not overdo the claims of business as usual. Scott K From nobody Mon Nov 3 08:04:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AAD1A040B for ; Mon, 3 Nov 2014 08:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XseOctRshzaX for ; Mon, 3 Nov 2014 08:04:30 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 484B51A0B76 for ; Mon, 3 Nov 2014 08:04:30 -0800 (PST) Received: from [192.168.82.67] (unknown [72.250.228.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 85B69CB46 for ; Mon, 3 Nov 2014 11:04:27 -0500 (EST) From: Tim Draegen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <81F67F64-58B3-400C-95DB-61A87B4DEBA1@eudaemon.net> Date: Mon, 3 Nov 2014 11:04:36 -0500 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/R7EBWmou1FgLQwodsicSA99Blb4 Subject: [dmarc-ietf] draft IETF 91 WG agenda up for review & input X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 16:04:32 -0000 Hi, this WG=E2=80=99s IETF91 agenda is up for review: http://www.ietf.org/proceedings/91/agenda/agenda-91-dmarc = If you have comments, suggestions, or modifications, please feel free to = reply here or if you're shy, reply privately. 1/2 of this WG's chair, =3D- Tim From nobody Mon Nov 3 12:04:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4625A1A8710 for ; Mon, 3 Nov 2014 12:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_vfFsMw0rsU for ; Mon, 3 Nov 2014 12:04:22 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00151A8713 for ; Mon, 3 Nov 2014 12:04:22 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id rp18so6092471iec.9 for ; Mon, 03 Nov 2014 12:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=d9MNgOM4niX2vGUSzcWmCkPOGqbPflzHmy/W+wyXs8s=; b=j4fkeMSWy0f9Zpvd3TcBeENosKUY3X7iEbHxfPsPl/5tq+KeH3DqgrvSaTr3V6kgTH LoKtcQE2BfPrGFfu/v951FbDrl0vWPdQMI8fRnWaMSAXgbwTX8CnHTJ6qDszBHLXBjbL aOnmmdihpXB4/Rpg8ILxxndAIxGKHyb+uzFtJKKs2Llg84sY6rskIQCtAt4qRyqvJH8e S7QhcWH+V0l+8Jrb/7koV+/6cGQPS0XPa7nqZNHbx2CAl/ON+9JhQtKTMOxmNNvItnhH WZ9opRb31OlFS6IKCLkg+yteIHrvhy1NF9t7QejmkE9vak/hvzrbIbiII7sXgdBT+wJa ZI9w== X-Received: by 10.42.175.202 with SMTP id bb10mr42426061icb.45.1415045062018; Mon, 03 Nov 2014 12:04:22 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id o130sm264339ioo.3.2014.11.03.12.04.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 12:04:21 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 3 Nov 2014 12:04:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AlB4v6vVBS1jvR1G6gptPmq-wSA Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 20:04:25 -0000 On Nov 1, 2014, at 2:09 AM, Stephen J. Turnbull = wrote: > Douglas Otis writes: >=20 >> As such, using the terms authenticates and authentication should >> not be used when referring to DKIM or SPF results. Nothing is >> being authenticated. >=20 > I'm confused. The sending domain is being authenticated, as well as > as much content as is signed (none for SPF, at least the =46rom and > DKIM-Signature fields for DKIM). Otherwise there's no point to either > protocol. Of course, DKIM does NOT ensure that the use of the Author > Domain is *authorized* (unless the author domain is the signing > domain, it which case it seems reasonable to presume authorization), > but it is *authentic* in the sense of being used as the sending domain > intended. >=20 > Or are you referring to the fact that these protocols don't put any > requirements on the security of the DNS? Dear Stephen, With SPF, it is fairly common to find authorizations from hundreds or = even thousands of different domains. Nothing based on SPF confirms a = purported domain is not being spoofed by one of the other authorized IP = addresses of other domains. A Botnet spoofing technique seeing = increased use, such as by the Kelios Botnet. After all, DMARC permits = the weakest authorization as a basis for acceptance, so it would be = misleading to describe DMARC results as having been *authenticated*. It = seems this is the motivation for attempting to promote SPF as being an = Authentication method when in fact it is clearly only Authorization, = especially with EHLO confirmation described as a null return path = fallback. With a high percentage of compromised systems, overstating = authorization as authentication only benefits malefactors with this = document's effort to oversell DMARC's functionality. While DKIM should be able to actually authenticate a signing domain, it = does not authenticate either the actual sending domain nor intended = recipient. In addition, the Authentication-Results header fields can = not be trusted on the basis of DKIM and SPF alone. Valid results are = premised on unreported checks of the =46rom header structure, while = ignoring others, such as that of the Subject which is able to include = clickable links and carry enticing messages. It seems few domains = bother to implement DKIM's Section 8.15 fixes intended to compensate for = an oversight of not checking the header stack structure within DKIM's = signature algorithm that must traverse the entire header stack in = reverse. Your comments offer convincing support for changing the DMARC acronym to = mean Domain-based Message Authorization, Reporting and Compliance = (DMARC), =20 >> The real function is verification of an authorization. >=20 > I think you are overcomplicating things here, and I don't understand > why. Both recipients and administrators are being misled into accepting = malicious content while forgoing other safety checks! > We *identify* a terminal of a channel (here by using the IP address > for SPF and the DKIM-Signature for DKIM), then *authenticate* that > identity, and finally accept its communications as *authorized* when > accompanied by an appropriate (secure) token from an "authority". In > many cases the identity is the token (as when a user is authorized to > access a file because she is the owner). It is not using SPF AND DKIM, it is using SPF OR DKIM. SPF can't = identify the domain owner (without using unscalable and unused macros). = When based on header results as suggested by the DKIM deployment RFC and = perhaps soon the DMARC BCP draft, nor can DKIM. Both SPF and DKIM still = permit significant security exposures. The intent of DMARC is to block = a large portion of abuse to better retain email as a transactional = signaling media. Since neither of these mechanisms identify the domain = involved, it would be safer to describe them as an authorization process = to better convey DMARC's underlying limitations. > In the case of a domain publishing an SPF "policy", the nature of the > protocol is essentially that "anything from these hosts is authentic > and authorized" (the identity =3D=3D sending IP is the authorization > token). If you don't want to say that, don't publish any hosts with > your restrictive SPF policy. Any message emitted by an authorized IP address is SPF authorized. SPF = says nothing about the use of a domain being authentic, as would DNSsec = and to a lesser degree DNS for example. > Analogously for DKIM, as far as I can see. The signed part of a > message is similarly self-authorizing if the signature is valid, and > if you don't like that, don't sign anything and use some other > protocol. I suppose here you also need DMARC or other policy protocol > to actually announce that you aren't sending any authentic mail with > DKIM signatures. DKIM indicates the signing domain handled the signed portion of the = message. DKIM failed to provide a practical means to signal its = results, especially when modified by receiving MTAs. Domain alignment = permits assumptions about the authorization intent of either SPF or = DKIM. Neither DKIM nor DMARC have been able to fully protect underlying = reliability which still accepts the weakest method. The intent of DMARC = was to increase delivery reliability at the expense of security. As = such it seems far safer to describe both SPF and DKIM as an = Authorization mechanism, and not as an Authentication mechanism as the = name's acronym implies.=20 > Agreed, there are good reasons to demand =46rom alignment. This can = be > is authenticated by DKIM (assuming the DNS and MTA have not been > subverted), and I suppose SPF (but in a world of virtualization and > shared resources I'm not so sure about SPF). This view continues to overlook security gaps present within DKIM while = at the same time ignoring DKIM might be supplanted by SPF. =20 > Again agreed, these don't identify users. But nobody in the mailbox > provider game seems to care about that anyway. Mailbox providers exclude non-authorized and known malicious domains. = This is not the same as providers identifying specific domains. =20 >> Section 2, >>=20 >> Was: >> However, there has been >> no single widely accepted or publicly available mechanism to >> communicate domain-specific message authentication policies, or to >> request reporting of authentication and disposition of received = mail. >>=20 >> Should be: >> However, there has been >> no single widely accepted or publicly available mechanism to >> communicate domain-specific message verification policies, or to >> request reporting of verification and disposition of received mail. >=20 > This is also inaccurate, however. Nothing about the message is > verified by any of these protocols, except the sending domain (and in > the case of DKIM, the integrity of the signed portion of message can > be verified). If you want to be more specific, you could write > "authentication of the sending domain and the signed portion of the > message, if any." (Again, unless you want to question the use of the > DNS as a source of authentication information. But I think that is > outside of the scope of these protocol documents, let alone of the = WG.) Concerns related to DNS and BGP aside, the sending domain is never = verified by DKIM. A message that most might consider undesired can be = sent from anywhere to anyone and still have a valid DKIM signature. = =46rom anywhere to anywhere is a feature of DKIM. With that in mind, = the most that can be safely said, is the DKIM signature acts as a = message authorization, in much the same manner as that offered by SPF. = Neither SPF nor DKIM should be considered to offer domain assurances = beyond Authorization. =20 >> Was: >> As a result, senders who have implemented email authentication have >> had difficulty determining how effective their authentication is, = and >> use of authentication failures to filter mail has not been a = success >>=20 >> Should be: >> As a result, senders implementing email authorization schemes have >> had difficulty determining how effective their authorization is, = and >> use of authorization failures to filter mail has not been a = success. >=20 > I think this is exactly correct as "was". I think that in the case > where *authentic* communications are *authorized* implicitly, we > should use the weaker term. >=20 >> Section 2.2 >> Was: >> o authentication of entities other than domains, since DMARC is >> built upon SPF and DKIM which authenticate domains; and >> Should be: >> o authorizations of entities other than domains, since DMARC is >> built upon SPF and DKIM which authorizes domains; and=20 >=20 > These and following changes are clearly incorrect, because > "authorization of domains" is done by domain registrars, not by the > domains. Do you mean "authentication" -> "verification" as above? (I > still think this is better as "was", but I'm trying to understand your > intent here.) You are conflating the use of a domain name itself with that of an email = message authorized to purport having a domain's return path (SPF) or = signed content purporting having been seen by the signing domain (DKIM). = DMARC permits the weaker of these assertions as a basis for acceptance. = Nor does DKIM ensure results are properly conveyed while leaving both = ends of the message path wide open, nor does DKIM or DMARC protect the = entirety of the message. Regards, Douglas Otis= From nobody Mon Nov 3 15:10:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7A51A8843 for ; Mon, 3 Nov 2014 15:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkywKk5oW_zC for ; Mon, 3 Nov 2014 15:10:00 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075AF1A883D for ; Mon, 3 Nov 2014 15:09:59 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so7896882wib.17 for ; Mon, 03 Nov 2014 15:09: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:date:message-id:subject:from:to :cc:content-type; bh=qiUgRTGSriCm/akkC7zi1dtN4Gx6+1oLPKYYgTEENeo=; b=HQkC8fAu4bwMfpdXCtVm2JPeY7ULMRVEf5qEA2YV8pTDThHJ/tWDnRbfCDKu93dw6E I/mhO3gxRB+wVzizqT86PK7lcUjLVDLFzUTwJNHZHgbRKc2cZAt/XJcR96qh8vF6hZmi p49TgeiffUt3EE7rbaHK5Q9SN+NWaPpnB50NxMVfaqdmLDVWjRjpwb6u1eQP0znSpgDb 5oDQGQd2YhWO7uNpyguQbLvOz1Uh9/Z82WIU09JbWuSH9dOxfLWeXR3C3sY20JXv1qJt JzbzdpRrmT5v9KIgAbVT+oZZi0DJIN0w6kDQLV6bpJQoQANX45s0Xy7/DvZep+VIq8az h11g== MIME-Version: 1.0 X-Received: by 10.194.189.240 with SMTP id gl16mr5910485wjc.119.1415056198581; Mon, 03 Nov 2014 15:09:58 -0800 (PST) Received: by 10.27.76.134 with HTTP; Mon, 3 Nov 2014 15:09:57 -0800 (PST) In-Reply-To: <2772219.NfCipyHrkn@scott-latitude-e6320> References: <2772219.NfCipyHrkn@scott-latitude-e6320> Date: Mon, 3 Nov 2014 15:09:57 -0800 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bb03c340dc3c70506fc7283 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-DNBB94cwuxD09eHld_ZeVdP7No Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 23:10:03 -0000 --047d7bb03c340dc3c70506fc7283 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 2, 2014 at 6:28 AM, Scott Kitterman wrote: > On Sunday, November 02, 2014 01:42:49 Murray S. Kucherawy wrote: > ... > > As was done with the DKIM deployment RFCs, the same has been done for > > DMARC. It seems neither DKIM nor DMARC follow the path of least > > astonishment. > Not quite. There was an actual DKIM working group that produced standards > track documents that, due to an actual technical issue they found, broke > backward compatibility with existing DK key records. DMARC was developed > outside the IETF and submitted via the ISE. Not at all the same (nor the > least astonishing from my PoV). > > Not that it's going to change at this point, but let's not overdo the > claims > of business as usual. > Just to get the citation right, it was Doug who said this, not me. -MSK --047d7bb03c340dc3c70506fc7283 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Nov 2, 2014 at 6:28 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
On Sunday, November 02,= 2014 01:42:49 Murray S. Kucherawy wrote:
...
> As was done with the DKIM deployment RFCs, the same h= as been done for
> DMARC. It seems neither DKIM nor DMARC follow the path of least
> astonishment.=C2=A0
=
Not quite.=C2=A0 There was an actual DKIM working group that produce= d standards
track documents that, due to an actual technical issue they found, broke backward compatibility with existing DK key records.=C2=A0 DMARC was develo= ped
outside the IETF and submitted via the ISE.=C2=A0 Not at all the same (nor = the
least astonishing from my PoV).

Not that it's going to change at this point, but let's not overdo t= he claims
of business as usual.

Just to get the c= itation right, it was Doug who said this, not me.

-MSK
--047d7bb03c340dc3c70506fc7283-- From nobody Mon Nov 3 18:02:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098241A1B82 for ; Mon, 3 Nov 2014 18:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sI3L-d_ToWbz for ; Mon, 3 Nov 2014 18:02:08 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B767D1A1B7F for ; Mon, 3 Nov 2014 18:02:08 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id rd18so6560947iec.41 for ; Mon, 03 Nov 2014 18:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:date:subject:cc:to; bh=TvLgrUS627xTXdsksl/9bouv+/S3K3yZo/hGv/bDdYE=; b=W2yjpKOU7b2LlRVXp7gDDje54XgCHyUIhdahqFXECHP4k053unRerbgbR742HgO3+I B4/OaC0huylXrayJxrH4hoPP0m0fQeeueBNt0j1wJPMTrEuDM05l4ycF3j1F8lIw9M/f g3xY3VC9WlO+x3jV4lvmFkihN4QEc7PJYw+u0lsKRPc/5Ve7kQv0bnN4fz2li50ImQVo 5lFaztPfZ1iKlC1InCXFh7tuE2LtnR+lbRTnw9jaa4moac/PJJDvMO/mCqwerqlu4kBp zU0qDLK/bKauCIxRHzv4o16Gt6Fhiv7PFjsbNUqRO6Jrx8z67Z5xyHRPx+e2KXXTgbpx Hg0g== X-Received: by 10.50.79.135 with SMTP id j7mr20609674igx.14.1415066528223; Mon, 03 Nov 2014 18:02:08 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id u3sm10079028ioi.27.2014.11.03.18.02.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Nov 2014 18:02:07 -0800 (PST) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_F7AC8455-2CC8-4673-8D35-CAB4B50B3738" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Mon, 3 Nov 2014 18:02:02 -0800 To: dmarc X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4lznmV8nc50wjGxzGgvgwAOQOoo Cc: "Murray S. Kucherawy" Subject: [dmarc-ietf] draft-kucherawy-dmarc-base-05 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 02:02:13 -0000 --Apple-Mail=_F7AC8455-2CC8-4673-8D35-CAB4B50B3738 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ Dear Murray, Based on yours and Stephen's feedback, a few modifications have been = made to the proposed edits: Starting with the acronym. Was: Domain-based Message Authentication, Reporting and Conformance (DMARC) Change to: Domain-based Message Authorization, Reporting and Conformance (DMARC) This change affects the title, the abstract, and various defined terms. Justification for this change includes RFC7001 Section 1.5.2. that = states the following: o "Authorization" is the establishment of permission to use a resource or represent an identity. In this context, authorization indicates that a message from a particular ADMD arrived via a route the ADMD has explicitly approved. o "Authentication" is the assertion of validity of a piece of data about a message (such as the sender's identity) or the message in its entirety. Neither SPF nor DKIM can claim to authenticate the sending domain of any = particular message. A DKIM signature is independent of both the domain = sending the message and its intended recipient by design. While a DKIM = reference to a public key in its signature produces a cryptographically = strong association with signed portions of a message, many message = elements are excluded. This exclusion permits unlimited message = variability independent of the actual sending domains or intended = message recipients by design. As such, DKIM alone is unable to = authenticate a domain publishing a referenced public key actually = generated any specific message. At best it might be claimed that by = signing the message, it has authorized various related functions, such = as delivery status notifications and specific use of some header fields, = particularly the =46rom header field.=20 In addition, the identifier purportedly verified in = Authentication-Results header fields as specified by RFC7001 suffers = from these DKIM related uncertainties caused by exclusion of portions of = the message. In addition, DKIM permits header obfuscation by failing to = detect invalid header field structures. SMTP makes no assurance of = message structure, and most DKIM signatures circumvent the overhead = necessary to patch DKIM's non-detection of invalid header structures. = It took a large provider several years to discover this particular = oversight, even after being warned in appeals and technical publications = making specific reference to their service. Others remain unaware DKIM = still permits header spoofing, especially when deployment suggests a = valid DKIM signature of a trusted domain can be allowed to bypass = subsequent checks. =20 In addition, DKIM's lack of header stack validation permits errant = results to be conveyed when maliciously changed. Suggesting a DKIM = signature authenticates the source domain places anyone depending on = this identity having been authenticated in respect to any particular = message at risk. =20 The introduction properly states the function of DKIM or SPF is to = detect and block unauthorized email. Neither DKIM nor SPF determines: 1) valid RFC5322 structure 2) intended message recipient 3) sending domain (not related to signing domain and may have a one of = many relationship) 4) =46rom header field content 5) Subject header field content Of course points 4 and 5 might be repaired, but when such a repair has = occurred can not be determined using the present protocol as intended. = Just as most senders avoid the overhead needed to ensure against invalid = header field structures, most receivers have similar sensibilities = related to subsequent handling necessary to detect these deceptions. As such, using the terms authenticates and authentication should not be = used when referring to DKIM or SPF results. Nothing is being = authenticated. The real function is the confirmation of an = authorization. It is dangerously misleading to overstate DMARC/SPF/DKIM = mechanisms, especially since DMARC permits the weakest mechanism (simple = authorization) as a basis for acceptance. Section 2, Was: However, there has been no single widely accepted or publicly available mechanism to communicate domain-specific message authentication policies, or to request reporting of authentication and disposition of received mail. Should be: However, there has been no single widely accepted or publicly available mechanism to communicate domain-specific message authorization policies, or to request reporting of authorization and disposition of received mail. Was: As a result, senders who have implemented email authentication have had difficulty determining how effective their authentication is, and use of authentication failures to filter mail has not been a success Should be: As a result, senders implementing email authorization schemes have had difficulty determining how effective their authorization is, and use of authorization failures to filter mail has not been a success. Section 2.2 Was: o authentication of entities other than domains, since DMARC is built upon SPF and DKIM which authenticate domains; and Should be: o authorizations of entities other than domains, since DMARC is built upon SPF and DKIM which authorizes domains; and=20 Section 3: Was: Authenticated Identifiers: Domain-level identifiers that are established using authentication technologies are referred to as "Authenticated Identifiers". See Section 3.1.1 for details about the supported mechanisms. Should be: Authorized Identifiers: Domain-level identifiers that are established using authorization technologies are referred to as "Authorized Identifiers". See Section 3.1.1 for details about the supported mechanisms. Was: 3.1.1. Authentication Mechanisms Should be: 3.1.1. Authorization Mechanisms Was: o [SPF], which authenticates the domain found in an [SMTP] MAIL command when it is the authorized domain. Should be: o [SPF], which authorizes the domain found in an [SMTP] MAIL command. Section 3.1.4 Was: Each of the underlying authentication technologies Should be: Each of the underlying authorization technologies Was: 3.1.4.2. SPF-authenticated Identifiers Should be: 3.1.4.2. SPF-authorized Identifiers Section 5 Was: A Domain Owner may find that although its messages pass a particular authentication scheme's checks, it wishes not to have Mail Receivers Should be; A Domain Owner may find that although its messages pass a particular authorization scheme's checks, it wishes not to have Mail Receivers Although DMARC requires subsequent format checks of the =46rom header = field, it does not do this with the Subject line which often permits = injectable clickable URLs. As was done with the DKIM deployment RFCs, the same has been done for = DMARC BCP. It seems neither DKIM nor DMARC follow the path of least = astonishment. If history is any sort of predictor, DMARC will be gamed whenever = receivers follow the path of least resistance by trusting = Authentication-Result header fields as recommended. The alternative to DKIM was IIM (Internet Identified Mail). IIM was not = adopted because it passed the public key within the message which was = considered to cause too much message size overhead. Now, rather than = correcting DKIM's signature validation process, domains are expected to = list all the headers used twice in each and every message. It is very dangerous to over sell the function of SPF and DKIM. Both of = these mechanisms are experiencing increased exploitation in highly = critical areas. It is unfortunate it took until May of 2014 for a major = provider to finally acknowledge the nature of these exploits, although = they had been explained much earlier in appeals and magazine articles. = Unless DKIM is repaired, both the DKIM Deployment and DMARC BCPs drafts = are sorely lacking much needed guidance. Guidance, if written to be = effective, many are likely to find astonishing. DMARC is missing an opportunity to permit =46rom header exceptions that = could be based on specific group syntax. Visible =46rom header field = exceptions are needed to permit undisrupted and safer use of third-party = services. =20 Regards, Douglas Otis= --Apple-Mail=_F7AC8455-2CC8-4673-8D35-CAB4B50B3738 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http= s://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/

Dear = Murray,

Based on yours and Stephen's feedback, a few = modifications have been made to the proposed = edits:

Starting with = the acronym.
Was:
  Domain-based Message = Authentication, Reporting and Conformance (DMARC)
Change = to:
  Domain-based Message Authorization, Reporting and = Conformance (DMARC)

This change affects the = title, the abstract, and various defined = terms.

Justification for this change includes = RFC7001 Section 1.5.2. that states the = following:

 o  "Authorization" = is the establishment of permission to use a
    =   resource or represent an identity.  In this context, = authorization
      indicates that a message = from a particular ADMD arrived via a
      = route the ADMD has explicitly approved.

 o =  "Authentication" is the assertion of validity of a piece of = data
      about a message (such as the = sender's identity) or the message in
      its = entirety.

Neither SPF nor = DKIM can claim to authenticate the sending domain of any particular = message.  A DKIM signature is independent of both the domain = sending the message and its intended recipient by design.  While a = DKIM reference to a public key in its signature produces a = cryptographically strong association with signed portions of a message, = many message elements are excluded.  This exclusion permits = unlimited message variability independent of the actual sending domains = or intended message recipients by design.  As such, DKIM alone is = unable to authenticate a domain publishing a referenced public key = actually generated any specific message.  At best it might be = claimed that by signing the message, it has authorized various related = functions, such as delivery status notifications and specific use of = some header fields, particularly the =46rom header = field. 

In addition, the identifier = purportedly verified in Authentication-Results header fields as = specified by RFC7001 suffers from these DKIM related uncertainties = caused by exclusion of portions of the message.  In addition, DKIM = permits header obfuscation by failing to detect invalid header field = structures.  SMTP makes no assurance of message structure, and most = DKIM signatures circumvent the overhead necessary to patch DKIM's = non-detection of invalid header structures.  It took a large = provider several years to discover this particular oversight, even after = being warned in appeals and technical publications making specific = reference to their service.  Others remain unaware DKIM still = permits header spoofing, especially when deployment suggests a valid = DKIM signature of a trusted domain can be allowed to bypass subsequent = checks.  

In addition, DKIM's lack of = header stack validation permits errant results to be conveyed when = maliciously changed.  Suggesting a DKIM signature authenticates the = source domain places anyone depending on this identity having been = authenticated in respect to any particular message at risk.   =  

The introduction properly states the = function of DKIM or SPF is to detect and block unauthorized = email.

Neither DKIM nor SPF determines:
1) valid = RFC5322 structure
2) intended message recipient
3) sending domain =  (not related to signing domain and may have a one of many = relationship)
4) =46rom header field content
5) Subject header = field content

Of course points 4 and 5 might be = repaired, but when such a repair has occurred can not be determined = using the present protocol as intended.  Just as most senders avoid = the overhead needed to ensure against invalid header field structures, = most receivers have similar sensibilities related to subsequent handling = necessary to detect these deceptions.

As such, using the = terms authenticates and authentication should not be = used when referring to DKIM or SPF results.  Nothing is being = authenticated.  The real function is the confirmation of = an authorization.  It is dangerously misleading to overstate = DMARC/SPF/DKIM mechanisms, especially since DMARC permits the weakest = mechanism (simple authorization) as a basis for = acceptance.

Section 2,
Was:
   However, there has = been
   no single widely accepted or publicly available = mechanism to
   communicate domain-specific message = authentication policies, or to
   request reporting of = authentication and disposition of received mail.
Should be:
  =  However, there has been
   no single widely accepted = or publicly available mechanism to
   communicate = domain-specific message authorization policies, or to
  =  request reporting of authorization and disposition of received = mail.

Was:
   As a result, senders who have = implemented email authentication have
   had difficulty = determining how effective their authentication is, and
  =  use of authentication failures to filter mail has not been a = success
Should be:
   As a result, senders implementing = email authorization schemes have
   had difficulty = determining how effective their authorization is, and
  =  use of authorization failures to filter mail has not been a = success.

Section 2.2
 Was:
 o =  authentication of entities other than domains, since DMARC = is
     built upon SPF and DKIM which authenticate = domains; and
Should be:
 o  authorizations of entities = other than domains, since DMARC is
     built upon SPF = and DKIM which authorizes domains; and 

Section = 3:
Was:
      Authenticated Identifiers: =  Domain-level identifiers that are
      = established using authentication technologies are referred to = as
      "Authenticated Identifiers".  See = Section 3.1.1 for details about
      the supported = mechanisms.
Should be:
      Authorized = Identifiers:  Domain-level identifiers that are
    =   established using authorization technologies are referred to = as
      "Authorized Identifiers".  See Section = 3.1.1 for details about
      the supported = mechanisms.

Was:
3.1.1.  Authentication = Mechanisms
Should be:
3.1.1.  Authorization = Mechanisms

Was:
o  [SPF], which authenticates the domain = found in an [SMTP] MAIL
      command when it is the = authorized domain.
Should be:
o  [SPF], which authorizes the = domain found in an [SMTP] MAIL
      = command.

Section 3.1.4
Was:
  Each of the = underlying authentication technologies
Should be:
  Each of = the underlying authorization technologies

Was:
  =  3.1.4.2.  SPF-authenticated Identifiers
Should = be:
   3.1.4.2.  SPF-authorized = Identifiers

Section 5
Was:
   A = Domain Owner may find that although its messages pass a = particular
   authentication scheme's checks, it = wishes not to have Mail Receivers
Should be;
   A = Domain Owner may find that although its messages pass a = particular
   authorization scheme's checks, it = wishes not to have Mail Receivers

Although DMARC = requires subsequent format checks of the =46rom header field, it does = not do this with the Subject line which often permits injectable = clickable URLs.

As was done with the DKIM = deployment RFCs, the same has been done for DMARC BCP.  It seems = neither DKIM nor DMARC follow the path of least astonishment.
If = history is any sort of predictor, DMARC will be gamed whenever receivers = follow the path of least resistance by trusting Authentication-Result = header fields as recommended.
The alternative to DKIM was IIM = (Internet Identified Mail).  IIM was not adopted because it passed = the public key within the message which was considered to cause too much = message size overhead.  Now, rather than correcting DKIM's = signature validation process, domains are expected to list all the = headers used twice in each and every = message.

It is very dangerous to over sell the = function of SPF and DKIM.  Both of these mechanisms are = experiencing increased exploitation in highly critical areas.  It = is unfortunate it took until May of 2014 for a major provider to finally = acknowledge the nature of these exploits, although they had been = explained much earlier in appeals and magazine articles.  Unless = DKIM is repaired, both the DKIM Deployment and DMARC BCPs drafts are = sorely lacking much needed guidance.  Guidance, if written to be = effective, many are likely to find = astonishing.

DMARC is missing an opportunity to = permit =46rom header exceptions that could be based on specific group = syntax.  Visible =46rom header field exceptions are needed to = permit undisrupted and safer use of third-party services. =  

Regards,
Douglas = Otis
= --Apple-Mail=_F7AC8455-2CC8-4673-8D35-CAB4B50B3738-- From nobody Mon Nov 3 21:04:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9B91A88A8 for ; Mon, 3 Nov 2014 21:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pvofoLVE1Zh for ; Mon, 3 Nov 2014 21:04:52 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9318C1A88A7 for ; Mon, 3 Nov 2014 21:04:51 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id B4C651C39D6; Tue, 4 Nov 2014 14:04:49 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A86C31A27CF; Tue, 4 Nov 2014 14:04:49 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 04 Nov 2014 14:04:49 +0900 Message-ID: <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_AJ6KblJczG_3AbwuJ7ur3Wh5Bs Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 05:04:55 -0000 Douglas Otis writes: > After all, DMARC permits the weakest authorization as a basis for > acceptance, so it would be misleading to describe DMARC results as > having been *authenticated*. Well, no, it isn't necessarily misleading. According to RFC 4949, authentication = identification + verification, while authorization is a permission to do something. For example, in DKIM "d=" identifies the Signing Domain and "b=" + a DNS lookup provides the data needed for verification. At that point you have in fact authenticated the Signing Domain, and with From alignment (and the additional assumptions that the key is available only to the Author/Signing Domain and that the Author Domain authenticates users) you have authenticated the "authorization to use that mailbox in From." (You could add a lot more caveats -- there is a lot of attack surface in email. :-( ) Some similar statement is true for SPF (at least under favorable conditions :-). AFAICS authenticating that particular authorization is precisely what DMARC claims to do, although the I-D uses different words to say that. Anyway, AIUI, the question we're trying to address in Milestone One is how does that affect third parties on the assumptions that (1) mail receivers are satisfied that DMARC does what they think it does and (2) such mail receivers respect "p=reject". From nobody Tue Nov 4 15:34:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5217A1A19F8 for ; Tue, 4 Nov 2014 15:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqoawQcBbEIG for ; Tue, 4 Nov 2014 15:34:18 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E4E1A1A13 for ; Tue, 4 Nov 2014 15:34:17 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id b13so14070061wgh.25 for ; Tue, 04 Nov 2014 15:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=phkDk/7ury3bJubdAzPN1l1tH8Rc9IxXL2e0GZhtpSk=; b=LvFIjE8amDu7SWyVVXBHM8TCi8kAW1pcU6nBL/3rkMRs6i7ATi3itTBsN7YEUvhIPd H59517xM84eXpCcibW17YKb1x2xkWqyuXJUKRYBV6xk9jQGBuvm35TYMyyWFdfKmYnlM HvGIdpDbHN/bMsvKwGXBwIdYPqviitY9seArUhIRVHAPG8//BmoXjV4fDXqv37f3YotR caghWAH0DM/81awrYfHzGLUZw8zLpUSEI9NnwUXLsJjAG+iXVJ4nr+hl1B8zEA6shLam xNaucVfwM7f0lVaugD6bYd/cY4EoxO3WLkwmy4ZlSnXC7Vpht9W4NZHHsLrToAlohbiq kjBg== MIME-Version: 1.0 X-Received: by 10.180.14.226 with SMTP id s2mr1120300wic.61.1415144056505; Tue, 04 Nov 2014 15:34:16 -0800 (PST) Received: by 10.27.76.134 with HTTP; Tue, 4 Nov 2014 15:34:16 -0800 (PST) In-Reply-To: <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 4 Nov 2014 15:34:16 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d04138c9fcb4996050710e63c Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-2JskBP6wZNnRJec-rNorKTVJC8 Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 23:34:20 -0000 --f46d04138c9fcb4996050710e63c Content-Type: text/plain; charset=UTF-8 On Mon, Nov 3, 2014 at 9:04 PM, Stephen J. Turnbull wrote: > > Well, no, it isn't necessarily misleading. According to RFC 4949, > authentication = identification + verification, while authorization is > a permission to do something. For example, in DKIM "d=" identifies > the Signing Domain and "b=" + a DNS lookup provides the data needed > for verification. At that point you have in fact authenticated the > Signing Domain, and with From alignment (and the additional > assumptions that the key is available only to the Author/Signing > Domain and that the Author Domain authenticates users) you have > authenticated the "authorization to use that mailbox in From." (You > could add a lot more caveats -- there is a lot of attack surface in > email. :-( ) Some similar statement is true for SPF (at least under > favorable conditions :-). AFAICS authenticating that particular > authorization is precisely what DMARC claims to do, although the I-D > uses different words to say that. > Maybe I'm the only one, but I think that while the RFC4949 definitions are fairly cut-and-dry when one talks about pure cryptography and authorization systems, they seem more murky when applied to the email space. For example, one might argue that in the "permission to do something" definition you gave, the "do something" in our case is the use of a particular domain name in the From field. Hence, the term "authorization" applies. However, the definitions of "verification" and "identification" also apply, hence so does "authentication". They're all arguably correct. Also, Section 1 of -05 already contains this: For the purposes of discussion, this document defines the word "authentication" to include techniques used to verify message integrity and/or sending-entity authorization. Accordingly, I don't see any evidence that, within the email space and hence our target audience, our use of "authentication" to date has been dangerously misleading or that anything really needs to change. -MSK --f46d04138c9fcb4996050710e63c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 3, 2014 at 9:04 PM, Stephen J. Turnbull <ste= phen@xemacs.org> wrote:

Well, no, it isn't necessarily misleading.=C2=A0 According to RF= C 4949,
authentication =3D identification + verification, while authorization is a permission to do something.=C2=A0 For example, in DKIM "d=3D" i= dentifies
the Signing Domain and "b=3D" + a DNS lookup provides the data ne= eded
for verification.=C2=A0 At that point you have in fact authenticated the Signing Domain, and with From alignment (and the additional
assumptions that the key is available only to the Author/Signing
Domain and that the Author Domain authenticates users) you have
authenticated the "authorization to use that mailbox in From."=C2= =A0 (You
could add a lot more caveats -- there is a lot of attack surface in
email. :-( )=C2=A0 Some similar statement is true for SPF (at least under favorable conditions :-).=C2=A0 AFAICS authenticating that particular
authorization is precisely what DMARC claims to do, although the I-D
uses different words to say that.

Maybe= I'm the only one, but I think that while the RFC4949 definitions are f= airly cut-and-dry when one talks about pure cryptography and authorization = systems, they seem more murky when applied to the email space.=C2=A0 For ex= ample, one might argue that in the "permission to do something" d= efinition you gave, the "do something" in our case is the use of = a particular domain name in the From field.=C2=A0 Hence, the term "aut= horization" applies.=C2=A0 However, the definitions of "verificat= ion" and "identification" also apply, hence so does "au= thentication".=C2=A0 They're all arguably correct.

Also, Section 1 of -05 already contains this:
   For =
the purposes of discussion, this document defines the word
   "authentication" to include techniques used to verify message
   integrity and/or sending-entity authorization.
Accordingly, I don't see any evidence that, within the email spac= e and hence our target audience, our use of "authentication" to d= ate has been dangerously misleading or that anything really needs to change= .

-MSK
--f46d04138c9fcb4996050710e63c-- From nobody Tue Nov 4 15:48:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B9A1A1A31 for ; Tue, 4 Nov 2014 15:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLAXeuLp9ASg for ; Tue, 4 Nov 2014 15:48:04 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5901F1A1A42 for ; Tue, 4 Nov 2014 15:48:04 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id q5so10892748wiv.16 for ; Tue, 04 Nov 2014 15:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gvSUQSq9/a0GnUcP43/TKd8tT7Uafhg+TtiPL+WISVQ=; b=Txts9qu4MTInIjx4McLA0XKsQWpI8ggi+ZrO0jXmNFIPJCpccQTrcd8nXLZ3gwd3zO Smr5E5v+CPaW0eHKX7Q3J7b0ZPE8cFjiyBOkt5GV30t2nHOBjDVSoqCjO939I6x9CtJD 8kLrHaSPrGzUbid11h+d9pdwhcSWRX8hw64POvPGFjUEVsHQ5VwXBj9XKOQJiA1d8sNt 7kYVojmIsNByqkJhjAOgGDJESMzc3JjPltqwOOy15SoIcaiPnuRmvVMi9fBskqtS9m7w CQEbh0aYdma2xfXL4HTLtGEnLstWMIcILwTA2b11Vq0oB1bx96eVIsF1rM3sJ0MIpWkM JKPg== MIME-Version: 1.0 X-Received: by 10.194.189.240 with SMTP id gl16mr14412459wjc.119.1415144883014; Tue, 04 Nov 2014 15:48:03 -0800 (PST) Received: by 10.27.76.134 with HTTP; Tue, 4 Nov 2014 15:48:02 -0800 (PST) Date: Tue, 4 Nov 2014 15:48:02 -0800 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb03c340ed32d0507111878 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/iNff8SdYNSZYzst1cEsET5Fcxnk Subject: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 23:48:06 -0000 --047d7bb03c340ed32d0507111878 Content-Type: text/plain; charset=UTF-8 [co-chairs: I appreciate the latitude in letting me post this here, as there appears to be no other appropriate venue, and presumably we'll be done with this part of the work very soon anyway.] I've received some on-list (which you've seen) and off-list feedback since posting -05. My understanding is that the ISE is waiting for review comments from specific people he's asked (Eliot) but also is interested in any other review comments people might be able to provide before advancing to publication. I have only two changes pending for an -06 based on the feedback I've received and an observation of my own, namely: 1) Several editorial changes that don't alter the meaning of the technical work at all; and 2) A change to the IANA Considerations that reduces the requirements on the new registries from IETF Review to Specification Required (see RFC5226). The justification for (1) is pretty straightforward in that they are of little consequence overall. The justification for (2) is largely procedural: I believe an independent submission, not being a product of the IETF, shouldn't create such a burden on the IETF; furthermore, there's really no reason for such stringent review of extensions that don't seem likely to appear anyway. The original choice was made way back when we planned to do this document on the Standards Track, but that's not how things worked out. So if anyone feels comfortable making comments on whether or not such an -06 would be ready for publication (i.e., -05, which is public, plus the above changes), please say so on this list so the ISE can see them. Any other feedback is of course welcome. I will post what I have for -06 as soon as the embargo lifts on Monday. I have not as yet included Doug's proposed changes as they don't seem to be supported (there has only been opposition voiced so far), but that does mean they were considered. We would like to put this document to bed as soon as is practical as it will be the reference basis for the current and future WG milestones, so hopefully reviews will be quick and plentiful. :-) Thanks, -MSK --047d7bb03c340ed32d0507111878 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[co-chairs: I= appreciate the latitude in letting me post this here, as there appears to = be no other appropriate venue, and presumably we'll be done with this p= art of the work very soon anyway.]

I've received some on-list (w= hich you've seen) and off-list feedback since posting -05.=C2=A0 My und= erstanding is that the ISE is waiting for review comments from specific peo= ple he's asked (Eliot) but also is interested in any other review comme= nts people might be able to provide before advancing to publication.
I have only two changes pending for an -06 based on the feedback I&#= 39;ve received and an observation of my own, namely:

1) Severa= l editorial changes that don't alter the meaning of the technical work = at all; and

2) A change to the IANA Considerations that reduce= s the requirements on the new registries from IETF Review to Specification = Required (see RFC5226).

The justification for (1) is pretty st= raightforward in that they are of little consequence overall.

The ju= stification for (2) is largely procedural: I believe an independent submiss= ion, not being a product of the IETF, shouldn't create such a burden on= the IETF; furthermore, there's really no reason for such stringent rev= iew of extensions that don't seem likely to appear anyway.=C2=A0 The or= iginal choice was made way back when we planned to do this document on the = Standards Track, but that's not how things worked out.

So = if anyone feels comfortable making comments on whether or not such an -06 w= ould be ready for publication (i.e., -05, which is public, plus the above c= hanges), please say so on this list so the ISE can see them.=C2=A0 Any othe= r feedback is of course welcome.=C2=A0 I will post what I have for -06 as s= oon as the embargo lifts on Monday.

I have not as yet included= Doug's proposed changes as they don't seem to be supported (there = has only been opposition voiced so far), but that does mean they were consi= dered.

We would like to put this document to bed as soon as is= practical as it will be the reference basis for the current and future WG = milestones, so hopefully reviews will be quick and plentiful.=C2=A0 :-)
=
Thanks,
-MSK
--047d7bb03c340ed32d0507111878-- From nobody Tue Nov 4 16:22:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8721A8741 for ; Tue, 4 Nov 2014 16:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4mvfpUaDpww for ; Tue, 4 Nov 2014 16:22:39 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BAB1A872C for ; Tue, 4 Nov 2014 16:22:39 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id y10so11916613wgg.2 for ; Tue, 04 Nov 2014 16:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=L72ov34TPQEeaQGOa3Yo3xVvKniof8eBOTdo8klVudw=; b=UK04fKk7UGT+rf690TDEg1RGdDi7SvK3zbSrE4o8pRLyT6ookYrQx/Ck5t3pwKW4aL a+/7aE4cjT6XQ7fzp1hN9Cywjg/sTM+IvdZmB5h77gs05heYJUC9kLTDlwiTjvxdJrvo HTI1H77FQDFkGVMbYhv1/LcAVU477BZtNLjIQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc:content-type; bh=L72ov34TPQEeaQGOa3Yo3xVvKniof8eBOTdo8klVudw=; b=IJB4eESpnqY1P64Vxw/zl23W9HF8eHKmcbUzALYRIIft4x3OM89l9BbOQT4SK6qb1Z NNb/qwxSLKxZvn9++uWkE456jSJCWndvUaWsJAvt3w3Q3FucnFE09nFeHYfopV5dqfJs 2pldN+qs9w/R8pPOIgoZIJJ/qRPhYvy9L0OEvpycDHqg1vYcurGrDNstcfzcAY1sGwGN kIKsGZo50zJxEYOVbPQVR6QMsyFi10EzSLgjskz/bLJNYsdubclLTiuXP6HUmt8C6/GV q4oia9/5JJB2ybphuXS67WrsHUPkgn5klnlJYqeGphyeE/VD31VVrY+SLbRJ+m3m/4Gr CKYQ== X-Gm-Message-State: ALoCoQkUPiQcKKzcIZdwNR/ha3W5/eqRvqevk8NtICgojUhVjzSlTjmqTow4bbUEXetBoEzSjVhj MIME-Version: 1.0 X-Received: by 10.181.8.72 with SMTP id di8mr27986933wid.1.1415146957740; Tue, 04 Nov 2014 16:22:37 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.188.115 with HTTP; Tue, 4 Nov 2014 16:22:37 -0800 (PST) Date: Tue, 4 Nov 2014 16:22:37 -0800 X-Google-Sender-Auth: qo-InKldsxC-D249VD-Pj-sQIi4 Message-ID: From: Kurt Andersen To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a1134cdeeb8b02605071193f7 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/qZNDi164tsJp35OoavduJfCjc1s Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 00:22:40 -0000 --001a1134cdeeb8b02605071193f7 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 4, 2014 at 3:48 PM, Murray S. Kucherawy wrote: > So if anyone feels comfortable making comments on whether or not such an > -06 would be ready for publication (i.e., -05, which is public, plus the > above changes), please say so on this list so the ISE can see them. Any > other feedback is of course welcome. I will post what I have for -06 as > soon as the embargo lifts on Monday. > > I'm in favor of a -06 as you propose. --Kurt Andersen --001a1134cdeeb8b02605071193f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 4, 2014 at 3:48 PM, Murray S. Kucherawy <<= a href=3D"mailto:superuser@gmail.com" target=3D"_blank">superuser@gmail.com= > wrote:
So if anyone = feels comfortable making comments on whether or not such an -06 would be re= ady for publication (i.e., -05, which is public, plus the above changes), p= lease say so on this list so the ISE can see them.=C2=A0 Any other feedback= is of course welcome.=C2=A0 I will post what I have for -06 as soon as the= embargo lifts on Mo= nday.


I'm in favor of a -06 as you propose.

--Kurt Andersen
--001a1134cdeeb8b02605071193f7-- From nobody Tue Nov 4 17:59:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB3A1A1BCE for ; Tue, 4 Nov 2014 17:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhW9xNHWCUll for ; Tue, 4 Nov 2014 17:59:47 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 155C01A1B29 for ; Tue, 4 Nov 2014 17:59:46 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 69DCC1C3A86; Wed, 5 Nov 2014 10:59:45 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5D2551A27CF; Wed, 5 Nov 2014 10:59:45 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 05 Nov 2014 10:59:45 +0900 Message-ID: <87egtiz9ta.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ciCY1nNNUX5Z30JiIhsIVBbTacw Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 01:59:49 -0000 Murray S. Kucherawy writes: > Maybe I'm the only one, but I think that while the RFC4949 > definitions are fairly cut-and-dry when one talks about pure > cryptography and authorization systems, they seem more murky when > applied to the email space. I think this is going to be true of the use of these words in any application where they refer to real security issues. > For example, one might argue that in the "permission to do > something" definition you gave, the "do something" in our case is > the use of a particular domain name in the From field. Hence, the > term "authorization" applies. However, the definitions of > "verification" and "identification" also apply, hence so does > "authentication". They're all arguably correct. If you say that they're all arguably correct, I'd say they're all definitely wrong in that context. :-) My point is that there are at least two agents involved in each activity (a credentials provider and a credentials verifier), and there may be more. Eg, in the case of DKIM you could argue that the From mailbox is provided by the originating author while the public key used to verify it is provided by the author domain, and with third-party auth*, it's more complicated yet -- and we haven't yet started on the issues of transitive trust with third party auth*. If we want to use these words accurately, we need explicit references to the subjects and objects of the verbs, at least somewhere in the immediate context. I don't have a problem with the I-D because I think it's the responsibility of readers to *read* it, at the algorithm level, and not try to interpret the verbal discussion as a precise specification. But in this WG, where we're engaged in meta-discussion of the spec and its effects, I think we need to be a lot more precise in use of these words, and far more frequently mention the subjects and objects of the verbs "identify", "authenticate", "verify", and "authorize", and typically avoid the noun forms, especially "authentication" and "authorization". Also, we face yet another layer of complexity (which Douglas Otis have referred to several times), and that is that I can say that people *ought* to refer to protocol algorithms as the authoritative definition all I like (and that has some validity) but Doug is right that many users and admins do and think something else, and the consequent deviation of belief from reality is often an attack vector. Regards, Steve From nobody Tue Nov 4 18:05:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7551A6FB8 for ; Tue, 4 Nov 2014 18:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KnZB9tNUjqz for ; Tue, 4 Nov 2014 18:05:17 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 31D701A3B9D for ; Tue, 4 Nov 2014 18:05:17 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9C0D01C3A90; Wed, 5 Nov 2014 11:05:16 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8B8351A27CF; Wed, 5 Nov 2014 11:05:16 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 05 Nov 2014 11:05:16 +0900 Message-ID: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/VnHxcOMRd7ry4RK1OHS5pJYwCSY Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 02:05:19 -0000 Murray S. Kucherawy writes: > I have only two changes pending for an -06 based on the feedback I've > received and an observation of my own, namely: > > 1) Several editorial changes that don't alter the meaning of the technical > work at all; and I'm happy with the editorial state of the document, including the state of the changes to -05 I've proposed off-list as accepted or rejected by the editors. > 2) A change to the IANA Considerations that reduces the requirements on the > new registries from IETF Review to Specification Required (see > RFC5226). I agree with this change for the reasons you gave. I believe the document is ready for publication. > The justification for (1) is pretty straightforward in that they are of > little consequence overall. > > The justification for (2) is largely procedural: I believe an independent > submission, not being a product of the IETF, shouldn't create such a burden > on the IETF; furthermore, there's really no reason for such stringent > review of extensions that don't seem likely to appear anyway. The original > choice was made way back when we planned to do this document on the > Standards Track, but that's not how things worked out. > > So if anyone feels comfortable making comments on whether or not such an > -06 would be ready for publication (i.e., -05, which is public, plus the > above changes), please say so on this list so the ISE can see them. Any > other feedback is of course welcome. I will post what I have for -06 as > soon as the embargo lifts on Monday. > > I have not as yet included Doug's proposed changes as they don't seem to be > supported (there has only been opposition voiced so far), but that does > mean they were considered. > > We would like to put this document to bed as soon as is practical as it > will be the reference basis for the current and future WG milestones, so > hopefully reviews will be quick and plentiful. :-) > > Thanks, > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Nov 5 10:20:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B776B1A90E2 for ; Wed, 5 Nov 2014 10:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUT6JfwSG5ek for ; Wed, 5 Nov 2014 10:20:45 -0800 (PST) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF651A90C1 for ; Wed, 5 Nov 2014 10:20:44 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id i17so1015571qcy.17 for ; Wed, 05 Nov 2014 10:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dXuV1tCDocqghIXqIaE+WdGmFYv0+ry9GQ7tEJeuV0s=; b=ztuDC+3sjWM667LaqUsR1YDZ/q2lXWHksV2qqe6cmfD08zym0g6657QueYT+4pva/A z6VqNg11uw1jlJmAO1pnYFd9m4/LfN4O30ce4ALtHsUnwskGcLfwg0bqvuUX0y+pBFwM dETeN/5FA49wUR4u0KICyC8RMW2mckU4GVLvxi7iY3dEBXY+Bmmttd4GmTwrkicwYVt3 lefhNpMLVTuQ4fsIj0rEoXJqyadj8dugQGmmEEcKJrjzu1wkNHuQ1P3DsqGKQlyvEZ7g EvdIzIQHZsRdhL2zo3ITsJrxEudwNdKcMgCqgRS79b0Ge/8eA0stN2nMEnSK+/FEodNq 1HEA== X-Received: by 10.140.81.36 with SMTP id e33mr19340417qgd.90.1415211643977; Wed, 05 Nov 2014 10:20:43 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id e19sm3752974qaq.20.2014.11.05.10.20.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 10:20:43 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Wed, 5 Nov 2014 10:20:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p4PErNBmOWzrGzIqwPmzsEmEFE8 Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 18:20:49 -0000 On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull = wrote: > Douglas Otis writes: >=20 >> After all, DMARC permits the weakest authorization as a basis for >> acceptance, so it would be misleading to describe DMARC results as >> having been *authenticated*. >=20 > Well, no, it isn't necessarily misleading. According to RFC 4949, > authentication =3D identification + verification, while authorization = is > a permission to do something. Dear Stephen, Since SPF authorizes an often _shared_ outbound IP address, it has been = accurately described as an authorization method. DMaRC permits a DKIM = signature to be spoofed and still allow a message to be accepted solely = on the basis of SPF. What magic turns authorization into = authentication??? Describing authorization as authentication has been = an exaggeration that started with SenderID. Large attack surfaces = provided by often overly broad SPF is increasingly being exploited by = botnets. Calling DMaRC Authentication threatens victims of malefactors that gain = access by way of SPF's fairly insecure authorization scheme which might = also employ reverse DNS handily exploited by compromised systems. This = misrepresentation injures recipients misled into believing DMaRC = authenticated the =46rom email address, as well as senders blocked = because an administrator believed DMaRC authenticated the identity in = question, the =46rom email address. It has not, nor can it. In addition, incorrectly defining DMARC as an authentication scheme = tends to exclude many possible adjustments needed to safely lessen = DMARC's disruptive impact on otherwise legitimate and desired = third-party services relied upon for decades. Don't let the erroneous = term authentication stand in the way of less disruptive authorization = extensions. > For example, in DKIM "d=3D" identifies > the Signing Domain and "b=3D" + a DNS lookup provides the data needed > for verification. At that point you have in fact authenticated the > Signing Domain, and with =46rom alignment (and the additional > assumptions that the key is available only to the Author/Signing > Domain and that the Author Domain authenticates users) you have > authenticated the "authorization to use that mailbox in From." (You > could add a lot more caveats -- there is a lot of attack surface in > email. :-( ) Some similar statement is true for SPF (at least under > favorable conditions :-). >=20 > AFAICS authenticating that particular > authorization is precisely what DMARC claims to do, although the I-D > uses different words to say that. Authenticating an Authorization? Does that then make an Authorization = authentication? > Anyway, AIUI, the question we're trying to address in Milestone One is > how does that affect third parties on the assumptions that (1) mail > receivers are satisfied that DMARC does what they think it does and > (2) such mail receivers respect "p=3Dreject". Removing DMaRC's disruption can be done by enabling the authorization of = necessary exceptions. Perhaps by way of authorizing specific domains or = or authorizing a specific =46rom header field group syntax. The DMaRC = WG should not attempt to define new =46rom header fields as a means to = enable policy exceptions. This would be sweeping DMaRC problems under = the rug, as any new header field used to replace the =46rom header field = will be eventually displayed to users for obvious reasons. Such = expected change would provide the effect of re-arranging deck chairs on = the Titanic. draft-kucherawy-dmarc-base is not ready, as its definitions remain = seriously flawed. Regards, Douglas Otis From nobody Wed Nov 5 10:35:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5C91A1AA0 for ; Wed, 5 Nov 2014 10:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQtZgDjEVths for ; Wed, 5 Nov 2014 10:35:33 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDC21A9137 for ; Wed, 5 Nov 2014 10:35:33 -0800 (PST) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.1.26.3; Wed, 5 Nov 2014 18:35:32 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.10.48]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.10.48]) with mapi id 15.01.0026.003; Wed, 5 Nov 2014 18:35:32 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] draft-kucherawy-dmarc-base Thread-Index: AQHP9WTMtPWp+p5pM06rxT1gQIhQHZxLfGkAgAPbdYCAAJcQgIACcLAAgAABw5A= Date: Wed, 5 Nov 2014 18:35:32 +0000 Message-ID: References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> In-Reply-To: <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.230] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB605; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(199003)(377454003)(13464003)(189002)(24454002)(52314003)(2501002)(33656002)(2656002)(19580405001)(54206007)(54606007)(54356999)(97736003)(106116001)(50986999)(106356001)(20776003)(19580395003)(64706001)(105586002)(87936001)(66066001)(15975445006)(76176999)(4396001)(101416001)(107046002)(2351001)(21056001)(92566001)(92726001)(77096003)(107886001)(120916001)(31966008)(450100001)(110136001)(46102003)(99396003)(93886004)(62966003)(77156002)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IEWJY4-tMowN9utUHmO938ePEUU Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 18:35:36 -0000 > Since SPF authorizes an often _shared_ outbound IP address, it has been a= ccurately described=20 > as an authorization method. DMaRC permits a DKIM signature to be spoofed= and still allow=20 > a message to be accepted solely on the basis of SPF. What magic turns au= thorization into=20 > authentication??? =20 This is a good point and I can share some of our own experiences in Microso= ft's Office 365. We have a hosted service. Companies/users can either have hosted email acco= unts wherein they login to the portal and send/receive email, or connect to= it via IMAP/POP3. The second option is an on-premise environment wherein t= heir email passes through us and we relay it to their on-premise machines. = They can send outbound email through us by connecting to the service by spe= cifying their outbound IP in a "Connector". We ask customers to add our service's SPF record to their own SPF records. = When they send outbound email through us, it will authenticate at the desti= nation. However, if Customer A ever spoofs Customer B, it will also authent= icate via SPF. This is a very real problem. So how are we fixing it? First, hosted email accounts cannot spoof another customer. If you login to= the portal, or connect via IMAP/POP3, you can't specify your MAIL FROM dom= ain. You have to set it up in the portal and put a key into your TXT record= . That's not changeable. Second, for on-premise machines, they *can* spoof another customer. If they= connect over their IP, if the domain they connect with is not provisioned = with them, it is attributed to a "safe tenant" (a misnomer in my opinion). = It is here that they could spoof someone else. To get around this, we will = check DMARC on outbound mail before we relay it out. If a domain fails DMAR= C when it connects to us, and it is an outbound email intended for the rest= of the Internet, we will reject the message so it cannot be sent out to an= unsuspecting third party that might pass SPF since it came from our servic= e's outbound IPs. This is not a perfect solution, but it does close a gap. The existing DMARC= specification lets us do this without making any changes to it. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Douglas Otis Sent: Wednesday, November 5, 2014 10:21 AM To: Stephen J. Turnbull Cc: dmarc@ietf.org; Murray S. Kucherawy; Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base On Nov 3, 2014, at 9:04 PM, Stephen J. Turnbull wrote: > Douglas Otis writes: >=20 >> After all, DMARC permits the weakest authorization as a basis for >> acceptance, so it would be misleading to describe DMARC results as >> having been *authenticated*. >=20 > Well, no, it isn't necessarily misleading. According to RFC 4949, > authentication =3D identification + verification, while authorization is > a permission to do something. Dear Stephen, Since SPF authorizes an often _shared_ outbound IP address, it has been acc= urately described as an authorization method. DMaRC permits a DKIM signatu= re to be spoofed and still allow a message to be accepted solely on the bas= is of SPF. What magic turns authorization into authentication??? Describi= ng authorization as authentication has been an exaggeration that started wi= th SenderID. Large attack surfaces provided by often overly broad SPF is i= ncreasingly being exploited by botnets. Calling DMaRC Authentication threatens victims of malefactors that gain acc= ess by way of SPF's fairly insecure authorization scheme which might also e= mploy reverse DNS handily exploited by compromised systems. This misrepres= entation injures recipients misled into believing DMaRC authenticated the F= rom email address, as well as senders blocked because an administrator beli= eved DMaRC authenticated the identity in question, the From email address. = It has not, nor can it. In addition, incorrectly defining DMARC as an authentication scheme tends t= o exclude many possible adjustments needed to safely lessen DMARC's disrupt= ive impact on otherwise legitimate and desired third-party services relied = upon for decades. Don't let the erroneous term authentication stand in the= way of less disruptive authorization extensions. > For example, in DKIM "d=3D" identifies > the Signing Domain and "b=3D" + a DNS lookup provides the data needed > for verification. At that point you have in fact authenticated the > Signing Domain, and with From alignment (and the additional > assumptions that the key is available only to the Author/Signing > Domain and that the Author Domain authenticates users) you have > authenticated the "authorization to use that mailbox in From." (You > could add a lot more caveats -- there is a lot of attack surface in > email. :-( ) Some similar statement is true for SPF (at least under > favorable conditions :-). >=20 > AFAICS authenticating that particular > authorization is precisely what DMARC claims to do, although the I-D > uses different words to say that. Authenticating an Authorization? Does that then make an Authorization auth= entication? > Anyway, AIUI, the question we're trying to address in Milestone One is > how does that affect third parties on the assumptions that (1) mail > receivers are satisfied that DMARC does what they think it does and > (2) such mail receivers respect "p=3Dreject". Removing DMaRC's disruption can be done by enabling the authorization of ne= cessary exceptions. Perhaps by way of authorizing specific domains or or a= uthorizing a specific From header field group syntax. The DMaRC WG should = not attempt to define new From header fields as a means to enable policy ex= ceptions. This would be sweeping DMaRC problems under the rug, as any new = header field used to replace the From header field will be eventually displ= ayed to users for obvious reasons. Such expected change would provide the = effect of re-arranging deck chairs on the Titanic. draft-kucherawy-dmarc-base is not ready, as its definitions remain seriousl= y flawed. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Nov 5 12:50:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB471ACD51 for ; Wed, 5 Nov 2014 12:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYhwYl8Vch38 for ; Wed, 5 Nov 2014 12:50:34 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69251ACD50 for ; Wed, 5 Nov 2014 12:50:33 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so13587272wiw.15 for ; Wed, 05 Nov 2014 12:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QgMu6N8+9y4Zuyc1f4wJMiuSSpFYsAWSdzGupCh0Hkc=; b=uCKcK4sJ4ZDZFm8D2mBhfv5Rx0q0+7u4qW7iA9LRchoI3ISWlQCq60XaW1aqXVEkvh 9aUa8tloSJ5UXuYY18FQlm2O3aaB7Q5wWNBZKs6joaZ3VMzMRUmipTJsBaqJ6e7r92az HuzOuRq6I5qO6TciWhEEIkDQPybM5SXycW9P5P95J7ztBWGO9iwQOrnwNZ+tmCRGJext He3pt8pzpltACHhEnztWDSBeb95xQI57U54ax1D0LHTR+kr49/Bw0f9wND/vr4RAEwsu /D9jOjP9TJFD4+LguYXW6N/guw+M1VFD+6qZsVyhNZ94p1dTTctra9kWUgHcf6++pp8m p+RA== MIME-Version: 1.0 X-Received: by 10.180.221.129 with SMTP id qe1mr8930953wic.21.1415220632429; Wed, 05 Nov 2014 12:50:32 -0800 (PST) Received: by 10.27.76.134 with HTTP; Wed, 5 Nov 2014 12:50:32 -0800 (PST) In-Reply-To: References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> Date: Wed, 5 Nov 2014 12:50:32 -0800 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=001a1133c8fa132b55050722bb3b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jED8gmTX9RU_i515Sr-cjLw5XNc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 20:50:35 -0000 --001a1133c8fa132b55050722bb3b Content-Type: text/plain; charset=UTF-8 On Wed, Nov 5, 2014 at 10:35 AM, Terry Zink wrote: > > Since SPF authorizes an often _shared_ outbound IP address, it has been > accurately described > > as an authorization method. DMaRC permits a DKIM signature to be > spoofed and still allow > > a message to be accepted solely on the basis of SPF. What magic turns > authorization into > > authentication??? > > This is a good point and I can share some of our own experiences in > Microsoft's Office 365. > [...] > Terry, In terms of the base draft's content, I think the salient question is: Does the base draft's use of the term "authentication" mislead you or your customers in any way? -MSK --001a1133c8fa132b55050722bb3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 5, 2014 at 10:35 AM, Terry Zink <t= zink@exchange.microsoft.com> wrote:
> Since SPF authorizes an often _shared_ outbound IP address, it h= as been accurately described
> as an authorization method.=C2=A0 DMaRC permits a DKIM signature to be= spoofed and still allow
> a message to be accepted solely on the basis of SPF.=C2=A0 What magic = turns authorization into
> authentication???

This is a good point and I can share some of our own experiences in = Microsoft's Office 365.
[...]

Terry,

In terms= of the base draft's content, I think the salient question is:

<= /div>
Does the base draft's use of the term "authentication&qu= ot; mislead you or your customers in any way?

-MSK
--001a1133c8fa132b55050722bb3b-- From nobody Wed Nov 5 12:54:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500311ACD6B for ; Wed, 5 Nov 2014 12:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cEhpi1eYYOc for ; Wed, 5 Nov 2014 12:54:44 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39AAE1A87E9 for ; Wed, 5 Nov 2014 12:54:44 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id p10so1457167pdj.33 for ; Wed, 05 Nov 2014 12:54:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ty47h2futrshxDmkKxef/RHwETULQBkXfrv8hwaMu00=; b=IR2KaqFwvVGVt+hBTim4CsfMO+j8sz7C7nUjH0XEsYSxkKVysnrHbijpnorMb+gWqQ E/8QGUVE8BD5BxwwIIf34wq6j/jKxEYjreFmIUATsEaYsMKXGkQj3ICMDuP8wz1s/RJs K9suKFk0yUlWiAp8a6+DGnj9gX3zhLtNyhsb80/Gp7sVCjB8XPp2w3b19eLzEPoOE6vU Jv/DXRs636vCJP8HG4ZHMiwfP9oiKs6g68ZvH4hN6qVLOVaQL/VdpIIZv2j8WQuyIoXn Uirp7GKUgiqcixgjr3Sx8pvnuBo/XrVn/NzZqjFte9MuBniBpq0rquqB1XbMsFjTXj2n TmjQ== X-Received: by 10.66.165.200 with SMTP id za8mr4126622pab.156.1415220883464; Wed, 05 Nov 2014 12:54:43 -0800 (PST) Received: from ?IPv6:2601:9:7300:1510:6d62:89ff:cf2b:3a7e? ([2601:9:7300:1510:6d62:89ff:cf2b:3a7e]) by mx.google.com with ESMTPSA id l9sm4013582pbq.26.2014.11.05.12.54.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 12:54:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Wed, 5 Nov 2014 12:54:40 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <68085296-6FC9-4D1A-9EE0-A962451858E4@gmail.com> References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> To: Terry Zink X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/P_VPyehpg5BxFdlFs72v7B0LCGU Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 20:54:45 -0000 On Nov 5, 2014, at 10:35 AM, Terry Zink = wrote: >> Since SPF authorizes an often _shared_ outbound IP address, it has = been accurately described=20 >> as an authorization method. DMaRC permits a DKIM signature to be = spoofed and still allow=20 >> a message to be accepted solely on the basis of SPF. What magic = turns authorization into=20 >> authentication??? =20 >=20 > This is a good point and I can share some of our own experiences in = Microsoft's Office 365. >=20 > We have a hosted service. Companies/users can either have hosted email = accounts wherein they login to the portal and send/receive email, or = connect to it via IMAP/POP3. The second option is an on-premise = environment wherein their email passes through us and we relay it to = their on-premise machines. They can send outbound email through us by = connecting to the service by specifying their outbound IP in a = "Connector". >=20 > We ask customers to add our service's SPF record to their own SPF = records. When they send outbound email through us, it will authenticate = at the destination. However, if Customer A ever spoofs Customer B, it = will also authenticate via SPF. This is a very real problem. >=20 > So how are we fixing it? >=20 > First, hosted email accounts cannot spoof another customer. If you = login to the portal, or connect via IMAP/POP3, you can't specify your = MAIL FROM domain. You have to set it up in the portal and put a key into = your TXT record. That's not changeable. >=20 > Second, for on-premise machines, they *can* spoof another customer. If = they connect over their IP, if the domain they connect with is not = provisioned with them, it is attributed to a "safe tenant" (a misnomer = in my opinion). It is here that they could spoof someone else. To get = around this, we will check DMARC on outbound mail before we relay it = out. Dear Terry, What role does DMaRC play in a scheme that relies on the special TXT key = you mentioned? If so, is this really even describing DMaRC? > If a domain fails DMARC when it connects to us, and it is an outbound = email intended for the rest of the Internet, we will reject the message = so it cannot be sent out to an unsuspecting third party that might pass = SPF since it came from our service's outbound IPs. Could this satisfy Intuit should their customers make use your services = and assert p=3Dreject? > This is not a perfect solution, but it does close a gap. The existing = DMARC specification lets us do this without making any changes to it. How would this help resolve third-party issues the WG should be = attempting to address? While these efforts in your service are = commendable, how does this help address the fact that the base draft is = misleading and is using definitions that will be problematic when = resolving third-party issues through use of hopefully open protocol = extensions. Regards, Douglas Otis= From nobody Wed Nov 5 13:37:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB1B1A797C for ; Wed, 5 Nov 2014 13:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewGv3Za7EVeV for ; Wed, 5 Nov 2014 13:37:04 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB131A036A for ; Wed, 5 Nov 2014 13:37:04 -0800 (PST) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.26.3; Wed, 5 Nov 2014 21:37:02 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.10.136]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.10.136]) with mapi id 15.01.0026.003; Wed, 5 Nov 2014 21:37:02 +0000 From: Terry Zink To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] draft-kucherawy-dmarc-base Thread-Index: AQHP9WTMtPWp+p5pM06rxT1gQIhQHZxLfGkAgAPbdYCAAJcQgIACcLAAgAABw5CAACgcAIAADEKQ Date: Wed, 5 Nov 2014 21:37:01 +0000 Message-ID: References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.159.103] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=exchange.microsoft.com; x-dmarcaction: None x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(377454003)(199003)(33656002)(230783001)(46102003)(20776003)(19300405004)(110136001)(62966003)(76176999)(54356999)(19625215002)(19580395003)(120916001)(1411001)(19580405001)(77156002)(77096003)(99396003)(97736003)(16236675004)(107046002)(54206007)(66066001)(54606007)(106356001)(106116001)(93886004)(21056001)(4396001)(2656002)(15202345003)(31966008)(105586002)(50986999)(64706001)(87936001)(101416001)(92726001)(92566001)(15975445006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB605E66A9D61DD2BD75D975D96870BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/S2qO-oFGpJcIrW8oYthMPky0P14 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 21:37:07 -0000 --_000_BL2SR01MB605E66A9D61DD2BD75D975D96870BL2SR01MB605namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBEb2VzIHRoZSBiYXNlIGRyYWZ0J3MgdXNlIG9mIHRoZSB0ZXJtICJhdXRoZW50aWNhdGlvbiIg bWlzbGVhZCB5b3Ugb3IgeW91ciBjdXN0b21lcnMNCj4gaW4gYW55IHdheT8NCk5vLCBldmVyeXRo aW5nIGlzIGNsZWFyIGVub3VnaC4gSSB1c2UgdGhlIHRlcm0gdG8gcmVmZXIgdG8gcGFzc2luZyBl aXRoZXIgU1BGIG9yIERLSU0uDQoNCkFzIGFuIGFzaWRlLCBJIHNob3VsZCBoYXZlIG1lbnRpb25l ZCB0aGF0IHdlIGFyZSB3b3JraW5nIG9uIERNQVJDIGJ1dCBpdCBpcyBub3QgeWV0IGNvbXBsZXRl LiBCdXQgdGhlIHdheSBJIGRlc2NyaWJlZCBpdCBpcyBob3cgaXQgd2lsbCB3b3JrLg0KDQotLSBU ZXJyeQ0KDQpGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5IFttYWlsdG86c3VwZXJ1c2VyQGdtYWls LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgNSwgMjAxNCAxMjo1MSBQTQ0KVG86IFRl cnJ5IFppbmsNCkNjOiBkbWFyY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBk cmFmdC1rdWNoZXJhd3ktZG1hcmMtYmFzZQ0KDQpPbiBXZWQsIE5vdiA1LCAyMDE0IGF0IDEwOjM1 IEFNLCBUZXJyeSBaaW5rIDx0emlua0BleGNoYW5nZS5taWNyb3NvZnQuY29tPG1haWx0bzp0emlu a0BleGNoYW5nZS5taWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+IFNpbmNlIFNQRiBhdXRob3JpemVz IGFuIG9mdGVuIF9zaGFyZWRfIG91dGJvdW5kIElQIGFkZHJlc3MsIGl0IGhhcyBiZWVuIGFjY3Vy YXRlbHkgZGVzY3JpYmVkDQo+IGFzIGFuIGF1dGhvcml6YXRpb24gbWV0aG9kLiAgRE1hUkMgcGVy bWl0cyBhIERLSU0gc2lnbmF0dXJlIHRvIGJlIHNwb29mZWQgYW5kIHN0aWxsIGFsbG93DQo+IGEg bWVzc2FnZSB0byBiZSBhY2NlcHRlZCBzb2xlbHkgb24gdGhlIGJhc2lzIG9mIFNQRi4gIFdoYXQg bWFnaWMgdHVybnMgYXV0aG9yaXphdGlvbiBpbnRvDQo+IGF1dGhlbnRpY2F0aW9uPz8/DQoNClRo aXMgaXMgYSBnb29kIHBvaW50IGFuZCBJIGNhbiBzaGFyZSBzb21lIG9mIG91ciBvd24gZXhwZXJp ZW5jZXMgaW4gTWljcm9zb2Z0J3MgT2ZmaWNlIDM2NS4NClsuLi5dDQoNClRlcnJ5LA0KSW4gdGVy bXMgb2YgdGhlIGJhc2UgZHJhZnQncyBjb250ZW50LCBJIHRoaW5rIHRoZSBzYWxpZW50IHF1ZXN0 aW9uIGlzOg0KRG9lcyB0aGUgYmFzZSBkcmFmdCdzIHVzZSBvZiB0aGUgdGVybSAiYXV0aGVudGlj YXRpb24iIG1pc2xlYWQgeW91IG9yIHlvdXIgY3VzdG9tZXJzIGluIGFueSB3YXk/DQotTVNLDQo= --_000_BL2SR01MB605E66A9D61DD2BD75D975D96870BL2SR01MB605namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj4mZ3Q7IERvZXMgdGhlIGJhc2UgZHJhZnQncyB1 c2Ugb2YgdGhlIHRlcm0gJnF1b3Q7YXV0aGVudGljYXRpb24mcXVvdDsgbWlzbGVhZCB5b3Ugb3Ig eW91ciBjdXN0b21lcnMNCjxicj4NCiZndDsgaW4gYW55IHdheT88bzpwPjwvbzpwPjwvYT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPk5vLCBldmVyeXRoaW5nIGlzIGNsZWFyIGVub3VnaC4gSSB1c2UgdGhlIHRlcm0gdG8g cmVmZXIgdG8gcGFzc2luZyBlaXRoZXIgU1BGIG9yIERLSU0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkFzIGFuIGFzaWRlLCBJ IHNob3VsZCBoYXZlIG1lbnRpb25lZCB0aGF0IHdlIGFyZSB3b3JraW5nIG9uIERNQVJDIGJ1dCBp dCBpcyBub3QgeWV0IGNvbXBsZXRlLiBCdXQgdGhlIHdheSBJIGRlc2NyaWJlZCBpdCBpcyBob3cg aXQgd2lsbCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4tLSBUZXJyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gTXVycmF5IFMuIEt1Y2hlcmF3eSBbbWFpbHRvOnN1cGVydXNlckBnbWFp bC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciA1LCAyMDE0IDEy OjUxIFBNPGJyPg0KPGI+VG86PC9iPiBUZXJyeSBaaW5rPGJyPg0KPGI+Q2M6PC9iPiBkbWFyY0Bp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZdIGRyYWZ0LWt1Y2hl cmF3eS1kbWFyYy1iYXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBOb3YgNSwgMjAxNCBhdCAxMDozNSBBTSwgVGVycnkgWmluayAmbHQ7PGEgaHJlZj0ibWFp bHRvOnR6aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj50emlua0Bl eGNoYW5nZS5taWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFNpbmNlIFNQ RiBhdXRob3JpemVzIGFuIG9mdGVuIF9zaGFyZWRfIG91dGJvdW5kIElQIGFkZHJlc3MsIGl0IGhh cyBiZWVuIGFjY3VyYXRlbHkgZGVzY3JpYmVkPGJyPg0KJmd0OyBhcyBhbiBhdXRob3JpemF0aW9u IG1ldGhvZC4mbmJzcDsgRE1hUkMgcGVybWl0cyBhIERLSU0gc2lnbmF0dXJlIHRvIGJlIHNwb29m ZWQgYW5kIHN0aWxsIGFsbG93PGJyPg0KJmd0OyBhIG1lc3NhZ2UgdG8gYmUgYWNjZXB0ZWQgc29s ZWx5IG9uIHRoZSBiYXNpcyBvZiBTUEYuJm5ic3A7IFdoYXQgbWFnaWMgdHVybnMgYXV0aG9yaXph dGlvbiBpbnRvPGJyPg0KJmd0OyBhdXRoZW50aWNhdGlvbj8/Pzxicj4NCjxicj4NClRoaXMgaXMg YSBnb29kIHBvaW50IGFuZCBJIGNhbiBzaGFyZSBzb21lIG9mIG91ciBvd24gZXhwZXJpZW5jZXMg aW4gTWljcm9zb2Z0J3MgT2ZmaWNlIDM2NS48YnI+DQpbLi4uXTxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5UZXJyeSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SW4gdGVybXMgb2Yg dGhlIGJhc2UgZHJhZnQncyBjb250ZW50LCBJIHRoaW5rIHRoZSBzYWxpZW50IHF1ZXN0aW9uIGlz OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Eb2VzIHRoZSBiYXNlIGRyYWZ0J3MgdXNlIG9mIHRo ZSB0ZXJtICZxdW90O2F1dGhlbnRpY2F0aW9uJnF1b3Q7IG1pc2xlYWQgeW91IG9yIHlvdXIgY3Vz dG9tZXJzIGluIGFueSB3YXk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tTVNLPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL2SR01MB605E66A9D61DD2BD75D975D96870BL2SR01MB605namsdf_-- From nobody Wed Nov 5 13:53:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0DF1ACE2B for ; Wed, 5 Nov 2014 13:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1uIRGIGM_Ia for ; Wed, 5 Nov 2014 13:53:34 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9B11A0004 for ; Wed, 5 Nov 2014 13:53:34 -0800 (PST) Received: from kitterman-optiplex-9020m.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 785F3C40580 for ; Wed, 5 Nov 2014 15:53:33 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1415224413; bh=a1kfPpJq66cIRuPPS2PCF/nCcT6BOh0aZ6zmeVoK6ZE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=g3by7SBfxsIJ8fVE50yLotaUTEN1YN3Cn6FPNAdGL6S5vXPfLlftdJ2fSxKmrnEE3 tIpvgG8D8Mi1BSIRvTBevPlSJzC0C21D3ALzTQ444mphMDG13dEi+cf2DZHMkw6l83 jTDPR6V8EK1s9xQGt8E+fh05cZ8Eeb0alNyzBdgQ= From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 05 Nov 2014 16:54:01 -0500 Message-ID: <2235101.VGYhMm2FMR@kitterman-optiplex-9020m> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TUQTmEgUdNwsuczRcOMMpgdx-MU Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 21:53:36 -0000 On Wednesday, November 05, 2014 06:35:32 PM Terry Zink wrote: > > Since SPF authorizes an often _shared_ outbound IP address, it has been > > accurately described as an authorization method. DMaRC permits a DKIM > > signature to be spoofed and still allow a message to be accepted solely > > on the basis of SPF. What magic turns authorization into > > authentication??? > > This is a good point and I can share some of our own experiences in > Microsoft's Office 365. > > We have a hosted service. Companies/users can either have hosted email > accounts wherein they login to the portal and send/receive email, or > connect to it via IMAP/POP3. The second option is an on-premise environment > wherein their email passes through us and we relay it to their on-premise > machines. They can send outbound email through us by connecting to the > service by specifying their outbound IP in a "Connector". > > We ask customers to add our service's SPF record to their own SPF records. > When they send outbound email through us, it will authenticate at the > destination. However, if Customer A ever spoofs Customer B, it will also > authenticate via SPF. This is a very real problem. > > So how are we fixing it? > > First, hosted email accounts cannot spoof another customer. If you login to > the portal, or connect via IMAP/POP3, you can't specify your MAIL FROM > domain. You have to set it up in the portal and put a key into your TXT > record. That's not changeable. > > Second, for on-premise machines, they *can* spoof another customer. If they > connect over their IP, if the domain they connect with is not provisioned > with them, it is attributed to a "safe tenant" (a misnomer in my opinion). > It is here that they could spoof someone else. To get around this, we will > check DMARC on outbound mail before we relay it out. If a domain fails > DMARC when it connects to us, and it is an outbound email intended for the > rest of the Internet, we will reject the message so it cannot be sent out > to an unsuspecting third party that might pass SPF since it came from our > service's outbound IPs. > > This is not a perfect solution, but it does close a gap. The existing DMARC > specification lets us do this without making any changes to it. If all your customers add your SPF to theirs, then if they forge each other's mail, it'll pass DMARC. BTW, this has long been cited in the security considerations for the SPF RFCs (RFC 4408, 10.4 and RFC 7208 11.1). I don't think you're fixing it at all, at least not as described. Scott K From nobody Wed Nov 5 15:27:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF0F1A01F2 for ; Wed, 5 Nov 2014 15:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEy-_if5bUWc for ; Wed, 5 Nov 2014 15:27:19 -0800 (PST) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2on0023.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDFD1A01D5 for ; Wed, 5 Nov 2014 15:27:18 -0800 (PST) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.26.3; Wed, 5 Nov 2014 23:26:56 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.10.136]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.10.136]) with mapi id 15.01.0026.003; Wed, 5 Nov 2014 23:26:56 +0000 From: Terry Zink To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] draft-kucherawy-dmarc-base Thread-Index: AQHP9WTMtPWp+p5pM06rxT1gQIhQHZxLfGkAgAPbdYCAAJcQgIACcLAAgAABw5CAADnZgIAAFzOg Date: Wed, 5 Nov 2014 23:26:55 +0000 Message-ID: References: <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> <2235101.VGYhMm2FMR@kitterman-optiplex-9020m> In-Reply-To: <2235101.VGYhMm2FMR@kitterman-optiplex-9020m> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.159.103] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; authentication-results: kitterman.com; dkim=none (message not signed) header.d=none;kitterman.com; dmarc=none action=none header.from=exchange.microsoft.com; x-dmarcaction: None x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(13464003)(189002)(24454002)(377454003)(199003)(33656002)(120916001)(77096003)(64706001)(97736003)(230783001)(19580405001)(76176999)(50986999)(54356999)(19580395003)(99396003)(62966003)(46102003)(77156002)(2501002)(20776003)(107886001)(54206007)(66066001)(54606007)(106356001)(106116001)(93886004)(21056001)(31966008)(4396001)(87936001)(2656002)(105586002)(107046002)(101416001)(92566001)(92726001)(15975445006); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/irEaVO9QFYzDfZQXev1fNyiZs-c Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 23:27:21 -0000 > If all your customers add your SPF to theirs, then if they forge each oth= er's=20 > mail, it'll pass DMARC. I don't think you're fixing it at all, at least n= ot as=20 > described. For hosted customers, they cannot forge each others' email. So that part is= fine. For on-premise customers (whose mail servers connect to us and then we rela= y it out to the Internet), suppose that Customer1.com publishes a DMARC rec= ord of p=3Dreject, and an SPF record of "v=3Dspf1 ip4:1.2.3.4 include:offic= e365_IPs.com". They similarly connect to us over the IP 1.2.3.4 in order to= relay outbound email. Customer2.com publishes an SPF record of "v=3Dspf1 i= p4:5.6.7.8 include:office365_IPs.com" and connects to our service through t= he IP 5.6.7.8. Customer2.com then sends email as Customer1.com from the IP 5.6.7.8. When o= ur mail server scans it, it will see that the mail comes from customer1.com= , but from the IP 5.6.7.8. Since 5.6.7.8 is not in Customer1.com's SPF reco= rd, it will fail SPF. This forged message will also not have a DKIM signatu= re. Because it doesn't pass SPF or DKIM, and publishes a DMARC record, it f= ails DMARC. Because this message fails DMARC, and because customer1.com (who was spoofe= d) publishes a DMARC record of p=3Dreject, Office 365 will reject the messa= ge and not relay it outbound to the rest of the Internet. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Scott Kitterman Sent: Wednesday, November 5, 2014 1:54 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base On Wednesday, November 05, 2014 06:35:32 PM Terry Zink wrote: > > Since SPF authorizes an often _shared_ outbound IP address, it has been > > accurately described as an authorization method. DMaRC permits a DKIM > > signature to be spoofed and still allow a message to be accepted solely > > on the basis of SPF. What magic turns authorization into > > authentication??? >=20 > This is a good point and I can share some of our own experiences in > Microsoft's Office 365. >=20 > We have a hosted service. Companies/users can either have hosted email > accounts wherein they login to the portal and send/receive email, or > connect to it via IMAP/POP3. The second option is an on-premise environme= nt > wherein their email passes through us and we relay it to their on-premise > machines. They can send outbound email through us by connecting to the > service by specifying their outbound IP in a "Connector". >=20 > We ask customers to add our service's SPF record to their own SPF records= . > When they send outbound email through us, it will authenticate at the > destination. However, if Customer A ever spoofs Customer B, it will also > authenticate via SPF. This is a very real problem. >=20 > So how are we fixing it? >=20 > First, hosted email accounts cannot spoof another customer. If you login = to > the portal, or connect via IMAP/POP3, you can't specify your MAIL FROM > domain. You have to set it up in the portal and put a key into your TXT > record. That's not changeable. >=20 > Second, for on-premise machines, they *can* spoof another customer. If th= ey > connect over their IP, if the domain they connect with is not provisioned > with them, it is attributed to a "safe tenant" (a misnomer in my opinion)= . > It is here that they could spoof someone else. To get around this, we wil= l > check DMARC on outbound mail before we relay it out. If a domain fails > DMARC when it connects to us, and it is an outbound email intended for th= e > rest of the Internet, we will reject the message so it cannot be sent out > to an unsuspecting third party that might pass SPF since it came from our > service's outbound IPs. >=20 > This is not a perfect solution, but it does close a gap. The existing DMA= RC > specification lets us do this without making any changes to it. If all your customers add your SPF to theirs, then if they forge each other= 's=20 mail, it'll pass DMARC. BTW, this has long been cited in the security=20 considerations for the SPF RFCs (RFC 4408, 10.4 and RFC 7208 11.1). I don't think you're fixing it at all, at least not as described. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Nov 6 00:27:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06BA1A1A34 for ; Thu, 6 Nov 2014 00:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFJVe9a-xcTf for ; Thu, 6 Nov 2014 00:27:43 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDDF1A1A12 for ; Thu, 6 Nov 2014 00:27:43 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2144F1C3B57; Thu, 6 Nov 2014 17:27:42 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1570F1A27CF; Thu, 6 Nov 2014 17:27:42 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> References: <87r3xn1e3h.fsf@uwakimon.sk.tsukuba.ac.jp> <92E77FDE-4477-491F-9066-7AAFF1E7B390@gmail.com> <87oasnzhce.fsf@uwakimon.sk.tsukuba.ac.jp> <4EB1DF04-1CE8-4C71-A64F-C25BEE474BFE@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 06 Nov 2014 17:27:41 +0900 Message-ID: <874muczqbm.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TjPQfK3ITPHntUxwEYx2SZDKCfM Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 08:27:45 -0000 Douglas Otis writes: > Since SPF authorizes an often _shared_ outbound IP address, Not on my host, not ever -- I only have one IP address, and it *is* mine (at least until my employer takes it away from me, but I trust them to tell me if and when they do). What's your problem with that? > been accurately described as an authorization method. Well, no -- obviously if X authorizes Y, it's an authorization method. Circularity rules -- at least if you want to avoid the real question. Here you're describing a practice (ie, use with a shared address), not the protocol definition. If doug.example.com and steve.example.com are separate (virtual) Author Domains sharing a single IP address, who's doing that SPF authorization and since when is that a good idea, may I ask? If you want to deprecate SPF because it is frequently misused in such a way that *no* security verbs can properly be used to describe what it does, fine, deprecate it. But don't deprecate it by saying "existing practice is broken and doesn't authenticate what I think it should authenticate so I don't want you ever to say the protocol authenticates anything". That's not useful because I may disagree with you about what I need authenticated. > Describing authorization as authentication has been an exaggeration > that started with SenderID. Large attack surfaces provided by > often overly broad SPF is increasingly being exploited by botnets. You wrote that already, I read it and I understand it. What I *don't* understand is your definitions of "identification", "verification", "authorization" and "authentication" as applied to these protocols. > > AFAICS authenticating that particular authorization is precisely > > what DMARC claims to do, although the I-D uses different words to > > say that. > > Authenticating an Authorization? Does that then make an > Authorization authentication? No. Read what I wrote, I wrote what I meant, and I didn't write "an authorization is an authentication" because that's not what I meant. > draft-kucherawy-dmarc-base is not ready, as its definitions remain > seriously flawed. So far you have provided no evidence of incorrect definition. You have claimed that the draft's usage of security verbs is incorrect, but as far as I can tell they basically conform to RFC 4949. From nobody Thu Nov 6 15:07:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765861A0047 for ; Thu, 6 Nov 2014 15:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QErSUeA6OpIw for ; Thu, 6 Nov 2014 15:07:34 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BA21A0056 for ; Thu, 6 Nov 2014 15:07:24 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id a1so2393428wgh.6 for ; Thu, 06 Nov 2014 15:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brettmcdowell.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9AfMdyk5AEX/Rt9pZGI1zmatXoCUaK1hUJcFvdShqeA=; b=Y+2DHxPs052LvLA1JXMoj5fIQsGgs79BUWxtOVx2clPZtngy7l+lXdAxKqkBNPnkQR LBLD4FyU9+BgaauSYWtjAPnTpBAZvl3MOWLWkfpSrjxUetWBauYRiRSdT8cKswkScn6e fCeeYLpYu92KRh8JQE4NfnN574WnBcEBLceTY= 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:content-type; bh=9AfMdyk5AEX/Rt9pZGI1zmatXoCUaK1hUJcFvdShqeA=; b=LMFhuGeCkY6Gmoletn/h5KHocSXK8M35UxBI74m5Qk0q+EvQIYYTVKkg1g77vZoIZs m97wb5ESiNstgFyYG1HLAo3wOc45SROsQDs1uiuj4RERMOVcj3HfoZjpEeFhbi7XoROl FWDUBZIaSuT+H6SCOeplTMKsJ5u/OaK1XIU9s9eZEbWNB1p4v63SLxYvlNDNFYKxml05 9LBiSjqr4AYhr9vxMERcztgPEOty4FMyOWYFNxiIjWjqbKxgoyZdlXkyt4k+Wy1yYLR6 oLE5t5pQShuqz1eHkFjC3qR0K1gxO408VXoqXYIt12H21VevURu2eX+Th8JRGR3n+g4p YAng== X-Gm-Message-State: ALoCoQmR5JbEG/mjPsuyls7+KSBEuqS8xNMDuX1lpTwPu3UB7VV5nXh1mnu/RL9BuCfES0A8AP6+ X-Received: by 10.194.81.70 with SMTP id y6mr9833865wjx.113.1415315242796; Thu, 06 Nov 2014 15:07:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.175.233 with HTTP; Thu, 6 Nov 2014 15:06:42 -0800 (PST) In-Reply-To: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> From: Brett McDowell Date: Thu, 6 Nov 2014 18:06:42 -0500 Message-ID: To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=047d7bf0ca4a4adcc4050738c2b9 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XBVSlktJ0llK9WvhlqVSzR5wqkM Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 23:07:37 -0000 --047d7bf0ca4a4adcc4050738c2b9 Content-Type: text/plain; charset=UTF-8 I also support the -06 changes as you have explained them Murray. Add me to the list of people speaking in opposition to the proposal what would change "authentication" to "authorization". Brett McDowell | brett@brettmcdowell.com | @brettmcdowell | +1 (413) 404-5593 On Tue, Nov 4, 2014 at 9:05 PM, Stephen J. Turnbull wrote: > Murray S. Kucherawy writes: > > > I have only two changes pending for an -06 based on the feedback I've > > received and an observation of my own, namely: > > > > 1) Several editorial changes that don't alter the meaning of the > technical > > work at all; and > > I'm happy with the editorial state of the document, including the > state of the changes to -05 I've proposed off-list as accepted or > rejected by the editors. > > > 2) A change to the IANA Considerations that reduces the requirements on > the > > new registries from IETF Review to Specification Required (see > > RFC5226). > > I agree with this change for the reasons you gave. > > I believe the document is ready for publication. > > > The justification for (1) is pretty straightforward in that they are of > > little consequence overall. > > > > The justification for (2) is largely procedural: I believe an > independent > > submission, not being a product of the IETF, shouldn't create such a > burden > > on the IETF; furthermore, there's really no reason for such stringent > > review of extensions that don't seem likely to appear anyway. The > original > > choice was made way back when we planned to do this document on the > > Standards Track, but that's not how things worked out. > > > > So if anyone feels comfortable making comments on whether or not such an > > -06 would be ready for publication (i.e., -05, which is public, plus the > > above changes), please say so on this list so the ISE can see them. Any > > other feedback is of course welcome. I will post what I have for -06 as > > soon as the embargo lifts on Monday. > > > > I have not as yet included Doug's proposed changes as they don't seem > to be > > supported (there has only been opposition voiced so far), but that does > > mean they were considered. > > > > We would like to put this document to bed as soon as is practical as it > > will be the reference basis for the current and future WG milestones, so > > hopefully reviews will be quick and plentiful. :-) > > > > Thanks, > > -MSK > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7bf0ca4a4adcc4050738c2b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also support the -06 changes as you have explained them = Murray. =C2=A0

Add me to the list of people speaking in = opposition to the proposal what would change "authentication" to = "authorization".

Brett McDowell=C2=A0|=C2=A0brett@brettmcdowell.com=C2=A0| @brettmcdow= ell |=C2=A0= +1= (413) 404-5593

On Tue, Nov 4, 2014 at 9:05 PM, Stephen J. T= urnbull <stephen@xemacs.org> wrote:
Murray S. Kucherawy writes:

=C2=A0> I have only two changes pending for an -06 based on the feedback= I've
=C2=A0> received and an observation of my own, namely:
=C2=A0>
=C2=A0> 1) Several editorial changes that don't alter the meaning of= the technical
=C2=A0> work at all; and

I'm happy with the editorial state of the document, including th= e
state of the changes to -05 I've proposed off-list as accepted or
rejected by the editors.

=C2=A0> 2) A change to the IANA Considerations that reduces the requirem= ents on the
=C2=A0> new registries from IETF Review to Specification Required (see =C2=A0> RFC5226).

I agree with this change for the reasons you gave.

I believe the document is ready for publication.

=C2=A0> The justification for (1) is pretty straightforward in that they= are of
=C2=A0> little consequence overall.
=C2=A0>
=C2=A0> The justification for (2) is largely procedural: I believe an in= dependent
=C2=A0> submission, not being a product of the IETF, shouldn't creat= e such a burden
=C2=A0> on the IETF; furthermore, there's really no reason for such = stringent
=C2=A0> review of extensions that don't seem likely to appear anyway= .=C2=A0 The original
=C2=A0> choice was made way back when we planned to do this document on = the
=C2=A0> Standards Track, but that's not how things worked out.
=C2=A0>
=C2=A0> So if anyone feels comfortable making comments on whether or not= such an
=C2=A0> -06 would be ready for publication (i.e., -05, which is public, = plus the
=C2=A0> above changes), please say so on this list so the ISE can see th= em.=C2=A0 Any
=C2=A0> other feedback is of course welcome.=C2=A0 I will post what I ha= ve for -06 as
=C2=A0> soon as the embargo lifts on Monday.
=C2=A0>
=C2=A0> I have not as yet included Doug's proposed changes as they d= on't seem to be
=C2=A0> supported (there has only been opposition voiced so far), but th= at does
=C2=A0> mean they were considered.
=C2=A0>
=C2=A0> We would like to put this document to bed as soon as is practica= l as it
=C2=A0> will be the reference basis for the current and future WG milest= ones, so
=C2=A0> hopefully reviews will be quick and plentiful.=C2=A0 :-)
=C2=A0>
=C2=A0> Thanks,
=C2=A0> -MSK
=C2=A0> _______________________________________________
=C2=A0> dmarc mailing list
=C2=A0> dmarc@ietf.org
=C2=A0> https://www.ietf.org/mailman/listinfo/dmarc

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

--047d7bf0ca4a4adcc4050738c2b9-- From nobody Thu Nov 6 15:54:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410DD1A0196 for ; Thu, 6 Nov 2014 15:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWNKXc9vnOJV for ; Thu, 6 Nov 2014 15:54:07 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id C3D611A0137 for ; Thu, 6 Nov 2014 15:54:07 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PEMWEP6JDC0059KP@mauve.mrochek.com> for dmarc@ietf.org; Thu, 6 Nov 2014 15:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1415317747; bh=TcN083gc4baVa29LMfbWDo6a50U9iK4sPAg/TaeUQIM=; h=From:Date:Subject:In-reply-to:References:To; b=AYovVTuN23Rl0IUZDTwYS9jMKeCxvH9t4r3txmNr6739xctNtz0s7BFmhTb2uP0xq rmTta1bs6Sg9MrRnBgnCka9/g1ZBgLtc0jPdisFWtdfbas/npP0el7v4blHTfxGTGr vwgq7ryZ3L+qKAz2Qe9T6MzNyooPQY1JZ5rPsOFs= 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 <01PEKZE5Z31C003WE3@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Thu, 06 Nov 2014 15:49:02 -0800 (PST) From: ned+dmarc@mrochek.com Message-id: <01PEMWEN5Q8W003WE3@mauve.mrochek.com> Date: Thu, 06 Nov 2014 11:06:40 -0800 (PST) In-reply-to: "Your message dated Wed, 05 Nov 2014 11:05:16 +0900" <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Murray S. Kucherawy" , "dmarc@ietf.org" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cdz1oV4MApQJklQRC3NmP84Jklg Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 23:54:09 -0000 I have a few comments on the base specification. In the step 7 in section 3.1.3, I think it would be helpful to add a sentence about the determination of the organizational domain from the author domain. Step 7 is also pretty large; you might want to consider breaking it up into substeps or something along those lines. Another problem with step 7 is the statement "small number of further DNS queries to the Organizational Domain" is incorrect. Per step 1 in section 5.6.3, the author domain is queried first, then the organizational domain if that fails to produce a viable result. This needs to be fixed, and adding a reference to section 5.6.3 would be a good idea. In section 3.1.4, the paragraph It is important to note that identifier alignment cannot occur with a message that is not valid per [MAIL], particularly one with a malformed or absent RFC5322.From field. Handling of such cases is left to the discretion of the Mail Receiver. doesn't really make sense to me. If the From: field is missing or is so malformed that a domain cannot be extracted from it, it isn't a question of alignment to other fields, but rather that there's no way to determine a DMARC policy that applies to the message to begin with. Shouldn't that be the primary reason invalid mail is problematic? Am I missing something here? I'm not sure the use of a cousin domain in the example given in paragraph 5 of section 3.1.4.1 is a good idea. The point of using a cousin domain in an attack is that users will confuse/conflate that domain with a legitimate domain. (And this is important in the context of this document because DMARC doesn't do anything to prevent this attack in a From: field.) But the reason identifier alignment is important isn't that the use of a cousin domain in a DKIM signature, MAIL FROM, or EHLO/HELO field could cause problems, it's that without alignment a bad actor could freely use any domain whatsoever in these places. Users generally don't see these fields so why bother using a similar name? The way the section is written makes it sound like protecting against the use of cousin domains in particular is important. Unless I'm missing something, that's not the case. There's a bit of tension between section 5.5, which says that all you need to do to "implement the DMARC mechanism" is publish DMARC records in the DNS, and the diagram and list in section 3.1.3, which make it sound like deploying both DKIM and SPF are a required part of DMARC setup and operation. I'm not sure what, if anything, should be done about this, but I thought it worth noting. There's a big problem in section 5.6.1, where it says that any message with more than one address or an empty group in an RFC5322.From field SHOULD be rejected. I have to say I find this recommendation to be completely inappropriate. Surely it should be possible for me to a legitimate, syntactically valid message that happens to employ the multiple-from/sender format defined in RFC 5322 with all the domains under my personal control and none publish any sort of DMARC policy, and not have the application of DMARC to the overall message flow mess it up? Or alternately, one where the From: field contains an empty group, something we actually recently went to the trouble of writing RFC 6854 to allow? Sure, some clients may barf on such things, but that's a problem for whoever opts to use the mechanisms, not DMARC. I have no absolutely problem with rejecting messages with From: fields containing any sort of domain identifier that has any sort of attached DMARC policy because of how that From: field is constructed. But intruding on legitate uses of email that choose not to employ DMARC in any capacity goes much too far. And it isn't helped by the fact that the DMARC reporting mechanisms are meaningless when there's no domain owner to report these rejections to. There's also a direct contradiction between the third bullet item in section 5.6.1, which says that a message without a From: field SHOULD be rejected, and the fourth paragraph of section 3.1.4, which leaves this same case to the discretion of the mail receiver. Furthermore, does it really make sense to give malformed From: fields a pass - someomthing which could easily contain an identifier that has an attached DMARC policy - and require rejection of completely legitimate stuff with no DMARC policy in sight? I could have missed it, but I don't see any place where the semantics of how DKIM and SPF are combined (as an it's an OR) is specified prior to item 5 in section 5.6.2. If this is indeed the case, then this is bad: The way the mechanisms are combined needs to be made clear much sooner. I note in passing that we've already had a case on this list where someone misunderstood this detail. Section 6.2.2.1 states: In the case of a "mailto" URI, the Mail Receiver MUST communicate reports using the method described in [STARTTLS] whenever it is offered by a Report Receiver. I seriously question the value or appropriateness of this paragraph. So your DMARC agent, assuming it actually goes through a SUBMIT server and not through an internal API, uses STARTTLS to secure that connection. Now what? At present there's no standardized way to indicate in a message that it has to be transported securely. So if you really want that, that leaves configuration - a configuration that spans an essentially arbitrary set of transport agents, to enforce this. At least part of which would have to be enforced by the target of the mailto: to have any chance of being effective. It's poor practice to have MUSTs in specifications that we know are going to be ignored. It's also poor practice to have MUSTs that don't actually accomplish much of anything as written. As such, I strongly recommend dumping this, or at least making it a SHOULD. BTW, I took a glance at the source for opendmarc-reports. I don't see any place where it even tries to use STARTTLS, let alone requires it when talking to something other than the local host, which is supported via command line parameters. Section 9.3 recommends using reply codes during the SMTP session rather than doing anything that would require sending a DSN later, but doesn't come out and say that the reason for doing this is to avoid blowback spam. I think it would be clearer to be explicit about why these policies are a good idea. That's it! Ned From nobody Thu Nov 6 18:12:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55761A0010 for ; Thu, 6 Nov 2014 18:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de1SvU8yzvw9 for ; Thu, 6 Nov 2014 18:12:41 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE3D1ACE69 for ; Thu, 6 Nov 2014 18:12:41 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id n3so3246002wiv.6 for ; Thu, 06 Nov 2014 18:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OwgFrrn7Qsz25F3GjYhFk8fMOq9ab0XXe3RS4osUc+A=; b=abnFbk9PPznq/VhnXs8FqIhHQojkC/HQQ2aWlGo18gp+w/UrSD4JXQ7aOXnOnT3ve7 Ov4z/xVZPp2l/m9yEXlQTf61i5qJbMB0/Nn3axPEhhY5xn8rksRWPO9vVs55M/tXS/el M9ezRsCM3V5ZLUzAjSVd/RpqwCKdpz5GIPuywjrNZT8cJcKlXj6jWzumzlclzPHqsVAa wFSZ2DtC5xcs4cbL7uHJglUsDuqFsY9JYwDAg2U2nCZ5m6m4MSVz/pre9+hTkSpO/eoK DpwLd7Qd5miK1oyW9uIoUNwFXpzsjbOvVgThxQtgoYLVRQ0UhktGJuQan0Qi0ewHWfQE 1uDA== MIME-Version: 1.0 X-Received: by 10.194.157.137 with SMTP id wm9mr11484625wjb.5.1415326360154; Thu, 06 Nov 2014 18:12:40 -0800 (PST) Received: by 10.27.76.134 with HTTP; Thu, 6 Nov 2014 18:12:40 -0800 (PST) In-Reply-To: <01PEMWEN5Q8W003WE3@mauve.mrochek.com> References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> Date: Thu, 6 Nov 2014 18:12:40 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=089e013c6b68f039e105073b58f0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wX_psY3uiu5AVjyoXDrAkLOGtps Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 02:12:45 -0000 --089e013c6b68f039e105073b58f0 Content-Type: text/plain; charset=UTF-8 Thanks, this gives me something to do on the plane ride on Saturday. On Thu, Nov 6, 2014 at 11:06 AM, Ned Freed wrote: > > > I have a few comments on the base specification. > > In the step 7 in section 3.1.3, I think it would be helpful to add a > sentence > about the determination of the organizational domain from the author > domain. > Step 7 is also pretty large; you might want to consider breaking it up into > substeps or something along those lines. > > Another problem with step 7 is the statement "small number of further DNS > queries to the Organizational Domain" is incorrect. Per step 1 in section > 5.6.3, the author domain is queried first, then the organizational domain > if > that fails to produce a viable result. This needs to be fixed, and adding a > reference to section 5.6.3 would be a good idea. > > In section 3.1.4, the paragraph > > It is important to note that identifier alignment cannot occur with a > message that is not valid per [MAIL], particularly one with a > malformed or absent RFC5322.From field. Handling of such cases is > left to the discretion of the Mail Receiver. > > doesn't really make sense to me. If the From: field is missing or is so > malformed that a domain cannot be extracted from it, it isn't a question of > alignment to other fields, but rather that there's no way to determine a > DMARC > policy that applies to the message to begin with. Shouldn't that be the > primary > reason invalid mail is problematic? Am I missing something here? > > I'm not sure the use of a cousin domain in the example given in paragraph > 5 of > section 3.1.4.1 is a good idea. The point of using a cousin domain in an > attack > is that users will confuse/conflate that domain with a legitimate domain. > (And > this is important in the context of this document because DMARC doesn't do > anything to prevent this attack in a From: field.) But the reason > identifier > alignment is important isn't that the use of a cousin domain in a DKIM > signature, MAIL FROM, or EHLO/HELO field could cause problems, it's that > without alignment a bad actor could freely use any domain whatsoever in > these > places. Users generally don't see these fields so why bother using a > similar > name? The way the section is written makes it sound like protecting > against the > use of cousin domains in particular is important. Unless I'm missing > something, > that's not the case. > > There's a bit of tension between section 5.5, which says that all you need > to > do to "implement the DMARC mechanism" is publish DMARC records in the DNS, > and > the diagram and list in section 3.1.3, which make it sound like deploying > both > DKIM and SPF are a required part of DMARC setup and operation. I'm not sure > what, if anything, should be done about this, but I thought it worth > noting. > > There's a big problem in section 5.6.1, where it says that any message with > more than one address or an empty group in an RFC5322.From field SHOULD be > rejected. > > I have to say I find this recommendation to be completely inappropriate. > Surely > it should be possible for me to a legitimate, syntactically valid message > that > happens to employ the multiple-from/sender format defined in RFC 5322 with > all > the domains under my personal control and none publish any sort of DMARC > policy, and not have the application of DMARC to the overall message flow > mess > it up? Or alternately, one where the From: field contains an empty group, > something we actually recently went to the trouble of writing RFC 6854 to > allow? > > Sure, some clients may barf on such things, but that's a problem for > whoever > opts to use the mechanisms, not DMARC. > > I have no absolutely problem with rejecting messages with From: fields > containing any sort of domain identifier that has any sort of attached > DMARC > policy because of how that From: field is constructed. But intruding on > legitate uses of email that choose not to employ DMARC in any capacity goes > much too far. And it isn't helped by the fact that the DMARC reporting > mechanisms are meaningless when there's no domain owner to report these > rejections to. > > There's also a direct contradiction between the third bullet item in > section > 5.6.1, which says that a message without a From: field SHOULD be rejected, > and > the fourth paragraph of section 3.1.4, which leaves this same case to the > discretion of the mail receiver. Furthermore, does it really make sense to > give > malformed From: fields a pass - someomthing which could easily contain an > identifier that has an attached DMARC policy - and require rejection of > completely legitimate stuff with no DMARC policy in sight? > > I could have missed it, but I don't see any place where the semantics of > how > DKIM and SPF are combined (as an it's an OR) is specified prior to item 5 > in > section 5.6.2. If this is indeed the case, then this is bad: The way the > mechanisms are combined needs to be made clear much sooner. I note in > passing > that we've already had a case on this list where someone misunderstood this > detail. > > Section 6.2.2.1 states: > > In the case of a "mailto" URI, the Mail Receiver MUST communicate > reports using the method described in [STARTTLS] whenever it is > offered by a Report Receiver. > > I seriously question the value or appropriateness of this paragraph. So > your > DMARC agent, assuming it actually goes through a SUBMIT server and not > through > an internal API, uses STARTTLS to secure that connection. Now what? At > present > there's no standardized way to indicate in a message that it has to be > transported securely. So if you really want that, that leaves > configuration - a > configuration that spans an essentially arbitrary set of transport agents, > to > enforce this. At least part of which would have to be enforced by the > target of > the mailto: to have any chance of being effective. > > It's poor practice to have MUSTs in specifications that we know are going > to be > ignored. It's also poor practice to have MUSTs that don't actually > accomplish > much of anything as written. As such, I strongly recommend dumping this, > or at > least making it a SHOULD. > > BTW, I took a glance at the source for opendmarc-reports. I don't see any > place > where it even tries to use STARTTLS, let alone requires it when talking to > something other than the local host, which is supported via command line > parameters. > > Section 9.3 recommends using reply codes during the SMTP session rather > than > doing anything that would require sending a DSN later, but doesn't come > out and > say that the reason for doing this is to avoid blowback spam. I think it > would > be clearer to be explicit about why these policies are a good idea. > > That's it! > > Ned > --089e013c6b68f039e105073b58f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, this gives me something to do on the plane ride on= Saturday.

On Thu, Nov 6, 2014 at 11:06 AM, Ned Freed <ned.freed@mrochek.com> wrote:
<chair hat off>= ;

I have a few comments on the base specification.

In the step 7 in section 3.1.3, I think it would be helpful to add a senten= ce
about the determination of the organizational domain from the author domain= .
Step 7 is also pretty large; you might want to consider breaking it up into=
substeps or something along those lines.

Another problem with step 7 is the statement "small number of further = DNS
queries to the Organizational Domain" is incorrect. Per step 1 in sect= ion
5.6.3, the author domain is queried first, then the organizational domain i= f
that fails to produce a viable result. This needs to be fixed, and adding a=
reference to section 5.6.3 would be a good idea.

In section 3.1.4, the paragraph

=C2=A0 =C2=A0It is important to note that identifier alignment cannot occur= with a
=C2=A0 =C2=A0message that is not valid per [MAIL], particularly one with a<= br> =C2=A0 =C2=A0malformed or absent RFC5322.From field.=C2=A0 Handling of such= cases is
=C2=A0 =C2=A0left to the discretion of the Mail Receiver.

doesn't really make sense to me. If the From: field is missing or is so=
malformed that a domain cannot be extracted from it, it isn't a questio= n of
alignment to other fields, but rather that there's no way to determine = a DMARC
policy that applies to the message to begin with. Shouldn't that be the= primary
reason invalid mail is problematic? Am I missing something here?

I'm not sure the use of a cousin domain in the example given in paragra= ph 5 of
section 3.1.4.1 is a good idea. The point of using a cousin domain in an at= tack
is that users will confuse/conflate that domain with a legitimate domain. (= And
this is important in the context of this document because DMARC doesn't= do
anything to prevent this attack in a From: field.) But the reason identifie= r
alignment is important isn't that the use of a cousin domain in a DKIM<= br> signature, MAIL FROM, or EHLO/HELO field could cause problems, it's tha= t
without alignment a bad actor could freely use any domain whatsoever in the= se
places. Users generally don't see these fields so why bother using a si= milar
name? The way the section is written makes it sound like protecting against= the
use of cousin domains in particular is important. Unless I'm missing so= mething,
that's not the case.

There's a bit of tension between section 5.5, which says that all you n= eed to
do to "implement the DMARC mechanism" is publish DMARC records in= the DNS, and
the diagram and list in section 3.1.3, which make it sound like deploying b= oth
DKIM and SPF are a required part of DMARC setup and operation. I'm not = sure
what, if anything, should be done about this, but I thought it worth noting= .

There's a big problem in section 5.6.1, where it says that any message = with
more than one address or an empty group in an RFC5322.From field SHOULD be<= br> rejected.

I have to say I find this recommendation to be completely inappropriate. Su= rely
it should be possible for me to a legitimate, syntactically valid message t= hat
happens to employ the multiple-from/sender format defined in RFC 5322 with = all
the domains under my personal control and none publish any sort of DMARC policy, and not have the application of DMARC to the overall message flow m= ess
it up? Or alternately, one where the From: field contains an empty group, something we actually recently went to the trouble of writing RFC 6854 to allow?

Sure, some clients may barf on such things, but that's a problem for wh= oever
opts to use the mechanisms, not DMARC.

I have no absolutely problem with rejecting messages with From: fields
containing any sort of domain identifier that has any sort of attached DMAR= C
policy because of how that From: field is constructed. But intruding on
legitate uses of email that choose not to employ DMARC in any capacity goes=
much too far. And it isn't helped by the fact that the DMARC reporting<= br> mechanisms are meaningless when there's no domain owner to report these=
rejections to.

There's also a direct contradiction between the third bullet item in se= ction
5.6.1, which says that a message without a From: field SHOULD be rejected, = and
the fourth paragraph of section 3.1.4, which leaves this same case to the discretion of the mail receiver. Furthermore, does it really make sense to = give
malformed From: fields a pass - someomthing which could easily contain an identifier that has an attached DMARC policy - and require rejection of
completely legitimate stuff with no DMARC policy in sight?

I could have missed it, but I don't see any place where the semantics o= f how
DKIM and SPF are combined (as an it's an OR) is specified prior to item= 5 in
section 5.6.2. If this is indeed the case, then this is bad: The way the mechanisms are combined needs to be made clear much sooner. I note in passi= ng
that we've already had a case on this list where someone misunderstood = this
detail.

Section 6.2.2.1 states:

=C2=A0 =C2=A0In the case of a "mailto" URI, the Mail Receiver MUS= T communicate
=C2=A0 =C2=A0reports using the method described in [STARTTLS] whenever it i= s
=C2=A0 =C2=A0offered by a Report Receiver.

I seriously question the value or appropriateness of this paragraph. So you= r
DMARC agent, assuming it actually goes through a SUBMIT server and not thro= ugh
an internal API, uses STARTTLS to secure that connection. Now what? At pres= ent
there's no standardized way to indicate in a message that it has to be<= br> transported securely. So if you really want that, that leaves configuration= - a
configuration that spans an essentially arbitrary set of transport agents, = to
enforce this. At least part of which would have to be enforced by the targe= t of
the mailto: to have any chance of being effective.

It's poor practice to have MUSTs in specifications that we know are goi= ng to be
ignored. It's also poor practice to have MUSTs that don't actually = accomplish
much of anything as written. As such, I strongly recommend dumping this, or= at
least making it a SHOULD.

BTW, I took a glance at the source for opendmarc-reports. I don't see a= ny place
where it even tries to use STARTTLS, let alone requires it when talking to<= br> something other than the local host, which is supported via command line parameters.

Section 9.3 recommends using reply codes during the SMTP session rather tha= n
doing anything that would require sending a DSN later, but doesn't come= out and
say that the reason for doing this is to avoid blowback spam. I think it wo= uld
be clearer to be explicit about why these policies are a good idea.

That's it!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned

--089e013c6b68f039e105073b58f0-- From nobody Thu Nov 6 23:16:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7481ACF05 for ; Thu, 6 Nov 2014 23:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axJY6xfO6PT9 for ; Thu, 6 Nov 2014 23:16:43 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3B61ACF07 for ; Thu, 6 Nov 2014 23:16:42 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id ex7so3648291wid.4 for ; Thu, 06 Nov 2014 23:16:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=47vdyjNhjKtoHnJ8zD5YDpKQASEFSLenPIL9mJVv+SU=; b=iI9D2RzxOrhBQK8ChtRwYjOfCZZgECQsnZh0vgg6h04eI064nH2IcTi3NPVJo+RIgH pDcfcwbc3i7QxmKhMdpcKs/an2/5c7C7mRvafkQjTvQdECC8fYh0rGvS3Y/07cOqtyi+ mtEawfNj5J6HrFQWr6qSgZe5ZEzGkMeBjgRL/QieO6zuOrSDJVqJc7ifLwKlTKrxSp9v OwwCNyBx5+IytHCxq5YLuqbk4/qKjCiHmQc28VjkdRWXhOpKQE6uiy/zKunIoq8MR0Wp /udrn8X+0+DKuiOQNQ2k+DPfqKZIo/n31kwAcq58iYLEA+T0gOnET6kcG1WybzM6dusb Ajwg== MIME-Version: 1.0 X-Received: by 10.180.91.49 with SMTP id cb17mr2221153wib.30.1415344601640; Thu, 06 Nov 2014 23:16:41 -0800 (PST) Received: by 10.27.76.134 with HTTP; Thu, 6 Nov 2014 23:16:41 -0800 (PST) In-Reply-To: <01PEMWEN5Q8W003WE3@mauve.mrochek.com> References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> Date: Thu, 6 Nov 2014 23:16:41 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d043c7b2a3737ab05073f987f Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nyKK1IdOs81UbHZ7RkDCKcA9mjs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 07:16:46 -0000 --f46d043c7b2a3737ab05073f987f Content-Type: text/plain; charset=UTF-8 On Thu, Nov 6, 2014 at 11:06 AM, Ned Freed wrote: > In the step 7 in section 3.1.3, I think it would be helpful to add a > sentence > about the determination of the organizational domain from the author > domain. > Step 7 is also pretty large; you might want to consider breaking it up into > substeps or something along those lines. > OK. > Another problem with step 7 is the statement "small number of further DNS > queries to the Organizational Domain" is incorrect. Per step 1 in section > 5.6.3, the author domain is queried first, then the organizational domain > if > that fails to produce a viable result. This needs to be fixed, and adding a > reference to section 5.6.3 would be a good idea. > "small number" is "at most two", and "to the Organizational Domain" is meant to include its subdomains, so I guess what's meant is to the Organizational Domain's zone, or something like that. I'll tidy it up. Good suggestion on a forward reference. In section 3.1.4, the paragraph > > It is important to note that identifier alignment cannot occur with a > message that is not valid per [MAIL], particularly one with a > malformed or absent RFC5322.From field. Handling of such cases is > left to the discretion of the Mail Receiver. > > doesn't really make sense to me. If the From: field is missing or is so > malformed that a domain cannot be extracted from it, it isn't a question of > alignment to other fields, but rather that there's no way to determine a > DMARC > policy that applies to the message to begin with. Shouldn't that be the > primary > reason invalid mail is problematic? Am I missing something here? > No, I think you've got it, but I'm not clear on how the paragraph you cited doesn't say that. You have it exactly right: If From: is missing or so mangled that it's not possible to get a domain out, then there's nothing to which DKIM and SPF can align, and DMARC can't be applied. There might be other mangling though, like multiple From: fields that are properly formed but contain distinct values, in which case we don't know to which one to apply alignment. I'm not sure the use of a cousin domain in the example given in paragraph 5 > of > section 3.1.4.1 is a good idea. The point of using a cousin domain in an > attack > is that users will confuse/conflate that domain with a legitimate domain. > (And > this is important in the context of this document because DMARC doesn't do > anything to prevent this attack in a From: field.) But the reason > identifier > alignment is important isn't that the use of a cousin domain in a DKIM > signature, MAIL FROM, or EHLO/HELO field could cause problems, it's that > without alignment a bad actor could freely use any domain whatsoever in > these > places. Users generally don't see these fields so why bother using a > similar > name? The way the section is written makes it sound like protecting > against the > use of cousin domains in particular is important. Unless I'm missing > something, > that's not the case. > I agree. That paragraph should go. > There's a bit of tension between section 5.5, which says that all you need > to > do to "implement the DMARC mechanism" is publish DMARC records in the DNS, > and > the diagram and list in section 3.1.3, which make it sound like deploying > both > DKIM and SPF are a required part of DMARC setup and operation. I'm not sure > what, if anything, should be done about this, but I thought it worth > noting. > I'll see if I can tidy it up. > There's a big problem in section 5.6.1, where it says that any message with > more than one address or an empty group in an RFC5322.From field SHOULD be > rejected. > > I have to say I find this recommendation to be completely inappropriate. > Surely > it should be possible for me to a legitimate, syntactically valid message > that > happens to employ the multiple-from/sender format defined in RFC 5322 with > all > the domains under my personal control and none publish any sort of DMARC > policy, and not have the application of DMARC to the overall message flow > mess > it up? Or alternately, one where the From: field contains an empty group, > something we actually recently went to the trouble of writing RFC 6854 to > allow? > As I recall, there were some surveys of some pretty large email streams, and not a single instance of a From: field containing other than a single mailbox could be found that wasn't also part of something either spammy or some kind of attempt to confound spam filters, or just grossly malformed and unusable. This led the original DMARC community to what you see there now. There was no deliberate rejection of the RFC 6854 format, but just rather no observed valid use of it. Sure, some clients may barf on such things, but that's a problem for whoever > opts to use the mechanisms, not DMARC. > > I have no absolutely problem with rejecting messages with From: fields > containing any sort of domain identifier that has any sort of attached > DMARC > policy because of how that From: field is constructed. But intruding on > legitate uses of email that choose not to employ DMARC in any capacity goes > much too far. And it isn't helped by the fact that the DMARC reporting > mechanisms are meaningless when there's no domain owner to report these > rejections to. > What sort of remedy would you suggest here? Off the top of my head, here are some suggestions: 1) Evaluate all the domains you find, and if any of them have published DMARC policies, apply the strictest one (by that I mean: if there are any with p=reject that fail, then reject it; if there are any with p=quarantine, quarantine it); if not, treat the message as if DMARC simply did not apply. 2) Evaluate only the first domain you find, if any. 3) Same as (1), but limit it to some fixed (configurable?) number of domains. There's also a direct contradiction between the third bullet item in section > 5.6.1, which says that a message without a From: field SHOULD be rejected, > and > the fourth paragraph of section 3.1.4, which leaves this same case to the > discretion of the mail receiver. Furthermore, does it really make sense to > give > malformed From: fields a pass - someomthing which could easily contain an > identifier that has an attached DMARC policy - and require rejection of > completely legitimate stuff with no DMARC policy in sight? > We've covered the latter point above, but as to the point about malformation: Can you reliably extract a domain name from a malformed From: field? That seems to be a vector for trying to confuse a DMARC filter if the advice is to try anyway. > I could have missed it, but I don't see any place where the semantics of > how > DKIM and SPF are combined (as an it's an OR) is specified prior to item 5 > in > section 5.6.2. If this is indeed the case, then this is bad: The way the > mechanisms are combined needs to be made clear much sooner. I note in > passing > that we've already had a case on this list where someone misunderstood this > detail. > Section 5, third paragraph, is the first formal statement of this kind. Adding one somewhere up earlier in one of the overview sections would probably be a good idea. > Section 6.2.2.1 states: > > In the case of a "mailto" URI, the Mail Receiver MUST communicate > reports using the method described in [STARTTLS] whenever it is > offered by a Report Receiver. > > I seriously question the value or appropriateness of this paragraph. So > your > DMARC agent, assuming it actually goes through a SUBMIT server and not > through > an internal API, uses STARTTLS to secure that connection. Now what? At > present > there's no standardized way to indicate in a message that it has to be > transported securely. So if you really want that, that leaves > configuration - a > configuration that spans an essentially arbitrary set of transport agents, > to > enforce this. At least part of which would have to be enforced by the > target of > the mailto: to have any chance of being effective. > > It's poor practice to have MUSTs in specifications that we know are going > to be > ignored. It's also poor practice to have MUSTs that don't actually > accomplish > much of anything as written. As such, I strongly recommend dumping this, > or at > least making it a SHOULD. > I'd be fine with making it a SHOULD, exactly because of these reasons. > Section 9.3 recommends using reply codes during the SMTP session rather > than > doing anything that would require sending a DSN later, but doesn't come > out and > say that the reason for doing this is to avoid blowback spam. I think it > would > be clearer to be explicit about why these policies are a good idea. > Sounds good to me. Thanks! -MSK --f46d043c7b2a3737ab05073f987f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 6, 2014 at 11:06 AM, Ned Freed <ned.freed= @mrochek.com> wrote:
In the step 7 in section 3.= 1.3, I think it would be helpful to add a sentence
about the determination of the organizational domain from the author domain= .
Step 7 is also pretty large; you might want to consider breaking it up into=
substeps or something along those lines.

OK.
=C2=A0
Another problem with step 7 is the statement "small number of further = DNS
queries to the Organizational Domain" is incorrect. Per step 1 in sect= ion
5.6.3, the author domain is queried first, then the organizational domain i= f
that fails to produce a viable result. This needs to be fixed, and adding a=
reference to section 5.6.3 would be a good idea.

<= /div>
"small number" is "at most two", and "to= the Organizational Domain" is meant to include its subdomains, so I g= uess what's meant is to the Organizational Domain's zone, or someth= ing like that.=C2=A0 I'll tidy it up.=C2=A0 Good suggestion on a forwar= d reference.

In section 3.1.4, the paragraph

=C2=A0 =C2=A0It is important to note that identifier alignment cannot occur= with a
=C2=A0 =C2=A0message that is not valid per [MAIL], particularly one with a<= br> =C2=A0 =C2=A0malformed or absent RFC5322.From field.=C2=A0 Handling of such= cases is
=C2=A0 =C2=A0left to the discretion of the Mail Receiver.

doesn't really make sense to me. If the From: field is missing or is so=
malformed that a domain cannot be extracted from it, it isn't a questio= n of
alignment to other fields, but rather that there's no way to determine = a DMARC
policy that applies to the message to begin with. Shouldn't that be the= primary
reason invalid mail is problematic? Am I missing something here?

No, I think you've got it, but I'm not cl= ear on how the paragraph you cited doesn't say that.=C2=A0 You have it = exactly right: If From: is missing or so mangled that it's not possible= to get a domain out, then there's nothing to which DKIM and SPF can al= ign, and DMARC can't be applied.=C2=A0 There might be other mangling th= ough, like multiple From: fields that are properly formed but contain disti= nct values, in which case we don't know to which one to apply alignment= .

I'm not sure the use of a cousin domain in the example given in paragra= ph 5 of
section 3.1.4.1 is a good idea. The point of using a cousin domain in an at= tack
is that users will confuse/conflate that domain with a legitimate domain. (= And
this is important in the context of this document because DMARC doesn't= do
anything to prevent this attack in a From: field.) But the reason identifie= r
alignment is important isn't that the use of a cousin domain in a DKIM<= br> signature, MAIL FROM, or EHLO/HELO field could cause problems, it's tha= t
without alignment a bad actor could freely use any domain whatsoever in the= se
places. Users generally don't see these fields so why bother using a si= milar
name? The way the section is written makes it sound like protecting against= the
use of cousin domains in particular is important. Unless I'm missing so= mething,
that's not the case.

I agree.=C2=A0= That paragraph should go.
=C2=A0
There's a big problem in section 5.6.1, where it says that any message = with
more than one address or an empty group in an RFC5322.From field SHOULD be<= br> rejected.

I have to say I find this recommendation to be completely inappropriate. Su= rely
it should be possible for me to a legitimate, syntactically valid message t= hat
happens to employ the multiple-from/sender format defined in RFC 5322 with = all
the domains under my personal control and none publish any sort of DMARC policy, and not have the application of DMARC to the overall message flow m= ess
it up? Or alternately, one where the From: field contains an empty group, something we actually recently went to the trouble of writing RFC 6854 to allow?

As I recall, there were some surveys = of some pretty large email streams, and not a single instance of a From: fi= eld containing other than a single mailbox could be found that wasn't a= lso part of something either spammy or some kind of attempt to confound spa= m filters, or just grossly malformed and unusable.=C2=A0 This led the origi= nal DMARC community to what you see there now.=C2=A0 There was no deliberat= e rejection of the RFC 6854 format, but just rather no observed valid use o= f it.

There's also a direct contradiction between the third bullet item in se= ction
5.6.1, which says that a message without a From: field SHOULD be rejected, = and
the fourth paragraph of section 3.1.4, which leaves this same case to the discretion of the mail receiver. Furthermore, does it really make sense to = give
malformed From: fields a pass - someomthing which could easily contain an identifier that has an attached DMARC policy - and require rejection of
completely legitimate stuff with no DMARC policy in sight?
=

We've covered the latter point above, but as to the= point about malformation: Can you reliably extract a domain name from a ma= lformed From: field?=C2=A0 That seems to be a vector for trying to confuse = a DMARC filter if the advice is to try anyway.
=C2=A0
I could have missed it, but I don't see any place where the semantics o= f how
DKIM and SPF are combined (as an it's an OR) is specified prior to item= 5 in
section 5.6.2. If this is indeed the case, then this is bad: The way the mechanisms are combined needs to be made clear much sooner. I note in passi= ng
that we've already had a case on this list where someone misunderstood = this
detail.

Section 5, third paragraph, is = the first formal statement of this kind.=C2=A0 Adding one somewhere up earl= ier in one of the overview sections would probably be a good idea.
=C2= =A0
Section 6.2.2.1 states:

=C2=A0 =C2=A0In the case of a "mailto" URI, the Mail Receiver MUS= T communicate
=C2=A0 =C2=A0reports using the method described in [STARTTLS] whenever it i= s
=C2=A0 =C2=A0offered by a Report Receiver.

I seriously question the value or appropriateness of this paragraph. So you= r
DMARC agent, assuming it actually goes through a SUBMIT server and not thro= ugh
an internal API, uses STARTTLS to secure that connection. Now what? At pres= ent
there's no standardized way to indicate in a message that it has to be<= br> transported securely. So if you really want that, that leaves configuration= - a
configuration that spans an essentially arbitrary set of transport agents, = to
enforce this. At least part of which would have to be enforced by the targe= t of
the mailto: to have any chance of being effective.

It's poor practice to have MUSTs in specifications that we know are goi= ng to be
ignored. It's also poor practice to have MUSTs that don't actually = accomplish
much of anything as written. As such, I strongly recommend dumping this, or= at
least making it a SHOULD.

I'd be fi= ne with making it a SHOULD, exactly because of these reasons.
=C2=A0
=
Section 9.3 recommends using reply codes during the SMTP session rather tha= n
doing anything that would require sending a DSN later, but doesn't come= out and
say that the reason for doing this is to avoid blowback spam. I think it wo= uld
be clearer to be explicit about why these policies are a good idea.

Sounds good to me.

Thanks!

-MSK =
--f46d043c7b2a3737ab05073f987f-- From nobody Thu Nov 6 23:22:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781C41ACF1B for ; Thu, 6 Nov 2014 23:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW1bhNFnyXwn for ; Thu, 6 Nov 2014 23:22:37 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100981ACF14 for ; Thu, 6 Nov 2014 23:22:37 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so2976640wgh.15 for ; Thu, 06 Nov 2014 23:22:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8Zy2orTX5fzPBTbDLT087jm/0Q7DXAW9ACaJ/vMh1dU=; b=dJL/PktC30JrxrQOVXjZvo1pQpx/WywALq8OzfDMxmrMbcche14t0+LgI56lgTdMuL DT4VFsdeiCFFSIP3tMNL2G1JVVauOFGIlB4yLnsb/4APYCPAFQOjcqAFA5/wTF8lwyWi rkalu0Eojj3Y4Ns7IZvbPk8mqgO7zKSJY1vaJGGbBypEk3MKt4NSyzm6gAmEs6y1BGhD 0cPXCeNCjjZpeuJANbQ+4zfh5Vrq37uaj267JagCMNYKLVUSZJf8mdPqTJFR2LvVq0T6 4INzO1HYSVqRcXpI7RJOKlOn3xLzPeiEcMgz+T1pnkRZNnp9bExfZn3TLI58CKoa/G7S +58A== MIME-Version: 1.0 X-Received: by 10.180.9.106 with SMTP id y10mr2288387wia.30.1415344955864; Thu, 06 Nov 2014 23:22:35 -0800 (PST) Received: by 10.27.76.134 with HTTP; Thu, 6 Nov 2014 23:22:35 -0800 (PST) In-Reply-To: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> Date: Thu, 6 Nov 2014 23:22:35 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=001a11c22544543c3f05073fad54 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/u7300-AypO9TSKn5RtOD1oDjj-M Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 07:22:38 -0000 --001a11c22544543c3f05073fad54 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 6, 2014 at 11:16 PM, Murray S. Kucherawy wrote: > I have no absolutely problem with rejecting messages with From: fields > >> containing any sort of domain identifier that has any sort of attached >> DMARC >> policy because of how that From: field is constructed. But intruding on >> legitate uses of email that choose not to employ DMARC in any capacity >> goes >> much too far. And it isn't helped by the fact that the DMARC reporting >> mechanisms are meaningless when there's no domain owner to report these >> rejections to. >> > > What sort of remedy would you suggest here? Off the top of my head, here > are some suggestions: > > 1) Evaluate all the domains you find, and if any of them have published > DMARC policies, apply the strictest one (by that I mean: if there are any > with p=reject that fail, then reject it; if there are any with > p=quarantine, quarantine it); if not, treat the message as if DMARC simply > did not apply. > > 2) Evaluate only the first domain you find, if any. > > 3) Same as (1), but limit it to some fixed (configurable?) number of > domains. > 4) Acknowledge the conflict with RFC 6854, but point out that DMARC participants typically choose to reject them anyway (and drop the MUST). -MSK --001a11c22544543c3f05073fad54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 6, 2014 at 11:16 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
I have no absolutely problem with rejecting messages wi= th From: fields
containing any sort of domain identifier that has any sort of attached DMAR= C
policy because of how that From: field is constructed. But intruding on
legitate uses of email that choose not to employ DMARC in any capacity goes=
much too far. And it isn't helped by the fact that the DMARC reporting<= br> mechanisms are meaningless when there's no domain owner to report these=
rejections to.

What sort of reme= dy would you suggest here?=C2=A0 Off the top of my head, here are some sugg= estions:

1) Evaluate all the domains you find, and if any= of them have published DMARC policies, apply the strictest one (by that I = mean: if there are any with p=3Dreject that fail, then reject it; if there = are any with p=3Dquarantine, quarantine it); if not, treat the message as i= f DMARC simply did not apply.

2) Evaluate only the first = domain you find, if any.

3) Same as (1), but limit it to = some fixed (configurable?) number of domains.

4) Acknowledge the conflict with RFC 6854, b= ut point out that DMARC participants typically choose to reject them anyway= (and drop the MUST).

-MSK
--001a11c22544543c3f05073fad54-- From nobody Fri Nov 7 10:07:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B56C1AD3DE for ; Fri, 7 Nov 2014 10:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRFW5OpSEV6w for ; Fri, 7 Nov 2014 10:07:15 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C391AD3D3 for ; Fri, 7 Nov 2014 10:07:14 -0800 (PST) Received: (qmail 31402 invoked from network); 7 Nov 2014 18:07:13 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 7 Nov 2014 18:07:13 -0000 Date: 7 Nov 2014 18:06:51 -0000 Message-ID: <20141107180651.8446.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dfSjZNX8AkQcuAljyaGdJx28m78 Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 18:07:16 -0000 >What sort of remedy would you suggest here? Off the top of my head, here >are some suggestions: > >1) Evaluate all the domains you find, and if any of them have published >DMARC policies, apply the strictest one ... Given the anti-phishing goals of DMARC, I don't see how anything else makes any sense. Or you could skip a step, say that DMARC doesn't permit multi-address From headers, assume that validation failed on all of the domains and proceed directly to the punishment phase. For From: headers with address-free groups, recall that the motivation for this was EAI downgrades at delivery time. The un-downgraded message had a normal From: header, so normal DMARC applies. If the address is smashed in the downgrade I don't see any reason that the DMARC result needs to change. It also happens to enable an alternative to those do-not-reply@bigbank.com addresses in mail from robots, something I haven't seen yet, but wouldn't be totally silly. I'd say that whatever you do with them is out of scope for DMARC. R's, John From nobody Fri Nov 7 10:32:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C901AD3F3 for ; Fri, 7 Nov 2014 10:32: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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wvtiwxY8Jjv for ; Fri, 7 Nov 2014 10:32:54 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365BB1A88E5 for ; Fri, 7 Nov 2014 10:32:54 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id d1so5403741wiv.3 for ; Fri, 07 Nov 2014 10:32: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:date:message-id:subject:from:to :cc:content-type; bh=KWrfqkZiqy6P5PGknV2ars/ASoZEPG4OQl1FWKBIdWc=; b=cqSyjGrT+lpVNBuNXRIw593Nof9uW+TBYvqTpnn1Tq6wry8X8l8amh5LACtRBOlZOI FFDD7KkqWDO2mWg5OqXS+sNN9JRjIfUi89sV0xDbMeL2ODZce3bkbn/zSTgg29CI6TR5 ZDZ6EbQ2QadJxcjzSZoAJ7+ObGEE4DvYmQTqhAtLIIcPAHOLWeZmOwh+3wxxK4YVWu+m 6wkLMFyEQs2y82q7brn5mctMLMtoitk9ZjwZinfv1LuRLr9IPWgMyd81boo5d+VTXTE0 9WbqRDvWYG2R1r7F8Eu7yEBYqryXeL4jXznO15JWfEncCGgvqecf+yQzh5bZECj7XUuB CXdA== MIME-Version: 1.0 X-Received: by 10.194.143.7 with SMTP id sa7mr19174381wjb.110.1415385172942; Fri, 07 Nov 2014 10:32:52 -0800 (PST) Received: by 10.27.76.134 with HTTP; Fri, 7 Nov 2014 10:32:52 -0800 (PST) In-Reply-To: <20141107180651.8446.qmail@ary.lan> References: <20141107180651.8446.qmail@ary.lan> Date: Fri, 7 Nov 2014 10:32:52 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e0115e73274416f0507490aff Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/eFF2-f-6kX51lVEmbyD-TBll40w Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 18:32:55 -0000 --089e0115e73274416f0507490aff Content-Type: text/plain; charset=UTF-8 On Fri, Nov 7, 2014 at 10:06 AM, John Levine wrote: > >1) Evaluate all the domains you find, and if any of them have published > >DMARC policies, apply the strictest one ... > > Given the anti-phishing goals of DMARC, I don't see how anything else > makes any sense. Or you could skip a step, say that DMARC doesn't > permit multi-address From headers, assume that validation failed on > all of the domains and proceed directly to the punishment phase. > Right, that's also an option, and it at least accommodates the no-address >From field that RFC6854 permits. Another option I can think of is one where we just admit the conflict with RFC6854 and observe that streams likely to be DMARC-protected don't use this format, so if you see a multi-valued From where any domain has a DMARC policy, it's invalid and the receiver should act accordingly. For From: headers with address-free groups, recall that the motivation > for this was EAI downgrades at delivery time. The un-downgraded > message had a normal From: header, so normal DMARC applies. If the > address is smashed in the downgrade I don't see any reason that the > DMARC result needs to change. > I don't know much at all about EAI, but if the address is smashed, which DMARC result could you possibly use? -MSK --089e0115e73274416f0507490aff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 7, 2014 at 10:06 AM, John Levine <johnl@taugh.c= om> wrote:
>1) Evaluate all = the domains you find, and if any of them have published
>DMARC policies, apply the strictest one ...

Given the anti-phishing goals of DMARC, I don't see how anything else makes any sense.=C2=A0 Or you could skip a step, say that DMARC doesn't=
permit multi-address From headers, assume that validation failed on
all of the domains and proceed directly to the punishment phase.

Right, that's also an option, and it at least= accommodates the no-address From field that RFC6854 permits.

=
Another option I can think of is one where we just admit the conflict = with RFC6854 and observe that streams likely to be DMARC-protected don'= t use this format, so if you see a multi-valued From where any domain has a= DMARC policy, it's invalid and the receiver should act accordingly.
For From: headers with address-free groups, recall that the motivation
for this was EAI downgrades at delivery time.=C2=A0 The un-downgraded
message had a normal From: header, so normal DMARC applies.=C2=A0 If the address is smashed in the downgrade I don't see any reason that the
DMARC result needs to change.

I don'= ;t know much at all about EAI, but if the address is smashed, which DMARC r= esult could you possibly use?

-MSK
=
--089e0115e73274416f0507490aff-- From nobody Fri Nov 7 10:50:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFC71A890F for ; Fri, 7 Nov 2014 10:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PokPHj8S0rS7 for ; Fri, 7 Nov 2014 10:49:56 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC66C1A008A for ; Fri, 7 Nov 2014 10:49:55 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id a13so13268946igq.17 for ; Fri, 07 Nov 2014 10:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yTiS24jnhktfsSizgeea2v4s2Zhn03ccoT3pvHkHI94=; b=dfXfLgv86LkC0XMcn0UeGuaduMM+Rcmsb7muSY5SSxtgX4jsJSBXnJip3FTqOE2wJu ShgWod40CYfq/gi6tz89lxkvO9OTGshPQFar/yRrjY1sSC7X08+TY9V1pnkzjCALznm1 6o8qyxjJNIWH6rcURc752nSOcCf+u+B/9FPt1WoSA9c9ngCB35Bvv0hi/7FUEO2g6YXE 5uTa5K/YgQuxiMWdeqdez8Xz641IapT4aVEdD+enB9EsiI7UbUkvFgHXPeJGqL+7OVzm QHXo1mDpCIrHZpI1Eu6HOywYksEWrzSDU90jxmuigkTmiJlEU2l9mX30NDTKyms58Kk2 byzA== X-Received: by 10.107.11.67 with SMTP id v64mr4968302ioi.76.1415386195024; Fri, 07 Nov 2014 10:49:55 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id k140sm1259327ioe.39.2014.11.07.10.49.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Nov 2014 10:49:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: Date: Fri, 7 Nov 2014 10:49:52 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <966A0DC3-0DBD-44F0-88F6-0656BF3EBDA0@gmail.com> References: <20141107180651.8446.qmail@ary.lan> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/OVrOU3a_pq4mHgPmdLz2ii6k8Xo Cc: "dmarc@ietf.org" , John Levine , Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 18:49:57 -0000 On Nov 7, 2014, at 10:32 AM, Murray S. Kucherawy = wrote: > On Fri, Nov 7, 2014 at 10:06 AM, John Levine wrote: > >1) Evaluate all the domains you find, and if any of them have = published > >DMARC policies, apply the strictest one ... >=20 > Given the anti-phishing goals of DMARC, I don't see how anything else > makes any sense. Or you could skip a step, say that DMARC doesn't > permit multi-address =46rom headers, assume that validation failed on > all of the domains and proceed directly to the punishment phase. >=20 > Right, that's also an option, and it at least accommodates the = no-address =46rom field that RFC6854 permits. >=20 > Another option I can think of is one where we just admit the conflict = with RFC6854 and observe that streams likely to be DMARC-protected don't = use this format, so if you see a multi-valued =46rom where any domain = has a DMARC policy, it's invalid and the receiver should act = accordingly. >=20 > For From: headers with address-free groups, recall that the motivation > for this was EAI downgrades at delivery time. The un-downgraded > message had a normal From: header, so normal DMARC applies. If the > address is smashed in the downgrade I don't see any reason that the > DMARC result needs to change. >=20 > I don't know much at all about EAI, but if the address is smashed, = which DMARC result could you possibly use? Dear Murray, I too agree with John. It also seems a specific Group syntax might allow = an obvious (and safe) alternate address strategy. This same approach = might also support a scheme to re-write third-party services' =46rom = addresses. Regards, Douglas Otis From nobody Fri Nov 7 12:45:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BA41A1B0A for ; Fri, 7 Nov 2014 12:45:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nMFKky2Kaud for ; Fri, 7 Nov 2014 12:45:30 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10141A1AFD for ; Fri, 7 Nov 2014 12:45:29 -0800 (PST) Received: (qmail 55103 invoked from network); 7 Nov 2014 20:45:28 -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=d73e.545d2f68.k1411; bh=sI9VUkMSrt/z6Kbt4Gp31DJR+1B0g32yXiLR9DmoSiM=; b=sL6augloG9xqHHSXvDU+8vWKh2YxQpIRDo1kwqZj/PKHhJBzfunRvaWtERCj7IYB7ifeNc//rPHkAT4pmS5BMKLtM3zpL2U8cbdZs+j/g6uEXgQAWsXs+p6wNJR2YQglc4/5bmq6Jt5gwzzKgwHcQoNGJIEiVSGM/xfzAGN+xaJQ6pcfmDM59tK7QvZ/bJeiVLOL7Xh2PgrdScp40WtIDi4BaZhoL/+6vuCih1YZlSIpoi6SinTnt0mtQEnDzDQq 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=d73e.545d2f68.k1411; bh=sI9VUkMSrt/z6Kbt4Gp31DJR+1B0g32yXiLR9DmoSiM=; b=nD2zv8JBkWzfeVYb8+jT4rRZhkh13IAGBmUcNY2uGxNWIDdSlaepg1YbSeLbIx92iecHFia1ONBldPvOZC4bXQieMLs6zx8HSkxB3Bhfw8yG0MoaJllFJgOZHZ52JvIoYuz/pIdHwGtzXH9QfDu/aLxwUG8LJXwVCFu0b4FIahJCAejeQ6pioTR+32SW7tdPs/g/ehSrBM/yX/KCgqVr3fmtm4ko7p/dIRzodDKN+ecKVpO5rkF5pcxBk6SZHcFp 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; 07 Nov 2014 20:45:28 -0000 Date: 7 Nov 2014 15:45:27 -0500 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01PEO0RHSW5I00475I@mauve.mrochek.com> References: <20141107180651.8446.qmail@ary.lan> <01PEO0RHSW5I00475I@mauve.mrochek.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2pt8TyHvFE1PKWuCCzS2G9_s878 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Nov 2014 20:45:31 -0000 > That's fine if any of the domains have an associated DMARC record - of any > sort. My concern is the case where none of them do, or when there > are no domains present. In that case I agree with you, it's none of DMARC's business what happens. >> For From: headers with address-free groups, recall that the motivation >> for this was EAI downgrades at delivery time. The un-downgraded >> message had a normal From: header, so normal DMARC applies. If the >> address is smashed in the downgrade I don't see any reason that the >> DMARC result needs to change. > > Neither do I. Clarification for Murray: An EAI message might arrive with an address like this: From: stuff where AAAA, BBBB, and CCCC are UTF-8 strings, and for extra excitement, AAAA includes characters not allowed in u-labels. You can easily do a DMARC check on this address by turning BBBB.CCCC, which have to be U-labels, into A-labels and do a normal DMARC check. Non-EAI mail can't handle the AAAA, so one of the ways a message might be smashed for delivery might be this: From: "international address AAAA@BBBB.CCCC" :; (You can use MIME encoding for the comment.) So the address is gone, but the message remains, and the DMARC result might as well remain too. I agree this is pretty deep into nit-land, so my only real concern is that there not be langauge that forbids doing the obvious thing in this situation. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Nov 7 16:40:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBC31A0087 for ; Fri, 7 Nov 2014 16:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzsIDMjwrVAZ for ; Fri, 7 Nov 2014 16:40:34 -0800 (PST) Received: from BLU004-OMC3S37.hotmail.com (blu004-omc3s37.hotmail.com [65.55.116.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 1D68D1A0081 for ; Fri, 7 Nov 2014 16:40:34 -0800 (PST) Received: from BLU436-SMTP253 ([65.55.116.73]) by BLU004-OMC3S37.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 7 Nov 2014 16:40:33 -0800 X-TMN: [MLSPMSjuDAbZ0Vt+fUlkUjMbNZCUHTWM] X-Originating-Email: [jtrentadams@live.com] Message-ID: Date: Fri, 7 Nov 2014 17:40:31 -0700 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ned+dmarc@mrochek.com, "Murray S. Kucherawy" , "dmarc@ietf.org" References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> In-Reply-To: <01PEMWEN5Q8W003WE3@mauve.mrochek.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2014 00:40:33.0040 (UTC) FILETIME=[9A9F7100:01CFFAEC] Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/V6Vxp2yqsiyerogrIFk0d7vAdt8 Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 00:40:37 -0000 On 11/6/14 12:06 PM, ned+dmarc@mrochek.com wrote: > > > I have a few comments on the base specification. > > In section 3.1.4, the paragraph > > It is important to note that identifier alignment cannot occur with a > message that is not valid per [MAIL], particularly one with a > malformed or absent RFC5322.From field. Handling of such cases is > left to the discretion of the Mail Receiver. > > doesn't really make sense to me. If the From: field is missing or is so > malformed that a domain cannot be extracted from it, it isn't a question of > alignment to other fields, but rather that there's no way to determine a DMARC > policy that applies to the message to begin with. Shouldn't that be the primary > reason invalid mail is problematic? Am I missing something here? The foundational statement is that for DMARC to be implemented, there must be an address in the addr-spec portion of the RFC5322.From field. By my read, the current paragraph includes the necessary statements, but perhaps it could be modified as follows to be more clear: ----- It is important to note that identifier alignment cannot occur, and DMARC determination applied, with a message that is not valid per RFC 5322 [MAIL]. This is particularly true when a message has a malformed or absent RFC5322.From field. ----- This proposed edit also addresses another issue in the thread: it removes the tension between it and section 5.6.1. > > There's a big problem in section 5.6.1, where it says that any message with > more than one address or an empty group in an RFC5322.From field SHOULD be > rejected. > > I have to say I find this recommendation to be completely inappropriate. Surely > it should be possible for me to a legitimate, syntactically valid message that > happens to employ the multiple-from/sender format defined in RFC 5322 with all > the domains under my personal control and none publish any sort of DMARC > policy, and not have the application of DMARC to the overall message flow mess > it up? Or alternately, one where the From: field contains an empty group, > something we actually recently went to the trouble of writing RFC 6854 to > allow? > > Sure, some clients may barf on such things, but that's a problem for whoever > opts to use the mechanisms, not DMARC. > > I have no absolutely problem with rejecting messages with From: fields > containing any sort of domain identifier that has any sort of attached DMARC > policy because of how that From: field is constructed. But intruding on > legitate uses of email that choose not to employ DMARC in any capacity goes > much too far. And it isn't helped by the fact that the DMARC reporting > mechanisms are meaningless when there's no domain owner to report these > rejections to. There's a lot of interesting meat to chew on here... but maybe setting some context would help feed the conversation. Starting off, we can ignore a address in the RFC5322.From field as DMARC will have no bearing in that case. Similarly, when there is exactly one address in the RFC5322.From field, application of DMARC is reasonably straight forward. The question is what to do about more than one address in the RFC5322.From field. The options would be to not apply DMARC at all (regardless of any addresses with associated DMARC policies), reject the entire message, or run through the set of addresses and try to apply DMARC in some way (if any of the addresses have associated DMARC records). Not applying DMARC would enable malicious actors to slip through, so that's not a great choice. Rejecting the message outright (even if none of the addresses have an associated DMARC policy) seems like it unfairly punishes domains who aren't opting into DMARC. That leaves taking some action based on the DMARC policies associated with the set of domains represented in the RFC5322.From field. It seems that the most reasonable approach is to gather the DMARC policies for all addresses, and then apply the most strict. Given all that, here's my suggested revision to Section 5.6.1.: ----- 5.6.1. Extract Author Domain In order to be processed by DMARC, the domain(s) must be extracted from the domain of the email address(es) within the addr-spec portion of the RFC5322.From field. If the domain is encoded with UTF-8, the domain name must be converted to an A-label for further processing. If no domain is found, the message SHOULD be rejected (as it is forbidden under RFC 5322 [MAIL]). If more than one domain identifier is found, the full set of domains MAY be collected as a set of identifiers for DMARC processing. It is useful to note that it may not be possible to extract a meaningful author domain identifier from some messages. For example, some messages could: o have multiple RFC5322.From fields (which is also forbidden under RFC 5322 [MAIL]) o have no RFC5322.From field (which is also forbidden under RFC 5322 [MAIL]) o have an RFC5322.From field that contains no meaningful values, such as RFC 5322 [MAIL]'s "group" syntax. Messages that are forbidden under RFC 5322 [MAIL] SHOULD be rejected without requiring further DMARC processing. ----- This change would also necessitate a slight change to Section 5.6.2. Below is my suggested revision that would bridge the gap: ----- 5.6.2. Determine Handling Policy To arrive at a policy disposition for an individual message, Mail Receivers MUST perform the following actions or their semantic equivalents. Steps 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from previous steps. In the case where multiple identifiers were extracted from the RFC5322.From field, steps 1-4 are performed for each identifier, collecting the results, prior to performing steps 5 and 6. The steps are as follows: 1. Extract the identifier(s) from the addr-spec portion of the RFC5322.From field of from the message (as above). 2. For each identifier, query the DNS for a DMARC policy record published by the Domain Owner(s). Continue if at least one policy record is found, or abort DMARC evaluation otherwise. If there is more than one identifier, the DMARC policy found for each identifier SHOULD be collected as a set to be used in step 5. See Section 5.6.3 for the details of policy discovery. 3. Perform DKIM signature verification checks. A single email may contain multiple DKIM signatures. The results of this step are passed to the remainder of the algorithm and MUST include the value of the "d=" tag from all checked DKIM signatures. 4. Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check. 5. Conduct identifier alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks if Authenticated Identifiers fall into alignment as described in Section 3. If one or more of the Authenticated Identifiers align with an identifier extracted from the addr-spec of the RFC5322.From domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures. 6. Apply policy. Within the set of DMARC policies found in Step 2, select the most strict (with p="none" being the least strict, next being "quarantine", and "reject" being the most strict) to use in applying policy. See Section 5.3 for details of the discovered DMARC policies. ----- ... of course, now that I've gone through that exercise, I realize that this would necessitate a change to reporting (Section 6). Basically, that we need to report on the results to everyone with a DMARC record that includes a request to receive reports... then there's the question of what we should tell them (especially to a "none" policy domain about a rejection due to a "reject" policy from another domain found in the RFC5322.From field). Off to the side, there may be some concern about a message that is received with a large number (e.g. 100) of addresses in the RFC5322.From field. While ostensibly permitted, that would definitely raise some eyebrows. I have a feeling that mailbox providers know how to handle that case, irrespective of DMARC. > > There's also a direct contradiction between the third bullet item in section > 5.6.1, which says that a message without a From: field SHOULD be rejected, and > the fourth paragraph of section 3.1.4, which leaves this same case to the > discretion of the mail receiver. Furthermore, does it really make sense to give > malformed From: fields a pass - someomthing which could easily contain an > identifier that has an attached DMARC policy - and require rejection of > completely legitimate stuff with no DMARC policy in sight? I tried to remove the tension in the proposed edit above. > > Section 6.2.2.1 states: > > In the case of a "mailto" URI, the Mail Receiver MUST communicate > reports using the method described in [STARTTLS] whenever it is > offered by a Report Receiver. > > I seriously question the value or appropriateness of this paragraph. So your > DMARC agent, assuming it actually goes through a SUBMIT server and not through > an internal API, uses STARTTLS to secure that connection. Now what? At present > there's no standardized way to indicate in a message that it has to be > transported securely. So if you really want that, that leaves configuration - a > configuration that spans an essentially arbitrary set of transport agents, to > enforce this. At least part of which would have to be enforced by the target of > the mailto: to have any chance of being effective. > +1 to removing the STARTTLS requirement in this specification. HTH, Trent -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From turnbull@sk.tsukuba.ac.jp Fri Nov 7 20:57:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92A41A007C for ; Fri, 7 Nov 2014 20:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.615 X-Spam-Level: X-Spam-Status: No, score=0.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.594] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMbFN9y0hpQH for ; Fri, 7 Nov 2014 20:57:25 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 058481A023E for ; Fri, 7 Nov 2014 20:57:19 -0800 (PST) Received: from infoshako.sk.tsukuba.ac.jp (app-a.sk.tsukuba.ac.jp [130.158.97.162]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id 245DB1C3B7B; Sat, 8 Nov 2014 13:57:18 +0900 (JST) Received: from 113.148.46.181 (RisuMail authenticated user turnbull) by infoshako.sk.tsukuba.ac.jp with HTTP; Sat, 8 Nov 2014 13:57:18 +0900 (JST) Message-ID: <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> In-Reply-To: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp><01PEMWEN5Q8W003WE3@mauve.mrochek.com> Date: Sat, 8 Nov 2014 13:57:18 +0900 (JST) From: turnbull@sk.tsukuba.ac.jp To: "J. Trent Adams" User-Agent: RisuMail 3.1 X-Mailer: RisuMail 3.1 MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fig4scPo2-Yb56vzDhY1sDNTCD0 X-Mailman-Approved-At: Fri, 07 Nov 2014 23:08:05 -0800 Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 05:03:44 -0000 Trent Adams writes: > ----- > It is important to note that identifier alignment cannot occur, and > DMARC determination applied, with a message that is not valid per RFC > 5322 [MAIL]. This is particularly true when a message has a malformed > or absent RFC5322.From field. > ----- I occasionally see non-ASCII octets introduced by spam/virus checkers in X-Spam-* fields in the header or in the (non-8-bit) message body, due to copying message content into those contexts. The From field is perfectly valid, however. Does that really mean that identifier alignment cannot occur? (I think that is a plausible policy choice, since in an invalid message "anything can happen". But I don't see that it's a no-brainer.) > Starting off, we can ignore a address in the RFC5322.From field > as DMARC will have no bearing in that case. Similarly, when there is > exactly one address in the RFC5322.From field, application of DMARC is > reasonably straight forward. By "DMARC", you really mean "DMARC policy", right? DMARC the protocol does need to say something about what happens if alignment fails or no policy can be discovered. > That leaves taking some action based on the DMARC policies associated > with the set of domains represented in the RFC5322.From field. It seems > that the most reasonable approach is to gather the DMARC policies for > all addresses, and then apply the most strict. I wouldn't call that "reasonable". It's the only plausible option, but here's the problematic use case: Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. For organizational political reasons it is necessary that (a) both names appear on the memo and (b) Stephen has to do the dirty work. Stephen sends the mail "From: trent@example.com, stephen@example.org", with proper SPF and DKIM setups. Unfortunately, example.com publishes p=reject, example.com alignment fails because Stephen sent the message, the MTAs reject the message, and nobody except Trent and Stephen shows up to the meeting. I see two ways this message could pass DMARC: Stephen has the keys for example.com, or the Japanese "ringi" system, where I write and sign the message, send it to Trent, who then signs the message but otherwise forwards it verbatim. Both seem fragile to me. OTOH, only checking policies of aligned SPF source domains and DKIM signers means that Stephen (or any scammer) can add "POTUS@whitehouse.gov" to the From field and pass DMARC. It's obvious what the Felons of April would do with that. I guess the most plausible approach to this issue is to say that if you want to use DMARC and have multiple authors, you must contrive to give all the authors mailboxes in the same domain. In the example, I could create the-committee.example.org for committee members, or give trent a forwarding mailbox at example.org itself. > Given all that, here's my suggested revision to Section 5.6.1.: > > ----- > 5.6.1. Extract Author Domain > > In order to be processed by DMARC, the domain(s) must be extracted from > the domain of the email address(es) within the addr-spec portion of the > RFC5322.From field. If the domain is encoded with UTF-8, the domain name > must be converted to an A-label for further processing. If no domain is > found, the message SHOULD be rejected (as it is forbidden under RFC 5322 I still don't think a null From filed is any business of DMARC the protocol. That's really an issue for (a) the security considerations section or (b) the planned BCP. > [MAIL]). If more than one domain identifier is found, the full set of > domains MAY be collected as a set of identifiers for DMARC processing. But this seems to be the insecure approach I describe above: > 5. Conduct identifier alignment checks. With authentication checks > and policy discovery performed, the Mail Receiver checks if > Authenticated Identifiers fall into alignment as described in > Section 3. If one or more of the Authenticated Identifiers align > with an identifier extracted from the addr-spec of the > RFC5322.From domain, the message is considered to pass the > DMARC mechanism check. AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to send spam that passes DMARC on your behalf, as long as my mailbox appears in From, too. Am I misunderstanding your proposed algorithm? > All other conditions (authentication > failures, identifier mismatches) are considered to be DMARC > mechanism check failures. Bottom line, I think both messages where no Authenticated Identifiers can be extracted and those where multiple Authenticated Identifiers can be extracted should be defined to be mechanism check failures. In the former case, policy discovery is impossible, in the latter, the strictest policy should be applied. Regards, Steve From nobody Fri Nov 7 23:26:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7851A1AA3 for ; Fri, 7 Nov 2014 23:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ONHljUWRZNE for ; Fri, 7 Nov 2014 23:26:05 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5051A1A95 for ; Fri, 7 Nov 2014 23:26:04 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id x12so5265779wgg.17 for ; Fri, 07 Nov 2014 23:26:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QKyNDPQJ50LOGWcenBINpynIIXxCyKqW+8mzYgUwxGk=; b=LkjB/H45XPoGyME153l0fVTPIZsNaqIGfUEKDLbjWhr35cwdjIuJ73V88tUuvdCZxk jiHrgW+YimzDnyldnN/C4Sa4pIcCaddlRZiSdUXhrdChSu/fbOjQ9lX2y1hgi412+NGH F7az9byGMjJ0XAtiSIls6G9hHQtqQHx3mFA8Ru8tiCwDN3KV8o34LLC3tF5BfQimBuzS jJWSp7a2vxfjfRdJU8ec07E33jKc0ygByHigzew4mQmEOdEFlaUsQR9QDJwDAuaCswRp QtfxiHLO7ym77Qfa1p2s6msf6fnzmjvnsuy5BCD9dj6rC4vynD9TiPEeIhSASVAfkTbP sRrg== MIME-Version: 1.0 X-Received: by 10.194.3.2 with SMTP id 2mr23419581wjy.89.1415431563488; Fri, 07 Nov 2014 23:26:03 -0800 (PST) Received: by 10.27.76.134 with HTTP; Fri, 7 Nov 2014 23:26:03 -0800 (PST) In-Reply-To: <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> Date: Fri, 7 Nov 2014 23:26:03 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=047d7b343c188bb3e5050753d705 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-msY4aEvBOGZOO5-gKxtcxfpEnk Cc: "dmarc@ietf.org" , "J. Trent Adams" , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 07:26:07 -0000 --047d7b343c188bb3e5050753d705 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 7, 2014 at 8:57 PM, wrote: > Trent Adams writes: > > > ----- > > It is important to note that identifier alignment cannot occur, and > > DMARC determination applied, with a message that is not valid per RFC > > 5322 [MAIL]. This is particularly true when a message has a malformed > > or absent RFC5322.From field. > > ----- > > I occasionally see non-ASCII octets introduced by spam/virus checkers in > X-Spam-* fields in the header or in the (non-8-bit) message body, due to > copying message content into those contexts. The From field is perfectly > valid, however. Does that really mean that identifier alignment cannot > occur? > > (I think that is a plausible policy choice, since in an invalid message > "anything can happen". But I don't see that it's a no-brainer.) > Do you have another suggestion? Note that there's nothing normative in Trent's suggestion. If a receiver thinks it can continue with the X-Spam-* fields malformed as described, then it can continue on that basis. > > Starting off, we can ignore a address in the RFC5322.From field > > as DMARC will have no bearing in that case. Similarly, when there is > > exactly one address in the RFC5322.From field, application of DMARC is > > reasonably straight forward. > > By "DMARC", you really mean "DMARC policy", right? DMARC the protocol > does need to say something about what happens if alignment fails or no > policy can be discovered. > That's how I understood what he said. > > That leaves taking some action based on the DMARC policies associated > > with the set of domains represented in the RFC5322.From field. It seems > > that the most reasonable approach is to gather the DMARC policies for > > all addresses, and then apply the most strict. > > I wouldn't call that "reasonable". It's the only plausible option, but > here's the problematic use case: > > Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. > For organizational political reasons it is necessary that (a) both names > appear on the memo and (b) Stephen has to do the dirty work. Stephen > sends the mail "From: trent@example.com, stephen@example.org", with proper > SPF and DKIM setups. Unfortunately, example.com publishes p=reject, > example.com alignment fails because Stephen sent the message, the MTAs > reject the message, and nobody except Trent and Stephen shows up to the > meeting. I see two ways this message could pass DMARC: Stephen has the > keys for example.com, or the Japanese "ringi" system, where I write and > sign the message, send it to Trent, who then signs the message but > otherwise forwards it verbatim. Both seem fragile to me. > OTOH, only checking policies of aligned SPF source domains and DKIM > signers means that Stephen (or any scammer) can add "POTUS@whitehouse.gov" > to the From field and pass DMARC. It's obvious what the Felons of April > would do with that. > > I guess the most plausible approach to this issue is to say that if you > want to use DMARC and have multiple authors, you must contrive to give all > the authors mailboxes in the same domain. In the example, I could create > the-committee.example.org for committee members, or give trent a > forwarding mailbox at example.org itself. > Ned, do you concur with this analysis? Is Trent's proposal coupled with this caveat a valid remedy for your point? > > Given all that, here's my suggested revision to Section 5.6.1.: > > > > ----- > > 5.6.1. Extract Author Domain > > > > In order to be processed by DMARC, the domain(s) must be extracted from > > the domain of the email address(es) within the addr-spec portion of the > > RFC5322.From field. If the domain is encoded with UTF-8, the domain name > > must be converted to an A-label for further processing. If no domain is > > found, the message SHOULD be rejected (as it is forbidden under RFC 5322 > > I still don't think a null From filed is any business of DMARC the > protocol. That's really an issue for (a) the security considerations > section or (b) the planned BCP. > I think we're all in agreement on that point so far. > > [MAIL]). If more than one domain identifier is found, the full set of > > domains MAY be collected as a set of identifiers for DMARC processing. > > But this seems to be the insecure approach I describe above: > > > 5. Conduct identifier alignment checks. With authentication checks > > and policy discovery performed, the Mail Receiver checks if > > Authenticated Identifiers fall into alignment as described in > > Section 3. If one or more of the Authenticated Identifiers align > > with an identifier extracted from the addr-spec of the > > RFC5322.From domain, the message is considered to pass the > > DMARC mechanism check. > > AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to > send spam that passes DMARC on your behalf, as long as my mailbox appears > in From, too. Am I misunderstanding your proposed algorithm? > No, because in (6) the strictest rule applies. Your throwaway domain might pass, but the other advertised author's would not. > > All other conditions (authentication > > failures, identifier mismatches) are considered to be DMARC > > mechanism check failures. > > Bottom line, I think both messages where no Authenticated Identifiers can > be extracted and those where multiple Authenticated Identifiers can be > extracted should be defined to be mechanism check failures. In the former > case, policy discovery is impossible, in the latter, the strictest policy > should be applied. > Right, I think that's what Trent is also saying. And everyone seems to agree on just dropping STARTTLS as well. -MSK --047d7b343c188bb3e5050753d705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 7, 2014 at 8:57 PM, <turnbull@sk.tsu= kuba.ac.jp> wrote:
Trent Adam= s writes:

> -----
> It is important to note that identifier alignment cannot occur, and > DMARC determination applied, with a message that is not valid per RFC<= br> > 5322 [MAIL].=C2=A0 This is particularly true when a message has a malf= ormed
> or absent RFC5322.From field.
> -----

I occasionally see non-ASCII octets introduced by spam/virus checker= s in
X-Spam-* fields in the header or in the (non-8-bit) message body, due to copying message content into those contexts.=C2=A0 The From field is perfec= tly
valid, however.=C2=A0 Does that really mean that identifier alignment canno= t
occur?

(I think that is a plausible policy choice, since in an invalid message
"anything can happen".=C2=A0 But I don't see that it's a = no-brainer.)

Do you have another sugges= tion?

Note that there's nothing normative in Trent= 9;s suggestion.=C2=A0 If a receiver thinks it can continue with the X-Spam-= * fields malformed as described, then it can continue on that basis.
=C2= =A0
> Starting off, we can ignore a <null> address in= the RFC5322.From field
> as DMARC will have no bearing in that case.=C2=A0 Similarly, when ther= e is
> exactly one address in the RFC5322.From field, application of DMARC is=
> reasonably straight forward.

By "DMARC", you really mean "DMARC policy", righ= t?=C2=A0 DMARC the protocol
does need to say something about what happens if alignment fails or no
policy can be discovered.

That's ho= w I understood what he said.
=C2=A0
> That leaves taking some action based on the DMARC pol= icies associated
> with the set of domains represented in the RFC5322.From field.=C2=A0 I= t seems
> that the most reasonable approach is to gather the DMARC policies for<= br> > all addresses, and then apply the most strict.

I wouldn't call that "reasonable".=C2=A0 It's the = only plausible option, but
here's the problematic use case:

Co-Chairs Trent and Stephen decide to hold a meeting of The Committee.
For organizational political reasons it is necessary that (a) both names appear on the memo and (b) Stephen has to do the dirty work.=C2=A0 Stephen<= br> sends the mail "From: trent@examp= le.com, stephen@example.org&= quot;, with proper
SPF and DKIM setups.=C2=A0 Unfortunately, example.com publishes p=3Dreject,
example.com alignment = fails because Stephen sent the message, the MTAs
reject the message, and nobody except Trent and Stephen shows up to the
meeting.=C2=A0 I see two ways this message could pass DMARC: Stephen has th= e
keys for example.com, = or the Japanese "ringi" system, where I write and
sign the message, send it to Trent, who then signs the message but
otherwise forwards it verbatim.=C2=A0 Both seem fragile to me.=C2=A0

OTOH, only checking policies of aligned SPF source domains and DKIM
signers means that Stephen (or any scammer) can add "POTUS@whitehouse.gov"
to the From field and pass DMARC.=C2=A0 It's obvious what the Felons of= April
would do with that.

I guess the most plausible approach to this issue is to say that if you
want to use DMARC and have multiple authors, you must contrive to give all<= br> the authors mailboxes in the same domain.=C2=A0 In the example, I could cre= ate
the-committe= e.example.org for committee members, or give trent a
forwarding mailbox at exam= ple.org itself.

Ned, do you concur = with this analysis?=C2=A0 Is Trent's proposal coupled with this caveat = a valid remedy for your point?
=C2=A0
> Given all that, here's my suggested revision to S= ection 5.6.1.:
>
> -----
> 5.6.1.=C2=A0 Extract Author Domain
>
> In order to be processed by DMARC, the domain(s) must be extracted fro= m
> the domain of the email address(es) within the addr-spec portion of th= e
> RFC5322.From field. If the domain is encoded with UTF-8, the domain na= me
> must be converted to an A-label for further processing. If no domain i= s
> found, the message SHOULD be rejected (as it is forbidden under RFC 53= 22

I still don't think a null From filed is any business of DMARC t= he
protocol.=C2=A0 That's really an issue for (a) the security considerati= ons
section or (b) the planned BCP.

I think= we're all in agreement on that point so far.
=C2=A0
> [MAIL]).=C2=A0 If more than one domain identifier is = found, the full set of
> domains MAY be collected as a set of identifiers for DMARC processing.=

But this seems to be the insecure approach I describe above:

>=C2=A0 =C2=A0 5.=C2=A0 Conduct identifier alignment checks.=C2=A0 With = authentication checks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and policy discovery performed, the Mail Re= ceiver checks if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authenticated Identifiers fall into alignme= nt as described in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 3.=C2=A0 If one or more of the Auth= enticated Identifiers align
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 with an identifier extracted from the addr-= spec of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC5322.From domain, the message is conside= red to pass the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 DMARC mechanism check.

AFAICS this allows me (using a throwaway mailbox at a throwaway doma= in) to
send spam that passes DMARC on your behalf, as long as my mailbox appears in From, too.=C2=A0 Am I misunderstanding your proposed algorithm?

No, because in (6) the strictest rule applies.= =C2=A0 Your throwaway domain might pass, but the other advertised author= 9;s would not.
=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 All other conditions (auth= entication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 failures, identifier mismatches) are consid= ered to be DMARC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanism check failures.

Bottom line, I think both messages where no Authenticated Identifier= s can
be extracted and those where multiple Authenticated Identifiers can be
extracted should be defined to be mechanism check failures.=C2=A0 In the fo= rmer
case, policy discovery is impossible, in the latter, the strictest policy should be applied.

Right, I think that&= #39;s what Trent is also saying.

And everyone seems to ag= ree on just dropping STARTTLS as well.

-MSK
--047d7b343c188bb3e5050753d705-- From nobody Sat Nov 8 12:21:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC71A012D for ; Sat, 8 Nov 2014 12:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcv_z9OkN0R4 for ; Sat, 8 Nov 2014 12:21:45 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8951A00D6 for ; Sat, 8 Nov 2014 12:21:44 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id n3so7024276wiv.0 for ; Sat, 08 Nov 2014 12:21:43 -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:content-type; bh=lcMjY3XTTdGzpRNOROlfXgvW/we2wnm8YT5RxczEtY4=; b=Jr8A6pRlA58vNF50t5Szf6+kcgC002i8aQLopuKQUUG3TADQWq01kEU6WtjIE0WjDs +Bjr3X5RsxzI7VvRnV5ACNmEJkfeI3/Xo8wY0WATXFr12ql9MknIK23Qtig8YZSWAehw 7OTumku1kNx3DLPt72TCkxxSXtTIy2ykPfoP/du6Do6ucQEyD+A+Axtfr49ra7+W6tad hb0X+QHtSoQv321Uqv6WIAfHJu42f6641S+NZYgA5datqqkjP208MkjGRQvm5GQ0EHCc qz5keMJPEkbkGJYuZU8jiOwAJbv4YJuTLxXe9/UnufGN53yDqFTe4aCo+4TYmAT5EOMB 0hkg== 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:content-type; bh=lcMjY3XTTdGzpRNOROlfXgvW/we2wnm8YT5RxczEtY4=; b=kz49l7niXgKSIHgdHwNNgff8PdKDyd2Y+Mv7J0SySKiGite5oq+VaAM0/Bh93hlFdl 8/ojGMr2NVhxsYMc89w2E5as+7ytAxYDM7JOShfoJFE/2TQ/G8ljLElHNXvJPUwS4LQM +5T/4Lik0WPDycvZ+c5cGxb3c35AkO6TFe9vL+0DkKO1Wlkh3Ve1815wE/FNBu74DMqa Hejwmt/pWlMh+qDO6UTPvQdLWXZvaOe8b6FpGk1YzNZQHy/fbhq3/y9ZKkHEK0hIpuFE sS8ekS5AOxBhJT50MEcPgKKQvsVSFIQOnTLjB/0x1Q6JBX5XYm7aBOD+lwTyx9CX9MuT nnOg== X-Received: by 10.180.84.167 with SMTP id a7mr16724241wiz.39.1415478103305; Sat, 08 Nov 2014 12:21:43 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com. [209.85.212.176]) by mx.google.com with ESMTPSA id cz3sm16607387wjb.23.2014.11.08.12.21.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Nov 2014 12:21:41 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so7318047wiw.15 for ; Sat, 08 Nov 2014 12:21:40 -0800 (PST) X-Gm-Message-State: ALoCoQnE9Uj1DT5fvUHG8Wu9l9ApShyIQnLgpCa+MCkcN6e0A750AmmVsp+T1p6gzevJmFLd5UDm X-Received: by 10.194.77.4 with SMTP id o4mr28852181wjw.41.1415478100748; Sat, 08 Nov 2014 12:21:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.175.233 with HTTP; Sat, 8 Nov 2014 12:20:59 -0800 (PST) In-Reply-To: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> From: Brett McDowell Date: Sat, 8 Nov 2014 15:20:59 -0500 Message-ID: To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=047d7bfceec06205e405075eadd6 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wGixieleZrPgCMu_PeLBe7kjaXw Cc: "dmarc@ietf.org" , "J. Trent Adams" , ned+dmarc@mrochek.com, "Stephen J. Turnbull" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 20:21:48 -0000 --047d7bfceec06205e405075eadd6 Content-Type: text/plain; charset=UTF-8 I support making no change in dmarc-base-05 that might change how current mailbox providers implement dmarc-base. But to the extent this collection of contributors would like to see the recommendations/requirements in section 5.6.1 updated to better harmonize with related RFC's, I support Trent's proposal as it seems to introduce the least amount of increased risk to fraud. That said, we do have people here familiar with large-scale mailbox provider deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask them if they expect Trent's changes to have any impact on how they implement dmarc-base today. If it will, I think we should consider these changes for a future version of dmarc-base and let this version go through with these requirements unchanged. As you all know, there are now years of experience deploying dmarc-base with these requirements as written. Those deployments have had tremendous success protecting users from domain-spoofing the RFC5322.From field. The importance of the current dmarc-base specification's efficacy at blocking domain-spoofed phishing attacks should not be underestimated. I advise extreme caution when considering any normative changes at the 11th hour. Dear high volume MBP's, will any of these changes in Trent's proposal alter how you implement dmarc-base today? -Brett On Sat, Nov 8, 2014 at 2:26 AM, Murray S. Kucherawy wrote: > On Fri, Nov 7, 2014 at 8:57 PM, wrote: > >> Trent Adams writes: >> >> > ----- >> > It is important to note that identifier alignment cannot occur, and >> > DMARC determination applied, with a message that is not valid per RFC >> > 5322 [MAIL]. This is particularly true when a message has a malformed >> > or absent RFC5322.From field. >> > ----- >> >> I occasionally see non-ASCII octets introduced by spam/virus checkers in >> X-Spam-* fields in the header or in the (non-8-bit) message body, due to >> copying message content into those contexts. The From field is perfectly >> valid, however. Does that really mean that identifier alignment cannot >> occur? >> >> (I think that is a plausible policy choice, since in an invalid message >> "anything can happen". But I don't see that it's a no-brainer.) >> > > Do you have another suggestion? > > Note that there's nothing normative in Trent's suggestion. If a receiver > thinks it can continue with the X-Spam-* fields malformed as described, > then it can continue on that basis. > > >> > Starting off, we can ignore a address in the RFC5322.From field >> > as DMARC will have no bearing in that case. Similarly, when there is >> > exactly one address in the RFC5322.From field, application of DMARC is >> > reasonably straight forward. >> >> By "DMARC", you really mean "DMARC policy", right? DMARC the protocol >> does need to say something about what happens if alignment fails or no >> policy can be discovered. >> > > That's how I understood what he said. > > >> > That leaves taking some action based on the DMARC policies associated >> > with the set of domains represented in the RFC5322.From field. It seems >> > that the most reasonable approach is to gather the DMARC policies for >> > all addresses, and then apply the most strict. >> >> I wouldn't call that "reasonable". It's the only plausible option, but >> here's the problematic use case: >> >> Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. >> For organizational political reasons it is necessary that (a) both names >> appear on the memo and (b) Stephen has to do the dirty work. Stephen >> sends the mail "From: trent@example.com, stephen@example.org", with >> proper >> SPF and DKIM setups. Unfortunately, example.com publishes p=reject, >> example.com alignment fails because Stephen sent the message, the MTAs >> reject the message, and nobody except Trent and Stephen shows up to the >> meeting. I see two ways this message could pass DMARC: Stephen has the >> keys for example.com, or the Japanese "ringi" system, where I write and >> sign the message, send it to Trent, who then signs the message but >> otherwise forwards it verbatim. Both seem fragile to me. > > >> OTOH, only checking policies of aligned SPF source domains and DKIM >> signers means that Stephen (or any scammer) can add "POTUS@whitehouse.gov >> " >> to the From field and pass DMARC. It's obvious what the Felons of April >> would do with that. >> > >> I guess the most plausible approach to this issue is to say that if you >> want to use DMARC and have multiple authors, you must contrive to give all >> the authors mailboxes in the same domain. In the example, I could create >> the-committee.example.org for committee members, or give trent a >> forwarding mailbox at example.org itself. >> > > Ned, do you concur with this analysis? Is Trent's proposal coupled with > this caveat a valid remedy for your point? > > >> > Given all that, here's my suggested revision to Section 5.6.1.: >> > >> > ----- >> > 5.6.1. Extract Author Domain >> > >> > In order to be processed by DMARC, the domain(s) must be extracted from >> > the domain of the email address(es) within the addr-spec portion of the >> > RFC5322.From field. If the domain is encoded with UTF-8, the domain name >> > must be converted to an A-label for further processing. If no domain is >> > found, the message SHOULD be rejected (as it is forbidden under RFC 5322 >> >> I still don't think a null From filed is any business of DMARC the >> protocol. That's really an issue for (a) the security considerations >> section or (b) the planned BCP. >> > > I think we're all in agreement on that point so far. > > >> > [MAIL]). If more than one domain identifier is found, the full set of >> > domains MAY be collected as a set of identifiers for DMARC processing. >> >> But this seems to be the insecure approach I describe above: >> >> > 5. Conduct identifier alignment checks. With authentication checks >> > and policy discovery performed, the Mail Receiver checks if >> > Authenticated Identifiers fall into alignment as described in >> > Section 3. If one or more of the Authenticated Identifiers align >> > with an identifier extracted from the addr-spec of the >> > RFC5322.From domain, the message is considered to pass the >> > DMARC mechanism check. >> >> AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to >> send spam that passes DMARC on your behalf, as long as my mailbox appears >> in From, too. Am I misunderstanding your proposed algorithm? >> > > No, because in (6) the strictest rule applies. Your throwaway domain > might pass, but the other advertised author's would not. > > >> > All other conditions (authentication >> > failures, identifier mismatches) are considered to be DMARC >> > mechanism check failures. >> >> Bottom line, I think both messages where no Authenticated Identifiers can >> be extracted and those where multiple Authenticated Identifiers can be >> extracted should be defined to be mechanism check failures. In the former >> case, policy discovery is impossible, in the latter, the strictest policy >> should be applied. >> > > Right, I think that's what Trent is also saying. > > And everyone seems to agree on just dropping STARTTLS as well. > > -MSK > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --047d7bfceec06205e405075eadd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support making no change in dmarc-base-05 that might cha= nge how current mailbox providers implement dmarc-base.=C2=A0 But to the ex= tent this collection of contributors would like to see the recommendations/= requirements in section 5.6.1 updated to better harmonize with related RFC&= #39;s, I support Trent's proposal as it seems to introduce the least am= ount of increased risk to fraud.

That said, we do have p= eople here familiar with large-scale mailbox provider deployments (Google, = Yahoo!, Hotmail, etc.).=C2=A0 I'd like to ask them if they expect Trent= 's changes to have any impact on how they implement dmarc-base today.= =C2=A0 If it will, I think we should consider these changes for a future ve= rsion of dmarc-base and let this version go through with these requirements= unchanged.=C2=A0 As you all know, there are now years of experience deploy= ing dmarc-base with these requirements as written.=C2=A0 Those deployments = have had tremendous success protecting users from domain-spoofing the RFC53= 22.From field. =C2=A0

The importance of the curren= t dmarc-base specification's efficacy at blocking domain-spoofed phishi= ng attacks should not be underestimated.=C2=A0 I advise extreme caution whe= n considering any normative changes at the 11th hour.

<= div>Dear high volume MBP's, will any of these changes in Trent's pr= oposal alter how you implement dmarc-base today?

-= Brett

On Sat, Nov 8, 2014 at 2:26 AM, Murray S. Kucherawy = <superuser@gmai= l.com> wrote:
On Fri, Nov 7, 2014 at 8:57 PM, <= ;turnbull@sk= .tsukuba.ac.jp> wrote:
<= div class=3D"gmail_quote">
<= span>Trent Adams writes:

> -----
> It is important to note that identifier alignment cannot occur, and > DMARC determination applied, with a message that is not valid per RFC<= br> > 5322 [MAIL].=C2=A0 This is particularly true when a message has a malf= ormed
> or absent RFC5322.From field.
> -----

I occasionally see non-ASCII octets introduced by spam/virus checker= s in
X-Spam-* fields in the header or in the (non-8-bit) message body, due to copying message content into those contexts.=C2=A0 The From field is perfec= tly
valid, however.=C2=A0 Does that really mean that identifier alignment canno= t
occur?

(I think that is a plausible policy choice, since in an invalid message
"anything can happen".=C2=A0 But I don't see that it's a = no-brainer.)

Do you have another= suggestion?

Note that there's nothing normative in T= rent's suggestion.=C2=A0 If a receiver thinks it can continue with the = X-Spam-* fields malformed as described, then it can continue on that basis.=
=C2=A0
> Starting off, we can ignore a <null> address in the RFC532= 2.From field
> as DMARC will have no bearing in that case.=C2=A0 Similarly, when ther= e is
> exactly one address in the RFC5322.From field, application of DMARC is=
> reasonably straight forward.

By "DMARC", you really mean "DMARC policy", righ= t?=C2=A0 DMARC the protocol
does need to say something about what happens if alignment fails or no
policy can be discovered.

That&#= 39;s how I understood what he said.
=C2=A0
> That leaves taking some action based on the DMARC policies assoc= iated
> with the set of domains represented in the RFC5322.From field.=C2=A0 I= t seems
> that the most reasonable approach is to gather the DMARC policies for<= br> > all addresses, and then apply the most strict.

I wouldn't call that "reasonable".=C2=A0 It's the = only plausible option, but
here's the problematic use case:

Co-Chairs Trent and Stephen decide to hold a meeting of The Committee.
For organizational political reasons it is necessary that (a) both names appear on the memo and (b) Stephen has to do the dirty work.=C2=A0 Stephen<= br> sends the mail "From: trent@example.com, stephen@example.org", with proper
SPF and DKIM setups.=C2=A0 Unfortunately, example.com publishes p=3Dreject,
example.com alignment = fails because Stephen sent the message, the MTAs
reject the message, and nobody except Trent and Stephen shows up to the
meeting.=C2=A0 I see two ways this message could pass DMARC: Stephen has th= e
keys for example.com, = or the Japanese "ringi" system, where I write and
sign the message, send it to Trent, who then signs the message but
otherwise forwards it verbatim.=C2=A0 Both seem fragile to me.=C2=A0

OTOH, only checking policies of aligned SPF source domains and DKIM
signers means that Stephen (or any scammer) can add "POTUS@whitehouse.gov"
to the From field and pass DMARC.=C2=A0 It's obvious what the Felons of= April
would do with that.

I guess the most plausible approach to this issue is to say that if you
want to use DMARC and have multiple authors, you must contrive to give all<= br> the authors mailboxes in the same domain.=C2=A0 In the example, I could cre= ate
the-committe= e.example.org for committee members, or give trent a
forwarding mailbox at exam= ple.org itself.

Ned, do= you concur with this analysis?=C2=A0 Is Trent's proposal coupled with = this caveat a valid remedy for your point?
=C2=A0
> Given all that, here's my suggested revision to Section 5.6.1.:
>
> -----
> 5.6.1.=C2=A0 Extract Author Domain
>
> In order to be processed by DMARC, the domain(s) must be extracted fro= m
> the domain of the email address(es) within the addr-spec portion of th= e
> RFC5322.From field. If the domain is encoded with UTF-8, the domain na= me
> must be converted to an A-label for further processing. If no domain i= s
> found, the message SHOULD be rejected (as it is forbidden under RFC 53= 22

I still don't think a null From filed is any business of DMARC t= he
protocol.=C2=A0 That's really an issue for (a) the security considerati= ons
section or (b) the planned BCP.

= I think we're all in agreement on that point so far.
=C2=A0
> [MAIL]).=C2=A0 If more than one domain identifier is found, the = full set of
> domains MAY be collected as a set of identifiers for DMARC processing.=

But this seems to be the insecure approach I describe above:

>=C2=A0 =C2=A0 5.=C2=A0 Conduct identifier alignment checks.=C2=A0 With = authentication checks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and policy discovery performed, the Mail Re= ceiver checks if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authenticated Identifiers fall into alignme= nt as described in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 3.=C2=A0 If one or more of the Auth= enticated Identifiers align
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 with an identifier extracted from the addr-= spec of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC5322.From domain, the message is conside= red to pass the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 DMARC mechanism check.

AFAICS this allows me (using a throwaway mailbox at a throwaway doma= in) to
send spam that passes DMARC on your behalf, as long as my mailbox appears in From, too.=C2=A0 Am I misunderstanding your proposed algorithm?

No, because in (6) the strictest rule ap= plies.=C2=A0 Your throwaway domain might pass, but the other advertised aut= hor's would not.
=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 All other conditions (authentication<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 failures, identifier mismatches) are consid= ered to be DMARC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanism check failures.

Bottom line, I think both messages where no Authenticated Identifier= s can
be extracted and those where multiple Authenticated Identifiers can be
extracted should be defined to be mechanism check failures.=C2=A0 In the fo= rmer
case, policy discovery is impossible, in the latter, the strictest policy should be applied.

Right, I thin= k that's what Trent is also saying.

And everyone seem= s to agree on just dropping STARTTLS as well.

-MSK

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


--047d7bfceec06205e405075eadd6-- From nobody Sat Nov 8 15:00:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DEB1A0277 for ; Sat, 8 Nov 2014 15:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JbctQQCTlwr for ; Sat, 8 Nov 2014 15:00:44 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 5893F1A0276 for ; Sat, 8 Nov 2014 15:00:43 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3jZv8B0gf9z1L8cw; Sun, 9 Nov 2014 00:00:42 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3jZv892mfdz1L8cr; Sun, 9 Nov 2014 00:00:41 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 03BE412335F; Sun, 9 Nov 2014 00:00:43 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5rbtNbikQBNq; Sun, 9 Nov 2014 00:00:33 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id F006A12343F; Sun, 9 Nov 2014 00:00:32 +0100 (CET) Message-ID: <545EA08E.8080405@sonnection.nl> Date: Sun, 09 Nov 2014 00:00:30 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brett McDowell , "Murray S. Kucherawy" References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000907060105010402010907" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1415487642; bh=86hCi66TaZfSb9DYYNl1mFx4wjW3GsfbdhR0cI+uirA=; h=Message-ID:Date:From:To:Subject:From; b=kxnhKRCUYxGtng5Kbgw/ajDPNlcFUc5LW2DcAsrH/UlEE5vgMZiBVUifafn3PLeAy vVLGRihJjDjuWCXzVFRSJ3HSgB5UXFM5GdmPLVCRC3+0Ron2gvz+LTDfbZnkeqJgTQ h6Ob0X+rky1S9bYIsi+jofswof0FmVnJKlD4U7VQ= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3jZv8B0gf9z1L8cw Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_rYmT4qH_AUfOyVP3yhkUMzq_Gg Cc: "dmarc@ietf.org" , "J. Trent Adams" , "Stephen J. Turnbull" , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 23:00:48 -0000 This is a multi-part message in MIME format. --------------000907060105010402010907 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 11/08/2014 09:20 PM, Brett McDowell wrote: > I support making no change in dmarc-base-05 that might change how > current mailbox providers implement dmarc-base. But to the extent > this collection of contributors would like to see the > recommendations/requirements in section 5.6.1 updated to better > harmonize with related RFC's, I support Trent's proposal as it seems > to introduce the least amount of increased risk to fraud. > > That said, we do have people here familiar with large-scale mailbox > provider deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask > them if they expect Trent's changes to have any impact on how they > implement dmarc-base today. If it will, I think we should consider > these changes for a future version of dmarc-base and let this version > go through with these requirements unchanged. As you all know, there > are now years of experience deploying dmarc-base with these > requirements as written. Those deployments have had tremendous > success protecting users from domain-spoofing the RFC5322.From field. > > The importance of the current dmarc-base specification's efficacy at > blocking domain-spoofed phishing attacks should not be > underestimated. I advise extreme caution when considering any > normative changes at the 11th hour. > > Dear high volume MBP's, will any of these changes in Trent's proposal > alter how you implement dmarc-base today? The current effort to publish DMARC as informational RFC is mainly, to document the current specification 'as is', to be able to refer from other documents to a published spec. The concerns raised by Ned and the proposal of Trent try to address situations, where the spec does not yet describe what to do (RFC5322.From with multiple addresses), or leaves room for different interpretations/implementations. As such I welcome the text proposed by Trent. If the big MBP's deviate from what that text describes, then in my opinion: * either this is part of the 'secret sauce' which is being applied by Mail Receivers anyway (no matter what a spec will prescribe) * or (better) the big MBP's will need to come up with text describing what their implementations will do in these specific cases. Not changing the text, because the MBP's might have implemented these cases in a different way than what is being proposed here, but not documenting that way, is not a good idea, IMHO. /rolf --------------000907060105010402010907 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 11/08/2014 09:20 PM, Brett McDowell wrote:
I support making no change in dmarc-base-05 that might change how current mailbox providers implement dmarc-base.=A0 But to the extent this collection of contributors would like to see the recommendations/requirements in section 5.6.1 updated to better harmonize with related RFC's, I support Trent's proposal as it seems to introduce the least amount of increased risk to fraud.

That said, we do have people here familiar with large-scale mailbox provider deployments (Google, Yahoo!, Hotmail, etc.).=A0 I'd like to ask them if they expect Trent's changes to have any impact on how they implement dmarc-base today.=A0 If it will, I think we should consider these changes for a future version of dmarc-base and let this version go through with these requirements unchanged.=A0 As you all know, there are now years of experience deploying dmarc-base with these requirements as written.=A0 Those deployments have had tremendous success protecting users from domain-spoofing the RFC5322.From field. =A0

The importance of the current dmarc-base specification's efficacy at blocking domain-spoofed phishing attacks should not be underestimated.=A0 I advise extreme caution when considering any normative changes at the 11th hour.

Dear high volume MBP's, will any of these changes in Trent's proposal alter how you implement dmarc-base today?

The current effort to publish DMARC as informational RFC is mainly, to document the current specification 'as is', to be able to refer from other documents to a published spec. The concerns raised by Ned and the proposal of Trent try to address situations, where the spec does not yet describe what to do (RFC5322.From with multiple addresses), or leaves room for different interpretations/implementations. As such I welcome the text proposed by Trent. If the big MBP's deviate from what that text describes, then in my opinion:

  • either this is part of the 'secret sauce' which is being applied by Mail Receivers anyway (no matter what a spec will prescribe)
  • or (better) the big MBP's will need to come up with text describing what their implementations will do in these specific cases.

Not changing the text, because the MBP's might have implemented these cases in a different way than what is being proposed here, but not documenting that way, is not a good idea, IMHO.

/rolf
--------------000907060105010402010907-- From nobody Sat Nov 8 15:10:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812601A0277 for ; Sat, 8 Nov 2014 15:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.462 X-Spam-Level: * X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C7ixn5R1VUb for ; Sat, 8 Nov 2014 15:10:45 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3986D1A0183 for ; Sat, 8 Nov 2014 15:10:45 -0800 (PST) Received: (qmail 34836 invoked from network); 8 Nov 2014 23:10:43 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 8 Nov 2014 23:10:43 -0000 Date: 8 Nov 2014 23:10:21 -0000 Message-ID: <20141108231021.11922.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/THQWmQwi6DzYtjhel3V3QSq91co Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 23:10:46 -0000 >> I occasionally see non-ASCII octets introduced by spam/virus checkers in >> X-Spam-* fields in the header or in the (non-8-bit) message body, due to >> copying message content into those contexts. The From field is perfectly >> valid, however. Does that really mean that identifier alignment cannot >> occur? >> >> (I think that is a plausible policy choice, since in an invalid message >> "anything can happen". But I don't see that it's a no-brainer.) > >Do you have another suggestion? I don't see how we can offer useful advice beyond noting that strange things can happen if the message isn't 5322 compliant. On my mail system in the US, random headers with stray high bits are an extremely reliable indicator of botful spamminess, while in Japan, apparently it happens innocently all the time. >> Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. >> For organizational political reasons it is necessary that (a) both names >> appear on the memo and (b) Stephen has to do the dirty work. Stephen >> sends the mail "From: trent@example.com, stephen@example.org", with proper >> SPF and DKIM setups. Unfortunately, example.com publishes p=reject, >> example.com alignment fails because Stephen sent the message, the MTAs >> reject the message, and nobody except Trent and Stephen shows up to the >> meeting. If I may be direct, "our policies don't match what our users do but it's your problem" is not exactly a new issue with DMARC. Let's make a deal: if you fix the mailing list problem, I'll fix this problem, and I can probably do it for free since the plausible fixes for mailing lists (e.g., double signing, trusted forwarders) would probably work here, too. R's, John From nobody Sat Nov 8 17:29:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DF81A0030 for ; Sat, 8 Nov 2014 17:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tP6yEONqzwxA for ; Sat, 8 Nov 2014 17:29:38 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id E5BDB1A0073 for ; Sat, 8 Nov 2014 17:29:36 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 40DC55659AB; Sat, 8 Nov 2014 19:29:36 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3910260233; Sat, 8 Nov 2014 19:29:36 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBj0VAEBBRjb; Sat, 8 Nov 2014 19:29:36 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id F3ABA6035D; Sat, 8 Nov 2014 19:29:35 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com F3ABA6035D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415496576; bh=99ZBgjEapsHyyU+5eEg7mhxtdo8fM9CnXk+PsN2q1RQ=; h=Content-Type:From:Mime-Version:Subject:Message-Id:Date:To; b=EwmZXMA0LWnbZozYd3pdmUuILlW3YOsKwymFpkVFx6yqgcPtbD8P2T1jxfyK5oyaF 4sm//kjAUmjQAtuMbx1249UFoYFy1+buvHqpzS7GI6CqbJympNBdgP0E4We5RjV+Cj hC6p3pMrvpfbWR8yrcnSuSJcRW/onVqPs6BH+c7A= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id DC81B60352; Sat, 8 Nov 2014 19:29:35 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4uXFpglt56EV; Sat, 8 Nov 2014 19:29:35 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id AEC6860233; Sat, 8 Nov 2014 19:29:35 -0600 (CST) Content-Type: multipart/alternative; boundary=Apple-Mail-E1952D76-2B2B-4D59-90DC-CF7448E44B83 From: Franck Martin Mime-Version: 1.0 Message-Id: <35668414-6334-4BCD-B6C8-A471000D72C5@peachymango.org> Date: Sat, 8 Nov 2014 19:29:35 -0600 (CST) References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> To: "Murray S. Kucherawy" In-Reply-To: X-Mailer: Zimbra 8.0.5_GA_5839 (MobileSync - Apple-iPad4C1/1202.410) Thread-Topic: draft-kucherawy-dmarc-base feedback Thread-Index: 6JX/tvy6TVIAZ5KLtOnplVCxBLGNxg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/l-d_tqUT5x239_YRtt29_dQd8WI Cc: "dmarc@ietf.org" , Ned Freed Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 01:29:42 -0000 --Apple-Mail-E1952D76-2B2B-4D59-90DC-CF7448E44B83 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable See inline.... Printed on recycled paper! > On Nov 6, 2014, at 23:16, Murray S. Kucherawy wrote:= >=20 >> On Thu, Nov 6, 2014 at 11:06 AM, Ned Freed wrote:= >> In the step 7 in section 3.1.3, I think it would be helpful to add a sent= ence >> about the determination of the organizational domain from the author doma= in. >> Step 7 is also pretty large; you might want to consider breaking it up in= to >> substeps or something along those lines. >=20 > OK. > =20 >> Another problem with step 7 is the statement "small number of further DNS= >> queries to the Organizational Domain" is incorrect. Per step 1 in section= >> 5.6.3, the author domain is queried first, then the organizational domain= if >> that fails to produce a viable result. This needs to be fixed, and adding= a >> reference to section 5.6.3 would be a good idea. >=20 > "small number" is "at most two", and "to the Organizational Domain" is mea= nt to include its subdomains, so I guess what's meant is to the Organization= al Domain's zone, or something like that. I'll tidy it up. Good suggestion= on a forward reference. >=20 >> In section 3.1.4, the paragraph >>=20 >> It is important to note that identifier alignment cannot occur with a >> message that is not valid per [MAIL], particularly one with a >> malformed or absent RFC5322.=46rom field. Handling of such cases is >> left to the discretion of the Mail Receiver. >>=20 >> doesn't really make sense to me. If the From: field is missing or is so >> malformed that a domain cannot be extracted from it, it isn't a question o= f >> alignment to other fields, but rather that there's no way to determine a D= MARC >> policy that applies to the message to begin with. Shouldn't that be the p= rimary >> reason invalid mail is problematic? Am I missing something here? >=20 > No, I think you've got it, but I'm not clear on how the paragraph you cite= d doesn't say that. You have it exactly right: If From: is missing or so ma= ngled that it's not possible to get a domain out, then there's nothing to wh= ich DKIM and SPF can align, and DMARC can't be applied. There might be othe= r mangling though, like multiple From: fields that are properly formed but c= ontain distinct values, in which case we don't know to which one to apply al= ignment. Note that an email with no RFC 5322 field is not valid, as well as one with m= ore than 1. This header is mandatory as well as the Date header. These are t= he only 2 headers mandatory in an email. So rejecting an email with no RFC 5322 or more than one is just following th= e RFC. I'm not talking on how many mailboxes/domain there are in this header. >=20 >> I'm not sure the use of a cousin domain in the example given in paragraph= 5 of >> section 3.1.4.1 is a good idea. The point of using a cousin domain in an a= ttack >> is that users will confuse/conflate that domain with a legitimate domain.= (And >> this is important in the context of this document because DMARC doesn't d= o >> anything to prevent this attack in a From: field.) But the reason identif= ier >> alignment is important isn't that the use of a cousin domain in a DKIM >> signature, MAIL FROM, or EHLO/HELO field could cause problems, it's that >> without alignment a bad actor could freely use any domain whatsoever in t= hese >> places. Users generally don't see these fields so why bother using a simi= lar >> name? The way the section is written makes it sound like protecting again= st the >> use of cousin domains in particular is important. Unless I'm missing some= thing, >> that's not the case. >=20 > I agree. That paragraph should go. > =20 >> There's a bit of tension between section 5.5, which says that all you nee= d to >> do to "implement the DMARC mechanism" is publish DMARC records in the DNS= , and >> the diagram and list in section 3.1.3, which make it sound like deploying= both >> DKIM and SPF are a required part of DMARC setup and operation. I'm not su= re >> what, if anything, should be done about this, but I thought it worth noti= ng. >=20 > I'll see if I can tidy it up. > =20 >> There's a big problem in section 5.6.1, where it says that any message wi= th >> more than one address or an empty group in an RFC5322.=46rom field SHOULD= be >> rejected. >>=20 >> I have to say I find this recommendation to be completely inappropriate. S= urely >> it should be possible for me to a legitimate, syntactically valid message= that >> happens to employ the multiple-from/sender format defined in RFC 5322 wit= h all >> the domains under my personal control and none publish any sort of DMARC >> policy, and not have the application of DMARC to the overall message flow= mess >> it up? Or alternately, one where the From: field contains an empty group,= >> something we actually recently went to the trouble of writing RFC 6854 to= >> allow? >=20 > As I recall, there were some surveys of some pretty large email streams, a= nd not a single instance of a From: field containing other than a single mai= lbox could be found that wasn't also part of something either spammy or some= kind of attempt to confound spam filters, or just grossly malformed and unu= sable. This led the original DMARC community to what you see there now. Th= ere was no deliberate rejection of the RFC 6854 format, but just rather no o= bserved valid use of it. Note that RFC 6854 format is a "transitional" RFC. The applicability stateme= nt clearly indicates this syntax is to be used for non SMTPUTF8 aware MTA wh= en receiving mail from an upstream MTA SMTPUTF8 aware as a convenience and u= nder security considerations left to the receiver. So in my view if your rec= eiving MTA does SMTPUTF8 then there is little reason to accept this syntax. I always had a problem with RFC 6854 and opposed it in last call as it surpr= ised me the IETF would prefer convenience for security. The result was to st= rongly limit the applicability of this RFC. >=20 >> Sure, some clients may barf on such things, but that's a problem for whoe= ver >> opts to use the mechanisms, not DMARC. >>=20 >> I have no absolutely problem with rejecting messages with From: fields >> containing any sort of domain identifier that has any sort of attached DM= ARC >> policy because of how that From: field is constructed. But intruding on >> legitate uses of email that choose not to employ DMARC in any capacity go= es >> much too far. And it isn't helped by the fact that the DMARC reporting >> mechanisms are meaningless when there's no domain owner to report these >> rejections to. >=20 > What sort of remedy would you suggest here? Off the top of my head, here a= re some suggestions: >=20 > 1) Evaluate all the domains you find, and if any of them have published DM= ARC policies, apply the strictest one (by that I mean: if there are any with= p=3Dreject that fail, then reject it; if there are any with p=3Dquarantine,= quarantine it); if not, treat the message as if DMARC simply did not apply.= >=20 > 2) Evaluate only the first domain you find, if any. >=20 > 3) Same as (1), but limit it to some fixed (configurable?) number of domai= ns. My solution is that if all the domains are part of the same organisational d= omain, then the task is easy, you apply the policy of the organizational dom= ain, otherwise you reject the email. I found .NET early version uses an invalid syntax, that creates the appearan= ce of 2 mailboxes. If all domains are in the same organizational domain this= prevent to reject a bunch of .NET generated emails. >=20 >> There's also a direct contradiction between the third bullet item in sect= ion >> 5.6.1, which says that a message without a From: field SHOULD be rejected= , and >> the fourth paragraph of section 3.1.4, which leaves this same case to the= >> discretion of the mail receiver. Furthermore, does it really make sense t= o give >> malformed From: fields a pass - someomthing which could easily contain an= >> identifier that has an attached DMARC policy - and require rejection of >> completely legitimate stuff with no DMARC policy in sight? >=20 > We've covered the latter point above, but as to the point about malformati= on: Can you reliably extract a domain name from a malformed From: field? Th= at seems to be a vector for trying to confuse a DMARC filter if the advice i= s to try anyway. > =20 >> I could have missed it, but I don't see any place where the semantics of h= ow >> DKIM and SPF are combined (as an it's an OR) is specified prior to item 5= in >> section 5.6.2. If this is indeed the case, then this is bad: The way the >> mechanisms are combined needs to be made clear much sooner. I note in pas= sing >> that we've already had a case on this list where someone misunderstood th= is >> detail. >=20 > Section 5, third paragraph, is the first formal statement of this kind. A= dding one somewhere up earlier in one of the overview sections would probabl= y be a good idea. > =20 >> Section 6.2.2.1 states: >>=20 >> In the case of a "mailto" URI, the Mail Receiver MUST communicate >> reports using the method described in [STARTTLS] whenever it is >> offered by a Report Receiver. >>=20 >> I seriously question the value or appropriateness of this paragraph. So y= our >> DMARC agent, assuming it actually goes through a SUBMIT server and not th= rough >> an internal API, uses STARTTLS to secure that connection. Now what? At pr= esent >> there's no standardized way to indicate in a message that it has to be >> transported securely. So if you really want that, that leaves configurati= on - a >> configuration that spans an essentially arbitrary set of transport agents= , to >> enforce this. At least part of which would have to be enforced by the tar= get of >> the mailto: to have any chance of being effective. >>=20 >> It's poor practice to have MUSTs in specifications that we know are going= to be >> ignored. It's also poor practice to have MUSTs that don't actually accomp= lish >> much of anything as written. As such, I strongly recommend dumping this, o= r at >> least making it a SHOULD. >=20 > I'd be fine with making it a SHOULD, exactly because of these reasons. > =20 >> Section 9.3 recommends using reply codes during the SMTP session rather t= han >> doing anything that would require sending a DSN later, but doesn't come o= ut and >> say that the reason for doing this is to avoid blowback spam. I think it w= ould >> be clearer to be explicit about why these policies are a good idea. >=20 > Sounds good to me. >=20 > Thanks! >=20 > -MSK=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-E1952D76-2B2B-4D59-90DC-CF7448E44B83 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+U2VlIGlu bGluZS4uLi48YnI+PGJyPlByaW50ZWQgb24gcmVjeWNsZWQgcGFwZXIhPC9kaXY+PGRpdj48YnI+ T24gTm92IDYsIDIwMTQsIGF0IDIzOjE2LCBNdXJyYXkgUy4gS3VjaGVyYXd5ICZsdDs8YSBocmVm PSJtYWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNvbSI+c3VwZXJ1c2VyQGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48bWV0YSBo dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYt OCI+PGRpdiBkaXI9Imx0ciI+T24gVGh1LCBOb3YgNiwgMjAxNCBhdCAxMTowNiBBTSwgTmVkIEZy ZWVkIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOm5lZC5mcmVlZEBtcm9jaGVr LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5lZC5mcmVlZEBtcm9jaGVrLmNvbTwvYT4mZ3Q7PC9zcGFu PiB3cm90ZTo8YnI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAg LjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij5JbiB0aGUg c3RlcCA3IGluIHNlY3Rpb24gMy4xLjMsIEkgdGhpbmsgaXQgd291bGQgYmUgaGVscGZ1bCB0byBh ZGQgYSBzZW50ZW5jZTxicj4NCmFib3V0IHRoZSBkZXRlcm1pbmF0aW9uIG9mIHRoZSBvcmdhbml6 YXRpb25hbCBkb21haW4gZnJvbSB0aGUgYXV0aG9yIGRvbWFpbi48YnI+DQpTdGVwIDcgaXMgYWxz byBwcmV0dHkgbGFyZ2U7IHlvdSBtaWdodCB3YW50IHRvIGNvbnNpZGVyIGJyZWFraW5nIGl0IHVw IGludG88YnI+DQpzdWJzdGVwcyBvciBzb21ldGhpbmcgYWxvbmcgdGhvc2UgbGluZXMuPGJyPjwv YmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9LLjxicj4mbmJzcDs8YnI+PC9kaXY+PGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpBbm90aGVyIHByb2Js ZW0gd2l0aCBzdGVwIDcgaXMgdGhlIHN0YXRlbWVudCAic21hbGwgbnVtYmVyIG9mIGZ1cnRoZXIg RE5TPGJyPg0KcXVlcmllcyB0byB0aGUgT3JnYW5pemF0aW9uYWwgRG9tYWluIiBpcyBpbmNvcnJl Y3QuIFBlciBzdGVwIDEgaW4gc2VjdGlvbjxicj4NCjUuNi4zLCB0aGUgYXV0aG9yIGRvbWFpbiBp cyBxdWVyaWVkIGZpcnN0LCB0aGVuIHRoZSBvcmdhbml6YXRpb25hbCBkb21haW4gaWY8YnI+DQp0 aGF0IGZhaWxzIHRvIHByb2R1Y2UgYSB2aWFibGUgcmVzdWx0LiBUaGlzIG5lZWRzIHRvIGJlIGZp eGVkLCBhbmQgYWRkaW5nIGE8YnI+DQpyZWZlcmVuY2UgdG8gc2VjdGlvbiA1LjYuMyB3b3VsZCBi ZSBhIGdvb2QgaWRlYS48YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+InNtYWxs IG51bWJlciIgaXMgImF0IG1vc3QgdHdvIiwgYW5kICJ0byB0aGUgT3JnYW5pemF0aW9uYWwgRG9t YWluIiBpcyBtZWFudCB0byBpbmNsdWRlIGl0cyBzdWJkb21haW5zLCBzbyBJIGd1ZXNzIHdoYXQn cyBtZWFudCBpcyB0byB0aGUgT3JnYW5pemF0aW9uYWwgRG9tYWluJ3Mgem9uZSwgb3Igc29tZXRo aW5nIGxpa2UgdGhhdC4mbmJzcDsgSSdsbCB0aWR5IGl0IHVwLiZuYnNwOyBHb29kIHN1Z2dlc3Rp b24gb24gYSBmb3J3YXJkIHJlZmVyZW5jZS48YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNz PSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAj Y2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KSW4gc2VjdGlvbiAzLjEuNCwgdGhlIHBhcmFn cmFwaDxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtJdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0 IGlkZW50aWZpZXIgYWxpZ25tZW50IGNhbm5vdCBvY2N1ciB3aXRoIGE8YnI+DQombmJzcDsgJm5i c3A7bWVzc2FnZSB0aGF0IGlzIG5vdCB2YWxpZCBwZXIgW01BSUxdLCBwYXJ0aWN1bGFybHkgb25l IHdpdGggYTxicj4NCiZuYnNwOyAmbmJzcDttYWxmb3JtZWQgb3IgYWJzZW50IFJGQzUzMjIuRnJv bSBmaWVsZC4mbmJzcDsgSGFuZGxpbmcgb2Ygc3VjaCBjYXNlcyBpczxicj4NCiZuYnNwOyAmbmJz cDtsZWZ0IHRvIHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBNYWlsIFJlY2VpdmVyLjxicj4NCjxicj4N CmRvZXNuJ3QgcmVhbGx5IG1ha2Ugc2Vuc2UgdG8gbWUuIElmIHRoZSBGcm9tOiBmaWVsZCBpcyBt aXNzaW5nIG9yIGlzIHNvPGJyPg0KbWFsZm9ybWVkIHRoYXQgYSBkb21haW4gY2Fubm90IGJlIGV4 dHJhY3RlZCBmcm9tIGl0LCBpdCBpc24ndCBhIHF1ZXN0aW9uIG9mPGJyPg0KYWxpZ25tZW50IHRv IG90aGVyIGZpZWxkcywgYnV0IHJhdGhlciB0aGF0IHRoZXJlJ3Mgbm8gd2F5IHRvIGRldGVybWlu ZSBhIERNQVJDPGJyPg0KcG9saWN5IHRoYXQgYXBwbGllcyB0byB0aGUgbWVzc2FnZSB0byBiZWdp biB3aXRoLiBTaG91bGRuJ3QgdGhhdCBiZSB0aGUgcHJpbWFyeTxicj4NCnJlYXNvbiBpbnZhbGlk IG1haWwgaXMgcHJvYmxlbWF0aWM/IEFtIEkgbWlzc2luZyBzb21ldGhpbmcgaGVyZT88YnI+PC9i bG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+Tm8sIEkgdGhpbmsgeW91J3ZlIGdvdCBpdCwg YnV0IEknbSBub3QgY2xlYXIgb24gaG93IHRoZSBwYXJhZ3JhcGggeW91IGNpdGVkIGRvZXNuJ3Qg c2F5IHRoYXQuJm5ic3A7IFlvdSBoYXZlIGl0IGV4YWN0bHkgcmlnaHQ6IElmIEZyb206IGlzIG1p c3Npbmcgb3Igc28gbWFuZ2xlZCB0aGF0IGl0J3Mgbm90IHBvc3NpYmxlIHRvIGdldCBhIGRvbWFp biBvdXQsIHRoZW4gdGhlcmUncyBub3RoaW5nIHRvIHdoaWNoIERLSU0gYW5kIFNQRiBjYW4gYWxp Z24sIGFuZCBETUFSQyBjYW4ndCBiZSBhcHBsaWVkLiZuYnNwOyBUaGVyZSBtaWdodCBiZSBvdGhl ciBtYW5nbGluZyB0aG91Z2gsIGxpa2UgbXVsdGlwbGUgRnJvbTogZmllbGRzIHRoYXQgYXJlIHBy b3Blcmx5IGZvcm1lZCBidXQgY29udGFpbiBkaXN0aW5jdCB2YWx1ZXMsIGluIHdoaWNoIGNhc2Ug d2UgZG9uJ3Qga25vdyB0byB3aGljaCBvbmUgdG8gYXBwbHkgYWxpZ25tZW50Ljxicj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+Tm90ZSB0 aGF0IGFuIGVtYWlsIHdpdGggbm8gUkZDIDUzMjIgZmllbGQgaXMgbm90IHZhbGlkLCBhcyB3ZWxs IGFzIG9uZSB3aXRoIG1vcmUgdGhhbiAxLiBUaGlzIGhlYWRlciBpcyBtYW5kYXRvcnkgYXMgd2Vs bCBhcyB0aGUgRGF0ZSBoZWFkZXIuIFRoZXNlIGFyZSB0aGUgb25seSAyIGhlYWRlcnMgbWFuZGF0 b3J5IGluIGFuIGVtYWlsLjxkaXY+PGJyPjwvZGl2PjxkaXY+U28gcmVqZWN0aW5nIGFuIGVtYWls IHdpdGggbm8gUkZDIDUzMjIgb3IgbW9yZSB0aGFuIG9uZSBpcyBqdXN0IGZvbGxvd2luZyB0aGUg UkZDLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSdtIG5vdCB0YWxraW5nIG9uIGhvdyBtYW55 IG1haWxib3hlcy9kb21haW4gdGhlcmUgYXJlIGluIHRoaXMgaGVhZGVyLjxicj48ZGl2Pjxicj48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxkaXYgZGlyPSJsdHIiPjxkaXYgY2xhc3M9Imdt YWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdj48YnI+PC9kaXY+PGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpJJ20gbm90IHN1cmUgdGhl IHVzZSBvZiBhIGNvdXNpbiBkb21haW4gaW4gdGhlIGV4YW1wbGUgZ2l2ZW4gaW4gcGFyYWdyYXBo IDUgb2Y8YnI+DQpzZWN0aW9uIDMuMS40LjEgaXMgYSBnb29kIGlkZWEuIFRoZSBwb2ludCBvZiB1 c2luZyBhIGNvdXNpbiBkb21haW4gaW4gYW4gYXR0YWNrPGJyPg0KaXMgdGhhdCB1c2VycyB3aWxs IGNvbmZ1c2UvY29uZmxhdGUgdGhhdCBkb21haW4gd2l0aCBhIGxlZ2l0aW1hdGUgZG9tYWluLiAo QW5kPGJyPg0KdGhpcyBpcyBpbXBvcnRhbnQgaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkb2N1bWVu dCBiZWNhdXNlIERNQVJDIGRvZXNuJ3QgZG88YnI+DQphbnl0aGluZyB0byBwcmV2ZW50IHRoaXMg YXR0YWNrIGluIGEgRnJvbTogZmllbGQuKSBCdXQgdGhlIHJlYXNvbiBpZGVudGlmaWVyPGJyPg0K YWxpZ25tZW50IGlzIGltcG9ydGFudCBpc24ndCB0aGF0IHRoZSB1c2Ugb2YgYSBjb3VzaW4gZG9t YWluIGluIGEgREtJTTxicj4NCnNpZ25hdHVyZSwgTUFJTCBGUk9NLCBvciBFSExPL0hFTE8gZmll bGQgY291bGQgY2F1c2UgcHJvYmxlbXMsIGl0J3MgdGhhdDxicj4NCndpdGhvdXQgYWxpZ25tZW50 IGEgYmFkIGFjdG9yIGNvdWxkIGZyZWVseSB1c2UgYW55IGRvbWFpbiB3aGF0c29ldmVyIGluIHRo ZXNlPGJyPg0KcGxhY2VzLiBVc2VycyBnZW5lcmFsbHkgZG9uJ3Qgc2VlIHRoZXNlIGZpZWxkcyBz byB3aHkgYm90aGVyIHVzaW5nIGEgc2ltaWxhcjxicj4NCm5hbWU/IFRoZSB3YXkgdGhlIHNlY3Rp b24gaXMgd3JpdHRlbiBtYWtlcyBpdCBzb3VuZCBsaWtlIHByb3RlY3RpbmcgYWdhaW5zdCB0aGU8 YnI+DQp1c2Ugb2YgY291c2luIGRvbWFpbnMgaW4gcGFydGljdWxhciBpcyBpbXBvcnRhbnQuIFVu bGVzcyBJJ20gbWlzc2luZyBzb21ldGhpbmcsPGJyPg0KdGhhdCdzIG5vdCB0aGUgY2FzZS48YnI+ PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBhZ3JlZS4mbmJzcDsgVGhhdCBwYXJh Z3JhcGggc2hvdWxkIGdvLjxicj4mbmJzcDs8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9Imdt YWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mg c29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpUaGVyZSdzIGEgYml0IG9mIHRlbnNpb24gYmV0d2Vl biBzZWN0aW9uIDUuNSwgd2hpY2ggc2F5cyB0aGF0IGFsbCB5b3UgbmVlZCB0bzxicj4NCmRvIHRv ICJpbXBsZW1lbnQgdGhlIERNQVJDIG1lY2hhbmlzbSIgaXMgcHVibGlzaCBETUFSQyByZWNvcmRz IGluIHRoZSBETlMsIGFuZDxicj4NCnRoZSBkaWFncmFtIGFuZCBsaXN0IGluIHNlY3Rpb24gMy4x LjMsIHdoaWNoIG1ha2UgaXQgc291bmQgbGlrZSBkZXBsb3lpbmcgYm90aDxicj4NCkRLSU0gYW5k IFNQRiBhcmUgYSByZXF1aXJlZCBwYXJ0IG9mIERNQVJDIHNldHVwIGFuZCBvcGVyYXRpb24uIEkn bSBub3Qgc3VyZTxicj4NCndoYXQsIGlmIGFueXRoaW5nLCBzaG91bGQgYmUgZG9uZSBhYm91dCB0 aGlzLCBidXQgSSB0aG91Z2h0IGl0IHdvcnRoIG5vdGluZy48YnI+PC9ibG9ja3F1b3RlPjxkaXY+ PGJyPjwvZGl2PjxkaXY+SSdsbCBzZWUgaWYgSSBjYW4gdGlkeSBpdCB1cC48YnI+Jm5ic3A7PGJy PjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAg MCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KVGhl cmUncyBhIGJpZyBwcm9ibGVtIGluIHNlY3Rpb24gNS42LjEsIHdoZXJlIGl0IHNheXMgdGhhdCBh bnkgbWVzc2FnZSB3aXRoPGJyPg0KbW9yZSB0aGFuIG9uZSBhZGRyZXNzIG9yIGFuIGVtcHR5IGdy b3VwIGluIGFuIFJGQzUzMjIuRnJvbSBmaWVsZCBTSE9VTEQgYmU8YnI+DQpyZWplY3RlZC48YnI+ DQo8YnI+DQpJIGhhdmUgdG8gc2F5IEkgZmluZCB0aGlzIHJlY29tbWVuZGF0aW9uIHRvIGJlIGNv bXBsZXRlbHkgaW5hcHByb3ByaWF0ZS4gU3VyZWx5PGJyPg0KaXQgc2hvdWxkIGJlIHBvc3NpYmxl IGZvciBtZSB0byBhIGxlZ2l0aW1hdGUsIHN5bnRhY3RpY2FsbHkgdmFsaWQgbWVzc2FnZSB0aGF0 PGJyPg0KaGFwcGVucyB0byBlbXBsb3kgdGhlIG11bHRpcGxlLWZyb20vc2VuZGVyIGZvcm1hdCBk ZWZpbmVkIGluIFJGQyA1MzIyIHdpdGggYWxsPGJyPg0KdGhlIGRvbWFpbnMgdW5kZXIgbXkgcGVy c29uYWwgY29udHJvbCBhbmQgbm9uZSBwdWJsaXNoIGFueSBzb3J0IG9mIERNQVJDPGJyPg0KcG9s aWN5LCBhbmQgbm90IGhhdmUgdGhlIGFwcGxpY2F0aW9uIG9mIERNQVJDIHRvIHRoZSBvdmVyYWxs IG1lc3NhZ2UgZmxvdyBtZXNzPGJyPg0KaXQgdXA/IE9yIGFsdGVybmF0ZWx5LCBvbmUgd2hlcmUg dGhlIEZyb206IGZpZWxkIGNvbnRhaW5zIGFuIGVtcHR5IGdyb3VwLDxicj4NCnNvbWV0aGluZyB3 ZSBhY3R1YWxseSByZWNlbnRseSB3ZW50IHRvIHRoZSB0cm91YmxlIG9mIHdyaXRpbmcgUkZDIDY4 NTQgdG88YnI+DQphbGxvdz88YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2PkFzIEkgcmVj YWxsLCB0aGVyZSB3ZXJlIHNvbWUgc3VydmV5cyBvZiBzb21lIHByZXR0eSBsYXJnZSBlbWFpbCBz dHJlYW1zLCBhbmQgbm90IGEgc2luZ2xlIGluc3RhbmNlIG9mIGEgRnJvbTogZmllbGQgY29udGFp bmluZyBvdGhlciB0aGFuIGEgc2luZ2xlIG1haWxib3ggY291bGQgYmUgZm91bmQgdGhhdCB3YXNu J3QgYWxzbyBwYXJ0IG9mIHNvbWV0aGluZyBlaXRoZXIgc3BhbW15IG9yIHNvbWUga2luZCBvZiBh dHRlbXB0IHRvIGNvbmZvdW5kIHNwYW0gZmlsdGVycywgb3IganVzdCBncm9zc2x5IG1hbGZvcm1l ZCBhbmQgdW51c2FibGUuJm5ic3A7IFRoaXMgbGVkIHRoZSBvcmlnaW5hbCBETUFSQyBjb21tdW5p dHkgdG8gd2hhdCB5b3Ugc2VlIHRoZXJlIG5vdy4mbmJzcDsgVGhlcmUgd2FzIG5vIGRlbGliZXJh dGUgcmVqZWN0aW9uIG9mIHRoZSBSRkMgNjg1NCBmb3JtYXQsIGJ1dCBqdXN0IHJhdGhlciBubyBv YnNlcnZlZCB2YWxpZCB1c2Ugb2YgaXQuPGJyPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxv Y2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2Pk5vdGUgdGhhdCBSRkMgNjg1NCBmb3JtYXQgaXMg YSAidHJhbnNpdGlvbmFsIiBSRkMuIFRoZSBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBjbGVhcmx5 IGluZGljYXRlcyB0aGlzIHN5bnRheCBpcyB0byBiZSB1c2VkIGZvciBub24gU01UUFVURjggYXdh cmUgTVRBIHdoZW4gcmVjZWl2aW5nIG1haWwgZnJvbSBhbiB1cHN0cmVhbSBNVEEgU01UUFVURjgg YXdhcmUgYXMgYSBjb252ZW5pZW5jZSBhbmQgdW5kZXIgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg bGVmdCB0byB0aGUgcmVjZWl2ZXIuIFNvIGluIG15IHZpZXcgaWYgeW91ciByZWNlaXZpbmcgTVRB IGRvZXMgU01UUFVURjggdGhlbiB0aGVyZSBpcyBsaXR0bGUgcmVhc29uIHRvIGFjY2VwdCB0aGlz IHN5bnRheC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgYWx3YXlzIGhhZCBhIHByb2JsZW0g d2l0aCBSRkMgNjg1NCBhbmQgb3Bwb3NlZCBpdCBpbiBsYXN0IGNhbGwgYXMgaXQgc3VycHJpc2Vk IG1lIHRoZSBJRVRGIHdvdWxkIHByZWZlciBjb252ZW5pZW5jZSBmb3Igc2VjdXJpdHkuIFRoZSBy ZXN1bHQgd2FzIHRvIHN0cm9uZ2x5IGxpbWl0IHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoaXMgUkZD LjwvZGl2Pjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxkaXYgZGlyPSJsdHIiPjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGJyPjwvZGl2 PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUi IHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk aW5nLWxlZnQ6MWV4Ij4NClN1cmUsIHNvbWUgY2xpZW50cyBtYXkgYmFyZiBvbiBzdWNoIHRoaW5n cywgYnV0IHRoYXQncyBhIHByb2JsZW0gZm9yIHdob2V2ZXI8YnI+DQpvcHRzIHRvIHVzZSB0aGUg bWVjaGFuaXNtcywgbm90IERNQVJDLjxicj4NCjxicj4NCkkgaGF2ZSBubyBhYnNvbHV0ZWx5IHBy b2JsZW0gd2l0aCByZWplY3RpbmcgbWVzc2FnZXMgd2l0aCBGcm9tOiBmaWVsZHM8YnI+DQpjb250 YWluaW5nIGFueSBzb3J0IG9mIGRvbWFpbiBpZGVudGlmaWVyIHRoYXQgaGFzIGFueSBzb3J0IG9m IGF0dGFjaGVkIERNQVJDPGJyPg0KcG9saWN5IGJlY2F1c2Ugb2YgaG93IHRoYXQgRnJvbTogZmll bGQgaXMgY29uc3RydWN0ZWQuIEJ1dCBpbnRydWRpbmcgb248YnI+DQpsZWdpdGF0ZSB1c2VzIG9m IGVtYWlsIHRoYXQgY2hvb3NlIG5vdCB0byBlbXBsb3kgRE1BUkMgaW4gYW55IGNhcGFjaXR5IGdv ZXM8YnI+DQptdWNoIHRvbyBmYXIuIEFuZCBpdCBpc24ndCBoZWxwZWQgYnkgdGhlIGZhY3QgdGhh dCB0aGUgRE1BUkMgcmVwb3J0aW5nPGJyPg0KbWVjaGFuaXNtcyBhcmUgbWVhbmluZ2xlc3Mgd2hl biB0aGVyZSdzIG5vIGRvbWFpbiBvd25lciB0byByZXBvcnQgdGhlc2U8YnI+DQpyZWplY3Rpb25z IHRvLjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5XaGF0IHNvcnQgb2YgcmVt ZWR5IHdvdWxkIHlvdSBzdWdnZXN0IGhlcmU/Jm5ic3A7IE9mZiB0aGUgdG9wIG9mIG15IGhlYWQs IGhlcmUgYXJlIHNvbWUgc3VnZ2VzdGlvbnM6PGJyPjxicj48L2Rpdj48ZGl2PjEpIEV2YWx1YXRl IGFsbCB0aGUgZG9tYWlucyB5b3UgZmluZCwgYW5kIGlmIGFueSBvZiB0aGVtIGhhdmUgcHVibGlz aGVkIERNQVJDIHBvbGljaWVzLCBhcHBseSB0aGUgc3RyaWN0ZXN0IG9uZSAoYnkgdGhhdCBJIG1l YW46IGlmIHRoZXJlIGFyZSBhbnkgd2l0aCBwPXJlamVjdCB0aGF0IGZhaWwsIHRoZW4gcmVqZWN0 IGl0OyBpZiB0aGVyZSBhcmUgYW55IHdpdGggcD1xdWFyYW50aW5lLCBxdWFyYW50aW5lIGl0KTsg aWYgbm90LCB0cmVhdCB0aGUgbWVzc2FnZSBhcyBpZiBETUFSQyBzaW1wbHkgZGlkIG5vdCBhcHBs eS48YnI+PGJyPjwvZGl2PjxkaXY+MikgRXZhbHVhdGUgb25seSB0aGUgZmlyc3QgZG9tYWluIHlv dSBmaW5kLCBpZiBhbnkuPGJyPjxicj48L2Rpdj48ZGl2PjMpIFNhbWUgYXMgKDEpLCBidXQgbGlt aXQgaXQgdG8gc29tZSBmaXhlZCAoY29uZmlndXJhYmxlPykgbnVtYmVyIG9mIGRvbWFpbnMuPGJy PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rp dj5NeSBzb2x1dGlvbiBpcyB0aGF0IGlmIGFsbCB0aGUgZG9tYWlucyBhcmUgcGFydCBvZiB0aGUg c2FtZSBvcmdhbmlzYXRpb25hbCBkb21haW4sIHRoZW4gdGhlIHRhc2sgaXMgZWFzeSwgeW91IGFw cGx5IHRoZSBwb2xpY3kgb2YgdGhlIG9yZ2FuaXphdGlvbmFsIGRvbWFpbiwgb3RoZXJ3aXNlIHlv dSByZWplY3QgdGhlIGVtYWlsLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBmb3VuZCAuTkVU IGVhcmx5IHZlcnNpb24gdXNlcyBhbiBpbnZhbGlkIHN5bnRheCwgdGhhdCBjcmVhdGVzIHRoZSBh cHBlYXJhbmNlIG9mIDIgbWFpbGJveGVzLiBJZiBhbGwgZG9tYWlucyBhcmUgaW4gdGhlIHNhbWUg b3JnYW5pemF0aW9uYWwgZG9tYWluIHRoaXMgcHJldmVudCB0byByZWplY3QgYSBidW5jaCBvZiAu TkVUIGdlbmVyYXRlZCBlbWFpbHMuPGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGRp diBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj48ZGl2Pjxicj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4NClRoZXJlJ3MgYWxzbyBhIGRpcmVjdCBjb250cmFkaWN0aW9uIGJldHdlZW4gdGhl IHRoaXJkIGJ1bGxldCBpdGVtIGluIHNlY3Rpb248YnI+DQo1LjYuMSwgd2hpY2ggc2F5cyB0aGF0 IGEgbWVzc2FnZSB3aXRob3V0IGEgRnJvbTogZmllbGQgU0hPVUxEIGJlIHJlamVjdGVkLCBhbmQ8 YnI+DQp0aGUgZm91cnRoIHBhcmFncmFwaCBvZiBzZWN0aW9uIDMuMS40LCB3aGljaCBsZWF2ZXMg dGhpcyBzYW1lIGNhc2UgdG8gdGhlPGJyPg0KZGlzY3JldGlvbiBvZiB0aGUgbWFpbCByZWNlaXZl ci4gRnVydGhlcm1vcmUsIGRvZXMgaXQgcmVhbGx5IG1ha2Ugc2Vuc2UgdG8gZ2l2ZTxicj4NCm1h bGZvcm1lZCBGcm9tOiBmaWVsZHMgYSBwYXNzIC0gc29tZW9tdGhpbmcgd2hpY2ggY291bGQgZWFz aWx5IGNvbnRhaW4gYW48YnI+DQppZGVudGlmaWVyIHRoYXQgaGFzIGFuIGF0dGFjaGVkIERNQVJD IHBvbGljeSAtIGFuZCByZXF1aXJlIHJlamVjdGlvbiBvZjxicj4NCmNvbXBsZXRlbHkgbGVnaXRp bWF0ZSBzdHVmZiB3aXRoIG5vIERNQVJDIHBvbGljeSBpbiBzaWdodD88YnI+PC9ibG9ja3F1b3Rl PjxkaXY+PGJyPjwvZGl2PjxkaXY+V2UndmUgY292ZXJlZCB0aGUgbGF0dGVyIHBvaW50IGFib3Zl LCBidXQgYXMgdG8gdGhlIHBvaW50IGFib3V0IG1hbGZvcm1hdGlvbjogQ2FuIHlvdSByZWxpYWJs eSBleHRyYWN0IGEgZG9tYWluIG5hbWUgZnJvbSBhIG1hbGZvcm1lZCBGcm9tOiBmaWVsZD8mbmJz cDsgVGhhdCBzZWVtcyB0byBiZSBhIHZlY3RvciBmb3IgdHJ5aW5nIHRvIGNvbmZ1c2UgYSBETUFS QyBmaWx0ZXIgaWYgdGhlIGFkdmljZSBpcyB0byB0cnkgYW55d2F5Ljxicj4mbmJzcDs8YnI+PC9k aXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpJIGNvdWxk IGhhdmUgbWlzc2VkIGl0LCBidXQgSSBkb24ndCBzZWUgYW55IHBsYWNlIHdoZXJlIHRoZSBzZW1h bnRpY3Mgb2YgaG93PGJyPg0KREtJTSBhbmQgU1BGIGFyZSBjb21iaW5lZCAoYXMgYW4gaXQncyBh biBPUikgaXMgc3BlY2lmaWVkIHByaW9yIHRvIGl0ZW0gNSBpbjxicj4NCnNlY3Rpb24gNS42LjIu IElmIHRoaXMgaXMgaW5kZWVkIHRoZSBjYXNlLCB0aGVuIHRoaXMgaXMgYmFkOiBUaGUgd2F5IHRo ZTxicj4NCm1lY2hhbmlzbXMgYXJlIGNvbWJpbmVkIG5lZWRzIHRvIGJlIG1hZGUgY2xlYXIgbXVj aCBzb29uZXIuIEkgbm90ZSBpbiBwYXNzaW5nPGJyPg0KdGhhdCB3ZSd2ZSBhbHJlYWR5IGhhZCBh IGNhc2Ugb24gdGhpcyBsaXN0IHdoZXJlIHNvbWVvbmUgbWlzdW5kZXJzdG9vZCB0aGlzPGJyPg0K ZGV0YWlsLjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5TZWN0aW9uIDUsIHRo aXJkIHBhcmFncmFwaCwgaXMgdGhlIGZpcnN0IGZvcm1hbCBzdGF0ZW1lbnQgb2YgdGhpcyBraW5k LiZuYnNwOyBBZGRpbmcgb25lIHNvbWV3aGVyZSB1cCBlYXJsaWVyIGluIG9uZSBvZiB0aGUgb3Zl cnZpZXcgc2VjdGlvbnMgd291bGQgcHJvYmFibHkgYmUgYSBnb29kIGlkZWEuPGJyPiZuYnNwOzxi cj48L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NClNl Y3Rpb24gNi4yLjIuMSBzdGF0ZXM6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0luIHRoZSBjYXNl IG9mIGEgIm1haWx0byIgVVJJLCB0aGUgTWFpbCBSZWNlaXZlciBNVVNUIGNvbW11bmljYXRlPGJy Pg0KJm5ic3A7ICZuYnNwO3JlcG9ydHMgdXNpbmcgdGhlIG1ldGhvZCBkZXNjcmliZWQgaW4gW1NU QVJUVExTXSB3aGVuZXZlciBpdCBpczxicj4NCiZuYnNwOyAmbmJzcDtvZmZlcmVkIGJ5IGEgUmVw b3J0IFJlY2VpdmVyLjxicj4NCjxicj4NCkkgc2VyaW91c2x5IHF1ZXN0aW9uIHRoZSB2YWx1ZSBv ciBhcHByb3ByaWF0ZW5lc3Mgb2YgdGhpcyBwYXJhZ3JhcGguIFNvIHlvdXI8YnI+DQpETUFSQyBh Z2VudCwgYXNzdW1pbmcgaXQgYWN0dWFsbHkgZ29lcyB0aHJvdWdoIGEgU1VCTUlUIHNlcnZlciBh bmQgbm90IHRocm91Z2g8YnI+DQphbiBpbnRlcm5hbCBBUEksIHVzZXMgU1RBUlRUTFMgdG8gc2Vj dXJlIHRoYXQgY29ubmVjdGlvbi4gTm93IHdoYXQ/IEF0IHByZXNlbnQ8YnI+DQp0aGVyZSdzIG5v IHN0YW5kYXJkaXplZCB3YXkgdG8gaW5kaWNhdGUgaW4gYSBtZXNzYWdlIHRoYXQgaXQgaGFzIHRv IGJlPGJyPg0KdHJhbnNwb3J0ZWQgc2VjdXJlbHkuIFNvIGlmIHlvdSByZWFsbHkgd2FudCB0aGF0 LCB0aGF0IGxlYXZlcyBjb25maWd1cmF0aW9uIC0gYTxicj4NCmNvbmZpZ3VyYXRpb24gdGhhdCBz cGFucyBhbiBlc3NlbnRpYWxseSBhcmJpdHJhcnkgc2V0IG9mIHRyYW5zcG9ydCBhZ2VudHMsIHRv PGJyPg0KZW5mb3JjZSB0aGlzLiBBdCBsZWFzdCBwYXJ0IG9mIHdoaWNoIHdvdWxkIGhhdmUgdG8g YmUgZW5mb3JjZWQgYnkgdGhlIHRhcmdldCBvZjxicj4NCnRoZSBtYWlsdG86IHRvIGhhdmUgYW55 IGNoYW5jZSBvZiBiZWluZyBlZmZlY3RpdmUuPGJyPg0KPGJyPg0KSXQncyBwb29yIHByYWN0aWNl IHRvIGhhdmUgTVVTVHMgaW4gc3BlY2lmaWNhdGlvbnMgdGhhdCB3ZSBrbm93IGFyZSBnb2luZyB0 byBiZTxicj4NCmlnbm9yZWQuIEl0J3MgYWxzbyBwb29yIHByYWN0aWNlIHRvIGhhdmUgTVVTVHMg dGhhdCBkb24ndCBhY3R1YWxseSBhY2NvbXBsaXNoPGJyPg0KbXVjaCBvZiBhbnl0aGluZyBhcyB3 cml0dGVuLiBBcyBzdWNoLCBJIHN0cm9uZ2x5IHJlY29tbWVuZCBkdW1waW5nIHRoaXMsIG9yIGF0 PGJyPg0KbGVhc3QgbWFraW5nIGl0IGEgU0hPVUxELjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+ PC9kaXY+PGRpdj5JJ2QgYmUgZmluZSB3aXRoIG1ha2luZyBpdCBhIFNIT1VMRCwgZXhhY3RseSBi ZWNhdXNlIG9mIHRoZXNlIHJlYXNvbnMuPGJyPiZuYnNwOzxicj48L2Rpdj48YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDox cHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NClNlY3Rpb24gOS4zIHJlY29tbWVuZHMg dXNpbmcgcmVwbHkgY29kZXMgZHVyaW5nIHRoZSBTTVRQIHNlc3Npb24gcmF0aGVyIHRoYW48YnI+ DQpkb2luZyBhbnl0aGluZyB0aGF0IHdvdWxkIHJlcXVpcmUgc2VuZGluZyBhIERTTiBsYXRlciwg YnV0IGRvZXNuJ3QgY29tZSBvdXQgYW5kPGJyPg0Kc2F5IHRoYXQgdGhlIHJlYXNvbiBmb3IgZG9p bmcgdGhpcyBpcyB0byBhdm9pZCBibG93YmFjayBzcGFtLiBJIHRoaW5rIGl0IHdvdWxkPGJyPg0K YmUgY2xlYXJlciB0byBiZSBleHBsaWNpdCBhYm91dCB3aHkgdGhlc2UgcG9saWNpZXMgYXJlIGEg Z29vZCBpZGVhLjxicj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5Tb3VuZHMgZ29v ZCB0byBtZS48YnI+PGJyPlRoYW5rcyE8YnI+PGJyPi1NU0sgPGJyPjwvZGl2PjwvZGl2PjwvZGl2 PjwvZGl2Pg0KPC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+ PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3Nw YW4+PGJyPjxzcGFuPmRtYXJjIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0i bWFpbHRvOmRtYXJjQGlldGYub3JnIj5kbWFyY0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmMiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmM8L2E+PC9zcGFuPjxicj48 L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-E1952D76-2B2B-4D59-90DC-CF7448E44B83-- From nobody Sat Nov 8 17:38:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD741A00B0 for ; Sat, 8 Nov 2014 17:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o4K3dH4NdcY for ; Sat, 8 Nov 2014 17:38:11 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 635BA1A0075 for ; Sat, 8 Nov 2014 17:38:11 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 043065655CB; Sat, 8 Nov 2014 19:38:11 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id EB24360356; Sat, 8 Nov 2014 19:38:10 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gCpkAVnlcoz; Sat, 8 Nov 2014 19:38:10 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id BA2F360233; Sat, 8 Nov 2014 19:38:10 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com BA2F360233 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415497090; bh=PByVVzAcGDoWxXyabc9TH6cyD0lDdoetac4bqHDrb7o=; h=Content-Type:From:Mime-Version:Subject:Message-Id:Date:To; b=OEUvug8Q+ceeTVZXCkKVkrH49InhqXMaY/5i2R9Bf+r1wbFl3k+9Z0HW996caL62i Wuwa6b+xmlatYHVB/h3bse8djj0GwTDSXe9PIQB30YJ2elT8+Yvrzzdb9rbrclk8ts lhnCSEfHyy1Zp45BSM278jACXmTCCfvfnIROhiXc= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9E11E60356; Sat, 8 Nov 2014 19:38:10 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uOT2WqMlLmcv; Sat, 8 Nov 2014 19:38:10 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 7421D60233; Sat, 8 Nov 2014 19:38:10 -0600 (CST) Content-Type: multipart/alternative; boundary=Apple-Mail-7D4B30D6-E070-4EA2-8782-66544743EC14 From: Franck Martin Mime-Version: 1.0 Message-Id: Date: Sat, 8 Nov 2014 19:38:10 -0600 (CST) References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> <545EA08E.8080405@sonnection.nl> To: "" In-Reply-To: <545EA08E.8080405@sonnection.nl> X-Mailer: Zimbra 8.0.5_GA_5839 (MobileSync - Apple-iPad4C1/1202.410) Thread-Topic: draft-kucherawy-dmarc-base feedback Thread-Index: rcn76deel7rnzy6mOKlMW3ERaTijVQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2gAHMfFVZoI4z7oF5Yk7zgBqkSs Cc: "ned+dmarc@mrochek.com" , "J. Trent Adams" , Brett McDowell , "dmarc@ietf.org" , "Murray S. Kucherawy" , "Stephen J. Turnbull" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 01:38:13 -0000 --Apple-Mail-7D4B30D6-E070-4EA2-8782-66544743EC14 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Printed on recycled paper! > On Nov 8, 2014, at 15:00, Rolf E. Sonneveld w= rote: >=20 >> On 11/08/2014 09:20 PM, Brett McDowell wrote: >> I support making no change in dmarc-base-05 that might change how current= mailbox providers implement dmarc-base. But to the extent this collection o= f contributors would like to see the recommendations/requirements in section= 5.6.1 updated to better harmonize with related RFC's, I support Trent's pro= posal as it seems to introduce the least amount of increased risk to fraud. >>=20 >> That said, we do have people here familiar with large-scale mailbox provi= der deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask them if th= ey expect Trent's changes to have any impact on how they implement dmarc-bas= e today. If it will, I think we should consider these changes for a future v= ersion of dmarc-base and let this version go through with these requirements= unchanged. As you all know, there are now years of experience deploying dm= arc-base with these requirements as written. Those deployments have had tre= mendous success protecting users from domain-spoofing the RFC5322.=46rom fie= ld. =20 >>=20 >> The importance of the current dmarc-base specification's efficacy at bloc= king domain-spoofed phishing attacks should not be underestimated. I advise= extreme caution when considering any normative changes at the 11th hour. >>=20 >> Dear high volume MBP's, will any of these changes in Trent's proposal alt= er how you implement dmarc-base today? >=20 > The current effort to publish DMARC as informational RFC is mainly, to doc= ument the current specification 'as is', to be able to refer from other docu= ments to a published spec. The concerns raised by Ned and the proposal of Tr= ent try to address situations, where the spec does not yet describe what to d= o (RFC5322.=46rom with multiple addresses), or leaves room for different int= erpretations/implementations. As such I welcome the text proposed by Trent. I= f the big MBP's deviate from what that text describes, then in my opinion: >=20 > either this is part of the 'secret sauce' which is being applied by Mail R= eceivers anyway (no matter what a spec will prescribe) > or (better) the big MBP's will need to come up with text describing what t= heir implementations will do in these specific cases. There are no secret sauces. I thought it was clear this type of language on t= his list is frown upon as non constructive? Several MBPs use openDMARC, less use msys-dmarc but both are opensource. --Apple-Mail-7D4B30D6-E070-4EA2-8782-66544743EC14 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


Printed on recycled paper!

On Nov 8, 2014, at 15:00, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:

On 11/08/2014 09:20 PM, Brett McDowell wrote:
I support making no change in dmarc-base-05 that might change how current mailbox providers implement dmarc-base.  But to the extent this collection of contributors would like to see the recommendations/requirements in section 5.6.1 updated to better harmonize with related RFC's, I support Trent's proposal as it seems to introduce the least amount of increased risk to fraud.

That said, we do have people here familiar with large-scale mailbox provider deployments (Google, Yahoo!, Hotmail, etc.).  I'd like to ask them if they expect Trent's changes to have any impact on how they implement dmarc-base today.  If it will, I think we should consider these changes for a future version of dmarc-base and let this version go through with these requirements unchanged.  As you all know, there are now years of experience deploying dmarc-base with these requirements as written.  Those deployments have had tremendous success protecting users from domain-spoofing the RFC5322.From field.  

The importance of the current dmarc-base specification's efficacy at blocking domain-spoofed phishing attacks should not be underestimated.  I advise extreme caution when considering any normative changes at the 11th hour.

Dear high volume MBP's, will any of these changes in Trent's proposal alter how you implement dmarc-base today?

The current effort to publish DMARC as informational RFC is mainly, to document the current specification 'as is', to be able to refer from other documents to a published spec. The concerns raised by Ned and the proposal of Trent try to address situations, where the spec does not yet describe what to do (RFC5322.From with multiple addresses), or leaves room for different interpretations/implementations. As such I welcome the text proposed by Trent. If the big MBP's deviate from what that text describes, then in my opinion:

  • either this is part of the 'secret sauce' which is being applied by Mail Receivers anyway (no matter what a spec will prescribe)
  • or (better) the big MBP's will need to come up with text describing what their implementations will do in these specific cases.

There are no secret sauces. I thought it was clear this type of language on this list is frown upon as non constructive?

Several MBPs use openDMARC, less use msys-dmarc but both are opensource.


--Apple-Mail-7D4B30D6-E070-4EA2-8782-66544743EC14-- From nobody Sat Nov 8 19:58:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC041A0278 for ; Sat, 8 Nov 2014 19:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKmH4gVhZ5eq for ; Sat, 8 Nov 2014 19:58:39 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5CFF1A0179 for ; Sat, 8 Nov 2014 19:58:39 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PEO0RJGQ5C0050PC@mauve.mrochek.com> for dmarc@ietf.org; Fri, 7 Nov 2014 11:04:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1415387086; bh=2UN/sJBcr1rKOVGLy08F45m6trmCH2jGhVWc0rBMBE0=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=gbmgY+jGdftmRwqM3ZQHLM4cI7h3BpsaUoeUP0O4AJX/CaRTpmuJsvz9lViNnfUn4 GRG6sqbta+rpBOFpnADzEtetfmcVilTwQ449Ai6ctx2Evt1lHns/OE0d7p/MIuRa/G SCmlgmt6zsdaBJ26kiBhnpmcRzlbOZX2gSBvDGKk= 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 <01PEO030K1UO00475I@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Fri, 07 Nov 2014 11:04:43 -0800 (PST) From: ned+dmarc@mrochek.com Message-id: <01PEO0RHSW5I00475I@mauve.mrochek.com> Date: Fri, 07 Nov 2014 10:47:20 -0800 (PST) In-reply-to: "Your message dated Fri, 07 Nov 2014 18:06:51 +0000" <20141107180651.8446.qmail@ary.lan> References: <20141107180651.8446.qmail@ary.lan> To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/bS8yrx22KKgm7bpg7RkkZ7aZhu8 Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 03:58:41 -0000 > >What sort of remedy would you suggest here? Off the top of my head, here > >are some suggestions: > > > >1) Evaluate all the domains you find, and if any of them have published > >DMARC policies, apply the strictest one ... > Given the anti-phishing goals of DMARC, I don't see how anything else > makes any sense. Or you could skip a step, say that DMARC doesn't > permit multi-address From headers, assume that validation failed on > all of the domains and proceed directly to the punishment phase. That's fine if any of the domains have an associated DMARC record - of any sort. My concern is the case where none of them do, or when there are no domains present. > For From: headers with address-free groups, recall that the motivation > for this was EAI downgrades at delivery time. The un-downgraded > message had a normal From: header, so normal DMARC applies. If the > address is smashed in the downgrade I don't see any reason that the > DMARC result needs to change. Neither do I. > It also happens to enable an alternative to those > do-not-reply@bigbank.com addresses in mail from robots, something I > haven't seen yet, but wouldn't be totally silly. I'd say that > whatever you do with them is out of scope for DMARC. That's exactly my position. If you want to reject them on the basis that the mess up user agents, you have a pathological hatred of group syntax, or whatever, fine. Local policy choices always win. But DMARC should not be saying that valid things should be rejected when there's no DMARC records in sight. Ned From nobody Sat Nov 8 20:27:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 665561A038B for ; Sat, 8 Nov 2014 20:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYz4AEOnUHnE for ; Sat, 8 Nov 2014 20:27:07 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782071A038A for ; Sat, 8 Nov 2014 20:27:07 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sA94R3N7009989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 8 Nov 2014 20:27:06 -0800 Message-ID: <545EED06.4080404@dcrocker.net> Date: Sat, 08 Nov 2014 20:26:46 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ned+dmarc@mrochek.com References: <20141107180651.8446.qmail@ary.lan> <01PEO0RHSW5I00475I@mauve.mrochek.com> In-Reply-To: <01PEO0RHSW5I00475I@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 08 Nov 2014 20:27:07 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_00uUt6hMN_S0aUVXvuoR0pvz-o Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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: Sun, 09 Nov 2014 04:27:09 -0000 On 11/7/2014 10:47 AM, ned+dmarc@mrochek.com wrote: >>> > >1) Evaluate all the domains you find, and if any of them have published >>> > >DMARC policies, apply the strictest one ... ... > That's fine if any of the domains have an associated DMARC record - of any > sort. My concern is the case where none of them do, or when there > are no domains present. Right. I believe the phrasing of 1), above, constrains the scope of applicability carefully and in the way that avoids the possible problems you are (correctly, IMO) concerned about. That is, I believe the "if any of them" text matches your "if any of the" text... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Nov 8 23:58:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F3E1A1A18 for ; Sat, 8 Nov 2014 23:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOQRI9YDZh-E for ; Sat, 8 Nov 2014 23:58:04 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B121A1A17 for ; Sat, 8 Nov 2014 23:58:04 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id v10so5873029pde.36 for ; Sat, 08 Nov 2014 23:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qwfa/2NVW+m2GyW+uH/hF6zxqXxz0+I0yisTvhHmwJ8=; b=gMLHSsrYKhT5Rx0Fs5gIZMcObb5Bn16HRwqYevtfoEyhRm8sxl/h0prdcZ47DXt9Vh 77JDrbsFQkNQ5EeT2LE/uhf79wNQRAqmok5tj6y15gbMA/e0nXekvrUWf1fVXvBc96fD 5HFrwASFwHIyoAO44bE4jlwgJCjk5jt0QJcpTTMXb76WsgejVxPghd/07dBPdvu4WoRv YnL1pGTod9MgXeqxA+1JcGN3XROMYoUD9O47KIWGQbvVHRBwCMkGe7//qaGdFC+mwgkT R1qWVyG9VOtyWRsIp+0JvSxwNdnkpBFcVkxGnMw3aSe/jHFjpReR5vIMCJPAZCBZxu3I hKWw== X-Received: by 10.70.129.135 with SMTP id nw7mr23650498pdb.129.1415519883924; Sat, 08 Nov 2014 23:58:03 -0800 (PST) Received: from [192.168.2.110] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id c9sm13158988pdn.81.2014.11.08.23.58.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 08 Nov 2014 23:58:02 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: <35668414-6334-4BCD-B6C8-A471000D72C5@peachymango.org> Date: Sat, 8 Nov 2014 23:58:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <35668414-6334-4BCD-B6C8-A471000D72C5@peachymango.org> To: Franck Martin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/sQ4Ul73ThfOvvaTdVVB3VNm9564 Cc: Ned Freed , "dmarc@ietf.org" , "Murray S. Kucherawy" , Douglas Otis Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 07:58:06 -0000 On Nov 8, 2014, at 5:29 PM, Franck Martin = wrote: >> No, I think you've got it, but I'm not clear on how the paragraph you = cited doesn't say that. You have it exactly right: If From: is missing = or so mangled that it's not possible to get a domain out, then there's = nothing to which DKIM and SPF can align, and DMARC can't be applied. = There might be other mangling though, like multiple From: fields that = are properly formed but contain distinct values, in which case we don't = know to which one to apply alignment. Dear Franck, > Note that an email with no RFC 5322 field is not valid, as well as one = with more than 1. This header is mandatory as well as the Date header. = These are the only 2 headers mandatory in an email. >=20 > So rejecting an email with no RFC 5322 or more than one is just = following the RFC. Which normative RFC is that? >=20 > I'm not talking on how many mailboxes/domain there are in this header It would be wrong to assume SMTP will reject messages based on possible = RFC5322 violations. Also efforts to change the =46rom header field into = alignment with DKIM or SPF violates RFC 5322 as well. In addition, use = of DKIM and DMARC alignment to reject phishing attacks can not safely = rely on DKIM signatures being considered invalid when multiple =46rom = header fields exist. This makes the strategy suggested in RFC6376 = Section 8.15 dependent on all domains being checked for DMARC policy. = Because of this flaw in DKIM signature validation, it becomes necessary = to apply DMARC policy checks against each and every originating domain. = It would be incorrect to expect Authentication-Results headers will = indicate a failure in the case of invalid originating header fields. = The domain being checked for DMARC MUST NOT depend on = Authentication-Results headers, OR assume SMTP or DKIM validation = rejects such messages since there is no RFC language to impose message = rejection or a DMARC policy failure. DMARC now suggests making this = difficult check with an ought. It seems rather dubious to trust DKIM = signatures and that DMARC offers a safe and reliable policy enforcement.=20= Also consider that it took several years for Yahoo to notice exploits = allowed by multiple =46rom header Fields. Per RFC 5322: Also in Section 3.6.2: In all cases, the "From:" field SHOULD NOT = contain any mailbox that does not belong to the author(s) of the = message. Per RFC 5321: When the RFC 822 format ([28], [4]) is being used, the mail data include the header fields such as those named Date, Subject, To, Cc, and From. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message header section or message body. In particular, they MUST NOT reject messages in which the numbers of Resent-header fields do not match or Resent-to appears without Resent-from and/or Resent-date. Even the dmarc-base draft Section 4 and Section 10 removed rejection of = invalid =46rom header fields: The absence of a single, properly-formed RFC5322.=46rom field renders=20= the message invalid. This document prescribes no specific action in that case, other than to suggest that the message ought to be = disposed of by the Mail Receiver's infrastructure in a safe manner that recognizes and possibly even highlights the malformation. So it is perfectly valid to indicate a DKIM pass with multiple =46rom = header fields, and now ignore this situation with DMARC as well. Do you see the problem with the assumption you made? Heck, the DKIM = deploy RFC even suggests subsequent checks can be bypassed when a valid = DKIM signature is found from a trusted domain. Regards, Douglas Otis From nobody Sun Nov 9 01:19:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5CB1A1A4E for ; Sun, 9 Nov 2014 01:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2Wd9GNFAuUT for ; Sun, 9 Nov 2014 01:19:06 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id C16451A1A62 for ; Sun, 9 Nov 2014 01:19:05 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 41821565634; Sun, 9 Nov 2014 03:19:05 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 25C49A0308; Sun, 9 Nov 2014 03:19:05 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJx1zbk8Urqy; Sun, 9 Nov 2014 03:19:04 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 6803DA0330; Sun, 9 Nov 2014 03:19:03 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 6803DA0330 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415524743; bh=wYgs1gnGHJJNYaniZPruc8I35vUl9Wj9UObDf/rxCm8=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=SRM2O84mMxMAnBadHtp2o2XMTGIvM4c8OTUcCWFYP9tRVHpT/1ucMIOMSpoMnQ7nj ReiBw8MglDVSd/kzg501hZUt54N4RN/77t/UgpSfpqbO0QeWLI66OMFAiDoSEwiC7Z nSXwsnNPBKhCpurkJb0me4fO7qAF/jU5g+k/0SDA= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 29FD3A0318; Sun, 9 Nov 2014 03:19:03 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id V_eI2YL5zzdW; Sun, 9 Nov 2014 03:19:03 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id E9D80A0308; Sun, 9 Nov 2014 03:19:02 -0600 (CST) Date: Sun, 9 Nov 2014 03:19:02 -0600 (CST) From: Franck Martin To: Douglas Otis Message-ID: <1263541054.270.1415524742766.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <35668414-6334-4BCD-B6C8-A471000D72C5@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-kucherawy-dmarc-base feedback Thread-Index: y/ZmMNyl5ffRwajEqeuIbP+M32voVg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FTHNBWcn1JhN25ysPzS_jAXvJh4 Cc: "Murray S. Kucherawy" , dmarc@ietf.org, Ned Freed Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 09:19:08 -0000 ----- Original Message ----- > From: "Douglas Otis" > To: "Franck Martin" > Cc: "Ned Freed" , dmarc@ietf.org, "Murray S. Kucherawy" , "Douglas Otis" > > Sent: Saturday, November 8, 2014 11:58:00 PM > Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback > > > On Nov 8, 2014, at 5:29 PM, Franck Martin wrote: > > >> No, I think you've got it, but I'm not clear on how the paragraph you > >> cited doesn't say that. You have it exactly right: If From: is missing > >> or so mangled that it's not possible to get a domain out, then there's > >> nothing to which DKIM and SPF can align, and DMARC can't be applied. > >> There might be other mangling though, like multiple From: fields that > >> are properly formed but contain distinct values, in which case we don't > >> know to which one to apply alignment. > > Dear Franck, > > > Note that an email with no RFC 5322 field is not valid, as well as one with > > more than 1. This header is mandatory as well as the Date header. These > > are the only 2 headers mandatory in an email. > > > > So rejecting an email with no RFC 5322 or more than one is just following > > the RFC. > > Which normative RFC is that? see table under http://tools.ietf.org/html/rfc5322#section-3.6 > > > > > I'm not talking on how many mailboxes/domain there are in this header > > It would be wrong to assume SMTP will reject messages based on possible > RFC5322 violations. While SMTP implementations have been lenient, they have been lenient in a way which is contrary to this RFC. The Postel statement indicates to be lenient when there is protocol ambiguity, not to allow anything but the kitchen sink when the protocol is clear about what headers must be present. Therefore it is not wrong to assume SMTP will reject messages on protocol violations. From nobody Sun Nov 9 01:26:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7335C1A1A62 for ; Sun, 9 Nov 2014 01:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 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, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pfhlBIwG5T7 for ; Sun, 9 Nov 2014 01:26:28 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2B71A1A59 for ; Sun, 9 Nov 2014 01:26:28 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 18BB4565320; Sun, 9 Nov 2014 03:26:28 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E5361A0308; Sun, 9 Nov 2014 03:26:27 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AElWXxYZM_4n; Sun, 9 Nov 2014 03:26:27 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A5B68A0330; Sun, 9 Nov 2014 03:26:27 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com A5B68A0330 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415525187; bh=mZMYsUH8CJyMZvT3VNRJtx6VuQab0k+5LNaGB1hMshU=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=FNHd3r20y3GBE/s4j8BgwzQTqqJdDIYE8hF4tIsW5W56TV4IXr1KaOr1FKfE4akTU gzawO+d0hFRKo/YyAEqqxPapNX8yGAk/Uy2SoSx3SQdGxrSvYX6Ti2nOirmvLiz7vy LVZ4gnCFdKDiKsOuwfbiDa18yk0F/WbY1QmhM4ok= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7E5BDA0318; Sun, 9 Nov 2014 03:26:27 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7xrnubuIKq73; Sun, 9 Nov 2014 03:26:27 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 4FC01A0308; Sun, 9 Nov 2014 03:26:27 -0600 (CST) Date: Sun, 9 Nov 2014 03:26:27 -0600 (CST) From: Franck Martin To: ned+dmarc@mrochek.com Message-ID: <1734025990.279.1415525187170.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20141107180651.8446.qmail@ary.lan> <01PEO0RHSW5I00475I@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-kucherawy-dmarc-base feedback Thread-Index: NWNUNEEm1jhXiqZrvi6p3lJrHpW+/w== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZBdzHl_zAZb6sPitB2gySDH3mmE Cc: superuser@gmail.com, dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 09:26:29 -0000 ----- Original Message ----- > From: ned+dmarc@mrochek.com > To: "John Levine" > Cc: dmarc@ietf.org, superuser@gmail.com > Sent: Friday, November 7, 2014 10:47:20 AM > Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback > > > >What sort of remedy would you suggest here? Off the top of my head, here > > >are some suggestions: > > > > > >1) Evaluate all the domains you find, and if any of them have published > > >DMARC policies, apply the strictest one ... > > > Given the anti-phishing goals of DMARC, I don't see how anything else > > makes any sense. Or you could skip a step, say that DMARC doesn't > > permit multi-address From headers, assume that validation failed on > > all of the domains and proceed directly to the punishment phase. > > That's fine if any of the domains have an associated DMARC record - of any > sort. My concern is the case where none of them do, or when there > are no domains present. With IPv6 and openPGP or S/Mime it will become more and more prevalent to block emails based on the domain(s) present in the RFC5322.From. Are the domains, domains that exist? Are they emailable? are they present in blocking lists? When there are none, my eight ball tells me the preferred behavior will be to reject such emails... These are also a set of easy techniques to avoid that DMARC be by-passed. From nobody Sun Nov 9 01:31:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EB71A1A58 for ; Sun, 9 Nov 2014 01:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 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, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95lGioFSwOw4 for ; Sun, 9 Nov 2014 01:31:32 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id A473B1A1A2D for ; Sun, 9 Nov 2014 01:31:32 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 0A287565688; Sun, 9 Nov 2014 03:31:32 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 0209E601B4; Sun, 9 Nov 2014 03:31:32 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHO43baEPAC7; Sun, 9 Nov 2014 03:31:31 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id C6EA66020E; Sun, 9 Nov 2014 03:31:31 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com C6EA66020E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415525491; bh=CgqxYlkdCP+pJFlsTY+mdpdxHWJi/ZFFGkQvNZQ9DII=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=p2+s5my+49YSmRKAUpDO+FoH7PylG+e6J1ZUmMfX2bhhTCGE/nSiBMj6/gVzgeuZy uWSkCzjPfR+1EQf/PAg9FWe5SUEsIgZ0vzdy5BCOaoHOKA20d6M5WMUkQt3UW02ltT iaTAUatqqv9ACFFP/+9io2YMSFcwa1690LZPIUw0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AFEC960201; Sun, 9 Nov 2014 03:31:31 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yBgYVCRf_PrJ; Sun, 9 Nov 2014 03:31:31 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 950B4601B4; Sun, 9 Nov 2014 03:31:31 -0600 (CST) Date: Sun, 9 Nov 2014 03:31:31 -0600 (CST) From: Franck Martin To: ned+dmarc@mrochek.com Message-ID: <380386176.286.1415525491547.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20141107180651.8446.qmail@ary.lan> <01PEO0RHSW5I00475I@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-kucherawy-dmarc-base feedback Thread-Index: utRPz5Y/oyzY8PGA7dgFuZZSLxccNw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nyIAAbRcfrWpmXeDWyY3YtsgYJc Cc: superuser@gmail.com, dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 09:31:33 -0000 ----- Original Message ----- > From: ned+dmarc@mrochek.com > To: "John Levine" > Cc: dmarc@ietf.org, superuser@gmail.com > Sent: Friday, November 7, 2014 10:47:20 AM > Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback > > > > For From: headers with address-free groups, recall that the motivation > > for this was EAI downgrades at delivery time. The un-downgraded > > message had a normal From: header, so normal DMARC applies. If the > > address is smashed in the downgrade I don't see any reason that the > > DMARC result needs to change. > > Neither do I. Conclusion, a DMARC enabled MTA MUST be SMTPUTF8 enabled (so there is no to little reasons to downgrade). From nobody Sun Nov 9 03:01:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD321A1A86 for ; Sun, 9 Nov 2014 03:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc-4VzcbzBng for ; Sun, 9 Nov 2014 03:01:13 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A329F1A1A85 for ; Sun, 9 Nov 2014 03:01:13 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id y13so6049211pdi.34 for ; Sun, 09 Nov 2014 03:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Kt97OJ84teNmwNkh1i8o913TUy2V6RuWGPB+PfYpgFg=; b=vnX83Ga6C9HU0+08DYcJYry/Ry9jTz9NL7RP8dzgK8DiPq7jaQKsVDx5nnUU7b0NFK 1kt5/QUuVo8L7n/TN0t5Cy/erfxpmqexW3MNxVSZaInEykxE64lr0A2VZciG+nfPcm7T d9uour6RYLatVvUB7oZKlgvg5zDcVeYlV1ttBkc1JMd2dFAdytQYLkS/tOcOO7JtMm2l E5Sux+Re9L3/d10f+qYT50IH+P6puX7H07F9eRLAQiqO9UHdoU8QfOT+W9LyzLA5MDTd LlWU3RzJE7eBtugd/06dhBlKz+x1h9VGKY3Si6zMm+Iybve+iwcdp2Ixbacd79vWnt1+ Nn9g== X-Received: by 10.68.197.41 with SMTP id ir9mr25035128pbc.116.1415530872909; Sun, 09 Nov 2014 03:01:12 -0800 (PST) Received: from [192.168.2.110] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id xy3sm13570724pbb.38.2014.11.09.03.01.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 03:01:12 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: <1263541054.270.1415524742766.JavaMail.zimbra@peachymango.org> Date: Sun, 9 Nov 2014 03:01:10 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <35668414-6334-4BCD-B6C8-A471000D72C5@peachymango.org> <1263541054.270.1415524742766.JavaMail.zimbra@peachymango.org> To: Franck Martin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/VSu0MTXLV7NuGuNwzNlNVrzgCcs Cc: "Murray S. Kucherawy" , dmarc , Ned Freed Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 11:01:21 -0000 On Nov 9, 2014, at 1:19 AM, Franck Martin = wrote: > ----- Original Message ----- >> From: "Douglas Otis" >> To: "Franck Martin" >>=20 >> Dear Franck, >>=20 >>> Note that an email with no RFC 5322 field is not valid, as well as = one with >>> more than 1. This header is mandatory as well as the Date header. = These >>> are the only 2 headers mandatory in an email. >>>=20 >>> So rejecting an email with no RFC 5322 or more than one is just = following >>> the RFC. >>=20 >> Which normative RFC is that? >=20 > see table under http://tools.ietf.org/html/rfc5322#section-3.6 Dear Franck, This table defines a message format accompanied with an SMTP caution not = to reject messages based on perceived structural errors. Prior to DKIM = creating a security hole in its mandated =46rom header field signing, = repeated =46rom header fields often simply resulted from poorly = automated responses. Since such errors directly affect DKIM's = protection of header fields, DKIM should considered such messages as = having invalid signatures. This would allow subsequent processes an = ability to use results headers without re-examining message structure, = nor does such overlooked checks appear in the Authentication results = header field.=20 >>> I'm not talking on how many mailboxes/domain there are in this = header >>=20 >> It would be wrong to assume SMTP will reject messages based on = possible >> RFC5322 violations. =20 >=20 > While SMTP implementations have been lenient, they have been lenient = in a way which is contrary to this RFC. It is not contrary. SMTP is a store and forward protocol exchanging = messages over MTAs having changed little over decades. There is no = practical way to negotiate format changes, such as those created by RFC = 6854 for example. For SMTP to evolve, some change must be allowed. = Where the change is known to place the integrity of DKIM signatures at = risk, the signatures should not have been considered valid. Although a = simple configuration switch offers a low overhead solution, ignoring = this change was a deliberate choice made by DKIM. > The Postel statement indicates to be lenient when there is protocol = ambiguity, not to allow anything but the kitchen sink when the protocol = is clear about what headers must be present. Why not fix the problem in the algorithm walking the header field stack = from the bottom up during signature validation? It makes little since = to now say all such errors should be rejected. > Therefore it is not wrong to assume SMTP will reject messages on = protocol violations. It is a protocol violation to reject messages because of some perceived = error. It would not be a protocol violation to assert a DKIM signature = is invalid. With that change, Authentication results headers could be = trusted without subsequent processing. Why expect recipients to process = messages a second time? Get it right the first time, especially where = doing so is only a software switch in most cases. Regards, Douglas Otis From nobody Sun Nov 9 05:02:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAD21A1AA9 for ; Sun, 9 Nov 2014 05:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHTOg8pQUz4i for ; Sun, 9 Nov 2014 05:02:17 -0800 (PST) Received: from ntbbs.santronics.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9D31A1AA6 for ; Sun, 9 Nov 2014 05:02:17 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=430; t=1415538125; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=vaqTbUczcYZ+hDjd699rkodvaW8=; b=sLxiZd4cvvXWyU/asgGr W8GFFRm5peWnmBgWIz4bi6b+3ZMeNx7LyYeZ6c916lrLAOBiAKTQWht9IomdRC7j 1EysYtgndPkzaPtpvI++59AT23vjlv9pP7+Wh2H95sqDrvvdfsGZol2y1GK/MFsy oK+x94PH5aMjFaPZzlSAr08= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 09 Nov 2014 08:02: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; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2133196036.2233.4688; Sun, 09 Nov 2014 08:02:04 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=430; t=1415538163; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=XxlfV4U IgqxAJKl0G1UpO1dm3SL9T6nEcrR+QpWEJSs=; b=tH2leGAhv3w5uUjlM+r7IWA IQuZ+RFSYrDahj6NXbprhNkF7aEuuWnI40d5IpweWJJa2rLrD1DsIyaSMfcRdcsQ bb11AqSyqYIZLRFvLtco0cXs3sd1m8w4BF8Du7OP2ptvLJZJUKTONMtq9ESygLPg 8ewxpO+VUBIGYMgw4das= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 09 Nov 2014 08:02:43 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 725600892.9.4972; Sun, 09 Nov 2014 08:02:42 -0500 Message-ID: <545F65C9.8000306@isdg.net> Date: Sun, 09 Nov 2014 08:02:01 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Franck Martin , "Murray S. Kucherawy" References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <35668414-6334-4BCD-B6C8-A471000D72C5@peachymango.org> In-Reply-To: <35668414-6334-4BCD-B6C8-A471000D72C5@peachymango.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lsbJkiQYFRDMClCRU_94lEYlWTU Cc: "dmarc@ietf.org" , Ned Freed Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 13:02:21 -0000 On 11/8/2014 8:29 PM, Franck Martin wrote: > > Note that an email with no RFC 5322 field is not valid, as well as one with more than 1. This header is mandatory as well as the Date header. These are the only 2 headers mandatory in an email. > > So rejecting an email with no RFC 5322 or more than one is just following the RFC. > > I'm not talking on how many mailboxes/domain there are in this header. > +1 -- HLS From nobody Sun Nov 9 05:03:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB861A1AAC for ; Sun, 9 Nov 2014 05:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VadG12Nh_lcQ for ; Sun, 9 Nov 2014 05:02:56 -0800 (PST) Received: from ntbbs.santronics.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4D68E1A1AA6 for ; Sun, 9 Nov 2014 05:02:56 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=637; t=1415538165; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=5l+5IOONT2cnXax8zO1SI0NzFh0=; b=AqfUNBn6wXfqbFa/QFTi RfeG1U1eT1LQVTBcQfv9bwnLCZgjtkwW1XualLAoT/mntgQ7dDFyhrT0pZ/ZAvzg pshiG72l94Gt1FcuRxxnwCdxGRWv0DDeyMSNfTq7LlSHlqkhKWTTYZluZQkeB3Dx nyoluPpcBk65Pcj9VnbtnGQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 09 Nov 2014 08:02:45 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2133236378.2233.4700; Sun, 09 Nov 2014 08:02:44 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=637; t=1415538201; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Kqf/2yW 9v0N7Q9XjfPmYINEE0X6rW2/K2iFAX73R9RM=; b=e5U6VPLxH7I4ahtdXO6v3Zy wdTkDRx5SEmziJ5j+XGwQL9b3dV8CslUuAS56tNJ53yPts7FThi6GGlsrGEIJ4o6 QnWggqoFDh1vvOd0HRw69DN3SnCkbgQOs0fTYC7WbV4wFpKaps9b2nHynyFc4LNq RSeeK54c7g06Zw9oDYG0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 09 Nov 2014 08:03:21 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 725639564.9.4900; Sun, 09 Nov 2014 08:03:21 -0500 Message-ID: <545F65EF.6080906@isdg.net> Date: Sun, 09 Nov 2014 08:02:39 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Franck Martin , Douglas Otis References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <35668414-6334-4BCD-B6C8-A471000D72C5@peachymango.org> <1263541054.270.1415524742766.JavaMail.zimbra@peachymango.org> In-Reply-To: <1263541054.270.1415524742766.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/M3snHAm8xySOUORKt2VDp74mLFk Cc: Ned Freed , dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 13:02:58 -0000 On 11/9/2014 4:19 AM, Franck Martin wrote: >>> I'm not talking on how many mailboxes/domain there are in this header >> >> It would be wrong to assume SMTP will reject messages based on possible >> RFC5322 violations. > > While SMTP implementations have been lenient, they have been lenient in a way which is contrary to this RFC. The Postel statement indicates to be lenient when there is protocol ambiguity, not to allow anything but the kitchen sink when the protocol is clear about what headers must be present. > > Therefore it is not wrong to assume SMTP will reject messages on protocol violations. > +1 -- HLS From nobody Sun Nov 9 07:03:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B7C1A1AD0 for ; Sun, 9 Nov 2014 07:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0l5wpMrFElP0 for ; Sun, 9 Nov 2014 07:03:09 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0651A1AC8 for ; Sun, 9 Nov 2014 07:03:09 -0800 (PST) Received: from [10.162.237.182] (228.sub-70-193-133.myvzw.com [70.193.133.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id A9931CB46; Sun, 9 Nov 2014 10:03:06 -0500 (EST) References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> <545EA08E.8080405@sonnection.nl> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <6AB88EAE-9F5B-43EA-8577-9966FBDAEAAB@eudaemon.net> X-Mailer: iPhone Mail (12B411) From: Tim Draegen Date: Sun, 9 Nov 2014 10:03:04 -0500 To: Franck Martin Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mse18woWqrcuDrE01fJVLgJ07CE Cc: "ned+dmarc@mrochek.com" , "J. Trent Adams" , Brett McDowell , "dmarc@ietf.org" , "Murray S. Kucherawy" , "Stephen J. Turnbull" , "" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 15:03:11 -0000 > On Nov 8, 2014, at 8:38 PM, Franck Martin wrote: >=20 > There are no secret sauces. I thought it was clear this type of language o= n this list is frown upon as non constructive? Just a point of clarification here. The original author was referring to de= cisions that receivers make when processing email. "Secret sauce" is often s= horthand for the local conditions that exist at a receiver (eg input from lo= cal user behavior, site specific content scanning, etc). No foul here. Play on!= From nobody Sun Nov 9 09:34:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952EA1A1BDF for ; Sun, 9 Nov 2014 09:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.658 X-Spam-Level: * X-Spam-Status: No, score=1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuB9mM4I4ccl for ; Sun, 9 Nov 2014 09:34:32 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by ietfa.amsl.com (Postfix) with ESMTP id 226851A1BE1 for ; Sun, 9 Nov 2014 09:34:31 -0800 (PST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6EAE11A30A3; Sun, 9 Nov 2014 09:21:21 +0900 (JST) From: "Stephen J. Turnbull" To: R.E.Sonneveld@sonnection.nl In-Reply-To: <545EA08E.8080405@sonnection.nl> References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> <545EA08E.8080405@sonnection.nl> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 09 Nov 2014 09:21:21 +0900 Message-ID: <87h9y9xlz2.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nfv42RJMEPNCN8-EP4780bdVlQs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 17:34:33 -0000 Trimming the CC list, as we're getting into spam-trap numbers of mailboxes. Rolf E. Sonneveld writes: > The current effort to publish DMARC as informational RFC is mainly, to > document the current specification 'as is', to be able to refer from > other documents to a published spec. The concerns raised by Ned and the > proposal of Trent try to address situations, where the spec does not yet > describe what to do (RFC5322.From with multiple addresses), or leaves > room for different interpretations/implementations. I don't think that is the case here; the current spec says what to do (reject them). My problem is with the current rationale. I think it is somewhat bogus, and goes beyond DMARC's remit (it says to reject any message with multiple addresses in From, rather than rejecting on the basis of policy corresponding to Authenticated Identifiers). From nobody Sun Nov 9 09:43:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC671A2130 for ; Sun, 9 Nov 2014 09:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.488 X-Spam-Level: X-Spam-Status: No, score=-0.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpk46Q_4RDe4 for ; Sun, 9 Nov 2014 09:43:18 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8175B1A1C06 for ; Sun, 9 Nov 2014 09:43:18 -0800 (PST) Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5FB5CC403F7; Sun, 9 Nov 2014 11:43:17 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1415554997; bh=BJmfc2VpquL9vcb6aN8aI/k/9ZnJQFlCiSHUjAf1ETk=; h=In-Reply-To:References:Subject:From:Date:To:From; b=kZBv3AR/GV7YTO5ewHZC93fVBJ3tShPNIvu1RCehC3SmcAwU0gr8HkqLBlyD5nEPU wZJgp4N6qaCL/Jv80UK7PvwssYhKVTPd9OiT5wbg10Y6pbMQn3HsU65BF07eid64nz 6WTND36lWWq7UHtOhi5c1ThxLlQMSHC7urtFlTj8= User-Agent: K-9 Mail for Android In-Reply-To: <380386176.286.1415525491547.JavaMail.zimbra@peachymango.org> References: <20141107180651.8446.qmail@ary.lan> <01PEO0RHSW5I00475I@mauve.mrochek.com> <380386176.286.1415525491547.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sun, 09 Nov 2014 12:43:08 -0500 To: dmarc@ietf.org Message-ID: Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1WzDAsI431xDEjEktvDTpWy4INI Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 17:43:19 -0000 On November 9, 2014 4:31:31 AM EST, Franck Martin wrote: > >----- Original Message ----- >> From: ned+dmarc@mrochek.com >> To: "John Levine" >> Cc: dmarc@ietf.org, superuser@gmail.com >> Sent: Friday, November 7, 2014 10:47:20 AM >> Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback >> >> >> > For From: headers with address-free groups, recall that the >motivation >> > for this was EAI downgrades at delivery time. The un-downgraded >> > message had a normal From: header, so normal DMARC applies. If the >> > address is smashed in the downgrade I don't see any reason that the >> > DMARC result needs to change. >> >> Neither do I. > >Conclusion, a DMARC enabled MTA MUST be SMTPUTF8 enabled (so there is >no to little reasons to downgrade). In that case, DMARC ought to be deferred for several years. I don't think you really mean that. Scott K From nobody Sun Nov 9 10:14:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F4E1A1BE0 for ; Sun, 9 Nov 2014 10:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aec16LvbGfre for ; Sun, 9 Nov 2014 10:14:38 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA4B1A1B66 for ; Sun, 9 Nov 2014 10:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1415556878; x=1447092878; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=i7cGkrfHlaV7e6uwAHWd5pClZ7PfJjy63oOxtvZG2B8=; b=nMSpiNFlTgUL7EvtdbESP775Q3/QMRixj6jhA7f0dU8uYCq65RBd1Rnp p2S8UNjR6VBheb3cgrr5Hi3untY3BHZLj9HAlIbISUmIRiaJ4rGddMy/p 3nKLHQDTxPI5liK84oM2G71lFCD9kv1TOqVnOWAEO8YLy0UpeemfaYN+G 8=; X-IronPort-AV: E=Sophos;i="5.07,347,1413270000"; d="scan'208";a="158719803" Received: from ESV4-MB03.linkedin.biz ([fe80::1caa:1422:7ef8:5ceb]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.03.0195.001; Sun, 9 Nov 2014 10:14:37 -0800 From: Franck Martin To: Scott Kitterman Thread-Topic: [dmarc-ietf] draft-kucherawy-dmarc-base feedback Thread-Index: AQHP+//3bJo6BiWHmU2rwzw2Kqq6RpxZF1sA//+CsEk= Date: Sun, 9 Nov 2014 18:14:37 +0000 Message-ID: <2B8192F8-4659-4A8E-9AEF-410810ACB68C@linkedin.com> References: <20141107180651.8446.qmail@ary.lan> <01PEO0RHSW5I00475I@mauve.mrochek.com> <380386176.286.1415525491547.JavaMail.zimbra@peachymango.org>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6Axf1KosTI7F4EuLGKB7_1RoLww Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 18:14:43 -0000 Printed on recycled paper! > On Nov 9, 2014, at 09:43, Scott Kitterman wrote: >=20 >> On November 9, 2014 4:31:31 AM EST, Franck Martin wrote: >>=20 >> ----- Original Message ----- >>> From: ned+dmarc@mrochek.com >>> To: "John Levine" >>> Cc: dmarc@ietf.org, superuser@gmail.com >>> Sent: Friday, November 7, 2014 10:47:20 AM >>> Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback >>>=20 >>>=20 >>>> For From: headers with address-free groups, recall that the >> motivation >>>> for this was EAI downgrades at delivery time. The un-downgraded >>>> message had a normal From: header, so normal DMARC applies. If the >>>> address is smashed in the downgrade I don't see any reason that the >>>> DMARC result needs to change. >>>=20 >>> Neither do I. >>=20 >> Conclusion, a DMARC enabled MTA MUST be SMTPUTF8 enabled (so there is >> no to little reasons to downgrade). >=20 > In that case, DMARC ought to be deferred for several years. I don't think= you really mean that.=20 >=20 I'll settle for a SHOULD ;) Seriously, it is important to strengthen your MTA (and be less permissive),= if you don't want some forms of unwanted emails to work easily around DMAR= C.= From nobody Sun Nov 9 10:27:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E301A6EE9 for ; Sun, 9 Nov 2014 10:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6jyxw9b7T9g for ; Sun, 9 Nov 2014 10:27:46 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 04E631A1A19 for ; Sun, 9 Nov 2014 10:27:46 -0800 (PST) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3jbP2m3H9Cz1L8cr; Sun, 9 Nov 2014 19:27:44 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3jbP2m1wdpz5Mhc4; Sun, 9 Nov 2014 19:27:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 9C40012343B; Sun, 9 Nov 2014 19:27:45 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sDspMvc7LVhj; Sun, 9 Nov 2014 19:27:40 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 8346B1233D5; Sun, 9 Nov 2014 19:27:40 +0100 (CET) Message-ID: <545FB219.3080001@sonnection.nl> Date: Sun, 09 Nov 2014 19:27:37 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Tim Draegen , Franck Martin References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> <545EA08E.8080405@sonnection.nl> <6AB88EAE-9F5B-43EA-8577-9966FBDAEAAB@eudaemon.net> In-Reply-To: <6AB88EAE-9F5B-43EA-8577-9966FBDAEAAB@eudaemon.net> 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=1415557664; bh=RAtKEZvd3uINQQFBrUMvX7kOnVWvgdlSv3+qEu1PwlU=; h=Message-ID:Date:From:To:Subject:From; b=ChzeWSsvEOiGWx9rrdtXl9vUEEey61lqDaWMs4K4Ju4WtizmpiCD4B2VDhz6n2r3e s9SFpfLSdwZS+CizrBCy3orhB/kGYEfCE7U4Urz3XMUjgZf0lncS2X0fG6RqENvo23 PGw4tswpZYdm3AjsHfZpvNRknpGMIDrF+qGag1C8= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3jbP2m3H9Cz1L8cr Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fGrHlF6PgGdkN7eCIlhxU6DdeWE Cc: "ned+dmarc@mrochek.com" , "J. Trent Adams" , Brett McDowell , "dmarc@ietf.org" , "Murray S. Kucherawy" , "Stephen J. Turnbull" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 18:27:48 -0000 On 11/09/2014 04:03 PM, Tim Draegen wrote: >> On Nov 8, 2014, at 8:38 PM, Franck Martin wrote: >> >> There are no secret sauces. I thought it was clear this type of language on this list is frown upon as non constructive? > Just a point of clarification here. The original author was referring to decisions that receivers make when processing email. "Secret sauce" is often shorthand for the local conditions that exist at a receiver (eg input from local user behavior, site specific content scanning, etc). > > No foul here. Play on! thanks, Tim. Frank, this was exactly the meaning of 'secret sauce' I had in mind, like it has been used in the past, see for example [1] and [2]. From [2]: Obviously, in computing reputations via traffic analysis, some private algorithms may come into play. For some RSPs, such "secret sauce" comprises their competitive advantage over others in the same space. Although this is said in the context of reputation, a similar meaning can apply to the internal decision making process within MBP's/ESP's when dealing with the results of e.g. SPF verification or DMARC verification. Having said that, it's still interesting to learn (if you want to share that) what LinkedIn does in situations where there are e.g. multiple addresses in a From field. /rolf [1] http://lists.opendkim.org/archive/opendkim/users/2011/06/1143.html [2] https://tools.ietf.org/html/draft-ietf-repute-considerations-03 From nobody Sun Nov 9 10:36:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE45B1A6F10 for ; Sun, 9 Nov 2014 10:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFIK65f7YZNL for ; Sun, 9 Nov 2014 10:36:10 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2065D1A6EF2 for ; Sun, 9 Nov 2014 10:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1415558170; x=1447094170; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=quVuAy0cEK5cbadU0DCk9CoZp3qUpmIuw3YY5OUTR7Q=; b=1iCT4b+UpOvdPFfUlNaXjeFvBFTf4Xq9AdabkVcsnXQ2Oi+Qa9AhnmhO GzXS+g8eLhFwqQ6+Qdl6sJavyb1Xj0mpFjqIZC4gKGpJC5BW0hd0v7E8N LM6/2Vze9rLID0+bMqtHkZK2gmqydk/MOgOz36hK+bWLbZ90MMwfaoIS7 o=; X-IronPort-AV: E=Sophos;i="5.07,347,1413270000"; d="scan'208";a="158722620" Received: from ESV4-MB03.linkedin.biz ([fe80::1caa:1422:7ef8:5ceb]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.03.0195.001; Sun, 9 Nov 2014 10:36:08 -0800 From: Franck Martin To: "" Thread-Topic: [dmarc-ietf] draft-kucherawy-dmarc-base feedback Thread-Index: AQHP+73X/u6eNe3GuEeMe9vpOyQHjJxY6yYAgAA5J4D//3xEUw== Date: Sun, 9 Nov 2014 18:36:07 +0000 Message-ID: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> <545EA08E.8080405@sonnection.nl> <6AB88EAE-9F5B-43EA-8577-9966FBDAEAAB@eudaemon.net>, <545FB219.3080001@sonnection.nl> In-Reply-To: <545FB219.3080001@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/83aZ9LIqfrDFVzqoOCTjcwOx8Bs Cc: "ned+dmarc@mrochek.com" , Franck Martin , Tim Draegen , "J. Trent Adams" , Brett McDowell , "dmarc@ietf.org" , "Murray S. Kucherawy" , "Stephen J. Turnbull" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 18:36:12 -0000 Printed on recycled paper! > On Nov 9, 2014, at 10:27, Rolf E. Sonneveld = wrote: >=20 > On 11/09/2014 04:03 PM, Tim Draegen wrote: >>> On Nov 8, 2014, at 8:38 PM, Franck Martin wrot= e: >>>=20 >>> There are no secret sauces. I thought it was clear this type of languag= e on this list is frown upon as non constructive? >> Just a point of clarification here. The original author was referring t= o decisions that receivers make when processing email. "Secret sauce" is o= ften shorthand for the local conditions that exist at a receiver (eg input = from local user behavior, site specific content scanning, etc). >>=20 >> No foul here. Play on! >=20 > thanks, Tim. >=20 > Frank, this was exactly the meaning of 'secret sauce' I had in mind, like= it has been used in the past, see for example [1] and [2]. From [2]: >=20 > Obviously, in computing reputations via traffic analysis, some > private algorithms may come into play. For some RSPs, such "secret > sauce" comprises their competitive advantage over others in the same > space. >=20 >=20 > Although this is said in the context of reputation, a similar meaning can= apply to the internal decision making process within MBP's/ESP's when deal= ing with the results of e.g. SPF verification or DMARC verification. >=20 > Having said that, it's still interesting to learn (if you want to share t= hat) what LinkedIn does in situations where there are e.g. multiple address= es in a From field No secret sauce here cf https://github.com/linkedin/dmarc-msys/blob/master/= dmarc.lua#L815 ;)= From nobody Sun Nov 9 10:44:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3861A3BA6 for ; Sun, 9 Nov 2014 10:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBOiV5Ao0aSq for ; Sun, 9 Nov 2014 10:44:24 -0800 (PST) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4005E1A1AD2 for ; Sun, 9 Nov 2014 10:44:24 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3jbPPz1KGLz5Mhc4; Sun, 9 Nov 2014 19:44:23 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3jbPPy65n6z1L8cr; Sun, 9 Nov 2014 19:44:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 2FE4912343B; Sun, 9 Nov 2014 19:44:24 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VraRfnOy52wN; Sun, 9 Nov 2014 19:44:14 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 3B4991233D5; Sun, 9 Nov 2014 19:44:14 +0100 (CET) Message-ID: <545FB5FB.8070409@sonnection.nl> Date: Sun, 09 Nov 2014 19:44:11 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "J. Trent Adams" , ned+dmarc@mrochek.com, "Murray S. Kucherawy" , "dmarc@ietf.org" References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> 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=1415558663; bh=ppQ/ovKMXtCw5RkOi8rtCV4kG15XF1oXIz+EMv5sGBs=; h=Message-ID:Date:From:To:Subject:From; b=Abxvs0w3GkYGvzsI5nBRIpkMuyZCBqIdvaC31m34Xkb4oKY9UdvK9T4yXEIQ0DykU 54ikM5YeqYYAovhEOdu13nHLRnAfDDNARbV/Mjkdk+0KzOHaar3hK6cRoAGZCSd0CZ QAgjEqxqUJz9reZqJ/oW6sAA0+Clr6Ym/KmLRIvk= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3jbPPz1KGLz5Mhc4 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ykLVRbyOKo-M9YL84MQuVlg-uK0 Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 18:44:26 -0000 On 11/08/2014 01:40 AM, J. Trent Adams wrote: [...] > 5.6.2. Determine Handling Policy > > To arrive at a policy disposition for an individual message, Mail > Receivers MUST perform the following actions or their semantic > equivalents. Steps 2-4 MAY be done in parallel, whereas steps 5 and 6 > require input from previous steps. In the case where multiple > identifiers were extracted from the RFC5322.From field, steps 1-4 are > performed for each identifier, collecting the results, prior to > performing steps 5 and 6. > > The steps are as follows: > > 1. Extract the identifier(s) from the addr-spec portion of the > RFC5322.From field of from the message (as above). > > 2. For each identifier, query the DNS for a DMARC policy record > published by the Domain Owner(s). Continue if at least one > policy record is found, or abort DMARC evaluation otherwise. > If there is more than one identifier, the DMARC policy found > for each identifier SHOULD be collected as a set to be used in > step 5. See Section 5.6.3 for the details of policy discovery. > > 3. Perform DKIM signature verification checks. A single email may > contain multiple DKIM signatures. The results of this step are > passed to the remainder of the algorithm and MUST include the > value of the "d=" tag from all checked DKIM signatures. > > 4. Perform SPF validation checks. The results of this step are > passed to the remainder of the algorithm and MUST include the > domain name used to complete the SPF check. > > 5. Conduct identifier alignment checks. With authentication checks > and policy discovery performed, the Mail Receiver checks if > Authenticated Identifiers fall into alignment as described in > Section 3. If one or more of the Authenticated Identifiers align > with an identifier extracted from the addr-spec of the > RFC5322.From domain, the message is considered to pass the > DMARC mechanism check. All other conditions (authentication > failures, identifier mismatches) are considered to be DMARC > mechanism check failures. > > 6. Apply policy. Within the set of DMARC policies found in Step > 2, select the most strict (with p="none" being the least strict, > next being "quarantine", and "reject" being the most strict) to > use in applying policy. See Section 5.3 for details of the > discovered DMARC policies. We would like to apply the most strict policy, but doesn't that conflict with the p=none policy, where Domain Owners can start gathering reports without having to bother about impact on the disposition of their mail? Furthermore, doesn't a 'most strict' conflict with the meaning of the pct tag: > The purpose of > the "pct" tag is to allow Domain Owners to enact a slow rollout > enforcement of the DMARC mechanism. The prospect of "all or > nothing" is recognized as preventing many organizations from > experimenting with strong authentication-based mechanisms. Treating the mail with the most strict policy for a From field with two addresses, where one of them has p=reject and the other p=none, may have the result that p=reject is applied for mail from the domain which has policy=none. Or am I missing something? /rolf From nobody Sun Nov 9 10:51:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6C91A6F42 for ; Sun, 9 Nov 2014 10:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 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, URIBL_RHS_DOB=1.514] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0yB0jMxUy4I for ; Sun, 9 Nov 2014 10:51:46 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 328FC1A6F34 for ; Sun, 9 Nov 2014 10:51:46 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id B380C565226; Sun, 9 Nov 2014 12:51:45 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A4B1060280; Sun, 9 Nov 2014 12:51:45 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K10n5bAvgw3o; Sun, 9 Nov 2014 12:51:45 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 54034602E9; Sun, 9 Nov 2014 12:51:45 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 54034602E9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415559105; bh=mShfa3qsOs7O6Ex45d4UXvrUTmgRYAIi9bMoZRFgk/g=; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject: Message-Id:Date:To; b=YgPKe5kSQyh+HRc7CeLP6+FJmKdOqhACa0IKAX2pUTAiIT0luQLOoTT4LqrtHmue2 bwpaX18/sAdOGDj5t3hrLmMehG+wlxrhQSr5MgQ+yUIZHE77Z7aXeh5zt/vxIBiA0Y ufoUz1smXL0qjAg1RGL/yQUte7DL5jTOYP+nLpdQ= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3DAF060282; Sun, 9 Nov 2014 12:51:45 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id bKUrJPGi-6FJ; Sun, 9 Nov 2014 12:51:45 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 1D16A60280; Sun, 9 Nov 2014 12:51:45 -0600 (CST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Franck Martin Mime-Version: 1.0 Message-Id: Date: Sun, 9 Nov 2014 12:51:45 -0600 (CST) References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> <545EA08E.8080405@sonnection.nl> <6AB88EAE-9F5B-43EA-8577-9966FBDAEAAB@eudaemon.net> <545FB219.3080001@sonnection.nl> To: "" In-Reply-To: <545FB219.3080001@sonnection.nl> X-Mailer: Zimbra 8.0.5_GA_5839 (MobileSync - Apple-iPad4C1/1202.410) Thread-Topic: draft-kucherawy-dmarc-base feedback Thread-Index: 78x/IR8tmxoxwZJpLAMkaqnjuLILBw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HWy3kbtZSfPAPCiT_XHqQ92Sm4s Cc: "ned+dmarc@mrochek.com" , Tim Draegen , "J. Trent Adams" , Brett McDowell , "dmarc@ietf.org" , "Murray S. Kucherawy" , "Stephen J. Turnbull" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 18:51:47 -0000 Printed on recycled paper! > On Nov 9, 2014, at 10:27, Rolf E. Sonneveld w= rote: >=20 > On 11/09/2014 04:03 PM, Tim Draegen wrote: >>> On Nov 8, 2014, at 8:38 PM, Franck Martin wrote= : >>>=20 >>> There are no secret sauces. I thought it was clear this type of language= on this list is frown upon as non constructive? >> Just a point of clarification here. The original author was referring to= decisions that receivers make when processing email. "Secret sauce" is oft= en shorthand for the local conditions that exist at a receiver (eg input fro= m local user behavior, site specific content scanning, etc). >>=20 >> No foul here. Play on! >=20 > thanks, Tim. >=20 > Frank, this was exactly the meaning of 'secret sauce' I had in mind, like i= t has been used in the past, see for example [1] and [2]. =46rom [2]: >=20 > Obviously, in computing reputations via traffic analysis, some > private algorithms may come into play. For some RSPs, such "secret > sauce" comprises their competitive advantage over others in the same > space. >=20 >=20 > Although this is said in the context of reputation, a similar meaning can a= pply to the internal decision making process within MBP's/ESP's when dealing= with the results of e.g. SPF verification or DMARC verification. >=20 > Having said that, it's still interesting to learn (if you want to share th= at) what LinkedIn does in situations where there are e.g. multiple addresses= in a =46rom field. No secret sauce here cf https://github.com/linkedin/dmarc-msys/blob/master/d= marc.lua#L815 :P (Resent from a more suitable email address)= From nobody Sun Nov 9 11:58:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8581A6FDB for ; Sun, 9 Nov 2014 11:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmtY2M6YwS1h for ; Sun, 9 Nov 2014 11:58:29 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2961A6FE1 for ; Sun, 9 Nov 2014 11:58:28 -0800 (PST) Received: from [10.165.108.79] (51.sub-70-208-137.myvzw.com [70.208.137.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id AF524C403F8; Sun, 9 Nov 2014 13:58:27 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1415563108; bh=bGGs2zrKqdaGOeZ5p4V5HVSS5GeQbJcP34NXhe0rPv4=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Burd30+hwpM2xWMW8OVO9SjaHZ9eJ9Ah8UtxAEhZQ3y6hFSQW4EBg4DyG1ETJS5UB a3kDOqaGiz4Kx3KkKuQ6WSYXbChL2PZfbhw2ivjfKDG6t4rPPJ9P8vi/hqwrpvUwkN Ac9OzGy3QUZyxZVY0SKrZWhM1Vl6Qe10dim8pDiU= User-Agent: K-9 Mail for Android In-Reply-To: <545FB5FB.8070409@sonnection.nl> References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <545FB5FB.8070409@sonnection.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sun, 09 Nov 2014 14:58:19 -0500 To: "dmarc@ietf.org" Message-ID: <321E28BD-8520-440E-BA9E-C336A0156B22@kitterman.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gezLZbX91aFUy8aQELpt6UXu0KY Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 19:58:30 -0000 On November 9, 2014 1:44:11 PM EST, "Rolf E. Sonneveld" wrote: >On 11/08/2014 01:40 AM, J. Trent Adams wrote: > >[...] > >> 5.6.2. Determine Handling Policy >> >> To arrive at a policy disposition for an individual message, Mail >> Receivers MUST perform the following actions or their semantic >> equivalents. Steps 2-4 MAY be done in parallel, whereas steps 5 and >6 >> require input from previous steps. In the case where multiple >> identifiers were extracted from the RFC5322.From field, steps 1-4 are >> performed for each identifier, collecting the results, prior to >> performing steps 5 and 6. >> >> The steps are as follows: >> >> 1. Extract the identifier(s) from the addr-spec portion of the >> RFC5322.From field of from the message (as above). >> >> 2. For each identifier, query the DNS for a DMARC policy record >> published by the Domain Owner(s). Continue if at least one >> policy record is found, or abort DMARC evaluation otherwise. >> If there is more than one identifier, the DMARC policy found >> for each identifier SHOULD be collected as a set to be used >in >> step 5. See Section 5.6.3 for the details of policy >discovery. >> >> 3. Perform DKIM signature verification checks. A single email >may >> contain multiple DKIM signatures. The results of this step >are >> passed to the remainder of the algorithm and MUST include the >> value of the "d=" tag from all checked DKIM signatures. >> >> 4. Perform SPF validation checks. The results of this step are >> passed to the remainder of the algorithm and MUST include the >> domain name used to complete the SPF check. >> >> 5. Conduct identifier alignment checks. With authentication >checks >> and policy discovery performed, the Mail Receiver checks if >> Authenticated Identifiers fall into alignment as described in >> Section 3. If one or more of the Authenticated Identifiers >align >> with an identifier extracted from the addr-spec of the >> RFC5322.From domain, the message is considered to pass the >> DMARC mechanism check. All other conditions (authentication >> failures, identifier mismatches) are considered to be DMARC >> mechanism check failures. >> >> 6. Apply policy. Within the set of DMARC policies found in Step >> 2, select the most strict (with p="none" being the least >strict, >> next being "quarantine", and "reject" being the most strict) >to >> use in applying policy. See Section 5.3 for details of the >> discovered DMARC policies. > >We would like to apply the most strict policy, but doesn't that >conflict >with the p=none policy, where Domain Owners can start gathering reports > >without having to bother about impact on the disposition of their mail? > >Furthermore, doesn't a 'most strict' conflict with the meaning of the >pct tag: > >> The purpose of >> the "pct" tag is to allow Domain Owners to enact a slow rollout >> enforcement of the DMARC mechanism. The prospect of "all or >> nothing" is recognized as preventing many organizations from >> experimenting with strong authentication-based mechanisms. > >Treating the mail with the most strict policy for a From field with two > >addresses, where one of them has p=reject and the other p=none, may >have >the result that p=reject is applied for mail from the domain which has >policy=none. Or am I missing something? Sure. OTOH, picking anything other than the strongest policy makes for a trivially implemented bypass of DMARC checks. Given this is a rare corner case, I think it's better to lean towards strictness than leniency. Scott K From nobody Sun Nov 9 12:31:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A9A1A854D for ; Sun, 9 Nov 2014 12:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.2 X-Spam-Level: X-Spam-Status: No, score=0.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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRvFdH1D_Ksl for ; Sun, 9 Nov 2014 12:31:15 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B776D1A8549 for ; Sun, 9 Nov 2014 12:31:14 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so8724630wiv.13 for ; Sun, 09 Nov 2014 12:31:13 -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:content-type; bh=X/5Cz7WL6avWhCAfn51qIsKT/F/Y9LxJGfWFu/Zn/rw=; b=CzJNScO+q6fXahhJufF8ZBM1BDlD8+4mnBpfSo+rNQ4mlSSfAWiPXlMUogMR1j/0pg VRU0XGeVP+BbP0a5DoMuG1nw9d9hq5D6kiWAZdAulRcMF4+FsB1OiPhlixNmYk1wLsj+ +AyDDbYuOntwQKW6pQKDb/3CBXV5Vkk5hwL7DN+ZVGW9at634eP/4omuiY/pZdvBpFSY j5xAGm0AWQpoQgD0WWR9Sy1L8X+Homf/9Xr1GtBSG+mui6lFLK8BWEklKg6PJKX4FqVF FJKU2fKUphg7RrfsCcx9mHL1YgAvE2NDuQBMaDfVCF+VLqVjDjdx0OAmPvT/w9kdvCzh MFeg== 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:content-type; bh=X/5Cz7WL6avWhCAfn51qIsKT/F/Y9LxJGfWFu/Zn/rw=; b=BoUAjIz3N++qeBcSjRcThwoU3ZyHw7sITwXhxMyhHzUc6NFNXAAtzhzTjTJcpEZXu2 +H3xn6+vX/NBDwjW+Z9AgNnIOB0dL69i6lOkWyiz8MZrq4xHZiilkFx4SnjnvMj7wL9P l9Ml+NGpKaKf13StMGN6rVfYHoFbvPbOdP+lDFignp6yMH5/M+QlRUpPF54EC0Ch1qrn Sg65cIEsh7dZ7KB4FEnlsP+WdtSdIpuYI+ephOSoOBY20+k0HCfxeofiW+OiKuaSBzkx KIBvOIZS1u/3xMO3fi0W9lu9yJtPEQ+4MNsrc9P0ERvaoGeLEau1mBT0JBbueHYxcZ1G z1yQ== X-Received: by 10.194.60.16 with SMTP id d16mr37331575wjr.13.1415565073567; Sun, 09 Nov 2014 12:31:13 -0800 (PST) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com. [209.85.212.176]) by mx.google.com with ESMTPSA id pf4sm9388993wjb.36.2014.11.09.12.31.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 12:31:12 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id h11so8738363wiw.3 for ; Sun, 09 Nov 2014 12:31:11 -0800 (PST) X-Gm-Message-State: ALoCoQltZT1qnd0bkarC6j67FaPOAQNArcXxEwm8evSOASvhiulHfs/q8sdzwWLlLJF/Eqzo84Kv X-Received: by 10.180.19.234 with SMTP id i10mr25071211wie.28.1415565071827; Sun, 09 Nov 2014 12:31:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.175.233 with HTTP; Sun, 9 Nov 2014 12:30:31 -0800 (PST) In-Reply-To: <321E28BD-8520-440E-BA9E-C336A0156B22@kitterman.com> References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <545FB5FB.8070409@sonnection.nl> <321E28BD-8520-440E-BA9E-C336A0156B22@kitterman.com> From: Brett McDowell Date: Sun, 9 Nov 2014 15:30:31 -0500 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=bcaec53d5f0f435e0d050772ed0a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/iDjZkGDQ1XEVt2kZQ61ZMJQ35HY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 20:31:16 -0000 --bcaec53d5f0f435e0d050772ed0a Content-Type: text/plain; charset=UTF-8 On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman wrote: > >We would like to apply the most strict policy, but doesn't that > >conflict > >with the p=none policy, where Domain Owners can start gathering reports > > > >without having to bother about impact on the disposition of their mail? > > > >Furthermore, doesn't a 'most strict' conflict with the meaning of the > >pct tag: > > > >> The purpose of > >> the "pct" tag is to allow Domain Owners to enact a slow rollout > >> enforcement of the DMARC mechanism. The prospect of "all or > >> nothing" is recognized as preventing many organizations from > >> experimenting with strong authentication-based mechanisms. > > > >Treating the mail with the most strict policy for a From field with two > > > >addresses, where one of them has p=reject and the other p=none, may > >have > >the result that p=reject is applied for mail from the domain which has > >policy=none. Or am I missing something? > > Sure. OTOH, picking anything other than the strongest policy makes for a > trivially implemented bypass of DMARC checks. > > Given this is a rare corner case, I think it's better to lean towards > strictness than leniency. > > +1 --bcaec53d5f0f435e0d050772ed0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman <sklist@kitterman.com> wrote:
>We would like to apply the most strict policy, bu= t doesn't that
>conflict
>with the p=3Dnone policy, where Domain Owners can start gathering repor= ts
>
>without having to bother about impact on the disposition of their mail?=
>
>Furthermore, doesn't a 'most strict' conflict with the mean= ing of the
>pct tag:
>
>> The purpose of
>> the "pct" tag is to allow Domain Owners to enact a slow = rollout
>> enforcement of the DMARC mechanism. The prospect of "all or >> nothing" is recognized as preventing many organizations from<= br> >> experimenting with strong authentication-based mechanisms.
>
>Treating the mail with the most strict policy for a From field with two=
>
>addresses, where one of them has p=3Dreject and the other p=3Dnone, may=
>have
>the result that p=3Dreject is applied for mail from the domain which ha= s
>policy=3Dnone. Or am I missing something?

Sure. OTOH, picking anything other than the strongest policy ma= kes for a trivially implemented bypass of DMARC checks.

Given this is a rare corner case, I think it's better to lean towards s= trictness than leniency.


+1


--bcaec53d5f0f435e0d050772ed0a-- From nobody Sun Nov 9 13:15:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4101A8727 for ; Sun, 9 Nov 2014 13:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kaOSjsLKB7z for ; Sun, 9 Nov 2014 13:15:03 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8E81A8726 for ; Sun, 9 Nov 2014 13:15:03 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id AC57A564E5D; Sun, 9 Nov 2014 15:15:02 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 90A18A0392; Sun, 9 Nov 2014 15:15:02 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHPlCGuK5T67; Sun, 9 Nov 2014 15:15:02 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0F6D5A03C8; Sun, 9 Nov 2014 15:15:02 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 0F6D5A03C8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415567702; bh=EJ4tvmP8IejZ55228bQVM5AwSZDk6rl+FF0HY2Ujeyc=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=PLohuNjyLNnTa/DwjpbFlLukqQHJR4zaza0BA6p5WJLOmwoS6krpmtRqHR03r/mwi GLTJWKzRzcj1ko/W1ekI4GwPYsGwF9hHoavn+s78XJiUVktTEZCDxXBcGHGb7Isvzo eg3gxW6plwMaa+FIEKfDPBv2WzR5LbcW1ob1W8hk= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id CD988A03BA; Sun, 9 Nov 2014 15:15:01 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id afVBjO5nRq-9; Sun, 9 Nov 2014 15:15:01 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 9C939A0392; Sun, 9 Nov 2014 15:15:01 -0600 (CST) Date: Sun, 9 Nov 2014 15:15:01 -0600 (CST) From: Franck Martin To: Brett McDowell Message-ID: <720075258.3227.1415567701474.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <545FB5FB.8070409@sonnection.nl> <321E28BD-8520-440E-BA9E-C336A0156B22@kitterman.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3226_692317872.1415567701473" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-kucherawy-dmarc-base feedback Thread-Index: yyYpvHI3f/iBztx8cWTEloKHA7y5fg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/VdpIrFtOpJ6l4bZKrftax_R4gJw Cc: dmarc@ietf.org, Scott Kitterman Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 21:15:05 -0000 ------=_Part_3226_692317872.1415567701473 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Brett McDowell" > To: "Scott Kitterman" > Cc: dmarc@ietf.org > Sent: Sunday, November 9, 2014 12:30:31 PM > Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback > On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman < sklist@kitterman.com > > wrote: > > >We would like to apply the most strict policy, but doesn't that > > > >conflict > > > >with the p=none policy, where Domain Owners can start gathering reports > > > > > > > >without having to bother about impact on the disposition of their mail? > > > > > > > >Furthermore, doesn't a 'most strict' conflict with the meaning of the > > > >pct tag: > > > > > > > >> The purpose of > > > >> the "pct" tag is to allow Domain Owners to enact a slow rollout > > > >> enforcement of the DMARC mechanism. The prospect of "all or > > > >> nothing" is recognized as preventing many organizations from > > > >> experimenting with strong authentication-based mechanisms. > > > > > > > >Treating the mail with the most strict policy for a From field with two > > > > > > > >addresses, where one of them has p=reject and the other p=none, may > > > >have > > > >the result that p=reject is applied for mail from the domain which has > > > >policy=none. Or am I missing something? > > > Sure. OTOH, picking anything other than the strongest policy makes for a > > trivially implemented bypass of DMARC checks. > > > Given this is a rare corner case, I think it's better to lean towards > > strictness than leniency. > > +1 >From the code I gave, I ran for several weeks my system in logging mode to record the RFC5322.From when it had zero or more than one mailbox. This is what I found: A bug at a major mailbox provider that was not rendering a variable correctly (no domain in From) A bug with a common dot NET version that would do a From like this (If I recall correctly): From: jon@example.com (the first email address is meant to be double quoted) All the rest were bounces (NDM) with stuff like From: postmaster@local or From: mail-daemon@mail6.example.com, postmaster@localhost,... In short non configured machines, some doing backscatter, some not... NDM are getting rarer nowadays by the way. Did not find (probability close to 0 but non null) a single email with 2 email addresses in the From that is meant to an end user. I wish the mailbox-list syntax in the From would be deprecated for the mailbox syntax, but it is unlikely to happen, may be when RFC5322 gets revised (under Security, end to end, IPv6 experience), but from an operational point of view (if you want ops to come back to IETF, listen to them :P ) you don't loose any useful email if you reject emails with multiple mailboxes in the From. ------=_Part_3226_692317872.1415567701473 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Brett McDowell" <brettmcdowell@g= mail.com>
To: "Scott Kitterman" <sklist@kitterman.com>Cc: dmarc@ietf.org
Sent: Sunday, November 9, 2014 12:30:= 31 PM
Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedba= ck


On Sun, Nov 9, 2014 at 2:58 PM, Scott Kitterman <s= klist@kitterman.com> wrote:
>We would like to apply the m= ost strict policy, but doesn't that
>conflict
>with the p=3Dnone policy, where Domain Owners can start gathering repor= ts
>
>without having to bother about impact on the disposition of their mail?=
>
>Furthermore, doesn't a 'most strict' conflict with the meaning of the >pct tag:
>
>> The purpose of
>> the "pct" tag is to allow Domain Owners to enact a slow rollout >> enforcement of the DMARC mechanism. The prospect of "all or
>> nothing" is recognized as preventing many organizations from
>> experimenting with strong authentication-based mechanisms.
>
>Treating the mail with the most strict policy for a From field with two=
>
>addresses, where one of them has p=3Dreject and the other p=3Dnone, may=
>have
>the result that p=3Dreject is applied for mail from the domain which ha= s
>policy=3Dnone. Or am I missing something?

Sure. OTOH= , picking anything other than the strongest policy makes for a trivially im= plemented bypass of DMARC checks.

Given this is a rare corner case, I think it's better to lean towards stric= tness than leniency.


+1
<= /div>
From the code I gave, I ran for several weeks my sys= tem in logging mode to record the RFC5322.From when it had zero or more tha= n one mailbox. This is what I found:

A bug at = a major mailbox provider that was not rendering a variable correctly (no do= main in From)
A bug with a common dot NET version that would = do a From like this (If I recall correctly): From: jon@example.com <jon@= example.com> (the first email address is meant to be double quoted)
<= /div>
All the rest were bounces (NDM) with stuff like From: postmaster@local or From: mail-daemon@mail6.example.com, postmaster= @localhost,... In short non configured machines, some doing backscatter, so= me not... NDM are getting rarer nowadays by the way.
Did not = find (probability close to 0 but non null) a single email with 2 email addr= esses in the From that is meant to an end user.

I wish the mailbox-list syntax in the From would be deprecated for the ma= ilbox syntax, but it is unlikely to happen, may be when RFC5322 gets revise= d (under Security, end to end, IPv6 experience), but from an operational po= int of view (if you want ops to come back to IETF, listen to them :P ) you = don't loose any useful email if you reject emails with multiple mailboxes i= n the From.
------=_Part_3226_692317872.1415567701473-- From nobody Mon Nov 10 01:22:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4E01A894A for ; Mon, 10 Nov 2014 01:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYSdLNSklRq2 for ; Mon, 10 Nov 2014 01:22:26 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C340C1A887A for ; Mon, 10 Nov 2014 01:22:26 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 379DB1C397A; Mon, 10 Nov 2014 18:22:25 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1279E1A2844; Mon, 10 Nov 2014 18:22:25 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <720075258.3227.1415567701474.JavaMail.zimbra@peachymango.org> References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <545FB5FB.8070409@sonnection.nl> <321E28BD-8520-440E-BA9E-C336A0156B22@kitterman.com> <720075258.3227.1415567701474.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 10 Nov 2014 18:22:24 +0900 Message-ID: <87bnofxve7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zNrG2xkqmjzieUJABMhKFFl3ubA Cc: Brett McDowell , dmarc@ietf.org, Scott Kitterman Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 09:22:29 -0000 Franck Martin writes: > I wish the mailbox-list syntax in the From would be deprecated for > the mailbox syntax, but it is unlikely to happen, may be when > RFC5322 gets revised (under Security, end to end, IPv6 experience), I don't understand why any of those experiences would cause RFC 5322 to be revised in this way. The problem is not in the protocol used to implement the network, but rather in the structure of the network of people involved. Most email networks-of-people don't involve a use case for multiple mailboxes in From, but some do (see below). OTOH, if you really need to pin responsibility for message origination on a particular person, the Sender field is the appropriate field. Even in the case of DMARC, as far as I can tell, for the intended use case of transactional mail there is little problem with throwing From- with-multiple-mailboxes into the "unauthenticable" pool, and rejecting on that basis if you want to. I see no reason to disallow this useful feature in RFC 5322 when it is better done in DMARC, or perhaps in the lower level protocols. > but from an operational point of view (if you want ops to come back > to IETF, listen to them :P ) you don't loose any useful email if > you reject emails with multiple mailboxes in the From. Please take more care with your pronouns. I am not a member of your "you". I know for a fact that if every MTA rejects because of multiple mailboxes in From, mail I consider important will not be delivered. I know and consider it important because I write it on behalf of an anti-harassment committee, and it's important that the members be individually identified[1] and individually reply-able[2]. There are other ways to accomplish these goals simultaneously, but using multiple mailboxes in From is all of most economical, most intuitive, and most beautiful. (I occasionally do it in other cases, but this case is special because it is of true utility to the recipients.) Given that you say this practice is rare and mostly harmless in your own experience, I don't see that the costs of treating such messages as an unauthenticated are high. Also, your experience is probably far less generic than you think, if it's based on LinkedIn. LinkedIn is a social network based not on groups but on individual links (although it provides groups, IME they are not entities in themselves in the way that bureaucratic committees are, but rather aliases for a "me-to-many" set of bilateral links based on common interest rather than individual identity). It is no surprise to me that the vast majority of messaging at LinkedIn is related to *one*-to-one or *one*-to-many communications. The reverse relationship ("many-to-you") is more likely in a bureaucratic context (and certainly is useful for me personally). If you *aren't* speaking of LinkedIn, or that's not a correct analysis of how LinkedIn works, feel free to enlighten us. Footnotes: [1] We have ex oficio personal responsibilities to maintain student privacy that are actually a special exception to the normal faculty- administration relationship. [2] Not a group address -- it's not unheard of for bad actors to end up on such committees, although not in my tenure, thank heaven. From nobody Mon Nov 10 02:00:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34141A89A4 for ; Mon, 10 Nov 2014 02:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfUJojKc0MUC for ; Mon, 10 Nov 2014 02:00:19 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id B89E91A89A3 for ; Mon, 10 Nov 2014 02:00:18 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 33879564ACC; Mon, 10 Nov 2014 04:00:18 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E9956A02FF; Mon, 10 Nov 2014 04:00:17 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e00uAlfbcbX; Mon, 10 Nov 2014 04:00:17 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B12E2A0337; Mon, 10 Nov 2014 04:00:15 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com B12E2A0337 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415613616; bh=h8UYZgArmlAjo210xzKQMZGKacOn1fyUbh+Bz25T6Bk=; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject: Message-Id:Date:To; b=RXEGbOnaVhOQq0qNrwmV6OWiDW8chQDDa6mHHwsrwvHWbVqigvTQPMDiSdQ/bJaCF CwwynCMPF/oTV+ffsZtMTs+VmONolwhgHTqYf+AQa5HiEJEaSoMpdxkhWQP+6aXwCc 6fCogXWAj0hNI8R6C4tzmem/0IKdAAfzk2WUglO8= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 83B71A0320; Mon, 10 Nov 2014 04:00:15 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dGv2PWjbiwvx; Mon, 10 Nov 2014 04:00:15 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 442F9A02FF; Mon, 10 Nov 2014 04:00:15 -0600 (CST) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Franck Martin Mime-Version: 1.0 Message-Id: Date: Mon, 10 Nov 2014 04:00:14 -0600 (CST) References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <545FB5FB.8070409@sonnection.nl> <321E28BD-8520-440E-BA9E-C336A0156B22@kitterman.com> <720075258.3227.1415567701474.JavaMail.zimbra@peachymango.org> <87bnofxve7.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" In-Reply-To: <87bnofxve7.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: Zimbra 8.0.5_GA_5839 (MobileSync - Apple-iPad4C1/1202.410) Thread-Topic: draft-kucherawy-dmarc-base feedback Thread-Index: OBuBkMZFSdCHNJzsT7TPpTiekDNE9w== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WMoHS3fNwsBm469ieZYvrrhuDi8 Cc: Brett McDowell , "dmarc@ietf.org" , Scott Kitterman , Franck Martin Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 10:00:22 -0000 Printed on recycled paper! > On Nov 9, 2014, at 23:22, Stephen J. Turnbull wrote: >=20 > Franck Martin writes: >=20 >> I wish the mailbox-list syntax in the =46rom would be deprecated for >> the mailbox syntax, but it is unlikely to happen, may be when >> RFC5322 gets revised (under Security, end to end, IPv6 experience), >=20 > I don't understand why any of those experiences would cause RFC 5322 > to be revised in this way. The problem is not in the protocol used to > implement the network, but rather in the structure of the network of > people involved. Most email networks-of-people don't involve a use > case for multiple mailboxes in From, but some do (see below). OTOH, > if you really need to pin responsibility for message origination on a > particular person, the Sender field is the appropriate field. >=20 The part missing was end to end encryption where I heard that it could be co= nceivable that the entire DATA part be encrypted (headers+body). The only in= fo the MTA would have is the envelope. This would require a somehow update/r= ewrite of RFC5322, but we are not there. Ps: Please don't summarize my experience to Linkedin, I had many other lives= before that.= From nobody Mon Nov 10 08:34:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFC21A1B47 for ; Fri, 7 Nov 2014 23:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.015 X-Spam-Level: X-Spam-Status: No, score=0.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.594] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg5a-Y-1UmKF for ; Fri, 7 Nov 2014 23:50:51 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D71671A1B43 for ; Fri, 7 Nov 2014 23:50:50 -0800 (PST) Received: from infoshako.sk.tsukuba.ac.jp (app-a.sk.tsukuba.ac.jp [130.158.97.162]) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTP id B933C1C39DC; Sat, 8 Nov 2014 16:50:48 +0900 (JST) Received: from 113.148.46.181 (RisuMail authenticated user turnbull) by infoshako.sk.tsukuba.ac.jp with HTTP; Sat, 8 Nov 2014 16:50:48 +0900 (JST) Message-ID: <49726.113.148.46.181.1415433048.risu@infoshako.sk.tsukuba.ac.jp> In-Reply-To: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp><01PEMWEN5Q8W003WE3@mauve.mrochek.com><49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> Date: Sat, 8 Nov 2014 16:50:48 +0900 (JST) From: turnbull@sk.tsukuba.ac.jp To: "Murray S. Kucherawy" User-Agent: RisuMail 3.1 X-Mailer: RisuMail 3.1 MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Pa07cGSCLFqlAcnGaw47cYCDfgQ X-Mailman-Approved-At: Mon, 10 Nov 2014 08:34:53 -0800 Cc: "dmarc@ietf.org" , "J. Trent Adams" , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 07:50:52 -0000 [Excuse my broken mail system; until the tech staff return on Monday, it looks like I'm stuck with a webmail interface where I can't change my From to the subscribed address or break lines properly etc.] > On Fri, Nov 7, 2014 at 8:57 PM, wrote: >> Trent Adams writes: >> > ----- >> > It is important to note that identifier alignment cannot occur, and >> > DMARC determination applied, with a message that is not valid per RFC >> > 5322 [MAIL]. This is particularly true when a message has a malformed >> > or absent RFC5322.From field. >> > ----- >> (I think that is a plausible policy choice, since in an invalid message >> "anything can happen". But I don't see that it's a no-brainer.) > Do you have another suggestion? Remove the words "with a message that is not valid per RFC 5322 [MAIL]. This is particularly true", and add a comment to the effect of "other kinds of invalid message should be viewed with extreme suspicion in the DMARC context, because MTAs and MUAs will not necessarily be prepared for them and 'anything can happen'" to the Security Considerations. Or just leave that comment for the BCP. > Note that there's nothing normative in Trent's suggestion. Understood, I just think it's factually inaccurate. >> But this seems to be the insecure approach I describe above: >> >> > 5. Conduct identifier alignment checks. With authentication checks >> > and policy discovery performed, the Mail Receiver checks if >> > Authenticated Identifiers fall into alignment as described in >> > Section 3. If one or more of the Authenticated Identifiers align >> > with an identifier extracted from the addr-spec of the >> > RFC5322.From domain, the message is considered to pass the >> > DMARC mechanism check. >> >> AFAICS this allows me (using a throwaway mailbox at a throwaway domain) to >> send spam that passes DMARC on your behalf, as long as my mailbox appears >> in From, too. Am I misunderstanding your proposed algorithm? > No, because in (6) the strictest rule applies. Your throwaway domain might > pass, but the other advertised author's would not. I think my interpretation of Trent's words "If one or more of the Authenticated Identifiers aligns with an identifier extracted" is plausible, though: in that case we don't get to the policy application (6). My understanding is that policy is only applied when the DMARC alignment *fails* for a domain publishing a policy. > Right, I think that's what Trent is also saying. Probably, but I don't think my reading is implausible. Regards, From nobody Mon Nov 10 11:05:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E551A930A for ; Mon, 10 Nov 2014 11:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3ImxYQOIKvf for ; Mon, 10 Nov 2014 11:05:32 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 807F31ABC0F for ; Mon, 10 Nov 2014 11:05:25 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E74271C38F9; Tue, 11 Nov 2014 04:05:23 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C43881A2844; Tue, 11 Nov 2014 04:05:23 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <545FB5FB.8070409@sonnection.nl> <321E28BD-8520-440E-BA9E-C336A0156B22@kitterman.com> <720075258.3227.1415567701474.JavaMail.zimbra@peachymango.org> <87bnofxve7.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 11 Nov 2014 04:05:23 +0900 Message-ID: <87a93yyiz0.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/r7-vvbvGHkhniey37-t7z9YtfQw Cc: Brett McDowell , "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:05:39 -0000 Franck Martin writes: > Ps: Please don't summarize my experience to Linkedin, I had many > other lives before that. I have no choice but to make assumptions about the context in which you collected your data, since you didn't describe it, and the data collection context is required to assess the bias in your results. From nobody Mon Nov 10 11:13:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81201A1A68 for ; Mon, 10 Nov 2014 11:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUQDsux2AAPx for ; Mon, 10 Nov 2014 11:13:53 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2203A1A9252 for ; Mon, 10 Nov 2014 11:13:29 -0800 (PST) Received: from kitterman-optiplex-9020m.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 29AEBC403F7 for ; Mon, 10 Nov 2014 13:13:28 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1415646808; bh=cWPw9MdOUjEyH3p5+zUptuQR2388xdf7ZjpZpI1SZ8U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aCo6HckdvQ6d885RmvAcJGbqsgzn7CA+m34jf30lJkgiZhZ0n+hpOuezrCJfXAB7q hoocv+WpDG2vzxOp84kwoa57eLQ3CrbM1VWxj0slpKSRmdNwcs1pgFs1OWUY/LFEQR Uvk5XgZ+K+0ghviQ2WBjHkYfugCuKa+mWto0Vikc= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 10 Nov 2014 14:14:01 -0500 Message-ID: <3040754.z8V3FInbKc@kitterman-optiplex-9020m> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <5640766.9itaAbt4HU@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8Ze_tB5hGj6lqMhhG6yEXLHFaaM Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base-04 issue X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:13:54 -0000 On Sunday, November 02, 2014 01:44:16 AM Murray S. Kucherawy wrote: > Just noticed that I never replied to this: > > On Fri, Aug 29, 2014 at 8:39 PM, Scott Kitterman > > wrote: > > Since this is the WG list, I'm not sure if this is still the right list > > for > > issues with the base spec or not, but here goes ... > > > > The definition of "fo" in Section 5.2, General Record Format, allows both > > values of "0" and "1" to be specified. It was suggested to me offlist > > that this > > might not be appropriate, so I thought it worth a discussion. > > > > Does anyone who's implemented "fo" have a problem with both "0" and "1" > > being > > specified? If it is somehow problematic, then the base spec ought to say > > so. > > How about this? > > 1: Generate a DMARC failure report if any underlying > authentication mechanism produced something other > than an aligned "pass" result. I think it's fine. It is a bit of an odd situation where reports for fo=0 are a strict subset of fo=1 reports. As a result, having both 0 and 1 specified is somewhat pointless. OTOH, I don't expect an interoperability problem with it, so meh. Scott K From nobody Mon Nov 10 11:23:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124C41AC41F for ; Mon, 10 Nov 2014 11:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRYqBcS98y2x for ; Mon, 10 Nov 2014 11:23:44 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4F61A015B for ; Mon, 10 Nov 2014 11:23:24 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 0F80B564D14; Mon, 10 Nov 2014 13:23:24 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id EF6B860240; Mon, 10 Nov 2014 13:23:23 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-5BxkfIdBA6; Mon, 10 Nov 2014 13:23:23 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 98914601C5; Mon, 10 Nov 2014 13:23:23 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 98914601C5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415647403; bh=wqAN1vdKy+rmTI5fxAg5tofFc0wRT2/G4HihibV1yhQ=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=K9lRqqzPqwMv0I/pxuEUZmF9Zk3k83MDgGt0IQZNkcm/37XWpiBDizjYGp1yUBcLO S7R64Kw4EXSllRzmEj0UAl7TjOeFXh0O1X0tuUmOFcTaqPeEeKVdKj+/KNioafEU/m fDNAktpc83vThXP0R5EQycEmJopAmiDZviaINJ80= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7971860240; Mon, 10 Nov 2014 13:23:23 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nT_eQR0Cpwez; Mon, 10 Nov 2014 13:23:23 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 54D5B601C5; Mon, 10 Nov 2014 13:23:23 -0600 (CST) Date: Mon, 10 Nov 2014 13:23:23 -0600 (CST) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <1514357710.20452.1415647403101.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <720075258.3227.1415567701474.JavaMail.zimbra@peachymango.org> <87bnofxve7.fsf@uwakimon.sk.tsukuba.ac.jp> <87a93yyiz0.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-kucherawy-dmarc-base feedback Thread-Index: eBNbWWR9KUT0a8kUZDU5znAIaFirlg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QbfL7uCvZCEtgm80Hc-8Ij1-e68 Cc: Brett McDowell , dmarc@ietf.org, Scott Kitterman Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 19:23:47 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Franck Martin" > Cc: "Brett McDowell" , dmarc@ietf.org, "Scott Kitterman" > Sent: Monday, November 10, 2014 11:05:23 AM > Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback > > Franck Martin writes: > > > Ps: Please don't summarize my experience to Linkedin, I had many > > other lives before that. > > I have no choice but to make assumptions about the context in which > you collected your data, since you didn't describe it, and the data > collection context is required to assess the bias in your results. Fair enough, in the 20 years I do email (starting with uucp), I don't recall any such email where multiple email addresses where in the From: on purpose. So I'm curious to see some real world examples. If you could add them in the wiki may be? From nobody Mon Nov 10 11:27:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030AC1A1BDE for ; Mon, 10 Nov 2014 11:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.32 X-Spam-Level: X-Spam-Status: No, score=-12.32 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KsxmaJp-ZEX for ; Mon, 10 Nov 2014 11:27:09 -0800 (PST) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4BE1A1A24 for ; Mon, 10 Nov 2014 11:27:09 -0800 (PST) Received: from omp1048.mail.ne1.yahoo.com (omp1048.mail.ne1.yahoo.com [98.138.89.233]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id sAAJPwm3069312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 10 Nov 2014 11:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1415647559; bh=SBu7stRKRIcsheKNW4401is8Nnma8V6BMxJtaMg5N7c=; h=Date:From:Reply-To:To:Subject; b=kepNSJ1o3mx3jK6KzBTSZRdC9itLM42DwFCW59TVXjiyl1Ytz5C6gNRu21Dtr5+PC 3116K+++yjZ3ZdA60y93FIYkcsLDMmupW8vlr+VTxo7dLG0/KdJCJFhKPi9vdQL9dY 2ti7Unm8GUojMXIfQ3yPU6jvWvUHBf+UPSyMo7KU= Received: (qmail 39438 invoked by uid 1000); 10 Nov 2014 19:25:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1415647558; bh=SBu7stRKRIcsheKNW4401is8Nnma8V6BMxJtaMg5N7c=; h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type; b=sS8vmshdSfA8u83QQjTWOAJXQjgtzxD3vWSYoc1Ua3kth/vuyaCJNCfQyal6OoLKiXxqk3Zqdd4E2Qi9aDWISmQIZ/NJ3Ot6ZSxYGPNbqTamDnB8UgMzqwNVtyNTXhOaifkkCsgIIqU9NYWlUHeRTZJkTYuzwqChSfuUV945I5s= X-YMail-OSG: moo2dlYVM1kmSrbx7uMW4SYGKnhxDCgTrGEmOontgvxsP5Ka.ZrL5EvFOUJejSm 8IrWkpmzintTFGM0hoCIyWBTMrvTmeKPzuPZ8kbkMmPsMG6FOdTw3mLNitHa1uxIuUXd8VMH0Ulk GwfYQQLWCc2MofqLD8dMHv_NUKJ6_QzCiEBtMrsbZVG7qJastEhp22U2C_DZ9D.NX5k_C4ULtdEg B74MEqTbufKI4iNvaQzTnlZ7uUvH6teMjojtb.l962rvzLUbd7N1j Received: by 98.138.105.252; Mon, 10 Nov 2014 19:25:57 +0000 Date: Mon, 10 Nov 2014 19:25:56 +0000 (UTC) From: Elizabeth Zwicky To: Dmarc WG Message-ID: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_282178_297613422.1415647556916" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 647559000 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xESSczsFQxVHfi4k1lYdtGhLfag Subject: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Elizabeth Zwicky 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, 10 Nov 2014 19:27:12 -0000 ------=_Part_282178_297613422.1415647556916 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, so I've dived into Yahoo's incoming metadata to look at what fails DMAR= C and why. Conclusion 1: I cannot automatically tell the cases apart with a= ny accuracy. Hand coding them is so time-consuming as to be beyond my abili= ty to do at scale. So, not many numbers, but I have developed some very educated opinions, whi= ch unfortunately take a small novel to explain. First, transactional domains tend to have some mail that fails DMARC becaus= e of forwarding. The highest estimate of that I've seen is about 1.5% (that= 's not data I ran); on the domains I've looked at so far I saw rates well b= elow 0.1%. Still, that's people not getting their mail. For transactional m= ail, this is a strong majority forwarding (as in I send mail to a@b.com and= it delivers to a@c.com), and it's dominated by educational institutions fo= rwarding to their students/alumni, followed by hosting services and ISPs. T= he reasons for the forwarding breaking the signatures clearly vary; there a= re popular mail systems that, for instance, re-mime-encode bodies, or add s= ignature files of various sorts, ranging from notifications that the messag= e has been virus scanned to ads for the ISP forwarding the mail. Re-encodin= g things can result in intermittent breakage, where some forwarding works (= because the forwarder doesn't feel the need to fix it) and other messages d= on't. A minority is not straightforward, my old address routes to my new on= e, forwarding, but are services that are specialized to handling mail -- th= ird party spam filtering or mail classification products that then redelive= r mail. They don't make up a big percentage of the cases but they are notab= le as cases that presumably would be able to change their handling if we pr= ovided them with options. Then we get to end-user domains. Although I've heard from corporate domains= where DMARC breakage is actually lower for the humans than the transaction= al mail, for the big mailbox holders, as far as I can tell, the expected ra= tios hold; more mail fails for end-users than for transactional mail. How m= uch more? That gets interesting. For the domains at p=3Dreject, the mail that arrives with an aligned DKIM s= ignature still on it, but not working -- which is the common case for both = forwarding and mailing lists -- is significantly under 1%. For the domains = at p=3Dnone, that comes closer to 2%. That difference is partly in mailing = lists, but, sadly, a noticeable amount of the difference between p=3Dreject= and p=3Dnone domains when it comes to the mailing list mail is spam from a= few, mostly commercial, mailing list providers. It is clear that a number = of valid, happy mailing lists you might like have chosen to move subscriber= s from p=3Dreject to p=3Dnone providers, with mixed success; the high volum= e ones I've checked still have p=3Dreject posters, at low rates. It is also= clear that a lot of educational institutions *both* run popular, DKIM-brea= king forwarders *and* run popular, DKIM-breaking mailing lists (and, unsurp= risingly, have alumni who go through both at once), which is one way that t= hese things rapidly become intractable for automated processing.=C2=A0 For everybody, way more mail shows up with no aligned DKIM signature on it = than with a broken aligned DKIM signature on it, and no noticeable amount o= f that mail had a DKIM signature stripped off. In fact, for every domain I = looked at, the single largest cause of DMARC fail is purely forged mail, mo= stly spam. The rate of messages with no aligned DKIM signature ranged from = 88% (for a mailbox domain with p=3Dnone) to 2% (for a transactional domain = with p=3Dreject). For transactional domains, that mail is not readily disti= nguishable from pure trash. There must be a DKIM-stripping forward out ther= e somewhere, but I haven't found it. For end-user domains, once you ignore = forged spam, the major volume contributors are hosting sites, but again, th= e use-cases are mixed. The highest volume from hosting sites is spam. The n= ext highest is email to site owners "From:" themselves. There are a lot of = people out there not getting mail from really frequent cron jobs. Then we g= et bulletin boards and blog software letting you know somebody has responde= d to your comment, and e-commerce solutions letting you know that somebody = wants to order something -- all of that shows up in one big jumble from the= hosting providers.=C2=A0 Next we get "parental control" software and other monitoring uses that send= From: and To: the same address and are verbose. And large service provider= s for small businesses. After that, it's the land of a million different indirect uses. More e-comm= erce sites. The people who send you happy birthday messages from your denti= st, who uses a third-party account. Or your tee-time from your golf course,= ditto. Or your tanning bed schedule, because there's a service out there t= hat does nothing but email handling for tanning salons. Printers. Security = equipment. A surprising number of government agencies, including one nation= al nuclear agency sending mail to: and from: the same person when replying = to document requests or using a free email account to do government busines= s. Services for multi-level marketing plans and other sell-to-your-friends = plans. Oh, so many services for realtors. Lots of mail-to-friend features. = Some of which (the ones with the most volume) are being abused for spam. =C2=A0 =C2=A0 Elizabeth =C2=A0 =C2=A0 zwicky@yahoo-inc.com ------=_Part_282178_297613422.1415647556916 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, so I've dived into Yahoo's incoming metadata to look at what fai= ls DMARC and why. Conclusion 1: I cannot automatically tell the cases apart= with any accuracy. Hand coding them is so time-consuming as to be beyond m= y ability to do at scale.

So, not many numbers, but = I have developed some very educated opinions, which unfortunately take a sm= all novel to explain.

First, transactional domains t= end to have some mail that fails DMARC because of forwarding. The highest e= stimate of that I've seen is about 1.5% (that's not data I ran); on the dom= ains I've looked at so far I saw rates well below 0.1%. Still, that's peopl= e not getting their mail. For transactional mail, this is a strong majority= forwarding (as in I send mail to a@b.com and it delivers to a@c.com), and = it's dominated by educational institutions forwarding to their students/alu= mni, followed by hosting services and ISPs. The reasons for the forwarding = breaking the signatures clearly vary; there are popular mail systems that, = for instance, re-mime-encode bodies, or add signature files of various sort= s, ranging from notifications that the message has been virus scanned to ad= s for the ISP forwarding the mail. Re-encoding things can result in intermi= ttent breakage, where some forwarding works (because the forwarder doesn't = feel the need to fix it) and other messages don't. A minority is not straig= htforward, my old address routes to my new one, forwarding, but are service= s that are specialized to handling mail -- third party spam filtering or ma= il classification products that then redeliver mail. They don't make up a b= ig percentage of the cases but they are notable as cases that presumably wo= uld be able to change their handling if we provided them with options.

Then we get to end-user domains. Although I've heard fro= m corporate domains where DMARC breakage is actually lower for the humans t= han the transactional mail, for the big mailbox holders, as far as I can te= ll, the expected ratios hold; more mail fails for end-users than for transa= ctional mail. How much more? That gets interesting.

= For the domains at p=3Dreject, the mail that arrives with an aligned DKIM s= ignature still on it, but not working -- which is the common case for both = forwarding and mailing lists -- is significantly under 1%. For the domains = at p=3Dnone, that comes closer to 2%. That difference is partly in mailing = lists, but, sadly, a noticeable amount of the difference between p=3Dreject= and p=3Dnone domains when it comes to the mailing list mail is spam from a= few, mostly commercial, mailing list providers. It is clear that a number = of valid, happy mailing lists you might like have chosen to move subscriber= s from p=3Dreject to p=3Dnone providers, with mixed success; the high volum= e ones I've checked still have p=3Dreject posters, at low rates. It is also= clear that a lot of educational institutions *both* run popular, DKIM-brea= king forwarders *and* run popular, DKIM-breaking mailing lists (and, unsurp= risingly, have alumni who go through both at once), which is one way that t= hese things rapidly become intractable for automated processing. 

For everybody, way more mail shows up with no aligned DK= IM signature on it than with a broken aligned DKIM signature on it, and no = noticeable amount of that mail had a DKIM signature stripped off. In fact, = for every domain I looked at, the single largest cause of DMARC fail is pur= ely forged mail, mostly spam. The rate of messages with no aligned DKIM sig= nature ranged from 88% (for a mailbox domain with p=3Dnone) to 2% (for a tr= ansactional domain with p=3Dreject). For transactional domains, that mail i= s not readily distinguishable from pure trash. There must be a DKIM-strippi= ng forward out there somewhere, but I haven't found it. For end-user domain= s, once you ignore forged spam, the major volume contributors are hosting s= ites, but again, the use-cases are mixed. The highest volume from hosting s= ites is spam. The next highest is email to site owners "From:" themselves. = There are a lot of people out there not getting mail from really frequent c= ron jobs. Then we get bulletin boards and blog software letting you know so= mebody has responded to your comment, and e-commerce solutions letting you = know that somebody wants to order something -- all of that shows up in one = big jumble from the hosting providers. 

=
Next we= get "parental control" software and other monitoring uses that send From: = and To: the same address and are verbose. And large service providers for s= mall businesses.

After that, it's the land of a mi= llion different indirect uses. More e-commerce sites. The people who send y= ou happy birthday messages from your dentist, who uses a third-party accoun= t. Or your tee-time from your golf course, ditto. Or your tanning bed sched= ule, because there's a service out there that does nothing but email handli= ng for tanning salons. Printers. Security equipment. A surprising number of= government agencies, including one national nuclear agency sending mail to= : and from: the same person when replying to document requests or using a f= ree email account to do government business. Services for multi-level marke= ting plans and other sell-to-your-friends plans. Oh, so many services for r= ealtors. Lots of mail-to-friend features. Some of which (the ones with the = most volume) are being abused for spam.

    Elizabeth
    zwicky@yahoo-inc.com

------=_Part_282178_297613422.1415647556916-- From nobody Mon Nov 10 13:56:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988191A1B11 for ; Mon, 10 Nov 2014 13:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nO0Nf7DRFWa for ; Mon, 10 Nov 2014 13:56:33 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85D01A1B17 for ; Mon, 10 Nov 2014 13:56:32 -0800 (PST) Received: from kitterman-optiplex-9020m.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E5598C403F7 for ; Mon, 10 Nov 2014 15:56:31 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1415656591; bh=FSvp2EWmf8HRzf7F/UxoL9LqevKCUFLR8Z7bgdJIR88=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hS7msL/hw49rjSGIde53iFJH/ToViV++zQ3w8Al9ZtwVvWyEZpLK2tBBct10RmDyI EmpB87bfO+gmKTFTRFqBdQKcEUUr88vqn3/lvc7wIv7OH+j1Tdv/hh9fcgdk5cW5zZ ucpYCHnmeLOaGfCb72uq33UvB70qD3YS4lwDQr5A= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 10 Nov 2014 16:57:05 -0500 Message-ID: <1615251.R5XluhHgcf@kitterman-optiplex-9020m> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/aoYx5I9A5S4vYPQdUEq-IPMk17w Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 21:56:36 -0000 On Monday, November 10, 2014 07:25:56 PM Elizabeth Zwicky wrote: > OK, so I've dived into Yahoo's incoming metadata to look at what fails DMARC > and why. Conclusion 1: I cannot automatically tell the cases apart with any > accuracy. Hand coding them is so time-consuming as to be beyond my ability > to do at scale. So, not many numbers, but I have developed some very > educated opinions, which unfortunately take a small novel to explain. > First, transactional domains tend to have some mail that fails DMARC > because of forwarding. The highest estimate of that I've seen is about 1.5% > (that's not data I ran); on the domains I've looked at so far I saw rates > well below 0.1%. Still, that's people not getting their mail. For > transactional mail, this is a strong majority forwarding (as in I send mail > to a@b.com and it delivers to a@c.com), and it's dominated by educational > institutions forwarding to their students/alumni, followed by hosting > services and ISPs. The reasons for the forwarding breaking the signatures > clearly vary; there are popular mail systems that, for instance, > re-mime-encode bodies, or add signature files of various sorts, ranging > from notifications that the message has been virus scanned to ads for the > ISP forwarding the mail. Re-encoding things can result in intermittent > breakage, where some forwarding works (because the forwarder doesn't feel > the need to fix it) and other messages don't. A minority is not > straightforward, my old address routes to my new one, forwarding, but are > services that are specialized to handling mail -- third party spam > filtering or mail classification products that then redeliver mail. They > don't make up a big percentage of the cases but they are notable as cases > that presumably would be able to change their handling if we provided them > with options. Then we get to end-user domains. Although I've heard from > corporate domains where DMARC breakage is actually lower for the humans > than the transactional mail, for the big mailbox holders, as far as I can > tell, the expected ratios hold; more mail fails for end-users than for > transactional mail. How much more? That gets interesting. For the domains > at p=reject, the mail that arrives with an aligned DKIM signature still on > it, but not working -- which is the common case for both forwarding and > mailing lists -- is significantly under 1%. For the domains at p=none, that > comes closer to 2%. That difference is partly in mailing lists, but, sadly, > a noticeable amount of the difference between p=reject and p=none domains > when it comes to the mailing list mail is spam from a few, mostly > commercial, mailing list providers. It is clear that a number of valid, > happy mailing lists you might like have chosen to move subscribers from > p=reject to p=none providers, with mixed success; the high volume ones I've > checked still have p=reject posters, at low rates. It is also clear that a > lot of educational institutions *both* run popular, DKIM-breaking > forwarders *and* run popular, DKIM-breaking mailing lists (and, > unsurprisingly, have alumni who go through both at once), which is one way > that these things rapidly become intractable for automated processing. For > everybody, way more mail shows up with no aligned DKIM signature on it than > with a broken aligned DKIM signature on it, and no noticeable amount of > that mail had a DKIM signature stripped off. In fact, for every domain I > looked at, the single largest cause of DMARC fail is purely forged mail, > mostly spam. The rate of messages with no aligned DKIM signature ranged > from 88% (for a mailbox domain with p=none) to 2% (for a transactional > domain with p=reject). For transactional domains, that mail is not readily > distinguishable from pure trash. There must be a DKIM-stripping forward out > there somewhere, but I haven't found it. For end-user domains, once you > ignore forged spam, the major volume contributors are hosting sites, but > again, the use-cases are mixed. The highest volume from hosting sites is > spam. The next highest is email to site owners "From:" themselves. There > are a lot of people out there not getting mail from really frequent cron > jobs. Then we get bulletin boards and blog software letting you know > somebody has responded to your comment, and e-commerce solutions letting > you know that somebody wants to order something -- all of that shows up in > one big jumble from the hosting providers. Next we get "parental control" > software and other monitoring uses that send From: and To: the same address > and are verbose. And large service providers for small businesses. After > that, it's the land of a million different indirect uses. More e-commerce > sites. The people who send you happy birthday messages from your dentist, > who uses a third-party account. Or your tee-time from your golf course, > ditto. Or your tanning bed schedule, because there's a service out there > that does nothing but email handling for tanning salons. Printers. Security > equipment. A surprising number of government agencies, including one > national nuclear agency sending mail to: and from: the same person when > replying to document requests or using a free email account to do > government business. Services for multi-level marketing plans and other > sell-to-your-friends plans. Oh, so many services for realtors. Lots of > mail-to-friend features. Some of which (the ones with the most volume) are > being abused for spam. Elizabeth > zwicky@yahoo-inc.com Thanks for the insights. For my one tiny domain (that gets used in email), I'm doing p=none because the legitimate mail is 1% DMARC pass and 99% DMARC fail[1] because of mailing lists and various web based systems I use (mostly bug trackers for free software projects). Scott K [1] This is, of course, not the ratio of messages I send. Mailing list fails get counted once per subscriber and at the big mailbox provider that can be a lot. From nobody Mon Nov 10 15:50:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19761AD0C8 for ; Mon, 10 Nov 2014 15:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJERmsgLZGqK for ; Mon, 10 Nov 2014 15:50:06 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452811AD0BF for ; Mon, 10 Nov 2014 15:50:06 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so50323iga.2 for ; Mon, 10 Nov 2014 15:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4wPtuf1LSo0fUfQLKHs2eFbcDa4VfrcHP98ew6/iryk=; b=g3EyzkJJIW5vi6CiW3QsM57GCzom8eXl5clF7HhboVuDieG8GBa/sc+Br3L9Ceh+BP M16re9bqXIEusyle3bqNZzR/uDdj8CZckxqfV/zN7TDBm4EWxennkhChZuEEaWNYI8U9 X0fEFfWsnEnOgyFK1Fps5XEe94U/VaQ63UzdoWTfwYGcw8keu+itlApNJ7R+BCCZt8c1 zPUXzhdVnLbKFcWGabPI+iEqHtbMv9mVx/PkImGGJPcf0fZRJPDPfJEs8m/8iTUOUku/ gUhxuWTvEG2eowPnJn67il0juulFiC16Dwf3Hf1xJVn/Thx0Pxbv+K2mrNRdA3J1aVFR PQkw== 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:date :message-id:subject:from:to:cc:content-type; bh=4wPtuf1LSo0fUfQLKHs2eFbcDa4VfrcHP98ew6/iryk=; b=io4BQ7b5/CMF9myqfMIXNR/swV15+3jlS+oH8qb+CRheqFUfTAnfhJZh/oLeULtEn8 CE/mDfDGO4BZ9VKUker+0tl4u6tqMsSTsJULezRHxOHFOZbMV7eKhaFEcRu5I1yLFIm1 08xrO6Q9BQNr5kue5xMqgIC7vKbbIlkTbASGNmTQvKBzBqOg27krZFAN/63U6KNhaXbl qYhAdB4RxmeB61V2MzisdzQ/0cqVMWCJuQ9b/46W0TQ7QHfrWw8pK9pZji3ol+H9W5Kp 8u1Jmmm0SJ+EUn4ILogqTcFZKZJ0PRWeQjF/cy4MCQ1qOJqrEGtFZnjO3AtxTNYPVEPM GTSg== X-Gm-Message-State: ALoCoQmYlNNia2xvKt0N4ipex1P6k8T7fEDrfCXnJJ1KqB/vkVNdHs5OU+nqLLgeGnmG+QDfIsc8 MIME-Version: 1.0 X-Received: by 10.42.110.195 with SMTP id r3mr38783024icp.12.1415663404389; Mon, 10 Nov 2014 15:50:04 -0800 (PST) Received: by 10.64.1.165 with HTTP; Mon, 10 Nov 2014 15:50:04 -0800 (PST) In-Reply-To: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> Date: Mon, 10 Nov 2014 15:50:04 -0800 Message-ID: From: Brandon Long To: Brett McDowell Content-Type: multipart/alternative; boundary=20cf303dda42575275050789d2b2 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LfMz7z0CsROI23yVQUAZW3yZ2Oo Cc: "J. Trent Adams" , "dmarc@ietf.org" , "Murray S. Kucherawy" , "Stephen J. Turnbull" , "ned+dmarc@mrochek.com" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 23:50:10 -0000 --20cf303dda42575275050789d2b2 Content-Type: text/plain; charset=UTF-8 I don't think his changes in 5.6.1 would change anything we do. We currently require a single From header with a single address with a valid domain on all messages (not restricted to DMARC). RFC 6854 as used for EAI downgrades shouldn't apply since we support SMTPUTF8... though, if it became popular enough that we saw a large amount of mail forwarding in that format, we would adjust. I would think that how shipped software handles such things would be more likely to have issues, as its less likely to be upgraded. That said, from my understanding, this is a loosening of restrictions, from "only one" to "may allow more than one", so that doesn't seem particularly problematic. Would we support multiple addresses? Probably not. We've had the current restrictions for 2+ years, and before that had less strict but similar restrictions. I haven't seen any complaints to date about this restriction, but it does apply to a non-trivial amount of mail. Brandon On Sat, Nov 8, 2014 at 12:20 PM, Brett McDowell wrote: > I support making no change in dmarc-base-05 that might change how current > mailbox providers implement dmarc-base. But to the extent this collection > of contributors would like to see the recommendations/requirements in > section 5.6.1 updated to better harmonize with related RFC's, I support > Trent's proposal as it seems to introduce the least amount of increased > risk to fraud. > > That said, we do have people here familiar with large-scale mailbox > provider deployments (Google, Yahoo!, Hotmail, etc.). I'd like to ask them > if they expect Trent's changes to have any impact on how they implement > dmarc-base today. If it will, I think we should consider these changes for > a future version of dmarc-base and let this version go through with these > requirements unchanged. As you all know, there are now years of experience > deploying dmarc-base with these requirements as written. Those deployments > have had tremendous success protecting users from domain-spoofing the > RFC5322.From field. > > The importance of the current dmarc-base specification's efficacy at > blocking domain-spoofed phishing attacks should not be underestimated. I > advise extreme caution when considering any normative changes at the 11th > hour. > > Dear high volume MBP's, will any of these changes in Trent's proposal > alter how you implement dmarc-base today? > > -Brett > > On Sat, Nov 8, 2014 at 2:26 AM, Murray S. Kucherawy > wrote: > >> On Fri, Nov 7, 2014 at 8:57 PM, wrote: >> >>> Trent Adams writes: >>> >>> > ----- >>> > It is important to note that identifier alignment cannot occur, and >>> > DMARC determination applied, with a message that is not valid per RFC >>> > 5322 [MAIL]. This is particularly true when a message has a malformed >>> > or absent RFC5322.From field. >>> > ----- >>> >>> I occasionally see non-ASCII octets introduced by spam/virus checkers in >>> X-Spam-* fields in the header or in the (non-8-bit) message body, due to >>> copying message content into those contexts. The From field is perfectly >>> valid, however. Does that really mean that identifier alignment cannot >>> occur? >>> >>> (I think that is a plausible policy choice, since in an invalid message >>> "anything can happen". But I don't see that it's a no-brainer.) >>> >> >> Do you have another suggestion? >> >> Note that there's nothing normative in Trent's suggestion. If a receiver >> thinks it can continue with the X-Spam-* fields malformed as described, >> then it can continue on that basis. >> >> >>> > Starting off, we can ignore a address in the RFC5322.From field >>> > as DMARC will have no bearing in that case. Similarly, when there is >>> > exactly one address in the RFC5322.From field, application of DMARC is >>> > reasonably straight forward. >>> >>> By "DMARC", you really mean "DMARC policy", right? DMARC the protocol >>> does need to say something about what happens if alignment fails or no >>> policy can be discovered. >>> >> >> That's how I understood what he said. >> >> >>> > That leaves taking some action based on the DMARC policies associated >>> > with the set of domains represented in the RFC5322.From field. It >>> seems >>> > that the most reasonable approach is to gather the DMARC policies for >>> > all addresses, and then apply the most strict. >>> >>> I wouldn't call that "reasonable". It's the only plausible option, but >>> here's the problematic use case: >>> >>> Co-Chairs Trent and Stephen decide to hold a meeting of The Committee. >>> For organizational political reasons it is necessary that (a) both names >>> appear on the memo and (b) Stephen has to do the dirty work. Stephen >>> sends the mail "From: trent@example.com, stephen@example.org", with >>> proper >>> SPF and DKIM setups. Unfortunately, example.com publishes p=reject, >>> example.com alignment fails because Stephen sent the message, the MTAs >>> reject the message, and nobody except Trent and Stephen shows up to the >>> meeting. I see two ways this message could pass DMARC: Stephen has the >>> keys for example.com, or the Japanese "ringi" system, where I write and >>> sign the message, send it to Trent, who then signs the message but >>> otherwise forwards it verbatim. Both seem fragile to me. >> >> >>> OTOH, only checking policies of aligned SPF source domains and DKIM >>> signers means that Stephen (or any scammer) can add " >>> POTUS@whitehouse.gov" >>> to the From field and pass DMARC. It's obvious what the Felons of April >>> would do with that. >>> >> >>> I guess the most plausible approach to this issue is to say that if you >>> want to use DMARC and have multiple authors, you must contrive to give >>> all >>> the authors mailboxes in the same domain. In the example, I could create >>> the-committee.example.org for committee members, or give trent a >>> forwarding mailbox at example.org itself. >>> >> >> Ned, do you concur with this analysis? Is Trent's proposal coupled with >> this caveat a valid remedy for your point? >> >> >>> > Given all that, here's my suggested revision to Section 5.6.1.: >>> > >>> > ----- >>> > 5.6.1. Extract Author Domain >>> > >>> > In order to be processed by DMARC, the domain(s) must be extracted from >>> > the domain of the email address(es) within the addr-spec portion of the >>> > RFC5322.From field. If the domain is encoded with UTF-8, the domain >>> name >>> > must be converted to an A-label for further processing. If no domain is >>> > found, the message SHOULD be rejected (as it is forbidden under RFC >>> 5322 >>> >>> I still don't think a null From filed is any business of DMARC the >>> protocol. That's really an issue for (a) the security considerations >>> section or (b) the planned BCP. >>> >> >> I think we're all in agreement on that point so far. >> >> >>> > [MAIL]). If more than one domain identifier is found, the full set of >>> > domains MAY be collected as a set of identifiers for DMARC processing. >>> >>> But this seems to be the insecure approach I describe above: >>> >>> > 5. Conduct identifier alignment checks. With authentication checks >>> > and policy discovery performed, the Mail Receiver checks if >>> > Authenticated Identifiers fall into alignment as described in >>> > Section 3. If one or more of the Authenticated Identifiers >>> align >>> > with an identifier extracted from the addr-spec of the >>> > RFC5322.From domain, the message is considered to pass the >>> > DMARC mechanism check. >>> >>> AFAICS this allows me (using a throwaway mailbox at a throwaway domain) >>> to >>> send spam that passes DMARC on your behalf, as long as my mailbox appears >>> in From, too. Am I misunderstanding your proposed algorithm? >>> >> >> No, because in (6) the strictest rule applies. Your throwaway domain >> might pass, but the other advertised author's would not. >> >> >>> > All other conditions (authentication >>> > failures, identifier mismatches) are considered to be DMARC >>> > mechanism check failures. >>> >>> Bottom line, I think both messages where no Authenticated Identifiers can >>> be extracted and those where multiple Authenticated Identifiers can be >>> extracted should be defined to be mechanism check failures. In the >>> former >>> case, policy discovery is impossible, in the latter, the strictest policy >>> should be applied. >>> >> >> Right, I think that's what Trent is also saying. >> >> And everyone seems to agree on just dropping STARTTLS as well. >> >> -MSK >> >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >> >> > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --20cf303dda42575275050789d2b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think his changes in 5.6.1 would change anythi= ng we do.=C2=A0 We currently require a single From header with a single add= ress with a valid domain on all messages (not restricted to DMARC).=C2=A0 R= FC 6854 as used for EAI downgrades shouldn't apply since we support SMT= PUTF8... though, if it became popular enough that we saw a large amount of = mail forwarding in that format, we would adjust.

I would= think that how shipped software handles such things would be more likely t= o have issues, as its less likely to be upgraded.

Th= at said, from my understanding, this is a loosening of restrictions, from &= quot;only one" to "may allow more than one", so that doesn&#= 39;t seem particularly problematic.

Would we suppo= rt multiple addresses?=C2=A0 Probably not.=C2=A0 We've had the current = restrictions for 2+ years, and before that had less strict but similar rest= rictions.=C2=A0 I haven't seen any complaints to date about this restri= ction, but it does apply to a non-trivial amount of mail.

Brandon

On Sat, Nov 8, 2014 at 12:20 PM, Brett McDowell = <brettmcdow= ell@gmail.com> wrote:
I = support making no change in dmarc-base-05 that might change how current mai= lbox providers implement dmarc-base.=C2=A0 But to the extent this collectio= n of contributors would like to see the recommendations/requirements in sec= tion 5.6.1 updated to better harmonize with related RFC's, I support Tr= ent's proposal as it seems to introduce the least amount of increased r= isk to fraud.

That said, we do have people here familiar= with large-scale mailbox provider deployments (Google, Yahoo!, Hotmail, et= c.).=C2=A0 I'd like to ask them if they expect Trent's changes to h= ave any impact on how they implement dmarc-base today.=C2=A0 If it will, I = think we should consider these changes for a future version of dmarc-base a= nd let this version go through with these requirements unchanged.=C2=A0 As = you all know, there are now years of experience deploying dmarc-base with t= hese requirements as written.=C2=A0 Those deployments have had tremendous s= uccess protecting users from domain-spoofing the RFC5322.From field. =C2=A0=

The importance of the current dmarc-base specific= ation's efficacy at blocking domain-spoofed phishing attacks should not= be underestimated.=C2=A0 I advise extreme caution when considering any nor= mative changes at the 11th hour.

Dear high volume = MBP's, will any of these changes in Trent's proposal alter how you = implement dmarc-base today?
<= div>
-Brett

On Sat, Nov 8= , 2014 at 2:26 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Fri, Nov 7, 2014 at 8:57 PM, <turnbull@sk.tsuku= ba.ac.jp> wrote:
Trent Adams writes:

> -----
> It is important to note that identifier alignment cannot occur, and > DMARC determination applied, with a message that is not valid per RFC<= br> > 5322 [MAIL].=C2=A0 This is particularly true when a message has a malf= ormed
> or absent RFC5322.From field.
> -----

I occasionally see non-ASCII octets introduced by spam/virus checker= s in
X-Spam-* fields in the header or in the (non-8-bit) message body, due to copying message content into those contexts.=C2=A0 The From field is perfec= tly
valid, however.=C2=A0 Does that really mean that identifier alignment canno= t
occur?

(I think that is a plausible policy choice, since in an invalid message
"anything can happen".=C2=A0 But I don't see that it's a = no-brainer.)

Do you have another= suggestion?

Note that there's nothing normative in T= rent's suggestion.=C2=A0 If a receiver thinks it can continue with the = X-Spam-* fields malformed as described, then it can continue on that basis.=
=C2=A0
> Starting off, we can ignore a <null> address in the RFC532= 2.From field
> as DMARC will have no bearing in that case.=C2=A0 Similarly, when ther= e is
> exactly one address in the RFC5322.From field, application of DMARC is=
> reasonably straight forward.

By "DMARC", you really mean "DMARC policy", righ= t?=C2=A0 DMARC the protocol
does need to say something about what happens if alignment fails or no
policy can be discovered.

That&#= 39;s how I understood what he said.
=C2=A0
> That leaves taking some action based on the DMARC policies assoc= iated
> with the set of domains represented in the RFC5322.From field.=C2=A0 I= t seems
> that the most reasonable approach is to gather the DMARC policies for<= br> > all addresses, and then apply the most strict.

I wouldn't call that "reasonable".=C2=A0 It's the = only plausible option, but
here's the problematic use case:

Co-Chairs Trent and Stephen decide to hold a meeting of The Committee.
For organizational political reasons it is necessary that (a) both names appear on the memo and (b) Stephen has to do the dirty work.=C2=A0 Stephen<= br> sends the mail "From: trent@example.com, stephen@example.org", with proper
SPF and DKIM setups.=C2=A0 Unfortunately, example.com publishes p=3Dreject,
example.com alignment = fails because Stephen sent the message, the MTAs
reject the message, and nobody except Trent and Stephen shows up to the
meeting.=C2=A0 I see two ways this message could pass DMARC: Stephen has th= e
keys for example.com, = or the Japanese "ringi" system, where I write and
sign the message, send it to Trent, who then signs the message but
otherwise forwards it verbatim.=C2=A0 Both seem fragile to me.=C2=A0

OTOH, only checking policies of aligned SPF source domains and DKIM
signers means that Stephen (or any scammer) can add "POTUS@whitehouse.gov"
to the From field and pass DMARC.=C2=A0 It's obvious what the Felons of= April
would do with that.

I guess the most plausible approach to this issue is to say that if you
want to use DMARC and have multiple authors, you must contrive to give all<= br> the authors mailboxes in the same domain.=C2=A0 In the example, I could cre= ate
the-committe= e.example.org for committee members, or give trent a
forwarding mailbox at exam= ple.org itself.

Ned, do= you concur with this analysis?=C2=A0 Is Trent's proposal coupled with = this caveat a valid remedy for your point?
=C2=A0
> Given all that, here's my suggested revision to Section 5.6.1.:
>
> -----
> 5.6.1.=C2=A0 Extract Author Domain
>
> In order to be processed by DMARC, the domain(s) must be extracted fro= m
> the domain of the email address(es) within the addr-spec portion of th= e
> RFC5322.From field. If the domain is encoded with UTF-8, the domain na= me
> must be converted to an A-label for further processing. If no domain i= s
> found, the message SHOULD be rejected (as it is forbidden under RFC 53= 22

I still don't think a null From filed is any business of DMARC t= he
protocol.=C2=A0 That's really an issue for (a) the security considerati= ons
section or (b) the planned BCP.

= I think we're all in agreement on that point so far.
=C2=A0
> [MAIL]).=C2=A0 If more than one domain identifier is found, the = full set of
> domains MAY be collected as a set of identifiers for DMARC processing.=

But this seems to be the insecure approach I describe above:

>=C2=A0 =C2=A0 5.=C2=A0 Conduct identifier alignment checks.=C2=A0 With = authentication checks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and policy discovery performed, the Mail Re= ceiver checks if
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authenticated Identifiers fall into alignme= nt as described in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 3.=C2=A0 If one or more of the Auth= enticated Identifiers align
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 with an identifier extracted from the addr-= spec of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC5322.From domain, the message is conside= red to pass the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 DMARC mechanism check.

AFAICS this allows me (using a throwaway mailbox at a throwaway doma= in) to
send spam that passes DMARC on your behalf, as long as my mailbox appears in From, too.=C2=A0 Am I misunderstanding your proposed algorithm?

No, because in (6) the strictest rule ap= plies.=C2=A0 Your throwaway domain might pass, but the other advertised aut= hor's would not.
=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 All other conditions (authentication<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 failures, identifier mismatches) are consid= ered to be DMARC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanism check failures.

Bottom line, I think both messages where no Authenticated Identifier= s can
be extracted and those where multiple Authenticated Identifiers can be
extracted should be defined to be mechanism check failures.=C2=A0 In the fo= rmer
case, policy discovery is impossible, in the latter, the strictest policy should be applied.

Right, I thin= k that's what Trent is also saying.

And everyone seem= s to agree on just dropping STARTTLS as well.=

-MSK

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



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


--20cf303dda42575275050789d2b2-- From nobody Mon Nov 10 17:52:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3101F1AD3D1 for ; Mon, 10 Nov 2014 17:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iN3Jehz2Pq-B for ; Mon, 10 Nov 2014 17:52:36 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D761AD3DF for ; Mon, 10 Nov 2014 17:52:35 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id n3so210773wiv.14 for ; Mon, 10 Nov 2014 17:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=5ug0ppLz794G2HFyK6eiLVgh1PfZXSSP2llEnY1X0wI=; b=0GOT4JAU6mitE+SZedTTmrQMfB8eeitFWd4a3ioBZ++/QgB8tWJ0KrIDg6l4UlfQXN ASyvG1G3Ton6iNZy02Nr25Qkbs9gDQwca53zOc20PQyCZcnHVR2KXNF9PKP70TIqc+Pn 2ZpNY8BE8armFXUUI4QT/LPDI2oK16yl5prGuF7o0l98RRayHLk4iH82jFIs9gYzDe6Y KvZrsfbw/revkZQsJvOzFjonvRXt5i5ZGWL2oHLW/+ULq9iD3JcKQH5VgUoTxL4O8URa UcRhVWnuXIUeQYuCyhY9dbKlT1FjvXs1YrU6NUINDBCvEuRUDD7RTcGa0Ddxg9ggOlq2 eFfw== MIME-Version: 1.0 X-Received: by 10.194.3.2 with SMTP id 2mr48959900wjy.89.1415670754470; Mon, 10 Nov 2014 17:52:34 -0800 (PST) Received: by 10.27.76.134 with HTTP; Mon, 10 Nov 2014 17:52:34 -0800 (PST) Date: Mon, 10 Nov 2014 15:52:34 -1000 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7b343c1870760a05078b880f Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HOgWKiW3Wp1CETGLBxPov-5jvGk Subject: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 01:52:38 -0000 --047d7b343c1870760a05078b880f Content-Type: text/plain; charset=UTF-8 I've posted an update to the base draft, based on recent feedback from Ned and others. Hopefully I've resolved all of the concerns (especially the major ones), as the ISE would like to send the draft to the IESG for conflict review in the next day or two. It also has to begin formal review of its IANA Considerations section as soon as possible. Thanks to all who provided recent comments to lead us to this version. -MSK --047d7b343c1870760a05078b880f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've posted an update to the base draft, based on= recent feedback from Ned and others.=C2=A0 Hopefully I've resolved all= of the concerns (especially the major ones), as the ISE would like to send= the draft to the IESG for conflict review in the next day or two.=C2=A0 It= also has to begin formal review of its IANA Considerations section as soon= as possible.

Thanks to all who provided recent comments to lead us = to this version.

-MSK
--047d7b343c1870760a05078b880f-- From nobody Mon Nov 10 23:33:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC491A8843 for ; Mon, 10 Nov 2014 23:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADK-7lth9jZj for ; Mon, 10 Nov 2014 23:33:25 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 82E041ACE5A for ; Mon, 10 Nov 2014 23:33:25 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id B37F01C395D; Tue, 11 Nov 2014 16:33:23 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9B69E1A2844; Tue, 11 Nov 2014 16:33:23 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <1514357710.20452.1415647403101.JavaMail.zimbra@peachymango.org> References: <720075258.3227.1415567701474.JavaMail.zimbra@peachymango.org> <87bnofxve7.fsf@uwakimon.sk.tsukuba.ac.jp> <87a93yyiz0.fsf@uwakimon.sk.tsukuba.ac.jp> <1514357710.20452.1415647403101.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 11 Nov 2014 16:33:23 +0900 Message-ID: <8761emxkcc.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/S9jQWr7sTl_iZvroEC8rhtw7xKM Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Nov 2014 07:33:27 -0000 Franck Martin writes: > So I'm curious to see some real world examples. If you could add > them in the wiki may be? (a) Of the ones I have ready access to, there are privacy concerns with the email itself in many cases, and employer issues with all of them (Japanese institutions don't like to admit they even *might* have any problems in public). (b) They're in Japanese. So, no, not from my archives there won't be. I'll post the description of the use case and an example, though. I can tell you that in my "truly useful" case all addresses are "work addresses", and therefore all have the same domain and *could* satisfy the DMARC mechanism in the sense that the authenticated domain would be aligned with all addresses in From, like this: DKIM-Signature: ..., d=xemacs.org, ... From: "Stephen J. Turnbull" , "Another Steve" I wouldn't be surprised if that handles the majority of such cases. I have sent mail "frivolously" with multiple domains in From, like this: DKIM-Signature: ..., d=xemacs.org, ... From: "Stephen J. Turnbull" , "My Co-Presenter" Subject: Come see our presentation at Tokyo Linux Users Group but I don't seem to have a copy of that immediately available. Steve From nobody Tue Nov 11 09:20:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0C91A00B6 for ; Tue, 11 Nov 2014 09:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogMGaJY2UjbU for ; Tue, 11 Nov 2014 09:20:23 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F351A0118 for ; Tue, 11 Nov 2014 09:20:23 -0800 (PST) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id sABHKH1v017324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Nov 2014 09:20:20 -0800 Message-ID: <5462454C.1000000@dcrocker.net> Date: Tue, 11 Nov 2014 09:20:12 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "dmarc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 11 Nov 2014 09:20:20 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/S9d9BHeeYMNeZtiBbXy6eDkzyps Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 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, 11 Nov 2014 17:20:26 -0000 On 11/10/2014 5:52 PM, Murray S. Kucherawy wrote: > I've posted an update to the base draft, based on recent feedback from > Ned and others. Tidbits... Intro: > Security terms used in this document are defined in [SEC-TERMS]. There's a Terminology section, so this really belongs there. 2.2: > attacks in the RFC5322.From field, also known as "display-name" > attacks; attacks on using the free-form portion of the RFC5322.From field, also known as "display-name" attacks, after its ABNF rulename; 3.13: The Flow Diagram inneeds to have the DKIM and SPF boxes /also/ connected directly to the Filtering Engine, since they still provide information directly to it. I suggest either: +---------------+ | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . . +---------------+ . . . | . . . V V V . +-----------+ +--------+ +----------+ +----------+ . | MSA |<****| DKIM | | DKIM | | SPF | . | Service | | Signer | | Verifier | | Verifier | . +-----------+ +--------+ +----------+ +----------+ . | * * . | * . * . V ************** . * . +------+ (~~~~~~~~~~~~) +------+ * . | oMTA |------->( other MTAs )---->| rMTA | * . +------+ (~~~~~~~~~~~~) +------+ * . | * ....... | ************** . V V * . +-----------+ V V +---------+ | MDA | +----------+ | User |<--| Filtering |<***>| DMARC | | Mailbox | | Engine | | Verifier | +---------+ +-----------+ +----------+ or +---------------+ | Author Domain |. . . . . . . . . . . . . . . . . . . . . . . +---------------+ . . . | . . . V V V . +------------+ +--------+ +----------+ +----------+ . | MSA |<****| DKIM | | DKIM | | SPF | . | Service | | Signer | | Verifier | | Verifier | . +------------+ +--------+ +----------+ +----------+ . | * * V | * * +----------+ | *************>| DMARC | | * | Verifier | | * +----------+ | * * | * ******** | * * | V V V +-----------+ +------+ (~~~~~~~~~~~~) +------+ | MDA | | sMTA |--->( other MTAs )--->| rMTA |--->| Filtering | +------+ (~~~~~~~~~~~~) +------+ | Engine | +-----------+ +---------+ | | User |<-------+ | Mailbox | +---------+ Since Murray saw a variant of the latter from me earlier, he won't be surprised that I prefer it... 5. Policy: > A Domain Owner may choose not to participate in DMARC evaluation by may -> can (I'm assume that we don't use normative language to tell people that the have the right to opt out of a specification... Hmmm. Normative language would actually be contradictory, I think...) > Mail Receivers. In this case, the Domain Owner simply declines to > advertise participation in those schemes. For example, if the > results of path authorization checks ought not be considered as part > of the overall DMARC result for a given Author Domain, then the > Domain Owner does not publish an SPF policy record that can produce > an SPF pass result. The way to opt out of DMARC is to not publish a DMARC record. So "those schemes" doesn't make sense to me, nor does the reference to an SPF record. I think this should say: Mail Receivers. In this case, the Domain Owner simply declines to advertise participation. That is, the Domain Owner does not publish a DMARC record in the DNS. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Nov 12 11:38:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967CE1ACFD8 for ; Wed, 12 Nov 2014 11:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgCaVT5ZVFjC for ; Wed, 12 Nov 2014 11:38:53 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E756F1ACFC0 for ; Wed, 12 Nov 2014 11:38:52 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so15288710wgg.5 for ; Wed, 12 Nov 2014 11:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aor7yOfPz4qLsAT4Z7O6RuK2o1Mm/It3mbZ3OspjOTs=; b=AD3GWo1rJMJFa2X4WbZhSoXNtsy5D/Iuuil/mh6Ii6ns6ww91m8E9ac1gSsznJcQPK 3Ebb18s27zbx69FTa/EZVC6vwJvFe+/OSeqtFOCdMHzRyAACMzZ34fb0jVkY3GKwKlOl b2O9a7zWtpCIRFRn4FyRrzdkkcX2uWoVwPqZcsEFX75IvErn6ako9v6bR6XywYEZHBO2 R5J8bjKNDlswcR8ZC1IsQfY6rctV8ttkexaW3jcjkHu8ymkxW7AD4MhnTxMY1X8103yd bmzk7DJZlGRVRkNe2iS5DHjIIWWfCLZvVx44CfKb+8U+HfnB4CQ0E6jpDadEWvXURL7g 6EvQ== 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:content-type; bh=aor7yOfPz4qLsAT4Z7O6RuK2o1Mm/It3mbZ3OspjOTs=; b=a785iWFXqpM2oSGx1NXd0weICwtY6A2sXn0I/SYvfl/VMgPM0a6EkmpYImB+YITW7i 5LuVBMctJJxVihP31gsM0pC6kbqLSvHgzU4+JiahFefe4aOP1M103Nt+IMFtA7Ycvtwy VUfBhZKN6oGhFYPkL32duHKaLtahP8AEAZNNyoBCLGQ2Ig50gg87zTcsHELKYwjo3/EN fDUr1caALUXToGfSJyY75Gkf6WBChYWfVdsjAncbd/+OtOJSokkAJTbwKOmYe8zeWrlF LlZtWxV1lxXtYJYVSYf29Oj6yI0S+8HCWozR4dl2jgEhlJBVJAvmL/6hwU4sZf8z5FzS iohg== X-Received: by 10.180.74.201 with SMTP id w9mr52206713wiv.17.1415821131724; Wed, 12 Nov 2014 11:38:51 -0800 (PST) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com. [209.85.212.178]) by mx.google.com with ESMTPSA id wl1sm32648797wjb.4.2014.11.12.11.38.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 11:38:50 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bs8so5994392wib.11 for ; Wed, 12 Nov 2014 11:38:49 -0800 (PST) X-Gm-Message-State: ALoCoQmBKeNAzfIUHlmqKmj4D9KmBuYadOL9V3dr3baiNugvrCK4ktmGfbJLyCvin/Z229tjOLPv X-Received: by 10.194.77.4 with SMTP id o4mr67440848wjw.41.1415821129795; Wed, 12 Nov 2014 11:38:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.158.7 with HTTP; Wed, 12 Nov 2014 11:38:09 -0800 (PST) In-Reply-To: References: <87d292z9k3.fsf@uwakimon.sk.tsukuba.ac.jp> <01PEMWEN5Q8W003WE3@mauve.mrochek.com> <49460.113.148.46.181.1415422638.risu@infoshako.sk.tsukuba.ac.jp> From: Brett McDowell Date: Wed, 12 Nov 2014 14:38:09 -0500 Message-ID: To: Brandon Long Content-Type: multipart/alternative; boundary=047d7bfceec081e0d70507ae8bb5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/JLkwAGSOQI_v6Fq7KHA2IqbwQVM Cc: "ned+dmarc@mrochek.com" , "J. Trent Adams" , Brett McDowell , "dmarc@ietf.org" , "Murray S. Kucherawy" , "Stephen J. Turnbull" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:38:54 -0000 --047d7bfceec081e0d70507ae8bb5 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 6:50 PM, Brandon Long wrote: > I don't think his changes in 5.6.1 would change anything we do. We > currently require a single From header with a single address with a valid > domain on all messages (not restricted to DMARC). RFC 6854 as used for EAI > downgrades shouldn't apply since we support SMTPUTF8... though, if it > became popular enough that we saw a large amount of mail forwarding in that > format, we would adjust. > > I would think that how shipped software handles such things would be more > likely to have issues, as its less likely to be upgraded. > > That said, from my understanding, this is a loosening of restrictions, > from "only one" to "may allow more than one", so that doesn't seem > particularly problematic. > > Would we support multiple addresses? Probably not. We've had the current > restrictions for 2+ years, and before that had less strict but similar > restrictions. I haven't seen any complaints to date about this > restriction, but it does apply to a non-trivial amount of mail. > Thank you Brandon for replying with your perspective on Trent's proposed changes to 5.6.1. --047d7bfceec081e0d70507ae8bb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 10, 2014 at 6:50 PM, Brandon Long <blong@google.com> wrote:
I don't t= hink his changes in 5.6.1 would change anything we do.=C2=A0 We currently r= equire a single From header with a single address with a valid domain on al= l messages (not restricted to DMARC).=C2=A0 RFC 6854 as used for EAI downgr= ades shouldn't apply since we support SMTPUTF8... though, if it became = popular enough that we saw a large amount of mail forwarding in that format= , we would adjust.

I would think that how shipped softwa= re handles such things would be more likely to have issues, as its less lik= ely to be upgraded.

That said, from my understanding= , this is a loosening of restrictions, from "only one" to "m= ay allow more than one", so that doesn't seem particularly problem= atic.

Would we support multiple addresses?=C2=A0 P= robably not.=C2=A0 We've had the current restrictions for 2+ years, and= before that had less strict but similar restrictions.=C2=A0 I haven't = seen any complaints to date about this restriction, but it does apply to a = non-trivial amount of mail.

Thank y= ou Brandon for replying with your perspective on Trent's proposed chang= es to 5.6.1.


--047d7bfceec081e0d70507ae8bb5-- From nobody Wed Nov 12 11:48:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4DE1A19E5 for ; Wed, 12 Nov 2014 11:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.9 X-Spam-Level: ** X-Spam-Status: No, score=2.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Hu4ghpDlEIq for ; Wed, 12 Nov 2014 11:48:43 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 988201A0A6B for ; Wed, 12 Nov 2014 11:48:42 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id d1so6009811wiv.15 for ; Wed, 12 Nov 2014 11:48:41 -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:content-type; bh=lWLsT/QDJiUQ54FBUC+kz5efQ7fbiMqZYDVrM4Dd2kc=; b=LXHEx4nxPMY4hE80ouRn1PKNYYmAXfXHfMKaCeJC6izWhZsC5CFRotuMRzfTsm9vhw c1kT8eAe5HyXXn8bwtqlBeIucnc5tntJW2Tirfbuq8uguVboeAdj3mqiqSwggNlBonKC I0JnbCs4nfo4wBKRvzQNw+4xXgemtkZhNgHhwbC5A6DrjWipXysF/qiaDZfLmQKw64BT oVfirA/hTHCVqPxt0ZwFzKfIWZx+a1RghhC30R54ZCBAVLXzaiHy4Q/2GC9kScqOMyQz W5teKj+As37PoS99rvX8f6OVPT9eEyuHS62hMt1BK9wRTR248jAXjBuGej4OTplR01FZ xQpQ== 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:content-type; bh=lWLsT/QDJiUQ54FBUC+kz5efQ7fbiMqZYDVrM4Dd2kc=; b=Br468wdEk+GTZaFfcL5YoDLySHeYxG7XIu62ycsJAm2iAhEXdpyUesIHbRyNcU8QSH u0WiFN8/rw3COpHwldQbeXRNXPa5gER5Tuow2c5dK2U2V4JgonYJB1asFujyLTY/I+9H scufgFJLkkMYUjJJZJdBtpXnDGUBVt8OffbI4JSXenpObG7o8IGneXhbeSC/eV1QK1Rr hp+6Dhow/ig7yIuKLGDYqOMIVK3Rx9YiMAhBlTdEjSelgINs2qbVKDgW2wzHvDaHuh3l d4fLiSPnhPnD7hIWE9Er6y58ZVUqoXzscvUN27RXsMeEu35PfqN6NqAgT30WgzNfLLFl ffIA== X-Received: by 10.194.185.167 with SMTP id fd7mr68146347wjc.108.1415821721288; Wed, 12 Nov 2014 11:48:41 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com. [209.85.212.174]) by mx.google.com with ESMTPSA id u8sm32683777wjq.1.2014.11.12.11.48.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 11:48:40 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id d1so6057435wiv.13 for ; Wed, 12 Nov 2014 11:48:39 -0800 (PST) X-Gm-Message-State: ALoCoQke9Y5HKs0jF3mqluVBuKza5ySzh0BRyWXciaARuS2rtCnKMrY1xyDXaQ92L6b3zKA51FyJ X-Received: by 10.180.75.179 with SMTP id d19mr8562777wiw.21.1415821719748; Wed, 12 Nov 2014 11:48:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.158.7 with HTTP; Wed, 12 Nov 2014 11:47:58 -0800 (PST) In-Reply-To: <1615251.R5XluhHgcf@kitterman-optiplex-9020m> References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> From: Brett McDowell Date: Wed, 12 Nov 2014 14:47:58 -0500 Message-ID: To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04389513abd8720507aeaef9 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/qJQTPWq7CL8rowA2IRbjWO_Pmw0 Cc: dmarc Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 19:48:45 -0000 --f46d04389513abd8720507aeaef9 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 10, 2014 at 4:57 PM, Scott Kitterman wrote: > On Monday, November 10, 2014 07:25:56 PM Elizabeth Zwicky wrote: > > OK, so I've dived into Yahoo's incoming metadata to look at what fails > DMARC > > and why. Conclusion 1: I cannot automatically tell the cases apart with > any > > accuracy. Hand coding them is so time-consuming as to be beyond my > ability > > to do at scale. So, not many numbers, but I have developed some very > > educated opinions, which unfortunately take a small novel to explain. > > First, transactional domains tend to have some mail that fails DMARC > > because of forwarding. The highest estimate of that I've seen is about > 1.5% > > (that's not data I ran); on the domains I've looked at so far I saw rates > > well below 0.1%. Still, that's people not getting their mail. For > > transactional mail, this is a strong majority forwarding (as in I send > mail > > to a@b.com and it delivers to a@c.com), and it's dominated by > educational > > institutions forwarding to their students/alumni, followed by hosting > > services and ISPs. The reasons for the forwarding breaking the signatures > > clearly vary; there are popular mail systems that, for instance, > > re-mime-encode bodies, or add signature files of various sorts, ranging > > from notifications that the message has been virus scanned to ads for the > > ISP forwarding the mail. Re-encoding things can result in intermittent > > breakage, where some forwarding works (because the forwarder doesn't feel > > the need to fix it) and other messages don't. A minority is not > > straightforward, my old address routes to my new one, forwarding, but are > > services that are specialized to handling mail -- third party spam > > filtering or mail classification products that then redeliver mail. They > > don't make up a big percentage of the cases but they are notable as cases > > that presumably would be able to change their handling if we provided > them > > with options. Then we get to end-user domains. Although I've heard from > > corporate domains where DMARC breakage is actually lower for the humans > > than the transactional mail, for the big mailbox holders, as far as I can > > tell, the expected ratios hold; more mail fails for end-users than for > > transactional mail. How much more? That gets interesting. For the domains > > at p=reject, the mail that arrives with an aligned DKIM signature still > on > > it, but not working -- which is the common case for both forwarding and > > mailing lists -- is significantly under 1%. For the domains at p=none, > that > > comes closer to 2%. That difference is partly in mailing lists, but, > sadly, > > a noticeable amount of the difference between p=reject and p=none domains > > when it comes to the mailing list mail is spam from a few, mostly > > commercial, mailing list providers. It is clear that a number of valid, > > happy mailing lists you might like have chosen to move subscribers from > > p=reject to p=none providers, with mixed success; the high volume ones > I've > > checked still have p=reject posters, at low rates. It is also clear that > a > > lot of educational institutions *both* run popular, DKIM-breaking > > forwarders *and* run popular, DKIM-breaking mailing lists (and, > > unsurprisingly, have alumni who go through both at once), which is one > way > > that these things rapidly become intractable for automated processing. > For > > everybody, way more mail shows up with no aligned DKIM signature on it > than > > with a broken aligned DKIM signature on it, and no noticeable amount of > > that mail had a DKIM signature stripped off. In fact, for every domain I > > looked at, the single largest cause of DMARC fail is purely forged mail, > > mostly spam. The rate of messages with no aligned DKIM signature ranged > > from 88% (for a mailbox domain with p=none) to 2% (for a transactional > > domain with p=reject). For transactional domains, that mail is not > readily > > distinguishable from pure trash. There must be a DKIM-stripping forward > out > > there somewhere, but I haven't found it. For end-user domains, once you > > ignore forged spam, the major volume contributors are hosting sites, but > > again, the use-cases are mixed. The highest volume from hosting sites is > > spam. The next highest is email to site owners "From:" themselves. There > > are a lot of people out there not getting mail from really frequent cron > > jobs. Then we get bulletin boards and blog software letting you know > > somebody has responded to your comment, and e-commerce solutions letting > > you know that somebody wants to order something -- all of that shows up > in > > one big jumble from the hosting providers. Next we get "parental control" > > software and other monitoring uses that send From: and To: the same > address > > and are verbose. And large service providers for small businesses. After > > that, it's the land of a million different indirect uses. More e-commerce > > sites. The people who send you happy birthday messages from your dentist, > > who uses a third-party account. Or your tee-time from your golf course, > > ditto. Or your tanning bed schedule, because there's a service out there > > that does nothing but email handling for tanning salons. Printers. > Security > > equipment. A surprising number of government agencies, including one > > national nuclear agency sending mail to: and from: the same person when > > replying to document requests or using a free email account to do > > government business. Services for multi-level marketing plans and other > > sell-to-your-friends plans. Oh, so many services for realtors. Lots of > > mail-to-friend features. Some of which (the ones with the most volume) > are > > being abused for spam. Elizabeth > > zwicky@yahoo-inc.com > > Thanks for the insights. > +1 Thank you for this analysis. And, of course, I would have never seen this text if Scott hadn't replied-to-all. --f46d04389513abd8720507aeaef9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Nov 10, 2014 at 4:57 PM, Scott Kitterman <sklist@kitterman.com<= /a>> wrote:
On Monday, November 10, 2014 07:25:56= PM Elizabeth Zwicky wrote:
> OK, so I've dived into Yahoo's incoming metadata to look at wh= at fails DMARC
> and why. Conclusion 1: I cannot automatically tell the cases apart wit= h any
> accuracy. Hand coding them is so time-consuming as to be beyond my abi= lity
> to do at scale. So, not many numbers, but I have developed some very > educated opinions, which unfortunately take a small novel to explain.<= br> > First, transactional domains tend to have some mail that fails DMARC > because of forwarding. The highest estimate of that I've seen is a= bout 1.5%
> (that's not data I ran); on the domains I've looked at so far = I saw rates
> well below 0.1%. Still, that's people not getting their mail. For<= br> > transactional mail, this is a strong majority forwarding (as in I send= mail
> to a@b.com and it delivers to a@c.com), and it's dominated by educational
> institutions forwarding to their students/alumni, followed by hosting<= br> > services and ISPs. The reasons for the forwarding breaking the signatu= res
> clearly vary; there are popular mail systems that, for instance,
> re-mime-encode bodies, or add signature files of various sorts, rangin= g
> from notifications that the message has been virus scanned to ads for = the
> ISP forwarding the mail. Re-encoding things can result in intermittent=
> breakage, where some forwarding works (because the forwarder doesn'= ;t feel
> the need to fix it) and other messages don't. A minority is not > straightforward, my old address routes to my new one, forwarding, but = are
> services that are specialized to handling mail -- third party spam
> filtering or mail classification products that then redeliver mail. Th= ey
> don't make up a big percentage of the cases but they are notable a= s cases
> that presumably would be able to change their handling if we provided = them
> with options. Then we get to end-user domains. Although I've heard= from
> corporate domains where DMARC breakage is actually lower for the human= s
> than the transactional mail, for the big mailbox holders, as far as I = can
> tell, the expected ratios hold; more mail fails for end-users than for=
> transactional mail. How much more? That gets interesting. For the doma= ins
> at p=3Dreject, the mail that arrives with an aligned DKIM signature st= ill on
> it, but not working -- which is the common case for both forwarding an= d
> mailing lists -- is significantly under 1%. For the domains at p=3Dnon= e, that
> comes closer to 2%. That difference is partly in mailing lists, but, s= adly,
> a noticeable amount of the difference between p=3Dreject and p=3Dnone = domains
> when it comes to the mailing list mail is spam from a few, mostly
> commercial, mailing list providers. It is clear that a number of valid= ,
> happy mailing lists you might like have chosen to move subscribers fro= m
> p=3Dreject to p=3Dnone providers, with mixed success; the high volume = ones I've
> checked still have p=3Dreject posters, at low rates. It is also clear = that a
> lot of educational institutions *both* run popular, DKIM-breaking
> forwarders *and* run popular, DKIM-breaking mailing lists (and,
> unsurprisingly, have alumni who go through both at once), which is one= way
> that these things rapidly become intractable for automated processing.= For
> everybody, way more mail shows up with no aligned DKIM signature on it= than
> with a broken aligned DKIM signature on it, and no noticeable amount o= f
> that mail had a DKIM signature stripped off. In fact, for every domain= I
> looked at, the single largest cause of DMARC fail is purely forged mai= l,
> mostly spam. The rate of messages with no aligned DKIM signature range= d
> from 88% (for a mailbox domain with p=3Dnone) to 2% (for a transaction= al
> domain with p=3Dreject). For transactional domains, that mail is not r= eadily
> distinguishable from pure trash. There must be a DKIM-stripping forwar= d out
> there somewhere, but I haven't found it. For end-user domains, onc= e you
> ignore forged spam, the major volume contributors are hosting sites, b= ut
> again, the use-cases are mixed. The highest volume from hosting sites = is
> spam. The next highest is email to site owners "From:" thems= elves. There
> are a lot of people out there not getting mail from really frequent cr= on
> jobs. Then we get bulletin boards and blog software letting you know > somebody has responded to your comment, and e-commerce solutions letti= ng
> you know that somebody wants to order something -- all of that shows u= p in
> one big jumble from the hosting providers. Next we get "parental = control"
> software and other monitoring uses that send From: and To: the same ad= dress
> and are verbose. And large service providers for small businesses. Aft= er
> that, it's the land of a million different indirect uses. More e-c= ommerce
> sites. The people who send you happy birthday messages from your denti= st,
> who uses a third-party account. Or your tee-time from your golf course= ,
> ditto. Or your tanning bed schedule, because there's a service out= there
> that does nothing but email handling for tanning salons. Printers. Sec= urity
> equipment. A surprising number of government agencies, including one > national nuclear agency sending mail to: and from: the same person whe= n
> replying to document requests or using a free email account to do
> government business. Services for multi-level marketing plans and othe= r
> sell-to-your-friends plans. Oh, so many services for realtors. Lots of=
> mail-to-friend features. Some of which (the ones with the most volume)= are
> being abused for spam. Elizabeth
>=C2=A0 =C2=A0 =C2=A0zwicky@yaho= o-inc.com

Thanks for the insights.

+1

Thank you for this analys= is.

An= d, of course, I would have never seen this text if Scott hadn't replied= -to-all.

--f46d04389513abd8720507aeaef9-- From nobody Wed Nov 12 12:59:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799451A19E2 for ; Wed, 12 Nov 2014 12:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1sDj9yT_k_M for ; Wed, 12 Nov 2014 12:59:16 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 949A81A1A68 for ; Wed, 12 Nov 2014 12:59:16 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 1AB6E5649A2; Wed, 12 Nov 2014 14:59:16 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E84DAA0614; Wed, 12 Nov 2014 14:59:15 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AuOm8xvfYhM; Wed, 12 Nov 2014 14:59:15 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 747A6A061D; Wed, 12 Nov 2014 14:59:14 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 747A6A061D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415825954; bh=YKakIOr3VustVARwyKdvrQZ9rwlQHOG3S16AGGvPr2I=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=Nl7320J+1GAn4ORyjCvbB6hmzJU1/m3v8lsrLMvWnBlI7UoWA79GV0gTvuXwSyh17 01toWUxxTOJo6w00tfADnm1RTU/q3FjVN7F+xbr5wbnUnE2DJ+X20MCwCAyNWRN70H EEqdnqjSu51pQW6v87QHUKFfkk22ztQ0q8sHmtsM= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 40D4DA0618; Wed, 12 Nov 2014 14:59:14 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id j0FvP1ySObSf; Wed, 12 Nov 2014 14:59:14 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 1C5ECA0614; Wed, 12 Nov 2014 14:59:14 -0600 (CST) Date: Wed, 12 Nov 2014 14:59:13 -0600 (CST) From: Franck Martin To: Brett McDowell Message-ID: <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_72323_1147176684.1415825953449" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: Indirect email flows Thread-Index: 6MifTpC5239snEBllwd6k2mVjvVn7g== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Z4rTT5tVvCd2ujK93goSUOZVFMM Cc: "Murray S. Kucherawy" , dmarc , Scott Kitterman Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:59:20 -0000 ------=_Part_72323_1147176684.1415825953449 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Brett McDowell" > To: "Scott Kitterman" > Cc: "dmarc" > Sent: Wednesday, November 12, 2014 9:47:58 AM > Subject: Re: [dmarc-ietf] Indirect email flows > On Mon, Nov 10, 2014 at 4:57 PM, Scott Kitterman < sklist@kitterman.com > > wrote: > > On Monday, November 10, 2014 07:25:56 PM Elizabeth Zwicky wrote: > > > > being abused for spam. Elizabeth > > > > zwicky@yahoo-inc.com > > > Thanks for the insights. > > +1 > Thank you for this analysis. > And, of course, I would have never seen this text if Scott hadn't > replied-to-all. Could I request the list admins, to drop the subject tagging and the footer on this list? And if possible remove the removal of the HTML? Thanks. ------=_Part_72323_1147176684.1415825953449 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Brett McDowell" <brettmcdowell@g= mail.com>
To: "Scott Kitterman" <sklist@kitterman.com>Cc: "dmarc" <dmarc@ietf.org>
Sent: Wednesday, Nove= mber 12, 2014 9:47:58 AM
Subject: Re: [dmarc-ietf] Indirect email= flows


On Mon, Nov 10, 2014 at 4:57 PM, Scott Kitterman <= span dir=3D"ltr"><sklist@kitterman.com> wrote:
On Monday, N= ovember 10, 2014 07:25:56 PM Elizabeth Zwicky wrote:

> being abused for spam. Elizabeth
>     zwicky@yahoo-inc.com

Thanks for the insights.

+1

Thank you for this analys= is.

An= d, of course, I would have never seen this text if Scott hadn't replied-to-= all.

Co= uld I request the list admins, to drop the subject tagging and the footer o= n this list? And if possible remove the removal of the HTML?
=
Thanks.
------=_Part_72323_1147176684.1415825953449-- From nobody Wed Nov 12 13:32:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090B01AD366 for ; Wed, 12 Nov 2014 13:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6Wlttgo8DJC for ; Wed, 12 Nov 2014 13:32:50 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id ECDF31A8A54 for ; Wed, 12 Nov 2014 13:32:13 -0800 (PST) Received: from [192.168.80.56] (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 65E2A80CF2 for ; Wed, 12 Nov 2014 13:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1415827933; bh=PQ/ug8So33re/f7l5ZxjTSG+oem2Ul7mxBI3t+nsDrU=; h=Subject:From:In-Reply-To:Date:References:To:From; b=LjlDRKC3RiOfxOYxXouIokenKPv1avPp9ddgHYKne4WSnFqEKb+4j3odegqHMwxsQ y8+cPQSz4/6+C95PakJ76nNg6Ededa118h8943A5UpB2cupl0BYLYAfZF1UJNgGBi8 7zbi2tRj3VbUw0edbw6ODMKxbXW7B5RR+TezhPC4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> Date: Wed, 12 Nov 2014 13:32:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> To: dmarc X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/V0u3XvXn5zy4G9amXuRHspIFEdc Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 21:32:55 -0000 On Nov 12, 2014, at 12:59 PM, Franck Martin = wrote: > From: "Brett McDowell" > To: "Scott Kitterman" > Cc: "dmarc" > Sent: Wednesday, November 12, 2014 9:47:58 AM > Subject: Re: [dmarc-ietf] Indirect email flows >=20 >=20 > On Mon, Nov 10, 2014 at 4:57 PM, Scott Kitterman = wrote: > On Monday, November 10, 2014 07:25:56 PM Elizabeth Zwicky wrote: >=20 > > being abused for spam. Elizabeth > > zwicky@yahoo-inc.com >=20 > Thanks for the insights. >=20 > +1 >=20 > Thank you for this analysis. >=20 > And, of course, I would have never seen this text if Scott hadn't = replied-to-all. >=20 > Could I request the list admins, to drop the subject tagging and the = footer on this list? And if possible remove the removal of the HTML? -1 Let's not damage the functionality of the mailing list to work around a = few subscribers who are violating their employers email usage policies. Cheers, Steve From nobody Wed Nov 12 13:36:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 382831AD401 for ; Wed, 12 Nov 2014 13:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQouMs3rDxDp for ; Wed, 12 Nov 2014 13:36:49 -0800 (PST) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) by ietfa.amsl.com (Postfix) with SMTP id B51191AD3F7 for ; Wed, 12 Nov 2014 13:36:49 -0800 (PST) Received: (qmail 13615 invoked by uid 89); 12 Nov 2014 21:36:49 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 12 Nov 2014 21:36:49 -0000 Authentication-Results: mail.theartfarm.com; iprev=pass; auth=pass (cram-md5); spf=pass smtp.mailfrom=tnpi.net Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=[10.0.1.141]; envelope-from= Received: from [10.0.1.141] (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.1-toaster) with ESMTPSA id 273A47E1-CFFB-49D1-9F1C-100135343460.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES256-SHA verify=NO); Wed, 12 Nov 2014 13:36:48 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Matt Simerson In-Reply-To: <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> Date: Wed, 12 Nov 2014 13:36:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> To: dmarc X-Mailer: Apple Mail (2.1990.1) X-Haraka-p0f: os="Mac OS X " link_type="Ethernet or modem" distance=10 total_conn=1 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2699km X-Haraka-GeoIP-Received: X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: sonic.net: spamassassin.tnpi.net 1156; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-2527-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-2527-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 10.0.1.141, Ugly c=0.264319 p=-1 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-2527-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 4, history: 42, total_connects: 44, neighbors: -727, pass:fcrdns.fcrdns, relaying, auth_user, spamassassin.hits, fail:fcrdns.fail, neighbors(-727), karma.neighbors, karma.neighbors, karma.neighbors, dnsbl.fail, helo.checks.fail, helo.checks.fail, skip:penalty Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WPiyQyOmCjCCOVvXAgaO9jxikvU Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 21:36:51 -0000 > On Nov 12, 2014, at 12:59 PM, Franck Martin = wrote: >=20 >> Could I request the list admins, to drop the subject tagging and the = footer on this list? And if possible remove the removal of the HTML? +1 Matt= From nobody Wed Nov 12 14:49:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E90631A0154 for ; Wed, 12 Nov 2014 14:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMsV-qzzT10U for ; Wed, 12 Nov 2014 14:49:31 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D17E1A0147 for ; Wed, 12 Nov 2014 14:49:31 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id r20so6485828wiv.10 for ; Wed, 12 Nov 2014 14:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aK+6/cf45iprmr7VP08KRMbt5Or7uttlIUdGWda/3jU=; b=Y/c2nGEsHdnOtY1ZAayFrufVhxit1hhfZG7PbAR5WwMqaa48xyF1UGqgQ+TZ4NNJDF Iw8MJU+eAp73RdBiEWwGLDaqpP74nnK5Dx9ddVVUky/y+mKTJpLt5IeGvSIdQOBLq5Nd LffodiuSfAlzatXxTagNb6YY+DCzj4sXTEBJqbQ5rxOxIn+eCkxV1YUMEOec0y7EYUAh pj1nhTFekZu+8BFDfUWIoPbBDmBEj8tVj8YJpRjG6w84R5S0SUp7Z1G2Z0176hDcLqgP 24GOWyD0+uEOcQSY4J6fLYKD2MxcL7/y66o498NYIMHIQ/dkvqcBVmSr5wpqP4iFKXHh fSAA== 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:content-type; bh=aK+6/cf45iprmr7VP08KRMbt5Or7uttlIUdGWda/3jU=; b=VbGVlZSgj89vSi/HIvfiUKfilJOH9qIj4wFXA+lNmY5s23ESe0+tCOQZp/J6X88fmF +4SypGtrlgNo9ZmFK8cWn1SlRWMtk3b9Dp+NM5s1IA/rrEEMgGz9fBnGHaFR1d23B8M3 428Qd3ht/4tHcQn5xDxOL6ERoXQQzlhFUudtCncXl+cn+OZ0irWJQa+8GUDgl+zOpqNx z3SS6lJ/VueJI5x4YcuakBLJjWFjslmvJruMX+GvP1kmaa7rUvtYf43x79yL1atAIFB1 /bek4vHfz7sNK/0CC/aM8dPF8PizgySUTV+mOdCVFM5387j3srKLR5s5siIwwzlJTQaI g6GQ== X-Received: by 10.180.9.196 with SMTP id c4mr54321786wib.66.1415832570179; Wed, 12 Nov 2014 14:49:30 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com. [209.85.212.175]) by mx.google.com with ESMTPSA id wx3sm33152969wjc.19.2014.11.12.14.49.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 14:49:28 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so2508564wiw.8 for ; Wed, 12 Nov 2014 14:49:28 -0800 (PST) X-Gm-Message-State: ALoCoQmEmcaErd8sO1dupOBBbdpspeDhLdXbJJfhINZZSsjlAwfPDk7omVUEPvdbrbwMrPd5NM/Y X-Received: by 10.194.241.194 with SMTP id wk2mr28651244wjc.132.1415832568089; Wed, 12 Nov 2014 14:49:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.158.7 with HTTP; Wed, 12 Nov 2014 14:48:46 -0800 (PST) In-Reply-To: References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> From: Brett McDowell Date: Wed, 12 Nov 2014 17:48:46 -0500 Message-ID: To: Matt Simerson Content-Type: multipart/alternative; boundary=089e013d1da2486dd60507b1350c Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/grlc5W_Q0zsc62lH1lS1m5OwPz4 Cc: dmarc Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 22:49:33 -0000 --089e013d1da2486dd60507b1350c Content-Type: text/plain; charset=UTF-8 On Wed, Nov 12, 2014 at 4:36 PM, Matt Simerson wrote: > > On Nov 12, 2014, at 12:59 PM, Franck Martin > wrote: > > > >> Could I request the list admins, to drop the subject tagging and the > footer on this list? And if possible remove the removal of the HTML? > > +1 The mailing list is here as a tool to facilitate communication between the participants. We have a few (very valuable) participants who are employed by early adopters of DMARC protection, like Yahoo and Google. We all know that MLM's configured in traditional ways and subscribers using domains protected by DMARC, don't mix. That's why we are here, to try and "fix" this problem (among others). In the meantime we have to pick between the lesser of two evils. We either (a) ask subscribers to not use email addresses protected by DMARC policies or (b) change the default configurations of this mailing list. Personally, I don't know which of those two is the least painful compromise. It is easy for me to use my @gmail.com account instead of my DMARC-protected @brettmcdowell.com account. Maybe that's not so easy for others, I don't know. But if we choose option (a) and that results in less effective participation from Yahoo! or Google, then (a) would be the wrong choice IMHO. --089e013d1da2486dd60507b1350c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Nov 12, 2014 at 4:36 PM, Matt Simerson <matt@tnpi.net> w= rote:
> On Nov 12, 20= 14, at 12:59 PM, Franck Martin <franck@peachymango.org> wrote:
>
>> Could I request the list admins, to drop t= he subject tagging and the footer on this list? And if possible remove the = removal of the HTML?

+1

The mailing list is here as a tool to facilitate com= munication between the participants.=C2=A0 We have a few (very valuable) pa= rticipants who are employed by early adopters of DMARC protection, like Yah= oo and Google.=C2=A0 We all know that MLM's configured in traditional w= ays and subscribers using domains protected by DMARC, don't mix.=C2=A0 = That's why we are here, to try and "fix" this problem (among = others).=C2=A0 In the meantime we have to pick between the lesser of two ev= ils.=C2=A0 We either (a) ask subscribers to not use email addresses protect= ed by DMARC policies or (b) change the default configurations of this maili= ng list.

Personally, I don't know which of those two is the least painful com= promise.=C2=A0 It is easy for me to use my @gm= ail.com account instead of my DMARC-protected @brettmcdowell.com account.=C2=A0 Maybe that's not so e= asy for others, I don't know.=C2=A0 But if we choose option (a) and tha= t results in less effective participation from Yahoo! or Google, then (a) w= ould be the wrong choice IMHO.


<= /div>
--089e013d1da2486dd60507b1350c-- From nobody Wed Nov 12 15:27:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151211A1B44 for ; Wed, 12 Nov 2014 15:27:20 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6spKwGGoa9tI for ; Wed, 12 Nov 2014 15:27:13 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 32DEA1A1B4B for ; Wed, 12 Nov 2014 15:27:12 -0800 (PST) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3jdMXt4rM2z1L8cw; Thu, 13 Nov 2014 00:27:10 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3jdMXt3f44z1L8cr; Thu, 13 Nov 2014 00:27:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 3F3EC12344B; Thu, 13 Nov 2014 00:27:12 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MASnahHulkgl; Thu, 13 Nov 2014 00:26:58 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id CC03812343C; Thu, 13 Nov 2014 00:26:55 +0100 (CET) Message-ID: <5463ECBD.9030703@sonnection.nl> Date: Thu, 13 Nov 2014 00:26:53 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "dmarc@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060509060102060904080305" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1415834830; bh=7qmfKg8Pe/0IBJREfacAghxfr3HJHQmmLjZYw25e6ms=; h=Message-ID:Date:From:To:Subject:From; b=IAaDkEQuCF1cd8Ot5hd+G0vX3BKD4/6TsPgyw7NF/NuiIgv2zJ2xVCEtM6WVx1lfN rKSIeI1iMrZHJy00TSyioD2bs0E0FCyUwowPWcyP7okNBQ2jqJNjoVF5egoDeEH2Ew NhN63l/9DI7ejoe2pANyuNw85Tn6IQo4AQM8y1AE= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3jdMXt4rM2z1L8cw Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7apZsJKvMRDVhAYF4Ts-fmgqBvE Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 23:27:20 -0000 This is a multi-part message in MIME format. --------------060509060102060904080305 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Murray, On 11/11/2014 02:52 AM, Murray S. Kucherawy wrote: > I've posted an update to the base draft, based on recent feedback from=20 > Ned and others. Hopefully I've resolved all of the concerns=20 > (especially the major ones), as the ISE would like to send the draft=20 > to the IESG for conflict review in the next day or two. It also has=20 > to begin formal review of its IANA Considerations section as soon as=20 > possible. > > Thanks to all who provided recent comments to lead us to this version. I started earlier this week a review of -05. Please find below my=20 comments, I think most if not all of them also apply to -06. I didn't=20 have time to finish my review, but thought to send my comments 'as is'=20 (before -07 is published ;-)). Most of my comments are of type=20 'editorial nits', no big changes proposed ;-) Regards, /rolf Abstract: This lack of cohesion has several effects: receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology. This focuses on the reporting function of DMARC, leaving out the policy=20 part of it. Suggested text: This lack of cohesion has several effects: senders have difficulty providing information about their use of an authentication policy and receivers have difficulty determining a disposition preferred by senders. Vice versa, mail receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology. Introduction: [...] mail receivers have tried to protect senders [...] Suggested: [...] mail receivers have tried to protect senders and their own users/customers [...] Starting with "DMARC allows domain owners and receivers to collaborate=20 by", the terms 'domain owners', 'receivers', 'senders' and 'SMTP=20 receivers', 'Mail Receivers', 'mail receivers' are used throughout the=20 document. I'd suggest to add a definition of the term ' Mail Senders' to=20 the introduction part of chapter 3 and then use only the terms as=20 defined in 3., throughout the document. Suggested text for the term Mail=20 Sender: * Mail Sender: the sender of mail with a domain for which the Domain Owner may have published a DKIM public key and/or an SPF authentication record and/or a DMARC policy; (although we may want to not mention DKIM or SPF here). 2.2 Out of Scope Add: o cousin domain attacks 3.1.2 Key Concepts Last sentence: add a reference to this 'other referenced material'. 3.1.3 Flow diagram The box titled 'User Mailbox' could give the impression that there's=20 only one choice for delivery. However, quarantining can be done without=20 delivery to a mailbox. I'd suggest to label this box 'rMDA'. The part within parentheses of step 6: > 6. Recipient transport service conducts SPF and DKIM authentication=20 > checks by passing the necessary data to their respective modules, each=20 > of which require queries to the Author Domain=92s DNS data (when=20 > identifiers are aligned; see below). might indicate that SPF and DKIM authentication checks need not be=20 performed when identifiers are not aligned. However, for sake of=20 reporting, SPF and DKIM authentication checks will in general always be=20 done, or am I missing something? 3.1.4.1 DKIM-authenticated Identifiers remove (or change) the 'Cousin Domain' example: it doesn't hold when a=20 bad actor is signing the mail with d=3Dcousindomain and=20 RFC5322.From=3Dlocalpart@cousindomain 4 Use of RFC5322.From Last bullet (The DMARC mechanism ...). It seems the other bullets=20 provide reasons why RFC5322.From is chosen while the last one does not.=20 It looks to me as a circular reasoning. 5.2 DMARC URIs It is not clear from the text what the report originator must do when=20 the report payload exceeds the maximum size as indicated by the record.=20 Should it not send anything, should it split up reports, should it=20 notify the requester that there was a report exceeding the maximum size? 5.3 General Record Format adkim and aspf do not provide a list of all possible options (like is=20 done for fo and p). Of course it is pretty obvious that for 'strict' the=20 's' must be used, but it's not clear from the text. Suggested edit: adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether strict or relaxed DKIM identifier alignment mode is required by the Domain Owner. Possible values: r: relaxed DKIM identifier alignment mode required s: strict DKIM identifier alignment mode required See Section 3.1.4.1 for details. and aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether strict or relaxed SPF identifier alignment mode is required by the Domain Owner. Possible values: r: relaxed SPF identifier alignment mode required s: strict SPF identifier alignment mode required See Section 3.1.4.2 for details Next, the P: and pct: tags: they show that (in hindsight) the policy=20 part and the reporting part of DMARC might have been better off, when=20 they were defined in different specs. Now we need to complicate the text=20 to say that the policy tag p: is required, but not for third-party=20 reporting records. And for pct, that it "MUST NOT be applied to the=20 DMARC-generated reports". Well, I believe this has been discussed=20 before, no need to redo this discussion. I'd suggest to synchronize the short description of the tags in 5.3 with=20 the descriptions of the tags in the table of 10.4 (now different=20 terminology is used here and there, for example Requested Mail Receiver=20 policy (5.3) and Requested handling policy (10.4). Suggested text in 5.3=20 becomes then: adkim: DKIM alignment mode (plain-text; OPTIONAL, default is "r".) Indicates whether [...] aspf: SPF alignment mode (plain-text; OPTIONAL, default is "r".) Indicates whether [...] fo: (leave as it is) p: Requested Mail Receiver Policy (plain-text; REQUIRED for policy records). Indicates [...] pct: Sampling rate (plain-text integer between 0 and 100, inclusive; OPTIONAL; default is 100). Percentage of messages [...] rf: Failure Reporting Format(s) (colon-separated plain-text list of values; OPTIONAL; default "afrf"). Format to be used for message-specific failure reports. [...] ri: Aggregate Reporting Interval (plain-text, 32-bit unsigned integer; OPTIONAL; default 86400). Indicates [...] rua: Reporting URI(s) for aggregate data (comma-separated plain-text list of DMARC URIs; OPTIONAL). Addresses to which aggregate feedback is to be sent. A comma or exclamation point [...] ruf: Reporting URI(s) for failure data (comma-separated plain-text list of DMARC URIs; OPTIONAL). Addresses to which message-specific failure information is to be reported. If present [...] sp: Requested Mail Receiver Policy for subdomains (plain-text; OPTIONAL). Indicates [...] v: Specification Version (plain-text; REQUIRED). Identifies [...] and then change the corresponding table in 10.4 as follows: for p: use 'Requested Mail Receiver policy' for sp: use 'Requested Mail Receiver policy'. Further suggestion for the table in 10.4: reverse the order of 'p' and=20 'pct' as 'p' is first discussed in the text of 5.3, before 'pct'. Suggestion for 'ri': remove the normative language (MUST and SHOULD) as=20 that might ask for a 'compliancy' section. Instead, move these=20 suggested values to the BCP document. 5.6.2. Determine Handling Policy Bullet 6 in combination with the introduction text might give the=20 impression that the receiver MUST always follow the policy as published=20 by the Domain Owner. Suggestion to replace the text: 6. Apply policy. Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 5.3 with: 6. Apply policy. Emails that fail the DMARC mechanism SHOULD be disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 5.3 5.6.3. Policy Discovery. This paragraph states that: If the RFC5322.From domain does not exist in the DNS, Mail Receivers SHOULD direct the receiving SMTP server to reject the message. The choice of mechanism for such rejection and the implications of those choices are discussed in Section 9.3. Although this might be common practice (either by default MTA settings,=20 or by configuration parameters set by many mail operators), I believe=20 this informational RFC about DMARC cannot use normative language here to=20 decribe what must be done with mail with a domain that is not present in=20 DNS. 5.7 Last sentence: Mail Receivers SHOULD also implement reporting instructions of DMARC in place of any extensions to SPF or DKIM that might enable such reporting. Not sure what this means. But it seems to me DMARC cannot claim priority=20 over other options/extensions in other IETF protocols. --------------060509060102060904080305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi, Murray,

On 11/11/2014 02:52 AM, Murray S. Kucherawy wrote:
I've posted an update to the base draft, based on recent feedback from Ned and others.=A0 Hopefully I've resolved all of the concerns (especially the major ones), as the ISE would like to send the draft to the IESG for conflict review in the next day or two.=A0 It also has to begin formal review of its IANA Considerations section as soon as possible.

Thanks to all who provided recent comments to lead us to this version.

I started earlier this week a review of -05. Please find below my comments, I think most if not all of them also apply to -06. I didn't have time to finish my review, but thought to send my comments 'as is' (before -07 is published ;-)). Most of my comments are of type 'editorial nits', no big changes proposed ;-)

Regards,
/rolf

Abstract:

This lack of cohesion has several effects: receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology.

This focuses on the reporting function of DMARC, leaving out the policy part of it.

Suggested text:

This lack of cohesion has several effects: senders have difficulty providing information about their use of an authentication policy and receivers have difficulty determining a disposition preferred by senders. Vice versa, mail receivers have difficulty providing feedback to senders about authentication, senders therefore have difficulty evaluating their authentication deployments, and as a result neither is able to make effective use of existing authentication technology.
Introduction:

[...] mail receivers have tried to protect senders [...]<= br>

Suggested:

[...] mail receivers have tried to protect senders and their own users/customers [...]

Starting with "DMARC allows domain owners and receivers to collaborate by", the terms 'domain owners', 'receivers', 'senders' and 'SMTP receivers', 'Mail Receivers', 'mail receivers' are used throughout the document. I'd suggest to add a definition of the term ' Mail Senders' to the introduction part of chapter 3 and then use only the terms as defined in 3., throughout the document. Suggested text for the term Mail Sender:

  • Mail Sender: the sender of mail with a domain for which the Domain Owner may have published a DKIM public key and/or an SPF authentication record and/or a DMARC policy;

(although we may want to not mention DKIM or SPF here).

2.2 Out of Scope

Add:

o=A0=A0=A0 cousin domain attacks

3.1.2 Key Concepts

Last sentence: add a reference to this 'other referenced material'.

3.1.3 Flow diagram

The box titled 'User Mailbox' could give the impression that there's only one choice for delivery. However, quarantining can be done without delivery to a mailbox. I'd suggest to label this box 'rMDA'.

The part within parentheses of step 6:

=A06. Recipient transport service conducts = SPF and DKIM authentication checks by passing the necessary data to their respective modules, each of which require queries to the Author Domain=92s DNS data (when identifiers are aligned; see below).

might indicate that SPF and DKIM authentication checks need not be performed when identifiers are not aligned. However, for sake of reporting, SPF and DKIM authentication checks will in general always be done, or am I missing something?

3.1.4.1 DKIM-authenticated Identifiers

remove (or change) the 'Cousin Domain' example: it doesn't hold when a bad actor is signing the mail with d=3Dcousindomain and RFC5322.From=3Dlocalpart@cousindomain

4 Use of RFC5322.From

Last bullet (The DMARC mechanism ...). It seems the other bullets provide reasons why RFC5322.From is chosen while the last one does not. It looks to me as a circular reasoning.

5.2 DMARC URIs

It is not clear from the text what the report originator must do when the report payload exceeds the maximum size as indicated by the record. Should it not send anything, should it split up reports, should it notify the requester that there was a report exceeding the maximum size?

5.3 General Record Format

adkim and aspf do not provide a list of all possible options (like is done for fo and p). Of course it is pretty obvious that for 'strict' the 's' must be used, but it's not clear from the text.

Suggested edit:

adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether strict or relaxed DKIM identifier alignment mode is required by the Domain Owner.

Possible values:

r: relaxed DKIM identifier alignment mode required
s: strict DKIM identifier alignment mode required

See Section 3.1.4.1 for details.

and

aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether strict or relaxed SPF identifier alignment mode is required by the Domain Owner.

Possible values:

r: relaxed SPF identifier alignment mode required
s: strict SPF identifier alignment mode required

See Section 3.1.4.2 for details

Next, the P: and pct: tags: they show that (in hindsight) the policy part and the reporting part of DMARC might have been better off, when they were defined in different specs. Now we need to complicate the text to say that the policy tag p: is required, but not for third-party reporting records. And for pct, that it "MUST NOT be applied to the DMARC-generated reports". Well, I believe this has been discussed before, no need to redo this discussion.

I'd suggest to synchronize the short description of the tags in 5.3 with the descriptions of the tags in the table of 10.4 (now different terminology is used here and there, for example Requested Mail Receiver policy (5.3) and Requested handling policy (10.4). Suggested text in 5.3 becomes then:

adkim: DKIM alignment mode (plain-text; OPTIONAL, default is "r".) Indicates whether [...]

aspf: SPF alignment mode (plain-text; OPTIONAL, default is "r".) Indicates whether [...]

fo: (leave as it is)

p: Requested Mail Receiver Policy (plain-text; REQUIRED for policy records). Indicates [...]

pct: Sampling rate (plain-text integer between 0 and 100, inclusive; OPTIONAL; default is 100). Percentage of messages [...]

rf: Failure Reporting Format(s) (colon-separated plain-text list of values; OPTIONAL; default "afrf"). Format to be used for message-specific failure reports. [...]

ri: Aggregate Reporting Interval (plain-text, 32-bit unsigned integer; OPTIONAL; default 86400). Indicates [...]

rua: Reporting URI(s) for aggregate data (comma-separated plain-text list of DMARC URIs; OPTIONAL). Addresses to which aggregate feedback is to be sent. A comma or exclamation point [...]

ruf: Reporting URI(s) for failure data (comma-separated plain-text list of DMARC URIs; OPTIONAL). Addresses to which message-specific failure information is to be reported. If present [...]

sp: Requested Mail Receiver Policy for subdomains (plain-text; OPTIONAL). Indicates [...]

v: Specification Version (plain-text; REQUIRED). Identifies [...]

and then change the corresponding table in 10.4 as follows:

for p: use 'Requested Mail Receiver policy'
for sp: use 'Requested Mail Receiver policy'.

Further suggestion for the table in 10.4: reverse the order of 'p' and 'pct' as 'p' is first discussed in the text of 5.3, before 'pct'.

Suggestion for 'ri': remove the normative language (MUST and SHOULD) as that might ask for a 'compliancy'=A0 section. Instead, move these suggested values to the BCP document.

5.6.2. Determine Handling Policy

Bullet 6 in combination with the introduction text might give the impression that the receiver MUST always follow the policy as published by the Domain Owner. Suggestion to replace the text:

6. Apply policy. Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 5.3

with:

6. Apply policy. Emails that fail the DMARC mechanism SHOULD be disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 5.3


5.6.3. Policy Discovery.

This paragraph states that:

If the RFC5322.From domain does not exist in the DNS, Mail Receivers SHOULD direct the receiving SMTP server to reject the message. The choice of mechanism for such rejection and the implications of those choices are discussed in Section 9.3.

Although this might be common practice (either by default MTA settings, or by configuration parameters set by many mail operators), I believe this informational RFC about DMARC cannot use normative language here to decribe what must be done with mail with a domain that is not present in DNS.

5.7 Last sentence:

Mail Receivers SHOULD also implement reporting instructions of DMARC in place of any extensions to SPF or DKIM that might enable such reporting.

Not sure what this means. But it seems to me DMARC cannot claim priority over other options/extensions in other IETF protocols.
























--------------060509060102060904080305-- From nobody Wed Nov 12 15:37:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 232451A1B75 for ; Wed, 12 Nov 2014 15:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FYhsZJmC3l8 for ; Wed, 12 Nov 2014 15:37:04 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CEF1A1B6E for ; Wed, 12 Nov 2014 15:37:03 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so4727229wgg.35 for ; Wed, 12 Nov 2014 15:37:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vciEMHfvYwVxD8eHiInbr2jtm/lyrPQFd5Dd+VFPJ3A=; b=uj3+t9cS2HIu7DGVrFbTKxJuRjjKVH4rkOsMU042hVdsjpxYEAdhmjp3L5Y317uXHJ zI1HE7ee6QcYUpuKSWnPW+WGIfQn1koVurOHt3kiriySKmHZqywULJUqg1MYeO2KFY3C 4Ozp+Fa7yPCSuDHh+lrBR2O1d8H/v3GQRLikhvAraeKs5VV8sCmkeKppVNfmlC1a6Yu5 Coct5nFGAkxdOOT7E3VZovhQICgyXq4BtPzowlPpjpbJhejN8Y8anX2UL6Y3xMz8mPZw DLG4npA9W+LukKGoqUIVpooONmr1tSqIWOSzMbW/9Vq/6bv0uO/WnRbOmf7QA7jbv8wl C9uA== MIME-Version: 1.0 X-Received: by 10.180.9.106 with SMTP id y10mr53132119wia.30.1415835422615; Wed, 12 Nov 2014 15:37:02 -0800 (PST) Received: by 10.27.76.134 with HTTP; Wed, 12 Nov 2014 15:37:02 -0800 (PST) In-Reply-To: <5463ECBD.9030703@sonnection.nl> References: <5463ECBD.9030703@sonnection.nl> Date: Wed, 12 Nov 2014 13:37:02 -1000 Message-ID: From: "Murray S. Kucherawy" To: "" Content-Type: multipart/alternative; boundary=001a11c225446cefdd0507b1dfc7 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/21YjHoMCSaHdLGOioAMH-0FVwjs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 23:37:07 -0000 --001a11c225446cefdd0507b1dfc7 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 12, 2014 at 1:26 PM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > Hi, Murray, > Hello Rolf, > I started earlier this week a review of -05. Please find below my > comments, I think most if not all of them also apply to -06. I didn't have > time to finish my review, but thought to send my comments 'as is' (before > -07 is published ;-)). Most of my comments are of type 'editorial nits', no > big changes proposed ;-) > Thanks for taking time to take a closer look. At this point I'm not going to be making any other changes unless they are attempts to resolve things that are either major errors (i.e., they don't reflect the deployed DMARC base or are plainly wrong) or would cause the IESG's conflict review to return a blocking concern. If it does come back from the IESG for more editing, I'll take a run at applying your suggestions. Thanks again, -MSK --001a11c225446cefdd0507b1dfc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 12, 2014 at 1:26 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:
=20 =20 =20
Hi, Murray,

Hello Rolf,
=C2=A0
I started earlier this week = a review of -05. Please find below my comments, I think most if not all of them also apply to -06. I didn't have time to finish my review, but thought to send my comments 'as is' (before -07 is published ;-)). Most of my comm= ents are of type 'editorial nits', no big changes proposed ;-)

Thanks for taking time to take a close= r look.=C2=A0 At this point I'm not going to be making any other change= s unless they are attempts to resolve things that are either major errors (= i.e., they don't reflect the deployed DMARC base or are plainly wrong) = or would cause the IESG's conflict review to return a blocking concern.=

If it does come back from the IESG for more editing, I&#= 39;ll take a run at applying your suggestions.

Thanks aga= in,

-MSK

--001a11c225446cefdd0507b1dfc7-- From nobody Wed Nov 12 16:14:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A558B1A008C for ; Wed, 12 Nov 2014 16:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBVKEIUcKjDe for ; Wed, 12 Nov 2014 16:13:48 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2031A0077 for ; Wed, 12 Nov 2014 16:13:38 -0800 (PST) Received: (qmail 61377 invoked from network); 13 Nov 2014 00:13:36 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 13 Nov 2014 00:13:36 -0000 Date: 13 Nov 2014 00:13:14 -0000 Message-ID: <20141113001314.6944.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ogr7TzbSD1QHmu5-h8zvI4CP2dQ Cc: steve@wordtothewise.com Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 00:13:50 -0000 >>> Could I request the list admins, to drop the subject tagging and the footer on >this list? And if possible remove the removal of the HTML? Every IETF list I subscribe to, which is a lot of them, is set up the same way with subject tags, message footers, and flattened text. There is no more reason to screw up this list due to DMARC breakage than any of the other lists, and I can assure you that the chance that all of the IETF's lists will change rounds to zero, out to perhaps six places past the decimal point. If the IETF's e-mail is important to you, you all know at least six ways to arrange to receive it. R's, John From nobody Wed Nov 12 16:21:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD84C1A00AD for ; Wed, 12 Nov 2014 16:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXLLHIiiac8q for ; Wed, 12 Nov 2014 16:21:34 -0800 (PST) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id F2C2C1A00A3 for ; Wed, 12 Nov 2014 16:21:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 4592FCC134 for ; Wed, 12 Nov 2014 19:21:33 -0500 (EST) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kj1ozklP-qoJ for ; Wed, 12 Nov 2014 19:21:28 -0500 (EST) Received: from [172.18.3.60] (unknown [69.27.252.130]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 32C4FCC125 for ; Wed, 12 Nov 2014 19:21:28 -0500 (EST) Message-ID: <5463F9C0.7080303@meetinghouse.net> Date: Wed, 12 Nov 2014 19:22:24 -0500 From: Miles Fidelman User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 CC: dmarc References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p7vmUsck7ZxCKutxXpnT2OYK3vA Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 00:21:36 -0000 Brett McDowell wrote: > > On Wed, Nov 12, 2014 at 4:36 PM, Matt Simerson > wrote: > > > On Nov 12, 2014, at 12:59 PM, Franck Martin > > wrote: > > > >> Could I request the list admins, to drop the subject tagging and the footer on this list? > And if possible remove the removal of the HTML? > > +1 > > > The mailing list is here as a tool to facilitate communication between > the participants. We have a few (very valuable) participants who are > employed by early adopters of DMARC protection, like Yahoo and > Google. We all know that MLM's configured in traditional ways and > subscribers using domains protected by DMARC, don't mix. That's why > we are here, to try and "fix" this problem (among others). In the > meantime we have to pick between the lesser of two evils. We either > (a) ask subscribers to not use email addresses protected by DMARC > policies or (b) change the default configurations of this mailing list. > > Personally, I don't know which of those two is the least painful > compromise. It is easy for me to use my @gmail.com > account instead of my DMARC-protected @brettmcdowell.com > account. Maybe that's not so easy for > others, I don't know. But if we choose option (a) and that results in > less effective participation from Yahoo! or Google, then (a) would be > the wrong choice IMHO. > One might consider that option (a) provides a continual reminder to those at Yahoo and Google of the reason we really need to address the issue. :-) Miles Fidelman From nobody Wed Nov 12 16:22:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57EC41A009E for ; Wed, 12 Nov 2014 16:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwegQzfcdSi6 for ; Wed, 12 Nov 2014 16:22:16 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 71CFF1A0097 for ; Wed, 12 Nov 2014 16:22:16 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 0C1355645FA; Wed, 12 Nov 2014 18:22:16 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 05A15A0285; Wed, 12 Nov 2014 18:22:16 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PoUV9Ox5SX3; Wed, 12 Nov 2014 18:22:15 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 2B85CA05C7; Wed, 12 Nov 2014 18:22:15 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 2B85CA05C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415838135; bh=i5gpDFzsMCHo6F1AyU9YsAyRMOhG8hc2C1sXwFhIvvo=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Jed8Fduh1r25pIlE6MbipzS9XNLvUTEy500c18CHOGK5AJXSZKHVZMESGudNsQgtd b/rNVsuZHjjmAK6Gr81KFoRG7y4C1uXTS9uNJ74G7iMMp/atb14F8Mq5ANFCn2ujTm bEkWJT1LPyX0nPlL6VMoeow5AuUuZe7v0DUXyfCg= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 09AB3A03BF; Wed, 12 Nov 2014 18:22:15 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id M926ugf5G6AA; Wed, 12 Nov 2014 18:22:14 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id D9143A0285; Wed, 12 Nov 2014 18:22:14 -0600 (CST) Date: Wed, 12 Nov 2014 18:22:14 -0600 (CST) From: Franck Martin To: Steve Atkins Message-ID: <1121573836.78489.1415838134525.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: Indirect email flows Thread-Index: sw2aWyVkuaWMnA/11MzvtbnXxrO50Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vPKZnAKJWE8JO5qP0UUDFxJu-ks Cc: dmarc Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 00:22:18 -0000 ----- Original Message ----- > From: "Steve Atkins" > To: "dmarc" > Sent: Wednesday, November 12, 2014 11:32:12 AM > Subject: Re: [dmarc-ietf] Indirect email flows > > > On Nov 12, 2014, at 12:59 PM, Franck Martin wrote: > > > From: "Brett McDowell" > > To: "Scott Kitterman" > > Cc: "dmarc" > > Sent: Wednesday, November 12, 2014 9:47:58 AM > > Subject: Re: [dmarc-ietf] Indirect email flows > > > > > > On Mon, Nov 10, 2014 at 4:57 PM, Scott Kitterman > > wrote: > > On Monday, November 10, 2014 07:25:56 PM Elizabeth Zwicky wrote: > > > > > being abused for spam. Elizabeth > > > zwicky@yahoo-inc.com > > > > Thanks for the insights. > > > > +1 > > > > Thank you for this analysis. > > > > And, of course, I would have never seen this text if Scott hadn't > > replied-to-all. > > > > Could I request the list admins, to drop the subject tagging and the footer > > on this list? And if possible remove the removal of the HTML? > > -1 > > Let's not damage the functionality of the mailing list to work around a few > subscribers who are violating their employers email usage policies. > I'm just asking for this list to be set up exactly like the ietf@ietf.org list. If Elizabeth ensures she emails in txt only, everything will be fine. From nobody Wed Nov 12 16:34:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DBD1A0171 for ; Wed, 12 Nov 2014 16:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9ukOQW6ZZvb for ; Wed, 12 Nov 2014 16:33:58 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 247821A013B for ; Wed, 12 Nov 2014 16:33:58 -0800 (PST) Received: from dhcp-a558.meeting.ietf.org (dhcp-a558.meeting.ietf.org [31.133.165.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id C3D0DCB46; Wed, 12 Nov 2014 19:33:54 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_918C9B6E-113C-4DB9-AFD5-115128CE0B15" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Tim Draegen In-Reply-To: <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> Date: Wed, 12 Nov 2014 14:33:54 -1000 Message-Id: <8C9AC2B8-A52C-4BC4-B58B-5255FA95423B@eudaemon.net> References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> To: Franck Martin X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/E-Qy_gWKwzmhmXyH_TtBlttDTds Cc: Scott Kitterman , Brett McDowell , dmarc , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 00:34:00 -0000 --Apple-Mail=_918C9B6E-113C-4DB9-AFD5-115128CE0B15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 12, 2014, at 10:59 AM, Franck Martin = wrote: >=20 > Could I request the list admins, to drop the subject tagging and the = footer on this list? And if possible remove the removal of the HTML? No. --Apple-Mail=_918C9B6E-113C-4DB9-AFD5-115128CE0B15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Nov 12, 2014, at 10:59 AM, Franck Martin <franck@peachymango.org> wrote:

Could I request the list = admins, to drop the subject tagging and the footer on this list? And if = possible remove the removal of the = HTML?

No.


= --Apple-Mail=_918C9B6E-113C-4DB9-AFD5-115128CE0B15-- From nobody Wed Nov 12 17:33:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5FE1A0390 for ; Wed, 12 Nov 2014 17:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrpVKqHHoWQ5 for ; Wed, 12 Nov 2014 17:33:37 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363911A008C for ; Wed, 12 Nov 2014 17:33:37 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id l18so182729wgh.0 for ; Wed, 12 Nov 2014 17:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pt3QgrHF+YUDQxquFtHc8XVNMz8NP629TNqkZin/WBo=; b=Pj534xjAa6G1BiLLFhMGUt+Rdofm1UbKg08Zey4MJBvzuXXgCu3L7wbszwJ901rCkM uFlZSaAPRcgrsm+dFGibzM3qwdOEJqCJomjFuckr0nrZdMP4mjhL9BANhjXNW59fxvx6 LfIPV67I3PJ0VtYIRY7a/j2sh1m8YYGFv8eBio2cmmKngv029/qj7He+BL0NutN0hkxp 7yB7wdLeS9UZMrSjdZBx3EGVArqGvaRH0OUW98/XHGBuXcG+VltHzZezyZgeGboAkzNs RcTYldmijsGYz4eNdT1DK+Dh+8nfoizPs2BRuDnwf+avUVnPRu9v2mpGrmIknj6qEZv3 r5BQ== MIME-Version: 1.0 X-Received: by 10.180.126.104 with SMTP id mx8mr4426825wib.21.1415842415963; Wed, 12 Nov 2014 17:33:35 -0800 (PST) Received: by 10.27.76.134 with HTTP; Wed, 12 Nov 2014 17:33:35 -0800 (PST) In-Reply-To: <1121573836.78489.1415838134525.JavaMail.zimbra@peachymango.org> References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> <1121573836.78489.1415838134525.JavaMail.zimbra@peachymango.org> Date: Wed, 12 Nov 2014 15:33:35 -1000 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=e89a8f839ce542f53a0507b3808c Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/YeseRaWH13KF69TcAvoNFf_gU9s Cc: dmarc , Steve Atkins Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 01:33:38 -0000 --e89a8f839ce542f53a0507b3808c Content-Type: text/plain; charset=UTF-8 On Wed, Nov 12, 2014 at 2:22 PM, Franck Martin wrote: > > I'm just asking for this list to be set up exactly like the ietf@ietf.org > list. If Elizabeth ensures she emails in txt only, everything will be fine. > > ietf@ietf.org is the outlier, actually. Every other IETF list that I'm on appears to do subject tagging. -MSK --e89a8f839ce542f53a0507b3808c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 12, 2014 at 2:22 PM, Franck Martin <fr= anck@peachymango.org> wrote:

I'm just asking for this list to be set up exactly like the= ietf@ietf.org list.= If Elizabeth ensures she emails in txt only, everything will be fine.


ietf@ietf.org is the outlier, actual= ly.=C2=A0 Every other IETF list that I'm on appears to do subject taggi= ng.

-MSK
--e89a8f839ce542f53a0507b3808c-- From nobody Wed Nov 12 17:42:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0041D1A19E8 for ; Wed, 12 Nov 2014 17:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M2p5MHo3Iap for ; Wed, 12 Nov 2014 17:42:16 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id CB0C11A19F4 for ; Wed, 12 Nov 2014 17:42:03 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 6ED875644BA; Wed, 12 Nov 2014 19:42:03 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 50C32A044E; Wed, 12 Nov 2014 19:42:03 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1T7bL6l5Uby; Wed, 12 Nov 2014 19:42:03 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0FCEDA058B; Wed, 12 Nov 2014 19:42:03 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 0FCEDA058B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415842923; bh=cEzYTqZuOdhxOqwohQmWu7Gsn0KsnYPnegB6IDkqBRk=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=Ewufx8q4MU+atrDTe7Vm1Aye0In7yBtqsr4VsLVO0b1Y34tDtKFbNBVwhyLEuSxmL s2Xsiz7RFvjMYhe/i1JU58zYGQzkFrdi6h+aeg51u3cA4t8TzkieQokrW/ypZvFBt3 ldQ4BOCiUmWYM+Oj+c2NXUs+31UxM84WbnDznOlA= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E44EAA044E; Wed, 12 Nov 2014 19:42:02 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mTBZ3H393Q7Z; Wed, 12 Nov 2014 19:42:02 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id B06CCA058B; Wed, 12 Nov 2014 19:42:02 -0600 (CST) Date: Wed, 12 Nov 2014 19:42:02 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <122698990.79690.1415842922540.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> <1121573836.78489.1415838134525.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_79689_1933598663.1415842922539" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: Indirect email flows Thread-Index: ANLOGctU89Y8nhj/icd7LE9IdRyqZw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-DS8-c-YscK0-dQbMve-1YaOKLY Cc: dmarc , Steve Atkins Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 01:42:18 -0000 ------=_Part_79689_1933598663.1415842922539 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "dmarc" , "Steve Atkins" > Sent: Wednesday, November 12, 2014 3:33:35 PM > Subject: Re: [dmarc-ietf] Indirect email flows > On Wed, Nov 12, 2014 at 2:22 PM, Franck Martin < franck@peachymango.org > > wrote: > > I'm just asking for this list to be set up exactly like the ietf@ietf.org > > list. If Elizabeth ensures she emails in txt only, everything will be fine. > > ietf@ietf.org is the outlier, actually. Every other IETF list that I'm on > appears to do subject tagging. Ah! times have changed... ------=_Part_79689_1933598663.1415842922539 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Franck Martin" <franck@peachymango.org><= br>Cc: "dmarc" <dmarc@ietf.org>, "Steve Atkins" <steve@word= tothewise.com>
Sent: Wednesday, November 12, 2014 3:33:35 PMSubject: Re: [dmarc-ietf] Indirect email flows

<= div dir=3D"ltr">On Wed, Nov 12, 2014 at 2:22 PM, Franck Martin <franc= k@peachymango.org> wrote:

I'm just asking for this list to be set up exactly like the ietf@ietf.org list. If Elizabet= h ensures she emails in txt only, everything will be fine.

ietf@ietf.org is the outlier, actually.  Eve= ry other IETF list that I'm on appears to do subject tagging.
Ah! times have changed...

------=_Part_79689_1933598663.1415842922539-- From nobody Wed Nov 12 19:02:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157CF1A064C for ; Wed, 12 Nov 2014 19:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epybzvP-fSBI for ; Wed, 12 Nov 2014 19:02:17 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 55D711A0262 for ; Wed, 12 Nov 2014 19:02:17 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id EFA031C3967; Thu, 13 Nov 2014 12:02:15 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CC2501A2844; Thu, 13 Nov 2014 12:02:15 +0900 (JST) From: "Stephen J. Turnbull" To: Brett McDowell In-Reply-To: References: <1508956404.282179.1415647556923.JavaMail.yahoo@jws100211.mail.ne1.yahoo.com> <1615251.R5XluhHgcf@kitterman-optiplex-9020m> <490345222.72324.1415825953450.JavaMail.zimbra@peachymango.org> <9BFBEDD8-814D-4542-A6CE-98CEAE956CE4@wordtothewise.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 13 Nov 2014 12:02:15 +0900 Message-ID: <87fvdnx0p4.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WaVKnelyCvEw9hFm2ODo23fTGos Cc: dmarc , Matt Simerson Subject: Re: [dmarc-ietf] Indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 03:02:19 -0000 Brett McDowell writes: > But if we choose option (a) and that results in less effective > participation from Yahoo! or Google, then (a) would be the wrong > choice IMHO. I'm all in favor of participation from Yahoo! and Google, but catering to the destructive side of DMARC *in advance of IETF standardization* sends exactly the wrong signal. From nobody Fri Nov 14 00:35:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5F71A6F5B for ; Fri, 14 Nov 2014 00:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWjJ5uoaAaLT for ; Fri, 14 Nov 2014 00:35:35 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id BE5531A1A6B for ; Fri, 14 Nov 2014 00:35:35 -0800 (PST) Received: from [10.190.6.92] (unknown [107.14.56.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id D92C4CB46 for ; Fri, 14 Nov 2014 03:35:32 -0500 (EST) From: Tim Draegen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5A71ADCA-0CDF-4F8D-A240-1B0FC8BEE587@eudaemon.net> Date: Thu, 13 Nov 2014 22:35:32 -1000 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/V8AoFHyvtCwxZGHHwBeUOMuszZo Subject: [dmarc-ietf] slides for Friday session X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 08:35:37 -0000 Slides for tomorrow=E2=80=99s session can be found here: http://www.ietf.org/proceedings/91/slides/slides-91-dmarc-0.pdf More information on how to attend can be located from day's = agenda/schedule: http://tools.ietf.org/agenda/91/#FRIDAY =3D- Tim From nobody Fri Nov 14 05:10:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6646B1A00BA for ; Fri, 14 Nov 2014 05:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.998, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpfG_rPvJmLw for ; Fri, 14 Nov 2014 05:10:41 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F201A00C2 for ; Fri, 14 Nov 2014 05:10:41 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id z12so1213069wgg.29 for ; Fri, 14 Nov 2014 05:10: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:content-type; bh=SCadoeyCYgbX+B/1Qf2dE4FbgLU6vsW+M8nnpp/3vWQ=; b=gvDlSTVcEy1VXstulonJ/Q0O0FnNi5kFwCCtHm5lWJLa8B9ngli/hcbcsxbuPLSV7l dCoKI1lBlfozSXdniNe8Vl6k1/aOpD28t+iKMo02dv4N1bhmwHWhtFTL3jvuNUAa2GWi 4NM7YVN+UOUV1egivZ8KgM101ywBEnEqHJeBwZ5Gn+VwCztlOj40XiOzqHEupYjmG0We JCDUvPKjd7iFcs+j7Dbtr+Jy1gj9YE0hdYlrEbHHCCENcY9c8Qmt2yWiRk9H3iA8Swxf 3r8+XuGeZ9UUAOy2QQ65oIFpKdxzrD3Wus4V3WsxPpi7vaapp00Z1psV4d/BZIc9sqz5 JXYg== 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:content-type; bh=SCadoeyCYgbX+B/1Qf2dE4FbgLU6vsW+M8nnpp/3vWQ=; b=NGaintFXe9Do+blNzm49BC1dXQXw50zmu/V9he6Sc3AdmLE+EcaZc0cuG/oTMIYeAC 31fM11PjSgujpBzUiVbHQoaxd5gTFuynG5jWIZx9xcmSzsKOrm206PtkEVqBU4EaoPiM Z9JSLDJIU884s7crw3ezVZCz4ltoePkv7D6F6e6CII9XWVR4mLvlb4SvDzUWlAM37Mnh JhgK1N2zuBBHo7ZlpSCdLo8HjAZAXioiSfvf621KXS12dhVj8JeNLZcoT/sqAbfARD7O ah3hxIsqf2uRjdSi4kPTNwlrob88InU840Azn4tlfvRA4UXN4lK8AXwHdedQnBHCTwkG 7AIg== X-Received: by 10.194.176.100 with SMTP id ch4mr13896945wjc.101.1415970639837; Fri, 14 Nov 2014 05:10:39 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com. [209.85.212.172]) by mx.google.com with ESMTPSA id lm9sm39589106wjc.45.2014.11.14.05.10.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 05:10:38 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id bs8so2642449wib.5 for ; Fri, 14 Nov 2014 05:10:37 -0800 (PST) X-Gm-Message-State: ALoCoQnI5Sc6w5nBUqcRM4mzd5nTQggGNy3qiXBLfNmIByrEhmPT8DtlrWdV6x+cu4xzy6DSHuZc X-Received: by 10.180.206.4 with SMTP id lk4mr7498260wic.47.1415970637483; Fri, 14 Nov 2014 05:10:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.158.7 with HTTP; Fri, 14 Nov 2014 05:09:56 -0800 (PST) In-Reply-To: <5A71ADCA-0CDF-4F8D-A240-1B0FC8BEE587@eudaemon.net> References: <5A71ADCA-0CDF-4F8D-A240-1B0FC8BEE587@eudaemon.net> From: Brett McDowell Date: Fri, 14 Nov 2014 08:09:56 -0500 Message-ID: To: Tim Draegen Content-Type: multipart/alternative; boundary=001a11c382f0dc298d0507d15ac7 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/klsf-5hgWKcjoGizp6pj3iiXeAM Cc: dmarc Subject: Re: [dmarc-ietf] slides for Friday session X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 13:10:49 -0000 --001a11c382f0dc298d0507d15ac7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My first post to this list was to highlight this aspect of our charter [1] because I was concerned it was being overlooked: "It will also provide technical implementation guidance and review possible enhancements elsewhere in the mail handling sequence that could improve DMARC compatibility." Is this exercise within the scope of Milestone 2 [2], i.e. are we going to provide technical guidance elsewhere in the mail handling sequence (e.g. mailing lists) or are we only going to look at changes to dmarc-base [3]? --Brett [1] https://datatracker.ietf.org/wg/dmarc/charter/ [2] http://www.ietf.org/proceedings/91/slides/slides-91-dmarc-0.pdf [3] http://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ On Fri, Nov 14, 2014 at 3:35 AM, Tim Draegen wrote: > Slides for tomorrow=E2=80=99s session can be found here: > > http://www.ietf.org/proceedings/91/slides/slides-91-dmarc-0.pdf > > More information on how to attend can be located from day's > agenda/schedule: > > http://tools.ietf.org/agenda/91/#FRIDAY > > =3D- Tim > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --001a11c382f0dc298d0507d15ac7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My first post to this list was to highlight this aspect of= our charter [1] because I was concerned it was being overlooked:=C2=A0
"It w= ill also provide technical implementation guidance=C2=A0and review possible enhancements else= where in the mail handling=C2=A0sequence that could improve DMARC compatibility."<= /div>

Is this exercise wit= hin the scope of Milestone 2 [2], i.e. are we going to provide technical gu= idance elsewhere in the mail handling sequence (e.g. mailing lists) or are = we only going to look at changes to dmarc-base [3]?


On Fri, Nov 14, 2014 at 3:35 AM, Tim Draegen= <tim@eudaemon.net> wrote:
Slides for tom= orrow=E2=80=99s session can be found here:

=C2=A0 http://www.ietf.org/proceedings/91/slides/slides-= 91-dmarc-0.pdf

More information on how to attend can be located from day's agenda/sche= dule:

=C2=A0 http://tools.ietf.org/agenda/91/#FRIDAY

=3D- Tim

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

--001a11c382f0dc298d0507d15ac7-- From nobody Fri Nov 14 09:42:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B581A1A22 for ; Fri, 14 Nov 2014 09:42:39 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TEjP40YjvvM for ; Fri, 14 Nov 2014 09:42:35 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DFA1A1B3B for ; Fri, 14 Nov 2014 09:42:35 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id hz1so6788292pad.13 for ; Fri, 14 Nov 2014 09:42:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eudev.net; s=s1; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=9ZHJILi0H8Sd2QusJua/0QskSH6AW8xNs0VgZmcNU5k=; b=CvN53R47b3VyUjhWKPBrpG8plKgUTvimwtCMGg5SXtPAr/pguKqsnppPD4PfaMFHaA fEL11wN92yyzOd/KEVCjdtLjJY6o/RLaMVpAWgcENrJP1SjrUOF81zAuT2a8DXeIi5rA q7RwZlS7ilf86NJIBJu+4XcIBgbc89AwB6oAw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=9ZHJILi0H8Sd2QusJua/0QskSH6AW8xNs0VgZmcNU5k=; b=DWkWJi4IYyuxswgRRxi9ZCBiVXWGqe3JILnLMOORZWXFbMBvkvIySyY7Hc9Tsv/9Lx Po1RtzfFbLnjAuX4+SRj+t+lvoJRKzWg+PeP0rxldiMe0rQFTgCiA1qykY/qrmZPcZMF 05UOe1KtQSbrqw73FZBMFC8Ie9Aeq+/eisxHCHSmUC6DK0TxVKJECHNDz6gsVr+kTFBI 1YUKJ4IEC/bcBfm8l9t2w5JMCRf2r/M6Q1d7sO5/jKKFC+fKR5XeqyZ/SYEVfgl1rfDF RCXjMGmzns+7DzS7k9BCZEvSVL+wOn2R3/8XYAT05b88GTQVSeUdofFvpTWjmiHD+Gxp mLJQ== X-Gm-Message-State: ALoCoQkUliFRD5cV1HYlV2P5Sh3IEcacoQAoA8yRhJXPzfx+YuZnFGTS2Byw6vr0aG3GXJjrxSr4 X-Received: by 10.70.94.168 with SMTP id dd8mr11580867pdb.76.1415986954712; Fri, 14 Nov 2014 09:42:34 -0800 (PST) Received: from ?IPv6:2600:100f:b12f:44a6:8c7e:fb05:6fac:937c? ([2600:100f:b12f:44a6:8c7e:fb05:6fac:937c]) by mx.google.com with ESMTPSA id fs7sm2465304pdb.27.2014.11.14.09.42.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 09:42:33 -0800 (PST) References: <5A71ADCA-0CDF-4F8D-A240-1B0FC8BEE587@eudaemon.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-F0E09269-A404-43EC-B534-8AB1CB133146 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (12B411) From: Tim Draegen Date: Fri, 14 Nov 2014 07:42:30 -1000 To: Brett McDowell Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3bM44XJoU1BRJMLB1rj3-xgLszk Cc: dmarc , Tim Draegen Subject: Re: [dmarc-ietf] slides for Friday session X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:42:40 -0000 --Apple-Mail-F0E09269-A404-43EC-B534-8AB1CB133146 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Nov 14, 2014, at 3:09 AM, Brett McDowell wrot= e: >=20 > "It will also provide technical implementation guidance and review possibl= e enhancements elsewhere in the mail handling sequence that could improve DM= ARC compatibility." >=20 > Is this exercise within the scope of Milestone 2 [2], i.e. are we going to= provide technical guidance elsewhere in the mail handling sequence (e.g. ma= iling lists) Hi Brett, yes, this is exactly what milestone 2 concerns. > or are we only going to look at changes to dmarc-base [3]? Focus on changes to the base spec comes later.= --Apple-Mail-F0E09269-A404-43EC-B534-8AB1CB133146 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Nov 14, 2014, at 3:0= 9 AM, Brett McDowell <brettmcd= owell@gmail.com> wrote:

"= It will also provide technic= al implementation guidance and review possible enhancements elsewhere in the mail handling&n= bsp;sequence that cou= ld improve DMARC compatibility."

Is this exercise within the scope of Milestone 2 [2], i.e. a= re we going to provide technical guidance elsewhere in the mail handling seq= uence (e.g. mailing lists)

Hi Brett, yes, this is= exactly what milestone 2 concerns.

or are we only going= to look at changes to dmarc-base [3]?

Focus on changes to the base spec comes later.=
= --Apple-Mail-F0E09269-A404-43EC-B534-8AB1CB133146-- From nobody Fri Nov 14 09:50:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0463D1A1B3C for ; Fri, 14 Nov 2014 09:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsJdmgHTt2OF for ; Fri, 14 Nov 2014 09:50:04 -0800 (PST) Received: from c1smtp1.constantcontact.com (c1smtp1.constantcontact.com [205.207.104.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACFE1A1B2A for ; Fri, 14 Nov 2014 09:50:04 -0800 (PST) X-AuditID: c0a8fecc-f79dc6d0000040a6-77-546640cb471f Received: from c1smtp1.constantcontact.com (c1-exhts02.roving.com [192.168.254.229]) by c1smtp1.constantcontact.com (Symantec Messaging Gateway) with SMTP id 5D.EE.16550.BC046645; Fri, 14 Nov 2014 12:50:03 -0500 (EST) Received: from C1-EXMBX01.roving.com ([fe80::89ae:e69e:eff3:2fcf]) by C1-EXHTS02.roving.com ([::1]) with mapi id 14.03.0174.001; Fri, 14 Nov 2014 12:50:03 -0500 From: "Silberman, Sam" To: "dmarc@ietf.org" Thread-Topic: Indirect Mail Flows Thread-Index: AQHQADNqn6JIggman0qNprdzMbCsUw== Date: Fri, 14 Nov 2014 17:50:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [192.168.216.62] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsVyYMW/p7qnHdJCDPZOUbZYcmgtowOjx5Il P5kCGKO4bFJSczLLUov07RK4Mjrvn2YvmCFY8fPFFLYGxnu8XYycHBICJhLX9i9ihrDFJC7c W8/WxcjFISRwm1HiUPtVVpCEkMASRonbt2JAbDYBc4n5L84wgdgiAqoSJ6a1MILYwgIyEufb JrBBxBUl+n5eZ4Ww9SRen2oFq2cBqp/XtRvM5hWwltjd8oAFxGYEWvz91BqwOLOAuMStJ/OZ IA4SkFiy5zzUcaISLx//A5spCjRzcscRdoi4kkRPbw87RK+OxILdn9ggbCeJt2+eskDY2hLL Fr5mhtgrKHFy5hOWCYyis5Csm4WkfRaS9llI2mchaV/AyLqKUTjZULc4N73cUK8ovywzL10v OT93EyMkTs7sYLxwzPIQIxMHp1QD4z7OtL6zM1y/x9RYHZdaFeXorfRyR4D2DSHvyzVBra8U 9iTMqlyccK3EXkrrbGn0tGMCRgbO3Q4fVEpUk7im/41isy86lbbQ98H/h9mPEr4qHlx9tirz z7an55f2dCyUybb9US7AZrZiyfkd93Lq7aa/fmA6v/w475WDT+Q1VCdMnsL5U7XMUImlOCPR UIu5qDgRAKNPAW9DAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QwcvsgkVDFmGK3Y8mT-dYgh09M0 Subject: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 17:50:07 -0000 In anticipation of today's DMARC WG meeting, I want to highlight one of the many important use cases. Specifically: =09 Use of "unrelated" outbound SMTP servers Commercial email using free email address Newspaper Sites Reference wiki: =20 https://tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki Past discussion around these use cases assume the email author has control of the domain they send email from. While it may be true for the world's digital elite (i.e. us), it's not true for everyone. There are billion(s) of people who use "free" or very low cost hosting services to provide email. For many people, switching email providers is hard (or not an option). If their mail bounces, they simply don't have the context to decipher the difference between "mailbox non-existent" and "DMARC policy reject due to non-alignment" Most of the world does not have control over their sending domain. Previous posts have suggested this is a small problem. I respectfully disagree. We need to be focusing on # of users impacted, not percentage of mail bounced. Take the following example: My local PTO (Parent Teacher Organization). They are a volunteer non-profit. They have no time or expertise to deal with technical things like email setup. They can't ask the local school board for email mailbox (local policy, bureaucracy , etc). They have no $$, so they use a free mail service ( pto@dmarc-protected-mailservice.com) When their mail provider switched to p=3Dreject They no longer can email some parents directly who used forwards They no longer can reliably send emails via a 3rd party service provider (ESP) They no longer can reliably send update to community mailing list servers IMO, this is not the 1% use case. It's bigger, much bigger. I don't claim to have all the answers. Telling user like this one to change mail providers solves nothing in the long term.=20 DKIM Forward signatures do have promise and solves some of the issues I've listed above. Ultimately, solving DMARC indirect flows for this user will get us very close to solving indirect flows over the rest of the world. -Sam From nobody Fri Nov 14 10:04:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4356D1A1B56 for ; Fri, 14 Nov 2014 10:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.953 X-Spam-Level: X-Spam-Status: No, score=-0.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TThzTnBoMoIq for ; Fri, 14 Nov 2014 10:04:42 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 36D841A1B44 for ; Fri, 14 Nov 2014 10:04:42 -0800 (PST) Received: from dhcp-a558.meeting.ietf.org (dhcp-a558.meeting.ietf.org [31.133.165.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 8FCE0CB46 for ; Fri, 14 Nov 2014 13:04:39 -0500 (EST) From: Tim Draegen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5A71ADCA-0CDF-4F8D-A240-1B0FC8BEE587@eudaemon.net> Date: Thu, 13 Nov 2014 22:35:32 -1000 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/V8AoFHyvtCwxZGHHwBeUOMuszZo Subject: [dmarc-ietf] slides for Friday session X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 18:04:44 -0000 Slides for tomorrow=E2=80=99s session can be found here: http://www.ietf.org/proceedings/91/slides/slides-91-dmarc-0.pdf More information on how to attend can be located from day's = agenda/schedule: http://tools.ietf.org/agenda/91/#FRIDAY =3D- Tim From nobody Fri Nov 14 11:50:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29FA1A9040 for ; Fri, 14 Nov 2014 11:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pckahm3y5pB6 for ; Fri, 14 Nov 2014 11:50:09 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B00871A9044 for ; Fri, 14 Nov 2014 11:50:08 -0800 (PST) Received: (qmail 94500 invoked from network); 14 Nov 2014 19:50:07 -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=17123.54665cef.k1411; bh=Ymv/PXTY5ndjDSnDASP69lWFW6qpqGMwdSmMYGI6d/0=; b=jLA78EofG0NaSXdxHP3S594pdcpFO1yl4/7P0kXsd4gTjGRBmwax6AsVwEtNw69UaHRYkDI5Sv4GIDHFvYqNZYxEwAi4KkvLO9F4gCbXtJrpNJ2L01kX8nFu/WI8/vS97ZTQmHjwnzfWzzDiXkg0Ov1pTJ2nfNpRF4E6TJW3l6OQBffaopNXKlRAV6TxRtKyyUHfnwXoRr1xhDI91ZanZKf60OAS6KeS+DsrO/SqBuv8Z12bCWXj/DXgjgzB/I/Y 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=17123.54665cef.k1411; bh=Ymv/PXTY5ndjDSnDASP69lWFW6qpqGMwdSmMYGI6d/0=; b=WPgx6CtdJmlsYPvPDokDbS8NaEg62XbfTgoMv0wmC5I2A43hVuilZIAEN3uRLUYL/r6cIjfBuLE2/7vsyhRB57ty7XcyxnKLCOxs62lRshdreD1ggRmMMw87dQmJFYypx1ft+w2f2heT+TglXNX/FXwEBMFecEFBzTOsBeJhGHd2EoK7tDaXTaPhApTOax7n66RtSfYSNac11Eb+j7l8H/ydTqG70H8ONvbkfoZ6OgVDCMAMC5GhuaUVu6vHJCLI 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 2014 19:50:07 -0000 Date: 14 Nov 2014 09:50:05 -1000 Message-ID: From: "John R Levine" To: dmarc@ietf.org User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_tB4PNZZZwdmmAw57ZZXk3t0xAQ Subject: [dmarc-ietf] editor for issues draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 19:50:10 -0000 I'll stick my oar in. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Nov 14 11:50:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056FE1A9046 for ; Fri, 14 Nov 2014 11:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 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=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3vznosPkXww for ; Fri, 14 Nov 2014 11:50:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581AC1A904D for ; Fri, 14 Nov 2014 11:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=954; q=dns/txt; s=iport; t=1415994630; x=1417204230; h=message-id:date:from:mime-version:to:subject; bh=Z0wxVHxdU6Fv2i+vinNTY8P6kvcCASkcu5DUNVzOgZc=; b=mTwUjKPp8KoZNjIkE9hkyBygRKCOXuudSst9I1dh4akEsZ0l4lu/6teS WGmH3qHfkJy9YWfoToXudv28C2BE0rYa04MfgNAIMMfXJf8O+o5Edk7qY 21RduQyiVKl5tmRkhyplAirioDilYh7nfOFwFQa5D/5D+F8ZgexhrFxh+ A=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADtcZlStJV2a/2dsb2JhbABbgw6ENIphyAsWAQEBAQFyC4QiClU9FgsCCwMCAQIBSw0IAQGIPawRj0uWMwEBAQcCAR+QQBEBg06BVAWUY4FUiBWIA453hCAZgT+BPAEBAQ X-IronPort-AV: E=Sophos;i="5.07,387,1413244800"; d="asc'?scan'208";a="372312056" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 14 Nov 2014 19:50:29 +0000 Received: from [10.21.118.191] ([10.21.118.191]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAEJoTCd015475 for ; Fri, 14 Nov 2014 19:50:29 GMT Message-ID: <54665D0E.8060103@cisco.com> Date: Fri, 14 Nov 2014 09:50:38 -1000 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmarc@ietf.org" Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ho2KJfEGFc7B46tPtBbdfV6IGIBSJN2J5" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WW7rbF51xw4wF9wRtjBGxi5ta9w Subject: [dmarc-ietf] happy to help on editing team on indirect email flows.. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 19:50:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ho2KJfEGFc7B46tPtBbdfV6IGIBSJN2J5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Eliot --ho2KJfEGFc7B46tPtBbdfV6IGIBSJN2J5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUZl0OAAoJEIe2a0bZ0nozA+QIANvpUqkscwT87Fnj7AGZY0kz 9Gm42Ot3Zxt+UCSaIPyeZOAa85F2/ZD/4D7tCXTgj5vucNp38XJIE9N9AEcnrzK+ Ha6pgpE52vzYI7Md0EwrzIFDZ1LKSmCYWgl6kxg7gZSDdwMFvqSXmRAVcR0oQehg j8JuOgNN7OYJpZxCBj53dwmXayecIImPYgGbVUkzWOvc5DxO0V4aMxBy4GcvLxQV cMeJyoseLYwgKXPZ5FEy1BSEJU8/jZGQY+sBZFC/HZ5K724hLwgSaJmVxKN9y5E+ sggH55/44u19Me9sdDh07YPDIiuRMm2Be1CnHrGcp1X+yx/RksWqu5deModVkew= =k4Fx -----END PGP SIGNATURE----- --ho2KJfEGFc7B46tPtBbdfV6IGIBSJN2J5-- From nobody Fri Nov 14 11:51:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16F11A903C for ; Fri, 14 Nov 2014 11:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC2ZZXsHCnqU for ; Fri, 14 Nov 2014 11:51:04 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6549B1A8AFC for ; Fri, 14 Nov 2014 11:50:59 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id B79AD564EC3 for ; Fri, 14 Nov 2014 13:50:58 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B2858A04BC for ; Fri, 14 Nov 2014 13:50:58 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GI8NNjz71svL for ; Fri, 14 Nov 2014 13:50:58 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D7C9BA04B3 for ; Fri, 14 Nov 2014 13:50:54 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com D7C9BA04B3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1415994655; bh=HkIS2fbKs1eGY6xpdZucpJQ4c0n3iWbIXyMb41UHleY=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=kniiCBuhIauc0yc2zub2EMHLX+nYZpTSTCuB17aZcv/MasxXnmtGToVlkE0nC26g1 C5akYW32EfiMYZ/oEIlb9bcgVdNY3X03nT+rVIM1rmuhPiAEhCZDjQ6sor+I9scnAU 0PhGceq4IzcbY0izM/fIKsuRuJjYX1eToUWt2z08= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id AAD70A0477 for ; Fri, 14 Nov 2014 13:50:54 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4pUB1lXjJltL for ; Fri, 14 Nov 2014 13:50:54 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 7DC8DA04B3 for ; Fri, 14 Nov 2014 13:50:54 -0600 (CST) Date: Fri, 14 Nov 2014 13:50:54 -0600 (CST) From: Franck Martin To: dmarc Message-ID: <80375717.117855.1415994654338.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_117854_1051577961.1415994654338" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: Volunteering to write the next draft Thread-Index: xSU1qMeCFlMpTvs0POAwTQQILaVA0Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LN82nf6qij9LBqibCpGbvSm29Mo Subject: [dmarc-ietf] Volunteering to write the next draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 19:51:07 -0000 ------=_Part_117854_1051577961.1415994654338 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit As requested by chair during mail ------=_Part_117854_1051577961.1415994654338 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
As requested by chair during mail
------=_Part_117854_1051577961.1415994654338-- From nobody Fri Nov 14 11:58:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99E21A9068 for ; Fri, 14 Nov 2014 11:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IRlFp7BQIaZ for ; Fri, 14 Nov 2014 11:58:03 -0800 (PST) Received: from c1smtp1.constantcontact.com (c1smtp1.constantcontact.com [205.207.104.61]) by ietfa.amsl.com (Postfix) with ESMTP id 40A401A9096 for ; Fri, 14 Nov 2014 11:58:03 -0800 (PST) X-AuditID: c0a8fecc-f79dc6d0000040a6-4c-54665ecab01a Received: from c1smtp1.constantcontact.com (c1-exhts01.roving.com [192.168.254.228]) by c1smtp1.constantcontact.com (Symantec Messaging Gateway) with SMTP id 4C.D4.16550.ACE56645; Fri, 14 Nov 2014 14:58:02 -0500 (EST) Received: from C1-EXMBX01.roving.com ([fe80::89ae:e69e:eff3:2fcf]) by C1-EXHTS01.roving.com ([::1]) with mapi id 14.03.0174.001; Fri, 14 Nov 2014 14:58:01 -0500 From: "Silberman, Sam" To: "dmarc@ietf.org" Thread-Topic: Also happy to help on editing team on indirect email flows.. Thread-Index: AQHQAEVLS1BM429Gr0m5dkJQu0Ec4A== Date: Fri, 14 Nov 2014 19:58:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [192.168.216.62] Content-Type: text/plain; charset="us-ascii" Content-ID: <82A044730D08BF44BE42C5BFA84C982E@constantcontact.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLLMWRmVeSWpSXmKPExsVyYMW/J7qn4tJCDB4d1rVYcmgtowOjx5Il P5kCGKO4bFJSczLLUov07RK4Mk6seMhYwFFx5VkrawMjSxcjB4eEgInElx0iXYycQKaYxIV7 69lAbCGB24wSF074dTFyAdlLGCUaPrxhBkmwCZhLzH9xhgnEFhFQlTgxrYURxBYWcJU4On0n I0TcS+LHyRYoW09i84s3YPUsQPWrv/0Fi/MKWEsc7/0EtowRaPH3U2vAapgFxCVuPZnPBHGQ gMSSPeeZIWxRiZeP/7GC2KJAMyd3HGGHiCtJ9PT2sEP06kgs2A0xk1nASWLFwV+sELa2xLKF r5kh9gpKnJz5hGUCo+gsJOtmIWmfhaR9FpL2WUjaFzCyrmIUTjbULc5NLzfUK8ovy8xL10vO z93ECImQMzsYLxyzPMTIxMEp1cB4MHB9n1l88M/fj1dum2e1nHstz9wTlbcP3wvryOhcpP17 GaPxXq/UN2/crk+8myOntaBB3zb9mL3I2n/qW08+Xhi/67zglalyOvPkGL9mtHM7ZCV2xbHE M4Vuqt36lU1dIPHorc6p0n9upbtbcj1we8g308l7286raXoPNCRyBL2vSs25JdikxFKckWio xVxUnAgAgZH5EUACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/khPPBpQ2JnB-cC4xI5w9v8AC5cw Subject: [dmarc-ietf] Also happy to help on editing team on indirect email flows.. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 19:58:05 -0000 -Sam From nobody Fri Nov 14 12:01:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAB51A90D4 for ; Fri, 14 Nov 2014 12:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-P2QbeuMiDt for ; Fri, 14 Nov 2014 12:01:20 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 765C91A90AA for ; Fri, 14 Nov 2014 12:01:00 -0800 (PST) Received: from grover.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 1F1D980D00 for ; Fri, 14 Nov 2014 12:01:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1415995260; bh=Sx+gsGYGwYp1O60Yw0FqOdlezOX+I19+s92SJnPDvFM=; h=From:Subject:Date:To:From; b=PFjKdsbi9BWofVzrI2B8Nu6sKYkmhs6ArV5AKBMHrJAB/8+u8+ahEVoZD4BM1B6E/ l2WWhGHCY0W4g3Ppiz1PIOEwos4Df8WuaJA1rJqgnRWCsXtGXw1PK/SERGzlKapISF YrDtMKRHplos5wTfgpj1kd7VEmqUtyFQtsN5b8ik= From: Laura Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <4A0D2D47-A1C8-4030-A625-613F129E3C86@wordtothewise.com> Date: Fri, 14 Nov 2014 12:00:58 -0800 To: dmarc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GNhv4r6EpIXVuA_nqstga7V4OW0 Subject: [dmarc-ietf] Volunteering for indirect email flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 20:01:23 -0000 I'm happy to contribute laura -- Laura Atkins Word to the Wise "The Deliverability Experts!" Direct: 650 678-3454 Fax: 650 249-1909 @wise_laura Delivery blog: From nobody Fri Nov 14 12:23:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF1551ABD3E for ; Fri, 14 Nov 2014 12:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aisfOnvDrLxh for ; Fri, 14 Nov 2014 12:23:06 -0800 (PST) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:a60:f0b4:e503:2cdb:beff:feaa:880b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491041AC3A7 for ; Fri, 14 Nov 2014 12:22:54 -0800 (PST) Received: from horde.andreasschulze.de (horde.andreasschulze.de [IPv6:2001:a60:f0b4:e503:e49d:e7ff:fea2:4010]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3jfWMD3bh5zDfk; Fri, 14 Nov 2014 21:22:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=J4bWGJQcBmxMQ; t=1415996570; bh=13TmVZ39KwGAqdBBNA07Mb6j5OAHho8RcOvcAc5IdoE=; h=Date:From:To:Subject; b=Lk0QzU0Zx6pvPvpcGLOrJBFy4cB1jo9HVzn5BI2d6HXllGe73du6NmH7Moe/K9xkJ jRr9zJWK29IgwUngPoGES1FVgO6pgFEqfnyic/IGcLbvIJq/72pbWSKsXrA4wAeUJA HjoYx2zsILVusDcL6foT0eCVqMNQ2JkuJLMkOHzMb1reO4FhYzu3x7Tzyj4JXtsCTA N1hunx4GkR4l9rQhr1eyzEkWKvqEIlDWWlDqUVHfTz5sVTo/dpbprCoXKNdGNac0DY cSCXXzPZNvTRLoTuTFRZJrcaBs48VHLq+FNfDpVS+SY2BE7TQH4FserZmnpTnN2mEL M9md/C+dHadis8BuOM+RZmD5eA3u09dirfMed09biDviqvAyC+eTEQKzv18QqVQdOi 0NNn2DdPzYfKsQqRMjA7eTnQkaUlxI/U80sH4HRekn+ud1CAjRAJ/BDt7Zm9S6xgGj pvgCEJlHD4jJ+KAM2m90NcMOFGOGaFVRx10JMFqKqxC+1YuEdxY0odt+acSz8MVQ1b yZ8L4/tqQOcQ88Oj0tXajOGO5wjNZo4PkY1I0O/Wgp0rAXf9N/R1TDx+OXhbsXo6JX C13nAlp2mB6KivZcbjs1QX1RLFh7sFicWgVh8w6pqWZlSVXD+6vZ/9F1HviKhVdf6m Blk/uh5YXXrGq6BKHFvcjJlg= Received: from solar.andreasschulze.de (solar.andreasschulze.de [2001:a60:f0b4:e502::51]) by horde.andreasschulze.de (Horde Framework) with HTTP; Fri, 14 Nov 2014 21:22:45 +0100 Date: Fri, 14 Nov 2014 21:22:45 +0100 Message-ID: <20141114212245.Horde.gc55x6hUl4jYbYfI3C7NMQ1@horde.andreasschulze.de> From: "A. Schulze" To: dmarc , dmarc-discuss@dmarc.org User-Agent: Internet Messaging Program (IMP) H5 (6.2.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jOmi0oF-__pkrBsL9UjPhVvZhTo Subject: [dmarc-ietf] service for the dark side? aggregated reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 20:23:08 -0000 Hi, like just mentioned in jabber I like to know if and how you handle the situation where inbound message should be reported back to the sender while the sender is clearly not a good guy. Franck martin suggest to not send every dmarc report by - blacklisting - report volume other suggestions? franck also asked if these aggregate reports are really valuable for spammers. I'm not sure about yes or no. currently I generate (but am not allowed to send) reports for ~700 domains every day. 10 ...30 are for domains in my blocklists. Andreas From nobody Fri Nov 14 13:52:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6272F1A88D0 for ; Fri, 14 Nov 2014 13:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi7JK_6LMVDG for ; Fri, 14 Nov 2014 13:52:01 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B64A1A8716 for ; Fri, 14 Nov 2014 13:52:01 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id le20so2707159vcb.40 for ; Fri, 14 Nov 2014 13:52:00 -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:content-type; bh=0VHMRGlV8fQddLiu6BZmrrIRjQCtutDW0XM4BUZjn0M=; b=o8D5dhtI74PQTT9DwEf1xxlx1Mpi3Ze6GOYUQKGuKTRMheqRCiDfSnK62V9+WmIlav zFiNElrPGtlNG+l8rn5Gh+EwLxdGR0Jx8u2yomJkJLPIIvhH36RYABi2oUiw6+PWZLUH DVfjaddic9y+3F6JQVWR0Z4Wibn5Zq65SH7bPm48PrNEWFIgOhtJ7L18o+NBKTKefO5a hzDpWVm9EjvlzXNyNI2kDw4Dgyqhu4117N42mIjwKfJunUcfdE4kV5CCQltWwBf+2Sjs BQqqik/ABNaKhi8a/bJCxtgSJxtHw9ffC8Y1Km3pJHmpwIsOcTTCLQ/89AAS2xpGh7n8 6kBQ== X-Received: by 10.52.118.8 with SMTP id ki8mr305657vdb.85.1416001920206; Fri, 14 Nov 2014 13:52:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.1.210 with HTTP; Fri, 14 Nov 2014 13:51:39 -0800 (PST) In-Reply-To: <20141114212245.Horde.gc55x6hUl4jYbYfI3C7NMQ1@horde.andreasschulze.de> References: <20141114212245.Horde.gc55x6hUl4jYbYfI3C7NMQ1@horde.andreasschulze.de> From: Todd Herr Date: Fri, 14 Nov 2014 16:51:39 -0500 Message-ID: To: "A. Schulze" Content-Type: multipart/alternative; boundary=089e01229b18748ff80507d8a3b6 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CbpKrN09GKinm_nRSdbPtUIrBbg Cc: dmarc , "" Subject: Re: [dmarc-ietf] service for the dark side? aggregated reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 21:52:03 -0000 --089e01229b18748ff80507d8a3b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 14, 2014 at 3:22 PM, A. Schulze wrote: > like just mentioned in jabber I like to know if and how you handle the > situation > where inbound message should be reported back to the sender > while the sender is clearly not a good guy. > =E2=80=8BI'm not sure I understand why it might be a problem to send aggreg= ate reports to domains you're already blocking; to the contrary, there might be value in doing so, at least from an "enemy of my enemy" standpoint. If I understand the scenario correctly, there exists one or more domains that you're refusing mail from, domains which also publish DMARC policies. For the purposes of this discussion, we'll focus on just one such domain, wesellstuff.com. Whether or not you care for a given domain's sending practices, it still has a right to its identity and brand, assuming it's legally registered by whatever definition of "legally registered" is applicable. It might even be a legitimate business, albeit one with bad email sending practices. You're refusing mail from the domain wesellstuff.com, and they probably already know that (or should) so your aggregate reports won't tell them anything they don't already know (assuming that the rejection happens deep enough into the SMTP transaction that you can generate reports about it). At the same time, Criminals R Us is sending mail that is attempting to use wesellstuff.com's brand, but this mail either does or does not pass DMARC checks; either way, you're reporting the stats to wesellstuff.com. These reports might give wesellstuff.com enough information to try to take action to get this illegitimate mail stopped, which would be a win for you, as a provider who doesn't want mail from either entity. I guess I could see aggregate reports as a way for a bad guy to test the waters and see what stuff of his is getting through and what's not, but I'm not sure that there's any gain there, when you think about the cost of setting up an infrastructure to process DMARC reports; bounces or "250 ok" is a much more immediate feedback mechanism than aggregate reports that might be delayed by up to 24 hours. It seems to me that the relative anonymity of not publishing DMARC would be a better way to maximize (at least in the short term) one's ability to send a ton of crap. If they think DMARC is the answer to getting their mail accepted, probably the easiest path there is just publish an SPF record of "+all" and don't worry about DKIM signing anything. What am I missing here?=E2=80=8B --=20 Todd --089e01229b18748ff80507d8a3b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 14, 2014 at 3:22 PM, A. Schulze <sca@andreasschulze.de> wrote:
like just mentioned in jabber I like to know if and ho= w you handle the situation
where inbound message should be reported back to the sender
while the sender is clearly not a good guy.

=E2=80=8BI'm not sure I understand why it might be a problem to = send aggregate reports to domains you're already blocking; to the contr= ary, there might be value in doing so, at least from an "enemy of my e= nemy" standpoint.

If I understand the scenario correctly, there exi= sts one or more domains that you're refusing mail from, domains which a= lso publish DMARC policies. For the purposes of this discussion, we'll = focus on just one such domain, wesellstu= ff.com.

Whether or not you care for a given domain's sending pra= ctices, it still has a right to its identity and brand, assuming it's l= egally registered by whatever definition of "legally registered" = is applicable. It might even be a legitimate business, albeit one with bad = email sending practices.

You're refusing mail from the domain wesellstuff.com, and they probably already= know that (or should) so your aggregate reports won't tell them anythi= ng they don't already know (assuming that the rejection happens deep en= ough into the SMTP transaction that you can generate reports about it).

=
= At the same time, Criminals R Us is sending mail that is attempting to use = wesellstuff.com's brand, but thi= s mail either does or does not pass DMARC checks; either way, you're re= porting the stats to wesellstuff.com= . These reports might give wesellstuff.c= om enough information to try to take action to get this illegitimate ma= il stopped, which would be a win for you, as a provider who doesn't wan= t mail from either entity.

I guess I could see aggregate reports as a wa= y for a bad guy to test the waters and see what stuff of his is getting thr= ough and what's not, but I'm not sure that there's any gain the= re, when you think about the cost of setting up an infrastructure to proces= s DMARC reports; bounces or "250 ok" is a much more immediate fee= dback mechanism than aggregate reports that might be delayed by up to 24 ho= urs.=C2=A0 It seems to me that the relative anonymity of not publishing DMA= RC would be a better way to maximize (at least in the short term) one's= ability to send a ton of crap. If they think DMARC is the answer to gettin= g their mail accepted, probably the easiest path there is just publish an S= PF record of "+all" and don't worry about DKIM signing anythi= ng.

What am I missing here?=E2=80=8B

--
Todd

--089e01229b18748ff80507d8a3b6-- From nobody Fri Nov 14 14:23:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A181D1ACFEE for ; Fri, 14 Nov 2014 14:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 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=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3smDy8K-FiOr for ; Fri, 14 Nov 2014 14:23:34 -0800 (PST) Received: from mail.wordtothewise.com (mail.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9A51ACFD5 for ; Fri, 14 Nov 2014 14:23:34 -0800 (PST) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id A71AB80CFE for ; Fri, 14 Nov 2014 14:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1416003813; bh=zTFEOdHyNyTMb3dRG10IYV3SNzB4rRVVxBb7uDImK68=; h=Subject:From:In-Reply-To:Date:References:To:From; b=dUNApixNC9follqDjoqsxOx9rjS/aWwPcUwjPHguhg2nQOVBBghV0/c95Sk1olx81 sCiVv8+HXmeM8yqXXrLgG94tINvU4hCOALjxb+/jOJRCdIxxgumLJakT3LpSnFb5vJ HCwxerIi1lXaEqDP8uATjWOOsV9XiMLmU6XCwtuA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Steve Atkins In-Reply-To: Date: Fri, 14 Nov 2014 14:23:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <15CF2452-7C9B-40B4-ADB1-262581347332@wordtothewise.com> References: <20141114212245.Horde.gc55x6hUl4jYbYfI3C7NMQ1@horde.andreasschulze.de> To: dmarc X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BFMSps5x_jGrGALbpeP5aY7L1-w Subject: Re: [dmarc-ietf] service for the dark side? aggregated reports X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:23:36 -0000 On Nov 14, 2014, at 1:51 PM, Todd Herr wrote: >=20 > On Fri, Nov 14, 2014 at 3:22 PM, A. Schulze = wrote: > like just mentioned in jabber I like to know if and how you handle the = situation > where inbound message should be reported back to the sender > while the sender is clearly not a good guy. >=20 > =E2=80=8BI'm not sure I understand why it might be a problem to send = aggregate reports to domains you're already blocking; to the contrary, = there might be value in doing so, at least from an "enemy of my enemy" = standpoint. >=20 > If I understand the scenario correctly, there exists one or more = domains that you're refusing mail from, domains which also publish DMARC = policies. For the purposes of this discussion, we'll focus on just one = such domain, wesellstuff.com. >=20 > Whether or not you care for a given domain's sending practices, it = still has a right to its identity and brand, assuming it's legally = registered by whatever definition of "legally registered" is applicable. = It might even be a legitimate business, albeit one with bad email = sending practices. >=20 > You're refusing mail from the domain wesellstuff.com, and they = probably already know that (or should) so your aggregate reports won't = tell them anything they don't already know (assuming that the rejection = happens deep enough into the SMTP transaction that you can generate = reports about it). >=20 > At the same time, Criminals R Us is sending mail that is attempting to = use wesellstuff.com's brand, but this mail either does or does not pass = DMARC checks; either way, you're reporting the stats to wesellstuff.com. = These reports might give wesellstuff.com enough information to try to = take action to get this illegitimate mail stopped, which would be a win = for you, as a provider who doesn't want mail from either entity. If "good" and "bad" are complaint driven it's also possible that the = blocking of wesellstuff.com is (partially) due to the forgery of their = name / brand / content by Criminals R Us. If so, then providing that = information to them will help them understand why they're being blocked = and allow them to do something about it (benefiting both them and your = customers). It's not entirely theoretical - I've seen a somewhat annoying but not = actually evil daily mailer blocked because there were a bunch of people = imitating their content, and the overall volume of fake and real content = together drove up complaint rates. > I guess I could see aggregate reports as a way for a bad guy to test = the waters and see what stuff of his is getting through and what's not, = but I'm not sure that there's any gain there, when you think about the = cost of setting up an infrastructure to process DMARC reports; bounces = or "250 ok" is a much more immediate feedback mechanism than aggregate = reports that might be delayed by up to 24 hours. It seems to me that = the relative anonymity of not publishing DMARC would be a better way to = maximize (at least in the short term) one's ability to send a ton of = crap. If they think DMARC is the answer to getting their mail accepted, = probably the easiest path there is just publish an SPF record of "+all" = and don't worry about DKIM signing anything. >=20 > What am I missing here?=E2=80=8B Cheers, Steve= From nobody Fri Nov 14 22:55:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414E51A1B0C for ; Fri, 14 Nov 2014 22:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.909 X-Spam-Level: *** X-Spam-Status: No, score=3.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRyi5UvZjNoZ for ; Fri, 14 Nov 2014 22:55:51 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 696671A1B0D for ; Fri, 14 Nov 2014 22:55:50 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E68161C39CE; Sat, 15 Nov 2014 15:55:49 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C01101A2844; Sat, 15 Nov 2014 15:55:49 +0900 (JST) From: "Stephen J. Turnbull" To: "Silberman, Sam" In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 15 Nov 2014 15:55:49 +0900 Message-ID: <878ujdvtoq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cNjAw5tZotVq-4S402tviB8gEzI Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 06:55:54 -0000 Silberman, Sam writes: > Previous posts have suggested this is a small problem. I'm not quite sure what "this" refers to, but I think that is unfair. Several of us have repeatedly insisted on the importance of aspects of the issue other than the ones that get the most discussion, despite our personal concern with those aspects of the problem (eg, I'm an MLM developer) and personal lack of experience with other 3rd-party email services and backed-up-against-the-wall-by-mail-abuse large providers. Beyond acknowledging the need, advocacy needs to be informed by expertise in the particulars of these issues. If you have that expertise, I for one am all ears, and I suppose so is everyone else. It's been sadly deficient so far. > We need to be focusing on # of users impacted, not percentage of > mail bounced. I'm not sure I agree. You mention a use case where: > They have no $$, so they use a free mail service ( > pto@dmarc-protected-mailservice.com) which is a specifically deprecated use-case in the DMARC document (and at least some such services are well-aware that what they are doing is a Bad Idea[tm]). Should we spend effort specifically on remediating foot-shooting behavior by mailbox-provider services? > Telling user like this one to change mail providers solves nothing > in the long term. Of course it does make a difference, though. If enough users switch, that email/portal service will awaken to the need for solutions like DKIM-Delegate, DKIM-Conditional, and TPA-Labels, or alternative solutions to their specific spam problems. Otherwise I imagine they will be most comfortable continuing to throw their problems over the fence into our backyards, as they have been doing. Changing that benefit-cost proposition is essential to getting implementation of solutions effected. So far these services have contributed nothing helpful to the discussion of design of protocol improvements that I've seen; they clearly don't see a profitable (for them) way forward from the status quo. And the most active contributor from the DMARC-using operator group is an advocate of positions that I would summarize as "typical MLMs and 3rd-party services are broken and need to fix themselves to adapt to a DMARC 'p=reject' world". > Ultimately, solving DMARC indirect flows for this user will get us > very close to solving indirect flows over the rest of the world. But *we* can't *solve* indirect flows. All *we* can do is provide a protocol that mitigates the problem in theory. To have an effect, that protocol must be adopted by the same folks who created the problem and are busily telling 3rd parties to fix their service models, and thanking the 3rd parties for behavior clearly not conformant to the most basic of RFCs. I don't see why we can expect them to stop doing these things -- DMARC p=reject been quite effective in stopping some very dangerous spam/phishing, and blame the victim has convinced many of their users that the problem is in the 3rd-party service models, and those users turn around and complain to lists and other indirect mail services. Viz. the recent post to this list, requesting that list tags in Subject and footers containing detailed contact information no longer be added to list posts. That the poster would take that position doesn't surprise me: he's advocated that same measure on Mailman lists as well. But that other members of this WG would give even qualified support shows a clear lack of confidence that a solution attractive to the 'p=reject' freemail providers will be found *and* implemented. From nobody Mon Nov 17 18:52:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAA81A0065 for ; Mon, 17 Nov 2014 18:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.1 X-Spam-Level: * X-Spam-Status: No, score=1.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97n5IYt4TLM1 for ; Mon, 17 Nov 2014 18:52:33 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623341A0035 for ; Mon, 17 Nov 2014 18:52:33 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id kx10so3323494pab.2 for ; Mon, 17 Nov 2014 18:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=eqhrAjkgBsZA5wAXRrrmA5r8/MZMfjCd+zGmAtT+5QY=; b=ysobIooY6nnzFRDo8vMAGd0istXF1AZXyT7WL7/5gTDvnm/Hwq040u150jwJBu4S3d Y03U+z1oPnGdwLNzT4v13IeGNLIVaFa9vBROAswfC0TYKp7EVZK8p9vs4JTG9QwbzaOU Rzh/yL3CdxJl7bVnuIu5ulROgtQAOj8fqJJ9dmFyBK7DyYPq6FsWOA39Kv8BGIhctkHB 3YTbLA6KVwTUn1TdOS0ca7pxsERkiUX0F0bNm63XR3fjkd45wWkaeWtLxGHz9vkWJUtd I8i8SEuQ4C+SdY4J9Krjit5RN36T1lHine4pps+NF4VwmCn7o/WOsIVxu/KJK7EIz7wK g9xQ== X-Received: by 10.68.231.232 with SMTP id tj8mr478528pbc.166.1416279152610; Mon, 17 Nov 2014 18:52:32 -0800 (PST) Received: from [192.168.2.110] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id pz6sm4219845pbb.77.2014.11.17.18.52.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Nov 2014 18:52:31 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_B23AF4C7-5AB8-4D43-973F-3FF5BCE73F12" From: Douglas Otis In-Reply-To: <878ujdvtoq.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 17 Nov 2014 18:48:07 -0800 Message-Id: <4506A0D1-18A6-4C20-A07E-46C641C63BFF@gmail.com> References: <878ujdvtoq.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/soQWtWkGUZsCRa5kUC9WIZPz34M Cc: "dmarc@ietf.org" , "Silberman, Sam" , Douglas Otis Subject: Re: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 02:52:37 -0000 --Apple-Mail=_B23AF4C7-5AB8-4D43-973F-3FF5BCE73F12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 14, 2014, at 8:55 PM, Stephen J. Turnbull = wrote: > Silberman, Sam writes: >=20 >> They have no $$, so they use a free mail service ( >> pto@dmarc-protected-mailservice.com) >=20 > which is a specifically deprecated use-case in the DMARC document (and > at least some such services are well-aware that what they are doing is > a Bad Idea[tm]). Should we spend effort specifically on remediating > foot-shooting behavior by mailbox-provider services? Dear Sam and Stephen, A draft may attempt to dissuade assertion of disruptive policies (i.e. = p=3Dquarantine, or p=3Dreject) against typical email use. However, this = effort could be seen as explaining to a 900lb gorilla where they should = sleep. Justifications heard from those at DMaRC meeting were: -|- Disruptive policies protect their "brand" by disallowing other = sources use of their domain in =46rom header fields. -|- Disruptive policies protect their customers from being "spoofed" by = other domains. -|- Authorization schemes can never work because malefactors quickly = jump from domain to domain. -|- Forwarded email going to a different domain, even if approved on a = domain/user basis, is too difficult to manage. In other words, say goodbye to email's agility as a result of = restrictive policies placed on general use email accounts by AOL, Yahoo, = and others as they employ policies originally intended to protect = transactional email. Those promoting DMaRC claim this scheme now = protects 60% of all inboxes from being phished.=20 As a result, we can expect those being disrupted will arrange the =46rom = header field information into the Reply-To header field and ignore=20 http://tools.ietf.org/html/rfc5322#section-3.6.2=20 which states: "In all cases, the "From:" field SHOULD NOT contain any = mailbox that does not belong to the author(s) of the message." DMaRC simply does not offer a practical scheme that permits "alignment" = of the =46rom with either DKIM or SPF for third-party services. >> Telling user like this one to change mail providers solves nothing >> in the long term. >=20 > Of course it does make a difference, though. If enough users switch, > that email/portal service will awaken to the need for solutions like > DKIM-Delegate, DKIM-Conditional, and TPA-Labels, or alternative > solutions to their specific spam problems. Otherwise I imagine they > will be most comfortable continuing to throw their problems over the > fence into our backyards, as they have been doing. Changing that > benefit-cost proposition is essential to getting implementation of > solutions effected. Internet access often includes email accounts facilitating Internet = services. Most users are reliant on their Internet providers to restore = services when problems are experienced. As such, most are reluctant to = modify services offered, even when there may be a means to substitute = email-addresses from different providers. Typically no examples are = given leaving most unaware of possible options. This should be expected = since such options would interfere with the marketing of ads. In addition, not every email service relies on SPF or DKIM. Both of = these protocols offer weak protection which has led to a rapid uptake of = DANE/SMTP. In addition, without TPA-Labels, DMaRC is unable to align = with most third-party services. Mailing-lists that tag subject lines = and flatten messages actually provide safer services by making messages = less suitable for exploitation. It is a sad outcome, since DMaRC offers = feedback allowing various domains a means to monitor and identify = compromised accounts. Use of the TPA-label scheme would allow an = immediate method to omit abusive domains and alert users to a problem = while selectively permitting improved authentication schemes. Domains = offering bundled email combined with free accounts remain abuse prone. = Any risk associated with authorizing a third-party domain is offset by = improved feedback able to achieve an immediate remedy, when compared = against abuse emitted directly from the DMaRC domain that can be = replayed to an unlimited number of recipients for days at a time.=20 > So far these services have contributed nothing helpful to the > discussion of design of protocol improvements that I've seen; they > clearly don't see a profitable (for them) way forward from the status > quo. And the most active contributor from the DMARC-using operator > group is an advocate of positions that I would summarize as "typical > MLMs and 3rd-party services are broken and need to fix themselves to > adapt to a DMARC 'p=3Dreject' world". Sadly, I agree. We even offered to help manage the use of the TPA-label = scheme. There was a concern regarding the Forwarding of email from one = domain to another which might require special handling. It seems this = need to be explored further. >> Ultimately, solving DMARC indirect flows for this user will get us >> very close to solving indirect flows over the rest of the world. >=20 > But *we* can't *solve* indirect flows. All *we* can do is provide a > protocol that mitigates the problem in theory. >=20 > To have an effect, that protocol must be adopted by the same folks who > created the problem and are busily telling 3rd parties to fix their > service models, and thanking the 3rd parties for behavior clearly not > conformant to the most basic of RFCs. I don't see why we can expect > them to stop doing these things -- DMARC p=3Dreject been quite = effective > in stopping some very dangerous spam/phishing, and blame the victim > has convinced many of their users that the problem is in the 3rd-party > service models, and those users turn around and complain to lists and > other indirect mail services. >=20 > Viz. the recent post to this list, requesting that list tags in > Subject and footers containing detailed contact information no longer > be added to list posts. That the poster would take that position > doesn't surprise me: he's advocated that same measure on Mailman lists > as well. But that other members of this WG would give even qualified > support shows a clear lack of confidence that a solution attractive to > the 'p=3Dreject' freemail providers will be found *and* implemented. Agreed. Over time, domains too big to block causing work for others may = soon find that status fading. Only then, does it seem likely progress = can be made. I'll repeat an offer to help manage handling this very = serious problem. It seems that offering even weaker forms of DKIM is = not something that would be safe. An alternative solution might involve = using the Outlook scheme of "on behalf of" or displaying the Sender = header field (an available option with many MUAs). A DMARC flag could = then safely permit inclusion of Sender to satisfy alignments when being = used for general purpose user email accounts. This would give most = third-parties a simpler solution. TPA-Label could also allow selective = deployment of the Sender option as well.=20 Regards, Douglas Otis --Apple-Mail=_B23AF4C7-5AB8-4D43-973F-3FF5BCE73F12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Nov 14, 2014, at 8:55 PM, Stephen J. Turnbull <stephen@xemacs.org> = wrote:

Silberman, Sam = writes:

They have no $$, so they use a = free mail service (
pto@dmarc-protected-ma= ilservice.com)

which is a specifically = deprecated use-case in the DMARC document (and
at least some such = services are well-aware that what they are doing is
a Bad Idea[tm]). =  Should we spend effort specifically on = remediating
foot-shooting behavior by mailbox-provider = services?

Dear Sam and = Stephen,

A draft may attempt to dissuade = assertion of disruptive policies (i.e. p=3Dquarantine, or p=3Dreject) = against typical email use. However, this effort could be seen as = explaining to a 900lb gorilla where they should sleep. =  Justifications heard from those at DMaRC meeting = were:

-|- Disruptive policies protect their = "brand" by disallowing other sources use of their domain in =46rom = header fields.

-|- Disruptive policies protect = their customers from being "spoofed" by other = domains.

-|- Authorization schemes can never = work because malefactors quickly jump from domain to = domain.

-|- Forwarded email going to a = different domain, even if approved on a domain/user basis, is too = difficult to manage.

In other words, say = goodbye to email's agility as a result of restrictive policies placed on = general use email accounts by AOL, Yahoo, and others as they employ = policies originally intended to protect transactional email.  Those = promoting DMaRC claim this scheme now protects 60% of all inboxes from = being phished. 

As a result, we can expect = those being disrupted will arrange the =46rom header field information = into the Reply-To header field and ignore 
which states: "In = all cases, the "From:" field SHOULD NOT contain any mailbox that does = not belong to the author(s) of the = message."

DMaRC simply does not offer a = practical scheme that permits "alignment" of the =46rom with either DKIM = or SPF for third-party services.

Telling user like this one to = change mail providers solves nothing
in the long = term.

Of course it does make a difference, though. =  If enough users switch,
that email/portal service will awaken = to the need for solutions like
DKIM-Delegate, DKIM-Conditional, and = TPA-Labels, or alternative
solutions to their specific spam problems. =  Otherwise I imagine they
will be most comfortable continuing to = throw their problems over the
fence into our backyards, as they have = been doing.  Changing that
benefit-cost proposition is essential = to getting implementation of
solutions = effected.

Internet access often = includes email accounts facilitating Internet services.  Most users = are reliant on their Internet providers to restore services when = problems are experienced.  As such, most are reluctant to modify = services offered, even when there may be a means to substitute = email-addresses from different providers. Typically no examples are = given leaving most unaware of possible options.  This should be = expected since such options would interfere with the marketing of = ads.

In addition, not every email service = relies on SPF or DKIM.  Both of these protocols offer weak = protection which has led to a rapid uptake of DANE/SMTP.  In = addition, without TPA-Labels, DMaRC is unable to align with most = third-party services.  Mailing-lists that tag subject lines and = flatten messages actually provide safer services by making messages less = suitable for exploitation.  It is a sad outcome, since DMaRC offers = feedback allowing various domains a means to monitor and identify = compromised accounts. Use of the TPA-label scheme would allow an = immediate method to omit abusive domains and alert users to a problem = while selectively permitting improved authentication schemes. =  Domains offering bundled email combined with free accounts remain = abuse prone.  Any risk associated with authorizing a third-party = domain is offset by improved feedback able to achieve an immediate = remedy, when compared against abuse emitted directly from the DMaRC = domain that can be replayed to an unlimited number of recipients for = days at a time. 

So = far these services have contributed nothing helpful to the
discussion = of design of protocol improvements that I've seen; they
clearly don't = see a profitable (for them) way forward from the status
quo. =  And the most active contributor from the DMARC-using = operator
group is an advocate of positions that I would summarize as = "typical
MLMs and 3rd-party services are broken and need to fix = themselves to
adapt to a DMARC 'p=3Dreject' = world".

Sadly, I agree.  We = even offered to help manage the use of the TPA-label scheme.  There = was a concern regarding the Forwarding of email from one domain to = another which might require special handling. It seems this need to be = explored further.

Ultimately, solving DMARC = indirect flows for this user will get us
very close to solving = indirect flows over the rest of the world.

But *we* = can't *solve* indirect flows.  All *we* can do is provide = a
protocol that mitigates the problem in theory.

To have an = effect, that protocol must be adopted by the same folks who
created = the problem and are busily telling 3rd parties to fix their
service = models, and thanking the 3rd parties for behavior clearly = not
conformant to the most basic of RFCs.  I don't see why we = can expect
them to stop doing these things -- DMARC p=3Dreject been = quite effective
in stopping some very dangerous spam/phishing, and = blame the victim
has convinced many of their users that the problem = is in the 3rd-party
service models, and those users turn around and = complain to lists and
other indirect mail services.

Viz. the = recent post to this list, requesting that list tags in
Subject and = footers containing detailed contact information no longer
be added to = list posts.  That the poster would take that position
doesn't = surprise me: he's advocated that same measure on Mailman lists
as = well.  But that other members of this WG would give even = qualified
support shows a clear lack of confidence that a solution = attractive to
the 'p=3Dreject' freemail providers will be found *and* = implemented.

Agreed.  Over time, domains = too big to block causing work for others may soon find that status = fading.  Only then, does it seem likely progress can be made. =  I'll repeat an offer to help manage handling this very serious = problem.   It seems that offering even weaker forms of DKIM is not = something that would be safe.  An alternative solution might = involve using the Outlook scheme of "on behalf of" or displaying the = Sender header field (an available option with many MUAs).  A DMARC = flag could then safely permit inclusion of Sender to satisfy alignments = when being used for general purpose user email accounts.  This = would give most third-parties a simpler solution.  TPA-Label could = also allow selective deployment of the Sender option as = well. 

Regards,
Douglas = Otis


= --Apple-Mail=_B23AF4C7-5AB8-4D43-973F-3FF5BCE73F12-- From nobody Fri Nov 21 09:56:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731721AD62C for ; Fri, 21 Nov 2014 09:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.596 X-Spam-Level: X-Spam-Status: No, score=-0.596 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Qb5lZAs8kFF for ; Fri, 21 Nov 2014 09:56:39 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 505F61A1B8D for ; Fri, 21 Nov 2014 09:56:33 -0800 (PST) Received: from [10.0.1.4] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id D2037CB46 for ; Fri, 21 Nov 2014 12:56:29 -0500 (EST) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_6962E095-DC4A-4CF9-9036-C07E987D7761" Message-Id: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> Date: Fri, 21 Nov 2014 12:56:30 -0500 To: dmarc Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/JSXSHIxdIqcCaX6wmBv-dMSxu5Y Subject: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 17:56:41 -0000 --Apple-Mail=_6962E095-DC4A-4CF9-9036-C07E987D7761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 WG, The work found here: http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki = ..is almost complete. However, there is a note (reinforced by feedback = during the recent in-person meeting) to recast the collected issues in = terms of RFC 5598. Once this recasting is done, Milestone 1 will be = officially met. If you=E2=80=99re handy with the language found in RFC 5598, please = consider helping out. Getting the language correct now will only make = everything better later on. Co-chair, =3D- Tim PS. A group of editors spontaneously formed during the in-person = meeting. The group will tackle Milestone 2 =E2=80=94 which is to = transform issues learned and documented in Milestone 1 + proposed = solutions for each into a real reviewable draft. This is not a closed = group, so if you=E2=80=99d like to be actively involved, just say so. --Apple-Mail=_6962E095-DC4A-4CF9-9036-C07E987D7761 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 WG,

The = work found here:

  http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki<= /a>

..is = almost complete.  However, there is a note (reinforced by feedback = during the recent in-person meeting) to recast the collected issues in = terms of RFC 5598.  Once this recasting is done, Milestone 1 will = be officially met.

If you=E2=80=99re handy with the language found in RFC 5598, = please consider helping out.  Getting the language correct now will = only make everything better later on.

Co-chair,
=3D- = Tim

PS. =  A group of editors spontaneously formed during the in-person = meeting.  The group will tackle Milestone 2 =E2=80=94 which is to = transform issues learned and documented in Milestone 1 + proposed = solutions for each into a real reviewable draft.  This is not a = closed group, so if you=E2=80=99d like to be actively involved, just say = so.



= --Apple-Mail=_6962E095-DC4A-4CF9-9036-C07E987D7761-- From nobody Fri Nov 21 10:51:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C940C1A004C for ; Fri, 21 Nov 2014 10:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxPmUCt7bcDp for ; Fri, 21 Nov 2014 10:51:12 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5B91A007E for ; Fri, 21 Nov 2014 10:50:57 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id ft15so5813219pdb.32 for ; Fri, 21 Nov 2014 10:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v4ZDK67HuuQwf0poj2z9HdHgofcC+2axV7vlVKF3V30=; b=fnOcqN1tJV8TO8Zo/HG0Z7ralVMaJcw4VPMAw8xPoKJfcXrbq6CtjQ+Cz9atRTUkrP qNSzacq8EC6ru01zzrBbY7jQsMp7qz1sBa7QXJQ6zDRdTuXEvSB/ZBBQvi+pkb3CuZG1 hgVNYgUJthOfym4nici7Ly36OtzOaUpJabxkpyTzyJaNYfGhydd5pD6+YDt5cAFmUoud Gw6/884LkZHCNnn7GGHrcxI2DzWLEbpWWPpCwhPBl7S+3H3Aq0MkiLVglHzu+fzIi1qD QIj1giKWUvf/aa+2D4c7opD/8pnkJa4qvlxWOcaJ49MeD+tNWb1G72GRYpwVnsy+lGPI 1bpA== X-Received: by 10.68.218.231 with SMTP id pj7mr9479209pbc.163.1416595856687; Fri, 21 Nov 2014 10:50:56 -0800 (PST) Received: from [192.168.2.225] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id k10sm4421900pdm.3.2014.11.21.10.50.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 10:50:55 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Douglas Otis In-Reply-To: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> Date: Fri, 21 Nov 2014 10:50:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> To: Tim Draegen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nqTD6dQT5bh_0oWseYGIYH872ek Cc: dmarc , Douglas Otis Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:51:15 -0000 On Nov 21, 2014, at 9:56 AM, Tim Draegen wrote: > WG, >=20 > PS. A group of editors spontaneously formed during the in-person = meeting. The group will tackle Milestone 2 =97 which is to transform = issues learned and documented in Milestone 1 + proposed solutions for = each into a real reviewable draft. This is not a closed group, so if = you=92d like to be actively involved, just say so. Dear Tim, Please include me in the solution discussions. Regards, Douglas Otis From nobody Fri Nov 21 10:58:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DA61A020B for ; Fri, 21 Nov 2014 10:58:00 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h97u13hD68kZ for ; Fri, 21 Nov 2014 10:57:57 -0800 (PST) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id D28571A00D7 for ; Fri, 21 Nov 2014 10:54:44 -0800 (PST) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3jkn4M5jZSz5Mhdl; Fri, 21 Nov 2014 19:54:43 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3jkn4M4QWkz5Mhc4; Fri, 21 Nov 2014 19:54:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id A7BB2123341; Fri, 21 Nov 2014 19:54:45 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L6XJpLgfRCFk; Fri, 21 Nov 2014 19:54:40 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 98906122F08; Fri, 21 Nov 2014 19:54:40 +0100 (CET) Message-ID: <546F8A6D.30203@sonnection.nl> Date: Fri, 21 Nov 2014 19:54:37 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Tim Draegen , dmarc References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> In-Reply-To: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> Content-Type: multipart/alternative; boundary="------------040803020106090207070300" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1416596083; bh=dbioChS8XYxO5Gzkpgmyrh8ylV1CKmpXZljFt/DHzc4=; h=Message-ID:Date:From:To:Subject:From; b=H24ACwclfNbUBcRAAX9gx3abbaI8aFbBkwW/u8YwVCXeIlWkroqHr3+6Fj4NdTFuq tZ6rkqB4AUln42aJxj3lcrUnKaRrZQ1tOScrlu72t4+VQF6k23NvbZMXh8ne1IJna0 vvEAyQDrVOzaVFDTgx5YD4MwCtLn7WjzhwczSZgs= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3jkn4M5jZSz5Mhdl Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8Q7R9sek44_9cF0x2QD8sHLkp_8 Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:58:01 -0000 This is a multi-part message in MIME format. --------------040803020106090207070300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 11/21/2014 06:56 PM, Tim Draegen wrote: > WG, > > The work found here: > > http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki > > ..is almost complete. However, there is a note (reinforced by=20 > feedback during the recent in-person meeting) to recast the collected=20 > issues in terms of RFC 5598. Once this recasting is done, Milestone 1=20 > will be officially met. > > If you=92re handy with the language found in RFC 5598, please consider=20 > helping out. Getting the language correct now will only make=20 > everything better later on. > > Co-chair, > =3D- Tim > > PS. A group of editors spontaneously formed during the in-person=20 > meeting. The group will tackle Milestone 2 =97 which is to transform=20 > issues learned and documented in Milestone 1 + proposed solutions for=20 > each into a real reviewable draft. This is not a closed group, so if=20 > you=92d like to be actively involved, just say so. does this mean that any work/solutions will not be discussed on this=20 list, before a reviewable draft is ready? If so, please add me to the=20 discussion group. /rolf --------------040803020106090207070300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 11/21/2014 06:56 PM, Tim Draegen wrote:
WG,

The work found here:

=A0=A0http://trac.tools.ietf.org/wg/dmarc/trac/wiki/Milest= oneOneWiki

..is almost complete. =A0However, there is a note (reinforced by feedback during the recent in-person meeting) to recast the collected issues in terms of RFC 5598. =A0Once this recasting is done, Milestone 1 will be officially met.

If you=92re handy with the language found in RFC 55= 98, please consider helping out. =A0Getting the language correct now will only make everything better later on.

Co-chair,
=3D- Tim

PS. =A0A group of editors spontaneously formed duri= ng the in-person meeting. =A0The group will tackle Milestone 2 =97 which is to transform issues learned and documented in Milestone 1 + proposed solutions for each into a real reviewable draft. =A0This is not a closed group, so if you=92d like to be actively involved, just say so.

does this mean that any work/solutions will not be discussed on this list, before a reviewable draft is ready? If so, please add me to the discussion group.

/rolf

--------------040803020106090207070300-- From nobody Fri Nov 21 10:58:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB71A1A00D7 for ; Fri, 21 Nov 2014 10:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI9Xnch4D2nI for ; Fri, 21 Nov 2014 10:57:59 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 95C841A036F for ; Fri, 21 Nov 2014 10:54:45 -0800 (PST) Received: from [10.0.1.4] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id E9F24CB46; Fri, 21 Nov 2014 13:54:42 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Draegen In-Reply-To: Date: Fri, 21 Nov 2014 13:54:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3DD1D080-5344-40E7-B83F-DE3688069F89@eudaemon.net> References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> To: Douglas Otis X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p7nX1_mkw95BV5e2iVLjEaOZJLs Cc: dmarc Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:58:01 -0000 On Nov 21, 2014, at 1:50 PM, Douglas Otis wrote: >=20 > On Nov 21, 2014, at 9:56 AM, Tim Draegen wrote: >=20 >> WG, >>=20 >> PS. A group of editors spontaneously formed during the in-person = meeting. The group will tackle Milestone 2 =97 which is to transform = issues learned and documented in Milestone 1 + proposed solutions for = each into a real reviewable draft. This is not a closed group, so if = you=92d like to be actively involved, just say so. >=20 > Dear Tim, >=20 > Please include me in the solution discussions. Hi Doug, Discussion of solutions will happen on the mailing list -- I was = referring to the act of cramming the good bits of the discussion (text, = edits, making sure people aren't duplicating sections) into a draft. =20 If you're NOT interested in editing, it will be business as usual on the = WG list. =3D- Tim= From nobody Fri Nov 21 10:58:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114B71A0392 for ; Fri, 21 Nov 2014 10:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiApKfoo-ZWX for ; Fri, 21 Nov 2014 10:58:52 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id C840E1A0270 for ; Fri, 21 Nov 2014 10:56:45 -0800 (PST) Received: from [10.0.1.4] (97-82-216-27.dhcp.hckr.nc.charter.com [97.82.216.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 2CD48CB46; Fri, 21 Nov 2014 13:56:43 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Tim Draegen In-Reply-To: <546F8A6D.30203@sonnection.nl> Date: Fri, 21 Nov 2014 13:56:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> <546F8A6D.30203@sonnection.nl> To: R.E.Sonneveld@sonnection.nl X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1E4gc5D84eLYt975RSGTK_cU7VY Cc: dmarc Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 18:58:55 -0000 > On Nov 21, 2014, at 1:54 PM, Rolf E. Sonneveld = wrote: >=20 > does this mean that any work/solutions will not be discussed on this = list, before a reviewable draft is ready? If so, please add me to the = discussion group. No, I was not clear. Discussion of solutions will happen on the mailing = list -- I was referring to the act of cramming the good bits of the = discussion (text, edits, making sure people aren't duplicating sections) = into a draft. =20 If you're NOT interested in editing, it will be business as usual on the = WG list. From nobody Fri Nov 21 18:29:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E011AC3AC for ; Fri, 21 Nov 2014 18:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdI7aJgkxKOH for ; Fri, 21 Nov 2014 18:29:28 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E2B1AC3AB for ; Fri, 21 Nov 2014 18:29:28 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id z10so6335539pdj.26 for ; Fri, 21 Nov 2014 18:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9ST1NFRoPaSFZzaHuSa0sNv1GF0jM2yguW1HBAxyvjo=; b=ww40jFltGEUd+0qFqPuWNpXdMRti3SZD4/32/8mXGj4942OF7aSI8yIhYO1ihXfAqt oA3Nafdh2OpsNWEdEdKDkfx3jBJcGuNsaEpzmU+xg0mpvcKj3TbHZZtMp7SbfKBBg4uX 6TX/EIAJNgCxvNUdzhUZirIgQWR2zEA9PPTbPflJ+uyW0+HDpsI1MykAXdYLAXsTMuzX aA7fT6YZd1eJhocba8H284IO72B3kEcqkcR1U9mFN7WCeH48dlteFtN39LAuplDZurRv o6ClUXuGrjC6oJmwfU6HdqrhuoKAYmSI9SEovDOn7mgxFUqtkCvVdoAMn/FeLtqbmtFl ssWQ== X-Received: by 10.68.135.132 with SMTP id ps4mr12632018pbb.128.1416623367837; Fri, 21 Nov 2014 18:29:27 -0800 (PST) Received: from [192.168.2.226] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id lm3sm6016316pab.34.2014.11.21.18.29.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 18:29:26 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Fri, 21 Nov 2014 18:29:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4FFF0B20-0D1A-4CA7-8906-6BF0245AF6DF@gmail.com> References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> <546F8A6D.30203@sonnection.nl> To: dmarc X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zHZGTX4BOqnDioFJdUcIcewekEo Cc: Tim Draegen Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 02:29:31 -0000 On Nov 21, 2014, at 10:56 AM, Tim Draegen wrote: >> On Nov 21, 2014, at 1:54 PM, Rolf E. Sonneveld = wrote: >>=20 >> does this mean that any work/solutions will not be discussed on this = list, before a reviewable draft is ready? If so, please add me to the = discussion group. >=20 > No, I was not clear. Discussion of solutions will happen on the = mailing list -- I was referring to the act of cramming the good bits of = the discussion (text, edits, making sure people aren't duplicating = sections) into a draft. =20 >=20 > If you're NOT interested in editing, it will be business as usual on = the WG list. Dear Tim, There are serious concerns being ignored regarding email captured in = DMaRC feedback. Things like Intuit invoices or mailing-list = conversations are being misdirected simply because DMaRC incorrectly = assumes a sender/recipient relationship when general use email providers = assert restrictive DMaRC policies. DMaRC policies that require =46rom = header field alignment with the sender inhibit the forwarding of email = and dismiss Sender header field contents as being potentially deceptive = to justify ignoring this field in the determination of direct "mail = flows". It is incorrect to suggest an RFC compliant message which = accurately indicates the third-party sender somehow grants DMaRC = protocol permission to misdirect these messages. Even Microsoft enabled = special provisions to handle Sender header fields in their MUA, and most = MUAs can be configured to display Sender header fields when necessary. = SMTP's agility is afforded by its store-and-forward nature. However = this often relied upon agility is seriously damaged by DMaAC's short-cut = of ignoring the defined role of the Sender header field. While a provider is free to condition acceptance on any dubious = characteristic, this does not include redirecting accepted messages to = destinations neither specified by senders nor recipients.=20 I have tools to construct drafts and am willing to generate text. Regards, Douglas Otis= From nobody Sat Nov 22 00:43:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90241A00C3 for ; Sat, 22 Nov 2014 00:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-OBUVkLATCS for ; Sat, 22 Nov 2014 00:43:09 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B91021A005C for ; Sat, 22 Nov 2014 00:43:09 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 102DA1C39D1; Sat, 22 Nov 2014 17:43:08 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E04E51A2892; Sat, 22 Nov 2014 17:43:07 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <4FFF0B20-0D1A-4CA7-8906-6BF0245AF6DF@gmail.com> References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> <546F8A6D.30203@sonnection.nl> <4FFF0B20-0D1A-4CA7-8906-6BF0245AF6DF@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 22 Nov 2014 17:43:07 +0900 Message-ID: <87zjbjsk10.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PBAX6gjBRmztbHw9utjzaZYHtFc Cc: Tim Draegen , dmarc Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 08:43:12 -0000 Douglas Otis writes: > There are serious concerns being ignored regarding email captured in > DMaRC feedback. Things like Intuit invoices or mailing-list > conversations are being misdirected simply because DMaRC incorrectly > assumes a sender/recipient relationship when general use email > providers assert restrictive DMaRC policies. So do you propose something like Author Domains which impose policies that can result in failure reports being sent MUST have Terms of Service in which mailbox users agree that content of messages which fail DMARC checks may be forwarded to the Author Domain as part of failure reports. This includes messages that they have originated which are unauthorized according to the definition of DMARC. Or however you say that in IETF-ese? > DMaRC policies that require From header field alignment with the > sender inhibit the forwarding of email and dismiss Sender header > field contents as being potentially deceptive to justify ignoring > this field in the determination of direct "mail flows". Isn't that backward? DMARC focuses on From alignment *because* in typical MUA configurations Sender is not visible to the receiving user, and in any case would be unlikely to be useful in counteracting phishing and recommended-by-a-friend spam. That is, I don't see how verifying Sender would be useful. True, if you verify Intuit as the sender of mail on behalf of a billing company, the user seeing Intuit in Sender would likely come to an appropriate conclusion. But if you verify example.com as Sender, the user doesn't know who they are, and in most cases I would expect them to simply ignore that information and rely on From and any clues in the message content. > However this often relied upon agility is seriously damaged by > DMaAC's short-cut of ignoring the defined role of the Sender header > field. It's not a shortcut. Sender has the wrong semantics for combatting phishing and recommended-by-friend spam. > this does not include redirecting accepted messages to destinations > neither specified by senders nor recipients. This is not a problem restricted to DMARC. Any protocol that involves forwarding a message to a third party (eg, the Sender field or Return-Path) raises this issue (eg, in the case of a typo in the recipient mailbox name). It's true that DMARC seems designed to cause such problems. From nobody Mon Nov 24 17:42:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBEC1A70E1 for ; Mon, 24 Nov 2014 17:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z73eL9g1kyHZ for ; Mon, 24 Nov 2014 17:42:07 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1081A700B for ; Mon, 24 Nov 2014 17:42:07 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id j7so7338477qaq.1 for ; Mon, 24 Nov 2014 17:42:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=kmYjxAjrnU0fSaaqs22OgbTTOsCnBYs77AWl/M53hW0=; b=nm78ZqgKsQWFKg4dBEoDzYLy8kAYSMzvre3nieQcztCT5gLSwdFPABCfyKwSI3U5MT Xxbpe9YoxjBeBo//vI1QUEoxRXA2rZVS9XCum58qBjKi61nmG1qzBh1ayp/QrkWon/tn T3fBOFnz48lTpb1wgyXPQSbbfSnKm4UAQpUDGkC/vjjGT1FDzYXQ2eIvOSJWYyJ2TGf2 d1QE2744sJWxi2mZit7pJL9WKrDJrlPWdJWvd9h+0kudRGI3H7sLmR9bu+eUm2C6BStA xwdWIbFimkX50qjAxfAzmlDvwIK3TvAznM4QqixHsOuBMQONsSHGewMHG0vNzaf9gXcY 3yGw== X-Received: by 10.229.44.7 with SMTP id y7mr33267180qce.26.1416879726792; Mon, 24 Nov 2014 17:42:06 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id e8sm13519761qai.33.2014.11.24.17.42.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 17:42:05 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5328FB32-0D9E-45DB-8BDF-4B98DD03D64E" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <87zjbjsk10.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 24 Nov 2014 17:42:03 -0800 Message-Id: <065B07D0-FF4A-47F0-B527-6064D1A705F7@gmail.com> References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> <546F8A6D.30203@sonnection.nl> <4FFF0B20-0D1A-4CA7-8906-6BF0245AF6DF@gmail.com> <87zjbjsk10.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/37dFAINeDBc1oNYi3cQb0hXDjt8 Cc: Tim Draegen , dmarc , Douglas Otis Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 01:42:10 -0000 --Apple-Mail=_5328FB32-0D9E-45DB-8BDF-4B98DD03D64E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 22, 2014, at 12:43 AM, Stephen J. Turnbull = wrote: > Douglas Otis writes: >=20 >> There are serious concerns being ignored regarding email captured in >> DMaRC feedback. Things like Intuit invoices or mailing-list >> conversations are being misdirected simply because DMaRC incorrectly >> assumes a sender/recipient relationship when general use email >> providers assert restrictive DMaRC policies. >=20 > So do you propose something like >=20 > Author Domains which impose policies that can result in failure > reports being sent MUST have Terms of Service in which mailbox > users agree that content of messages which fail DMARC checks may > be forwarded to the Author Domain as part of failure reports. > This includes messages that they have originated which are > unauthorized according to the definition of DMARC. Dear Stephen, Consider invoices sent by Intuit on behalf of users who have an email = address obtained in conjunction with their Internet access who are = seeking financially related services. These messages are not spoofing = the source accurately indicated by Sender header fields as defined by = RFC5322. Why assume these entities assigned an email address by their = access provider intended their service related messages be insecurely = mis-directed to access providers instead of the intended recipients? In the case of legitimate third-party services, these messages are not = the property of the access provider. They are owned by the author = assigned the email address seeking these services. Failing DMaRC with a = message that has a valid and reputable domain aligned with the Sender = header field domain is unlikely malicious or in violation of any = recognized protocol standard. DMaRC related redirection of these valid = and legitimate messages disrupts vital services, such as forwarding and = use of third-party services in common use for decades. The disruption = of these services clearly indicates DMaRC is incompatible with SMTP by = neglecting consideration for sender agents not aligned with the = email-address provider. Rather than issuing click through agreements to in essence say "All your = email must represent direct transactions from the provider." they could = offer users a friendly SMTP compatible and safe solution that provides = MUA configurations that expose aligned Sender header fields in lieu of = aligned =46rom header fields. This could be coupled with DMaRC record = that offers this exception. With a simple change, their customers are = protected and afforded the agility SMTP normally allows. This could be = signaled by making specific authorizations such as those proposed in = TPA-Label or by defining an a DMaRC assertion which indicates TP=3DPSS = or TP=3DPSR for Sender header field strict and relaxed, or defines an = excepted group syntax which safely permits a highly visible exception = made using group syntax indicated with DMaRC assertions TP=3DG and = perhaps combined with TP=3DPSR,G. =20 > Or however you say that in IETF-ese? >=20 >> DMaRC policies that require =46rom header field alignment with the >> sender inhibit the forwarding of email and dismiss Sender header >> field contents as being potentially deceptive to justify ignoring >> this field in the determination of direct "mail flows". >=20 > Isn't that backward? DMARC focuses on =46rom alignment *because* in > typical MUA configurations Sender is not visible to the receiving > user, and in any case would be unlikely to be useful in counteracting > phishing and recommended-by-a-friend spam. That is, I don't see how > verifying Sender would be useful. True, if you verify Intuit as the > sender of mail on behalf of a billing company, the user seeing Intuit > in Sender would likely come to an appropriate conclusion. But if you > verify example.com as Sender, the user doesn't know who they are, and > in most cases I would expect them to simply ignore that information > and rely on =46rom and any clues in the message content. DMaRC makes an erroneous assumption incompatible with SMTP in the case = of user email accounts. Besides, DMaRC can not prevent all spoofing and = makes future improvement problematic. It would be wrong to characterize = Mailing-list traffic as being spam friendly or something most users are = unable to recognize and properly handle. Where the user sending a = message is critical, they can be S/MIME or OpenPGP signed, but = nevertheless these safer solutions are not recognized by DMaRC.=20 >> However this often relied upon agility is seriously damaged by >> DMaAC's short-cut of ignoring the defined role of the Sender header >> field. >=20 > It's not a shortcut. Sender has the wrong semantics for combatting > phishing and recommended-by-friend spam. We have handled a fair amount of DKIM related malicious traffic = exploiting trivial spoofing DKIM permits. This was giving users a false = sense of security where the problem was clearly noted in the Won't Fix = DKIM ticket 24 in May of 2011. It took until May of 2014 for a fix to = be implemented by one of the world's largest providers. Those following = DKIM deployment documents along with those waiting to be published for = DMaRC seem destine to ensure mistakes remain likely because logical = processing errors are never admitted, given clear warning, or directly = fixed without added overhead. =20 A false sense of assurance remains a concern for SPF heavily exploited = by Kelihos botnets, for example. Neither SPF nor DKIM can be used to = hold domains sending malicious email accountable because neither = authenticates actual sources. Authenticating the source by domain is = the only practical way to combat phishing that remains impractical when = using just DKIM or SPF. Misguided DMaRC requirements are attempting to = force standardization on weak protocols destined to prolong abuse and = associated damage. Lawsuits related to abuse blocking often involve = substantial sums where evidence must be rock solid. >> this does not include redirecting accepted messages to destinations >> neither specified by senders nor recipients. >=20 > This is not a problem restricted to DMARC. Any protocol that involves > forwarding a message to a third party (eg, the Sender field or > Return-Path) raises this issue (eg, in the case of a typo in the > recipient mailbox name). It's true that DMARC seems designed to cause > such problems. DMaRC along with DKIM and SPF were carefully designed to avoid = authenticating domains often well compensated for having sourced abuse. = Despite such an obvious defect in these plutocratic schemes, almost = every related authorization reporting method erroneously includes = Authentication in their title. What is standing the the way of DANE = deployment for both client and server? Regards, Douglas Otis= --Apple-Mail=_5328FB32-0D9E-45DB-8BDF-4B98DD03D64E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Nov 22, 2014, at 12:43 AM, Stephen J. Turnbull <stephen@xemacs.org> = wrote:

Douglas Otis = writes:

There are serious concerns = being ignored regarding email captured in
DMaRC feedback. =  Things like Intuit invoices or mailing-list
conversations are = being misdirected simply because DMaRC incorrectly
assumes a = sender/recipient relationship when general use email
providers assert = restrictive DMaRC policies.

So do you propose = something like

   Author Domains which impose policies = that can result in failure
   reports being sent MUST have = Terms of Service in which mailbox
   users agree that = content of messages which fail DMARC checks may
   be = forwarded to the Author Domain as part of failure reports.
  =  This includes messages that they have originated which = are
   unauthorized according to the definition of = DMARC.

Dear = Stephen,

Consider invoices sent by Intuit on = behalf of users who have an email address obtained in conjunction with = their Internet access who are seeking financially related services. =  These messages are not spoofing the source accurately indicated by = Sender header fields as defined by RFC5322.  Why assume these = entities assigned an email address by their access = provider intended their service related messages be insecurely = mis-directed to access providers instead of the intended = recipients?

In the case of legitimate = third-party services, these messages are not the property of the access = provider. They are owned by the author assigned the email address = seeking these services.  Failing DMaRC with a message that has a = valid and reputable domain aligned with the Sender header field domain = is unlikely malicious or in violation of any recognized protocol = standard.  DMaRC related redirection of these valid and legitimate = messages disrupts vital services, such as forwarding and use of = third-party services in common use for decades.  The disruption of = these services clearly indicates DMaRC is incompatible with SMTP by = neglecting consideration for sender agents not aligned with the = email-address provider.

Rather than issuing = click through agreements to in essence say "All your email must = represent direct transactions from the provider." they could offer users = a friendly SMTP compatible and safe solution that provides MUA = configurations that expose aligned Sender header fields in lieu of = aligned =46rom header fields.  This could be coupled with DMaRC = record that offers this exception.  With a simple change, their = customers are protected and afforded the agility SMTP normally allows. =  This could be signaled by making specific authorizations such as = those proposed in TPA-Label&nb= sp;or by defining an a DMaRC assertion which indicates TP=3DPSS or = TP=3DPSR for Sender header field strict and relaxed, or defines an = excepted group syntax which safely permits a highly visible exception = made using group syntax indicated with DMaRC assertions TP=3DG and = perhaps combined with TP=3DPSR,G.
 
Or however you say that in IETF-ese?

DMaRC policies that require =46rom header field alignment = with the
sender inhibit the forwarding of email and dismiss Sender = header
field contents as being potentially deceptive to justify = ignoring
this field in the determination of direct "mail = flows".

Isn't that backward?  DMARC focuses on = =46rom alignment *because* in
typical MUA configurations Sender is = not visible to the receiving
user, and in any case would be unlikely = to be useful in counteracting
phishing and recommended-by-a-friend = spam.  That is, I don't see how
verifying Sender would be = useful.  True, if you verify Intuit as the
sender of mail on = behalf of a billing company, the user seeing Intuit
in Sender would = likely come to an appropriate conclusion.  But if you
verify example.com as Sender, the user doesn't = know who they are, and
in most cases I would expect them to simply = ignore that information
and rely on =46rom and any clues in the = message content.

DMaRC makes an = erroneous assumption incompatible with SMTP in the case of user email = accounts.  Besides, DMaRC can not prevent all spoofing and makes = future improvement problematic.  It would be wrong to characterize = Mailing-list traffic as being spam friendly or something most users are = unable to recognize and properly handle.  Where the user sending a = message is critical, they can be S/MIME or OpenPGP signed, but = nevertheless these safer solutions are not recognized by = DMaRC. 

However this often relied upon agility is seriously = damaged by
DMaAC's short-cut of ignoring the defined role of the = Sender header
field.

It's not a shortcut. =  Sender has the wrong semantics for combatting
phishing and = recommended-by-friend spam.

We have = handled a fair amount of DKIM related malicious traffic exploiting = trivial spoofing DKIM permits.  This was giving users a false sense = of security where the problem was clearly noted in the Won't Fix = DKIM ticket 24 in May of 2011.  It took until May of 2014 = for a fix to be implemented by one of the world's largest providers. =  Those following DKIM deployment documents along with those waiting = to be published for DMaRC seem destine to ensure mistakes remain likely = because logical processing errors are never admitted, given clear = warning, or directly fixed without added overhead. =  

A false sense of assurance remains a = concern for SPF heavily exploited by Kelihos botnets, for example. =  Neither SPF nor DKIM can be used to hold domains sending malicious = email accountable because neither authenticates actual sources. =  Authenticating the source by domain is the only practical way to = combat phishing that remains impractical when using just DKIM or SPF. =  Misguided DMaRC requirements are attempting to force = standardization on weak protocols destined to prolong abuse and = associated damage.  Lawsuits related to abuse blocking often = involve substantial sums where evidence must be rock = solid.

this = does not include redirecting accepted messages to = destinations
neither specified by senders nor = recipients.

This is not a problem restricted to = DMARC.  Any protocol that involves
forwarding a message to a = third party (eg, the Sender field or
Return-Path) raises this issue = (eg, in the case of a typo in the
recipient mailbox name).  It's = true that DMARC seems designed to cause
such = problems.

DMaRC along with DKIM and = SPF were carefully designed to avoid authenticating domains often well = compensated for having sourced abuse.  Despite such an obvious = defect in these plutocratic schemes, almost every related authorization = reporting method erroneously includes Authentication in = their title.  What is standing the the way of DANE deployment for = both client and = server?

Regards,
Douglas = Otis
= --Apple-Mail=_5328FB32-0D9E-45DB-8BDF-4B98DD03D64E-- From nobody Tue Nov 25 02:49:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5181B1A00C2 for ; Tue, 25 Nov 2014 02:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O8FdkaugTlf for ; Tue, 25 Nov 2014 02:49:27 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6107B1A00C0 for ; Tue, 25 Nov 2014 02:49:26 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 97ABE1C3965; Tue, 25 Nov 2014 19:49:25 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 740681A2CE6; Tue, 25 Nov 2014 19:49:25 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <065B07D0-FF4A-47F0-B527-6064D1A705F7@gmail.com> References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> <546F8A6D.30203@sonnection.nl> <4FFF0B20-0D1A-4CA7-8906-6BF0245AF6DF@gmail.com> <87zjbjsk10.fsf@uwakimon.sk.tsukuba.ac.jp> <065B07D0-FF4A-47F0-B527-6064D1A705F7@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 25 Nov 2014 19:49:25 +0900 Message-ID: <871torsgga.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/veQqDPI7nTfoQxYtqG8rOX4OHn4 Cc: dmarc , Tim Draegen Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 10:49:29 -0000 Douglas Otis writes: > Rather than issuing click through agreements to in essence say "All > your email must represent direct transactions from the provider." > they could offer users a friendly SMTP compatible and safe solution > that provides MUA configurations that expose aligned Sender header > fields in lieu of aligned From header fields. I think implementing this suggestion would a disservice to the users at both ends. The requisitioning author (a business) wants *her* address, not the 3rd party's (Intuit's) address visible. The recipient *also* wants to see and has a trust relationship with the requisitioning author, not with Intuit. This is not about MUAs AFAICS, it's about how an Author Domain can tell a recipient MTA (DMARC verifier) that a particular sending MTA may use the Author Domain in From. This needs no help from the MUA (unless it's a DMARC verifier itself), and need not be visible at all to the user. > What is standing the the way of DANE deployment for both client and > server? Money and competent sysadmin time sound like candidates to me. From nobody Tue Nov 25 05:35:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD7D1A01EA for ; Tue, 25 Nov 2014 05:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.621 X-Spam-Level: * X-Spam-Status: No, score=1.621 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPy-5O3ksQCd for ; Tue, 25 Nov 2014 05:35:14 -0800 (PST) Received: from ftp.catinthebox.net (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 223AE1A0A85 for ; Tue, 25 Nov 2014 05:35:14 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5323; t=1416922506; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=QHUcmIjY59CWz5jF6rrdwOQMlFM=; b=VfjV3qnJMVg7SAs/7asH ZRRRGzcx6z4e+qPnkoVihHCUfK+K5zuQFz1TMWA/EQj1leu0fNCPxENjker5sWm3 c9P1thyuhTna2crotDI5yTzseVJxD55uXoz6fBujAhZTbVU85bJvld/97B4WHfi2 JJ7O1h7+F1y2INLBIcTc6Uk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 25 Nov 2014 08:35:06 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3517560515.1972.5396; Tue, 25 Nov 2014 08:35:04 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5323; t=1416922513; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Yu+3xvB OC5TViAS5+NKdPG4oXqTYaiymGevojrjBtTw=; b=p/5usAPiAWA7VZRqTIx1uew qX60h/bXE2jIDofqctn3q+UbzpJAH3D/glnBdRd3OjMUjJpYnbL26jbfvwUw05DB PAkogE1GfCoJfVD6PzjQro5jk4l6KrptIotMGvdHd1U4R0j6FPhblOV5WbJJmLJL SMSi0DlfNQhaX+UM58J0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 25 Nov 2014 08:35:13 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2109950970.9.2384; Tue, 25 Nov 2014 08:35:12 -0500 Message-ID: <54748585.1070505@isdg.net> Date: Tue, 25 Nov 2014 08:35:01 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tim Draegen , dmarc References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> In-Reply-To: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xY_NGh_EdFgo7Nb-kmGLmDoggo0 Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 13:35:19 -0000 On 11/21/2014 12:56 PM, Tim Draegen wrote: > WG, > > The work found here: > > http://trac.tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki > > ..is almost complete. However, there is a note (reinforced by > feedback during the recent in-person meeting) to recast the collected > issues in terms of RFC 5598. Once this recasting is done, Milestone 1 > will be officially met. > > If you’re handy with the language found in RFC 5598, please consider > helping out. Getting the language correct now will only make > everything better later on. Hi Tim, I did participate and was acknowledged in the production of RFC5598. Since I like to get my main points out of the way, here goes. One of my very few concerns at the time I envisioned during RFC5598 production is that its used SIEVE as its baseline "IETF" standard language for hooking in scripts. Understood, the email architectural document wanted to cover IETF sanctioned protocols and documents. Thats not the case in reality with different system using different server-side hooking language. In addition, it made an assumption that POST SMTP (after the mail is accepted) processing was the way things were done. See Figure 5: "Protocols and Services." When RFC5598 was produced "SPF" was still a "TABOO" among the IETF key cogs. It was a new "experiment" so clearly it was not going to get the attention it needed for an example of SMTP dynamic processing (before acceptance). It is a known fact, many of the key IETF folks were against SPF at the time. So the idea of spawning a job, shim, hook, what have you off SMTP states was still something that was still not widely acceptable. You had to be an advanced package to do this, a more nimble package/vendor/service to explore the more modern stuff. In fact, some folks was surprised to learn, dynamic SMTP filter processing was indeed increasing in practice when SPF was becoming more popular and DKIM itself began to be deployed at the DATA state hence raising issues about increasing SMTP session TIME delays. Major discussions about this about delaying/scaling high throughout systems. We have an very old RFC that raise that point about increasing sessions time that could cause SMTP client drops to occur, hence concerns about dupes, etc. I felt that better hardware and speeds was changing all this which is why DKIM and DMARC are now possible at DATA today. SIEVE, at the time, also didn't have DNS lookup capabilities so that would need to be added to the SIEVE language if it wants to be used as an example IETF sanction scripting tool for add-on protocols, like SPF, DKIM and DMARC, and even DNS RBL stuff. In short, RFC5598, nearly a 10 year old document itself, does need updating itself to FIT the more modern DYNAMIC SMTP level and data filtering models in existence today. The SIEVE description in section 4.1.0 added at the time, I considered "open-ended" enough to not be terribly locked down, but it does need updating. RFC5595 needs to be more open-ended in this regard. The whole idea of how any SMTP LEVEL FILTER and/or POST SMPT (POST ACCEPTANCE) FILTER is done should be talked about at length because that is how its going to be different among systems, including whether or not they can actually do the stuff we want to do with a multiple protocol add-on DMARC Policy layer. Just consider what the programmers are using for the scripting tools. You are seeing LUA out there now. But you are not going to see that with other systems. It shouldn't matter what they use, all this needs to be generalized. But the key point, not all of them is going to be using SIEVE. > PS. A group of editors spontaneously formed during the in-person > meeting. The group will tackle Milestone 2 — which is to transform > issues learned and documented in Milestone 1 + proposed solutions for > each into a real reviewable draft. This is not a closed group, so if > you’d like to be actively involved, just say so. I prefer to review the ideas before they are written and burned in stone, because if there is one thing I learn among the authors here, once its written, its very hard to correct at that point. Too high a burden. Many of the key problems we have today with DKIM is because of exactly this point, the document were changed and it was now a higher burden to make the corrections, i.e. the importance and exclusion of the Author Domain Identity from the DKIM specification, getting that idea back into the equation was lost, hence the problem we have today. DKIM is a TRUST document. DMARC is about SELF-SIGNING POLICY document. I also consider SPF a DOMAIN POLICY specification. DKIM excluded the self-signing part (when the IETF draft standard was ADSP) and was left only with TRUST model. Ideally that fine, but think code. If one is only looking at DKIM, SPF and not ADSP, oops, I mean DMARC, then passing the author to the filtering components is less important. Designers need to know, the author identity is part of the software interfacing and that means DATA and/or POST SMTP processing. DKIM itself SHOULD be updated (perhaps an errata) to get the model corrected for passing the one required binding header 5322.From passed into the assessment model. -- HLS From nobody Tue Nov 25 17:36:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0DF1A89D3 for ; Tue, 25 Nov 2014 17:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceLGmVswGomv for ; Tue, 25 Nov 2014 17:36:31 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DDF1A89AC for ; Tue, 25 Nov 2014 17:36:20 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id y10so1711162pdj.21 for ; Tue, 25 Nov 2014 17:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=0SdJyIwoFvYgR+MrV3U++Dw5VHLUhiW9wkTgkvHanCU=; b=oo+NrNo7G8Hoeik3Vm5ZG+CTfIlZbnU9g6h+afQjR+W81Dub9rH5nKAI4syQ6TnslD OipDScqJQIPP9vAN1LT6D5DDk2c9ciuV2uHtJSDz+9UKezaYtIs3Lnbwgk2uvTC7KHvl eD5GXNKQU2v8V7z20lUjwgBD3W+OuZWLgL/b3MAlF7mRHid8kvf2OUnMoe87cSWOJovr ilc8vIu6PQeCjGv0RnAkrKqvK7d7a4+aE8RK3BHkR+pBk+hbspTtZawFFXoQEtfBiQFj FOLzbXaXCv1eOSGt8j/aILFvGi3VMcSYy5aUp3cTtjBs59V0AqNJ1eiIIH9HczCrCTSm r12Q== X-Received: by 10.70.91.40 with SMTP id cb8mr49092235pdb.19.1416965780060; Tue, 25 Nov 2014 17:36:20 -0800 (PST) Received: from [192.168.2.227] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id fm9sm2645640pab.40.2014.11.25.17.36.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Nov 2014 17:36:19 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_084C77B0-726B-4803-9611-85372245702A" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <871torsgga.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 25 Nov 2014 17:36:18 -0800 Message-Id: <3B08EBA9-B87D-4C01-BE3A-9C60934C19AE@gmail.com> References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> <546F8A6D.30203@sonnection.nl> <4FFF0B20-0D1A-4CA7-8906-6BF0245AF6DF@gmail.com> <87zjbjsk10.fsf@uwakimon.sk.tsukuba.ac.jp> <065B07D0-FF4A-47F0-B527-6064D1A705F7@gmail.com> <871torsgga.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1U4BtuEYGuR2JroXueFWspcg8nc Cc: dmarc , Tim Draegen , Douglas Otis Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 01:36:34 -0000 --Apple-Mail=_084C77B0-726B-4803-9611-85372245702A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 25, 2014, at 2:49 AM, Stephen J. Turnbull = wrote: > Douglas Otis writes: >=20 >> Rather than issuing click through agreements to in essence say "All >> your email must represent direct transactions from the provider." >> they could offer users a friendly SMTP compatible and safe solution >> that provides MUA configurations that expose aligned Sender header >> fields in lieu of aligned =46rom header fields. >=20 > I think implementing this suggestion would a disservice to the users > at both ends. The requisitioning author (a business) wants *her* > address, not the 3rd party's (Intuit's) address visible. The > recipient *also* wants to see and has a trust relationship with the > requisitioning author, not with Intuit. This is not about MUAs > AFAICS, it's about how an Author Domain can tell a recipient MTA > (DMARC verifier) that a particular sending MTA may use the Author > Domain in From. Dear Stephen, Sorry for not being clear. In the example given, this assumes a = third-party service might be for a small outfit operating on a thin = budget using an accounting firm to send messages on their behalf. = Messages being sent may include a small outfit's email address assigned = by their Internet provider in the =46rom header field as permitted by = RFC5322. Only by including known entities in the =46rom header field = will intended recipients be able to recognize their relationship with = the author (the defined role of the =46rom header field). To permit = third-party services, it is also absolutely essential to recognize the = role of Sender header fields as a means to properly retain the role of = the =46rom header field. =20 To be compliant with SMTP, policy must permit acceptance of Sender = header fields representing the agent responsible for message = transmission per RFC5322. This scenario could apply in any number of = situations, nor should this be dismissed with a suggestion there are = =46rom header field re-write work-arounds to deal with DMaRCs' = disruption which defeats the explicit role of the =46rom header field = and ignores the role of the Sender header field. Whether for = mailing-lists such as this, financial services by an accounting firm, or = the forwarding of messages from alumni accounts, the whole email address = in the =46rom header field plays a vital role and MUST NOT be considered = to represent the property or the brand of the provider. The email = address represents the inbox of the individual author. Only by allowing policy alignment acceptance based on the Sender header = field, especially for domains providing general email service, the =46rom = header field containing the recognized entity would be displayed as it = is now, in addition to an aligned Sender header field indicating that = the message past through the third-party service. Mailing-lists often = ensure their role is clearly indicated by adding tags in the Subject = header field, but this can also be done using Outlook's "on behalf of" = which combines the Sender header field together with that of the From, = or simply displaying the Sender header field which is often an option = available in the MUA. What was meant by "in lieu of aligned =46rom header fields" was to = permit acceptance based on the Sender header field as well. The = TPA-Label scheme can also offer the mechanism you described. > This needs no help from the MUA (unless it's a DMARC verifier itself), > and need not be visible at all to the user. Disagree. Asserting policy that attempts to minimize successful = spoofing of transactional domains is being misapplied when solely based = on the =46rom header field against domains that offer general purpose = email services as defined by RFC5321/RFC5322 et al. Displaying the = Sender header field as an additional field, or in the form of "on behalf = of", would make successful phishing far less likely. TPA-Label can be = used to ensure good actors are accepted while being less dependent on = caution asserted by recipients. This is a service we would be willing = to offer a large provider to demonstrate the practicality and the = scalability of this approach. The goal is to retain the agility and = utility that had been offered by email. As it currently stands, the only quick fix for the abusive misuse of = DMaRC policy has been to change "reject" to "quarantine". Another = remedy might be to systematically include the Sender header field in = alignment assessments where the domains then need to ensure the proper = display of the message source. Regards, Douglas Otis --Apple-Mail=_084C77B0-726B-4803-9611-85372245702A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 25, 2014, at 2:49 AM, = Stephen J. Turnbull <stephen@xemacs.org> = wrote:

Douglas Otis = writes:

Rather than issuing click = through agreements to in essence say "All
your email must represent = direct transactions from the provider."
they could offer users a = friendly SMTP compatible and safe solution
that provides MUA = configurations that expose aligned Sender header
fields in lieu of = aligned =46rom header fields.

I think implementing = this suggestion would a disservice to the users
at both ends. =  The requisitioning author (a business) wants *her*
address, not = the 3rd party's (Intuit's) address visible.  The
recipient = *also* wants to see and has a trust relationship with = the
requisitioning author, not with Intuit.  This is not about = MUAs
AFAICS, it's about how an Author Domain can tell a recipient = MTA
(DMARC verifier) that a particular sending MTA may use the = Author
Domain in From.

Dear = Stephen,

Sorry for not being clear.  In = the example given, this assumes a third-party service might be for a = small outfit operating on a thin budget using an accounting firm to send = messages on their behalf.  Messages being sent may include a small = outfit's email address assigned by their Internet provider in the =46rom = header field as permitted by RFC5322.  Only by including known = entities in the =46rom header field will intended recipients be able to = recognize their relationship with the author (the defined role of the = =46rom header field).  To permit third-party services, it is also = absolutely essential to recognize the role of Sender header fields as a = means to properly retain the role of the =46rom header field. =  

To be compliant with SMTP, policy must = permit acceptance of Sender header fields representing the agent = responsible for message transmission per RFC5322.  This scenario = could apply in any number of situations, nor should this be dismissed = with a suggestion there are =46rom header field re-write work-arounds to = deal with DMaRCs' disruption which defeats the explicit role of the =46rom= header field and ignores the role of the Sender header field. =  Whether for mailing-lists such as this, financial services by an = accounting firm, or the forwarding of messages from alumni accounts, the = whole email address in the =46rom header field plays a vital role and = MUST NOT be considered to represent the property or the brand of the = provider.  The email address represents the inbox of the individual = author.

Only by allowing policy alignment = acceptance based on the Sender header field, especially for domains = providing general email service, the =46rom header field containing the = recognized entity would be displayed as it is now, in addition to an = aligned Sender header field indicating that the message past through the = third-party service.  Mailing-lists often ensure their role is = clearly indicated by adding tags in the Subject header field, but this = can also be done using Outlook's "on behalf of" which combines the = Sender header field together with that of the From, or simply displaying = the Sender header field which is often an option available in the = MUA.

What was meant by "in lieu of aligned =46rom= header fields" was to permit acceptance based on the Sender header = field as well. The TPA-Label&nbs= p;scheme can also offer the mechanism you = described.

This needs no = help from the MUA (unless it's a DMARC verifier itself),
and need not = be visible at all to the = user.

Disagree.  Asserting = policy that attempts to minimize successful spoofing of transactional = domains is being misapplied when solely based on the =46rom header field = against domains that offer general purpose email services as defined by = RFC5321/RFC5322 et al.  Displaying the Sender header field as an = additional field, or in the form of "on behalf of", would make = successful phishing far less likely.  TPA-Label can be used to = ensure good actors are accepted while being less dependent on caution = asserted by recipients.  This is a service we would be willing to = offer a large provider to demonstrate the practicality and the = scalability of this approach.  The goal is to retain the agility = and utility that had been offered by email.

As = it currently stands, the only quick fix for the abusive misuse of DMaRC = policy has been to change "reject" to "quarantine".  Another remedy = might be to systematically include the Sender header field in alignment = assessments where the domains then need to ensure the proper display of = the message source.

Regards,
Douglas = Otis

= --Apple-Mail=_084C77B0-726B-4803-9611-85372245702A-- From nobody Tue Nov 25 21:34:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6681A883E for ; Tue, 25 Nov 2014 20:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovss01XWBWB0 for ; Tue, 25 Nov 2014 20:23:42 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D0A2E1A87CB for ; Tue, 25 Nov 2014 20:23:41 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id A13C71C38F1; Wed, 26 Nov 2014 13:23:40 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 870891A273D; Wed, 26 Nov 2014 13:23:40 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <3B08EBA9-B87D-4C01-BE3A-9C60934C19AE@gmail.com> References: <050157CF-A203-495A-BBDB-781AC3A1DB00@eudaemon.net> <546F8A6D.30203@sonnection.nl> <4FFF0B20-0D1A-4CA7-8906-6BF0245AF6DF@gmail.com> <87zjbjsk10.fsf@uwakimon.sk.tsukuba.ac.jp> <065B07D0-FF4A-47F0-B527-6064D1A705F7@gmail.com> <871torsgga.fsf@uwakimon.sk.tsukuba.ac.jp> <3B08EBA9-B87D-4C01-BE3A-9C60934C19AE@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 26 Nov 2014 13:23:40 +0900 Message-ID: <87sih6r3n7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DCPpv8GH8piDJC6U12GkEnr0-6w X-Mailman-Approved-At: Tue, 25 Nov 2014 21:34:16 -0800 Cc: Tim Draegen , dmarc Subject: Re: [dmarc-ietf] milestone 1 *almost* done X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 04:23:44 -0000 Douglas Otis writes: > Sorry for not being clear. In the example given, this assumes a > third-party service might be for a small outfit operating on a thin > budget using an accounting firm to send messages on their behalf. The use case is well-understood. I wish you'd stop assuming people have no clue. > To permit third-party services, it is also absolutely essential to > recognize the role of Sender header fields as a means to properly > retain the role of the From header field. Nobody has ever suggested anything else. In particular, DMARC does not deprecate the Sender field in any way. DMARC is based on the hypothesis that phishing is most dangerous when the user believes that the *author* of a message is a familiar entity. That author is the entity in the From field, not anywhere else. That "From is author" (who may have delegated content creation to a third party as in the use case above, but who remains responsible for that content) is the RFC specification, my personal practice, and strongly supported by years of experience on Mailman channels with users confused by Outlook's "on behalf of" presentation. These users often understand "on behalf of" to mean that Sender is the author, and believe that the author is no longer responsible for content. That phishing is most facilitated by spoofing the From field seems plausible to me, but as I see it your task is to convince Yahoo! and AOL, not me and not the IETF. Or perhaps you can sell third-party sender auth to banks and government agencies who want to allow their representatives to participate in mailing lists like this one with their "official" addresses, and maybe Yahoo! and AOL will go along. > Whether for mailing-lists such as this, financial services by an > accounting firm, or the forwarding of messages from alumni > accounts, the whole email address in the From header field plays a > vital role and MUST NOT be considered to represent the property or > the brand of the provider. The email address represents the inbox > of the individual author. It does not. It represents whatever the terms of service for the inbox say. This is a problem of contract law, not of the email protocol. DMARC does not take a stand on terms of service AFAICS, but does warn that "p=reject" is inappropriate when those terms provide that the email address denotes a personal inbox. I agree with you that failure of DMARC to provide for cases where authentication of Sender would provide information useful to the recipient is a major issue. However, I don't see how DMARC deprecates such authentication in any way. The reason it hasn't been developed, I believe, is that the banks don't need it and AOL and Yahoo! are pretty sure it would entail large on-going costs if it existed so they would not use it, either. If you have a protocol that can provide authentication for third-party senders, go sell it to Yahoo! and AOL. > > This needs no help from the MUA (unless it's a DMARC verifier itself), > > and need not be visible at all to the user. > > Disagree. [...] Displaying the Sender header field as an > additional field, or in the form of "on behalf of", would make > successful phishing far less likely. Do you have evidence for that? My experience says that displaying the Sender field would probably confuse many users who clearly do not know the difference between "From" and "Sender", while I *know for a fact* that "on behalf of" engenders such confusion. I see no reason to suppose such confusion would reduce the effectiveness of phishing. > TPA-Label can be used to ensure good actors are accepted > while being less dependent on caution asserted by recipients. I'm sure it can. But nobody cares what I think, except a few of my friends. What matters is what "p=reject" abusers think. Go forth and sell to *them*! Note well: they are not participating in this debate on this list. I know what conclusion I draw from that. http://snoopyandthegang.weebly.com/page-14.html From nobody Wed Nov 26 10:10:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844521A0373 for ; Wed, 26 Nov 2014 10:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.597 X-Spam-Level: X-Spam-Status: No, score=-12.597 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URIBL_GREY=0.424, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR5K_14BfHcW for ; Wed, 26 Nov 2014 10:10:32 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CC071A017C for ; Wed, 26 Nov 2014 10:10:32 -0800 (PST) Received: from omp1045.mail.ne1.yahoo.com (omp1045.mail.ne1.yahoo.com [98.138.89.253]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id sAQI9InH033085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Nov 2014 10:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1417025359; bh=IJn2rk3O8q/stryLewcoVNLvjLsc9B+Xpjwv5SjCjuw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject; b=JXzbRuTeGkHnFDB3feJkoQ81Cr4hsjR9oyfvPgfe44dvU3IE3JXIQkm611nVJpMRW aASYIGy4ZXjl2mh8gASuKkv58p1mxcFVOuFlQi5TC7wsavBrzi4Hn/Rf29DVREHyRi rI4Bj2UFcz0g2JpGranNxFqI+cQOL2SIqqRPpOsU= Received: (qmail 28742 invoked by uid 1000); 26 Nov 2014 18:09:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1417025358; bh=1rwcJRXqUAJzWCq7+Ti59x8BqpdQIXl0x2xfAF0/cT4=; h=Date:From:Reply-To:To:Message-ID:In-Reply-To:References:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GA0I7dbiNn5GGcKg/oWlj8OPAIRK/jiBftv9tn0jASGKqUOzqMo2K5qiseQiPJVmaEABZiOXkyozg8DwdKjuAMgiCgXZggcocW5kopBvuwD+wumZP77lxNTMYdTU220ysVImKEubP9UFjwMoQq8I6u5yFRMLrM9MVv+kAxov3AU= X-YMail-OSG: v17tAhIVM1mW_u1xAk_jHgzCNbldQ5fslstkTxmZ3Iwuiz90CQqoqbk8noEhKnx 6dB8X9kLJkfddI26fXOydk1lgcjTh4zocSUR0JOD1_DJCf9Gh1q68F2J1Dw9AKbACi9p9FGCMxfZ SWbHEEMkvEBvynRMkgSpCTW83jfkH6YIW82gSyCUsTsEdQb_tzj8by5gfpDF3601as8cgIgawho3 Vi.3qxnoNu1xnr.JHNM_nRV7ma5Va4BEerlekSYpTM9qdwyYquX0Z Received: by 98.138.105.226; Wed, 26 Nov 2014 18:09:17 +0000 Date: Wed, 26 Nov 2014 18:08:16 +0000 (UTC) From: Elizabeth Zwicky To: "Silberman, Sam" , "dmarc@ietf.org" Message-ID: <872410169.52776.1417025296709.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6ak5lM8dqmZfnK6W3HQ3ikI00nM Subject: Re: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Elizabeth Zwicky 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, 26 Nov 2014 18:10:33 -0000 By my calculation, purely indirect mail -- mail that never authenticated -- is a more frequent problem than mail that was broken along the way. If I take a day's worth of data for a couple of end-user domains at p=reject and average them together, and the same for p=none, I get this table: DMARC pass DMARC fail DKIM broken DKIM absent p=reject 95.32% 0.27% 4.41% p=none 30.88% 1.02% 68.10% Much of the absent DKIM, regardless of policy, is horrible mail you wouldn't want to deliver. But even so, there's more good mail in that pile than in the broken DKIM pile. But you should notice that the ratios are also starkly different for p=reject and p=none; there's about 4 times as much broken DKIM mail at p=none as there is at p=reject. There's more than 15 times as much absent DKIM mail (and yes, the p=none domains I average do consistently sign their outbound). So, in practice, it looks like the absent-DKIM mail is faster to change than the broken-DKIM mail. I think both problems need attention. The broken-authentication problem is small, but there's no current solution to it that preserves desired semantics, and the places it happens are important. The never-authenticated problem is not going to be solved by the same solutions, it also affects good mail, and it also involves semantic changes or significant workarounds. In general, the workarounds are more available, because the good never-authenticated mail is strongly dominated by commercial entities; that opens a range of solutions that are less available for many broken-authentication cases. In practice, Intuit's purely third-party mail was not affected in the long term, but was interrupted for a few days. Elizabeth Zwicky On Friday, November 14, 2014 9:52 AM, "Silberman, Sam" wrote: In anticipation of today's DMARC WG meeting, I want to highlight one of the many important use cases. Specifically: Use of "unrelated" outbound SMTP servers Commercial email using free email address Newspaper Sites Reference wiki: https://tools.ietf.org/wg/dmarc/trac/wiki/MilestoneOneWiki Past discussion around these use cases assume the email author has control of the domain they send email from. While it may be true for the world's digital elite (i.e. us), it's not true for everyone. There are billion(s) of people who use "free" or very low cost hosting services to provide email. For many people, switching email providers is hard (or not an option). If their mail bounces, they simply don't have the context to decipher the difference between "mailbox non-existent" and "DMARC policy reject due to non-alignment" Most of the world does not have control over their sending domain. Previous posts have suggested this is a small problem. I respectfully disagree. We need to be focusing on # of users impacted, not percentage of mail bounced. Take the following example: My local PTO (Parent Teacher Organization). They are a volunteer non-profit. They have no time or expertise to deal with technical things like email setup. They can't ask the local school board for email mailbox (local policy, bureaucracy , etc). They have no $$, so they use a free mail service ( pto@dmarc-protected-mailservice.com) When their mail provider switched to p=reject They no longer can email some parents directly who used forwards They no longer can reliably send emails via a 3rd party service provider (ESP) They no longer can reliably send update to community mailing list servers IMO, this is not the 1% use case. It's bigger, much bigger. I don't claim to have all the answers. Telling user like this one to change mail providers solves nothing in the long term. DKIM Forward signatures do have promise and solves some of the issues I've listed above. Ultimately, solving DMARC indirect flows for this user will get us very close to solving indirect flows over the rest of the world. -Sam _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed Nov 26 13:23:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4041A1BBE for ; Wed, 26 Nov 2014 13:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.522 X-Spam-Level: * X-Spam-Status: No, score=1.522 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001, URIBL_GREY=0.424] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_BNdEoo17nK for ; Wed, 26 Nov 2014 13:23:16 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4F01A1B61 for ; Wed, 26 Nov 2014 13:23:16 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id BC569564B87; Wed, 26 Nov 2014 15:23:15 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B460460346; Wed, 26 Nov 2014 15:23:15 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xGUhOABKB8n; Wed, 26 Nov 2014 15:23:15 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 81C2D604D0; Wed, 26 Nov 2014 15:23:15 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 81C2D604D0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1417036995; bh=XvyRD9+MzCMFWeIZI+WTXl1kSTSdzQW4dFsT6XDAooU=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=cGf9da94ifaN2vTsosPl9lCgpIOIKh9EFPgQy9EpJjrZS3f+5FRomn6JD/ECP7geA CcKuMav3yWJr2bokkanglDvZmMkscrQN3lyo5LGeYSnxFa1VZSSJ8CcAUuE7QPMwRt 8bwBA3wxJJDHu6Nc1TZ+7/2r/tFZsQ0aTT9BaUiQ= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6C359604CE; Wed, 26 Nov 2014 15:23:15 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yyr_bO-cKkT8; Wed, 26 Nov 2014 15:23:15 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 4C00360346; Wed, 26 Nov 2014 15:23:15 -0600 (CST) Date: Wed, 26 Nov 2014 15:23:15 -0600 (CST) From: Franck Martin To: Elizabeth Zwicky Message-ID: <60281925.80653.1417036995112.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <872410169.52776.1417025296709.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: Indirect Mail Flows Thread-Index: yBWdH+2nJpsXNtA6QLS521qwxJrOKw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/N8wpTOSMM2XK8pPHHy-8M1k8adg Cc: dmarc@ietf.org, Sam Silberman Subject: Re: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 21:23:17 -0000 ----- Original Message ----- > From: "Elizabeth Zwicky" > To: "Sam Silberman" , dmarc@ietf.org > Sent: Wednesday, November 26, 2014 10:08:16 AM > Subject: Re: [dmarc-ietf] Indirect Mail Flows > > > > By my calculation, purely indirect mail -- mail that never authenticated -- > is a more frequent problem than mail that was broken along the way. > > If I take a day's worth of data for a couple of end-user domains at p=reject > and average them together, and the same for p=none, I get this table: > > > DMARC pass DMARC fail > DKIM broken DKIM absent > p=reject 95.32% 0.27% 4.41% > p=none 30.88% 1.02% 68.10% > > > Much of the absent DKIM, regardless of policy, is horrible mail you wouldn't > want to deliver. But even so, there's more good mail in that pile than in > the broken DKIM pile. > My experience points to the difficulty of DKIM signing bounces. It is notoriously known that postfix cannot DKIM sign the messages it generates(MDN). I wonder if you can pull data to show how many bounces are in the DKIM absent column, they are easy to identify: the Envelope From is empty From nobody Wed Nov 26 14:07:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3AE71A6F97 for ; Wed, 26 Nov 2014 14:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHcIHND0aUiY for ; Wed, 26 Nov 2014 14:07:42 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 221FB1A6EDA for ; Wed, 26 Nov 2014 14:07:42 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so16511321wib.1 for ; Wed, 26 Nov 2014 14:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EMW4skOFK++Ot3xMlTW+VsEn8AAcDIDsB2Gl0gR/Aos=; b=eejCCrQUPdi8QaEccoImhnPp76y+e182myeCkY25y1W0hgLQUgbJqp7G9cbGqEed/8 ouRvLqTWx1o3EH9MQLQEd1Y48xe+SuFxtOuS/EA5W/4kKX/B8bNdaWsSN09tHLV/oOZl wjNcAzTtxbMhuUAUBM9lwm++rT86GUHoJ9Z0qWaITBj5nhC5+p46RYjrwGSKZtWjNRmk Vhl5yvpJhlG/ZJzeSqXruNuK7cC6lsvoC5oIVnsrZsJDitSSfGlKj0pTJ17eqwgJVsWw 0NAAEdZlo8OglTW+OJTlLEaIsTw8XfOKLCZFkNreZEMSZVRegOeMP6ydi/I97tLjHnsd Q/xQ== MIME-Version: 1.0 X-Received: by 10.194.62.76 with SMTP id w12mr34437614wjr.5.1417039660953; Wed, 26 Nov 2014 14:07:40 -0800 (PST) Received: by 10.27.76.134 with HTTP; Wed, 26 Nov 2014 14:07:40 -0800 (PST) In-Reply-To: <60281925.80653.1417036995112.JavaMail.zimbra@peachymango.org> References: <872410169.52776.1417025296709.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com> <60281925.80653.1417036995112.JavaMail.zimbra@peachymango.org> Date: Wed, 26 Nov 2014 14:07:40 -0800 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=047d7ba977a49fba3a0508ca411b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/J82RogvhXW0qz8n1sb59bcj1Nx8 Cc: Sam Silberman , "dmarc@ietf.org" , Elizabeth Zwicky Subject: Re: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 22:07:45 -0000 --047d7ba977a49fba3a0508ca411b Content-Type: text/plain; charset=UTF-8 On Wed, Nov 26, 2014 at 1:23 PM, Franck Martin wrote: > My experience points to the difficulty of DKIM signing bounces. It is > notoriously known that postfix cannot DKIM sign the messages it > generates(MDN). > sendmail also has this limitation. The reason for both is that the plugin interface they provide is typically how DKIM signing is accomplished, but the interface is by definition only applied to incoming SMTP connections (including from localhost, for outgoing mail), and MDNs are generated internally, bypassing the SMTP server code. -MSK --047d7ba977a49fba3a0508ca411b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 26, 2014 at 1:23 PM, Franck Martin <fr= anck@peachymango.org> wrote:
My experience point= s to the difficulty of DKIM signing bounces. It is notoriously known that p= ostfix cannot DKIM sign the messages it generates(MDN).

sendmail also has this limitation.=C2=A0 The reason for bo= th is that the plugin interface they provide is typically how DKIM signing = is accomplished, but the interface is by definition only applied to incomin= g SMTP connections (including from localhost, for outgoing mail), and MDNs = are generated internally, bypassing the SMTP server code.

-MSK
--047d7ba977a49fba3a0508ca411b-- From nobody Wed Nov 26 14:29:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D431A7034 for ; Wed, 26 Nov 2014 14:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_GREY=0.424] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPlBjXrAlc5N for ; Wed, 26 Nov 2014 14:29:36 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id A5A691A7D84 for ; Wed, 26 Nov 2014 14:29:36 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 4BD46564EE0; Wed, 26 Nov 2014 16:29:36 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 42E4F604A3; Wed, 26 Nov 2014 16:29:36 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlaU2gaz2i8w; Wed, 26 Nov 2014 16:29:36 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 13EE8604D4; Wed, 26 Nov 2014 16:29:36 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 13EE8604D4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1417040976; bh=RPO2RvuP2Ke4N35dp70cXt5vEdgZ5LV2adt6vhrKv1Y=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=UDLn5iY5fSaYEgvzneIr0IoDm2fGElrYVVqvFIRv9no8E2/k55d0Ey+opkCrhYhl2 WOs2/G1OfKvyhUxyFYR1FWGl+Tm/KQMUud4hweQCyYmNpKHUehMJ/7HVa3mHdoG3Ov bPVQM8LtXOx95vcj1knyd/oLZ+YkddiYxrQDLZqw= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id F0FDB604D5; Wed, 26 Nov 2014 16:29:35 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id t4RazBlqOfd9; Wed, 26 Nov 2014 16:29:35 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id D5F2C604D4; Wed, 26 Nov 2014 16:29:35 -0600 (CST) Date: Wed, 26 Nov 2014 16:29:35 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <929138918.82130.1417040975754.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <872410169.52776.1417025296709.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com> <60281925.80653.1417036995112.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_82129_915919509.1417040975754" X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: Indirect Mail Flows Thread-Index: BF99YKjAzA82vIx7meEoq0GOdKwrkQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LlyuOTzvK6NuDTEw00jM-WnGGTc Cc: dmarc@ietf.org, Sam Silberman , Elizabeth Zwicky Subject: Re: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2014 22:29:38 -0000 ------=_Part_82129_915919509.1417040975754 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "Sam Silberman" , dmarc@ietf.org, > "Elizabeth Zwicky" > Sent: Wednesday, November 26, 2014 2:07:40 PM > Subject: Re: [dmarc-ietf] Indirect Mail Flows > On Wed, Nov 26, 2014 at 1:23 PM, Franck Martin < franck@peachymango.org > > wrote: > > My experience points to the difficulty of DKIM signing bounces. It is > > notoriously known that postfix cannot DKIM sign the messages it > > generates(MDN). > > sendmail also has this limitation. The reason for both is that the plugin > interface they provide is typically how DKIM signing is accomplished, but > the interface is by definition only applied to incoming SMTP connections > (including from localhost, for outgoing mail), and MDNs are generated > internally, bypassing the SMTP server code. I guess these two (sendmail and postfix) are the backbone of many appliances... Therefore it is important to read http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 on how to setup SPF to work with bounces. I know (or have known) several large properties that did not have this setup. Unfortunately, bounces are not very visible and it is hard to stop sending emails to an invalid address if you cannot receive bounces due to policy. ------=_Part_82129_915919509.1417040975754 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Franck Martin" <franck@peachymango.org><= br>Cc: "Sam Silberman" <ssilberman@constantcontact.com>, dmarc= @ietf.org, "Elizabeth Zwicky" <zwicky@yahoo-inc.com>
Sent: = Wednesday, November 26, 2014 2:07:40 PM
Subject: Re: [dmarc-ietf]= Indirect Mail Flows

On Wed, Nov 26, 201= 4 at 1:23 PM, Franck Martin <franck@peachymango.org> wr= ote:
My experience points to the difficulty of DKIM signing bo= unces. It is notoriously known that postfix cannot DKIM sign the messages i= t generates(MDN).

sendmail also has thi= s limitation.  The reason for both is that the plugin interface they p= rovide is typically how DKIM signing is accomplished, but the interface is = by definition only applied to incoming SMTP connections (including from loc= alhost, for outgoing mail), and MDNs are generated internally, bypassing th= e SMTP server code.
I guess these = two (sendmail and postfix) are the backbone of many appliances...
=

Therefore it is important to read http://trac.tools.ietf.org= /html/rfc7208#section-10.1.3 on how to setup SPF to work with bounc= es.

I know (or have known) several large prope= rties that did not have this setup. Unfortunately, bounces are not very vis= ible and it is hard to stop sending emails to an invalid address if you can= not receive bounces due to policy.
------=_Part_82129_915919509.1417040975754-- From nobody Wed Nov 26 16:35:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8771A020B for ; Wed, 26 Nov 2014 16:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 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, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_GREY=0.424] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSIP9doNTI1p for ; Wed, 26 Nov 2014 16:35:39 -0800 (PST) Received: from smtp.anubisnetworks.com (smtp.anubisnetworks.com [195.22.26.198]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CE31A0171 for ; Wed, 26 Nov 2014 16:35:39 -0800 (PST) Received: from rhea.anubis.local (localhost [127.0.0.1]) by smtp.anubisnetworks.com (Postfix) with ESMTP id 3jp0PM4w04z2xvM for ; Thu, 27 Nov 2014 00:35:35 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by rhea.anubis.local (Postfix) with ESMTP id 3jp0PM3p6Kz2xvT for ; Thu, 27 Nov 2014 00:35:35 +0000 (WET) Received: from zimbra2.anubis.via (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id 48BE2383B3E for ; Thu, 27 Nov 2014 00:35:35 +0000 (WET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id 32FEA383BF0 for ; Thu, 27 Nov 2014 00:35:35 +0000 (WET) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra2.anubis.via 32FEA383BF0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anubisnetworks.com; s=DE5D398A-DC66-11E3-92F6-76AE37576441; t=1417048535; bh=5Hp6e+6H45HNE+ET1jBfs79EcUvOAaTxRrmhwqjcAbU=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=SrKhCAloPRlYnwPy4CvRD9LEjUvKFZTLVVlT1nyFPogo5+1HWky2iXCj8ySbXSQG7 adqI1pleRAq+t6afUvzQio1I0FttHwpy94Rd0CSWPqoHNqW76o0iZzpTxmR36BuW91 ZPWzifAKY1easO4TfIdjvhd+RDBCKaNbX3dbGVH0= Received: from zimbra2.anubis.via ([127.0.0.1]) by localhost (zimbra2.anubis.via [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4aUzTMv9UlyG for ; Thu, 27 Nov 2014 00:35:35 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by zimbra2.anubis.via (Postfix) with ESMTP id 1E783383B3E for ; Thu, 27 Nov 2014 00:35:35 +0000 (WET) Date: Thu, 27 Nov 2014 00:35:35 +0000 (WET) From: =?utf-8?B?Sm9zw6k=?= Ferreira To: dmarc@ietf.org Message-ID: <124240094.2046785.1417048535075.JavaMail.zimbra@anubisnetworks.com> In-Reply-To: References: <872410169.52776.1417025296709.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com> <60281925.80653.1417036995112.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2046784_1346225498.1417048535074" X-Mailer: Zimbra 8.0.8_GA_6184 (ZimbraWebClient - GC39 (Linux)/8.0.8_GA_6184) Thread-Topic: Indirect Mail Flows Thread-Index: 0cL60bIKy7dq83HduYwrDUQg0L6vPA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/OCJcMC5A7p27lL7xOJX5WbG91qA Subject: Re: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 00:35:42 -0000 ------=_Part_2046784_1346225498.1417048535074 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "Sam Silberman" , dmarc@ietf.org, > "Elizabeth Zwicky" > Sent: Wednesday, November 26, 2014 10:07:40 PM > Subject: Re: [dmarc-ietf] Indirect Mail Flows > On Wed, Nov 26, 2014 at 1:23 PM, Franck Martin < franck@peachymango.org > > wrote: > > My experience points to the difficulty of DKIM signing bounces. It is > > notoriously known that postfix cannot DKIM sign the messages it > > generates(MDN). >=20 > sendmail also has this limitation. The reason for both is that the plugin > interface they provide is typically how DKIM signing is accomplished, but > the interface is by definition only applied to incoming SMTP connections > (including from localhost, for outgoing mail), and MDNs are generated > internally, bypassing the SMTP server code. Funny you mention it=20 Postfix doesn't have that issue. It can sign bounces, opendkim rejects the = default From address provided by Postfix.=20 opendkim[5120]: 3jnzZZ1h1Lz2pG1f: can't parse From: header value ' MAILER-D= AEMON (Mail Delivery System)'=20 With DefaultSender set you can overcome this.=20 Jos=C3=A9 Borges Ferreira=20 AnubisNetworks=20 ------=_Part_2046784_1346225498.1417048535074 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

From: "Murray S.= Kucherawy" <superuser@gmail.com>
To: "Franck Martin" <f= ranck@peachymango.org>
Cc: "Sam Silberman" <ssilberman@cons= tantcontact.com>, dmarc@ietf.org, "Elizabeth Zwicky" <zwicky@yahoo-in= c.com>
Sent: Wednesday, November 26, 2014 10:07:40 PM
Su= bject: Re: [dmarc-ietf] Indirect Mail Flows

On Wed, Nov 26, 2014 at 1:23 PM, Franck Martin &= lt;franck@peachymango.org> w= rote:
My experience points to the difficulty of DK= IM signing bounces. It is notoriously known that postfix cannot DKIM sign t= he messages it generates(MDN).

sendmail= also has this limitation.  The reason for both is that the plugin int= erface they provide is typically how DKIM signing is accomplished, but the = interface is by definition only applied to incoming SMTP connections (inclu= ding from localhost, for outgoing mail), and MDNs are generated internally,= bypassing the SMTP server code.

Funny you mention it

Postfix doe= sn't have that issue. It can sign bounces, opendkim rejects the default Fro= m address provided by Postfix. 

opendkim[5120]: 3jn= zZZ1h1Lz2pG1f: can't parse From: header value ' MAILER-DAEMON (Mail Deliver= y System)'


With DefaultSender set you can over= come this.

Jos=C3=A9 Borges Ferreira
AnubisNetw= orks
------=_Part_2046784_1346225498.1417048535074-- From nobody Thu Nov 27 03:35:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE211A88D7 for ; Thu, 27 Nov 2014 03:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXmbM0i1dvGF for ; Thu, 27 Nov 2014 03:35:03 -0800 (PST) Received: from smtp.anubisnetworks.com (smtp.anubisnetworks.com [195.22.26.198]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B111A88D8 for ; Thu, 27 Nov 2014 03:35:02 -0800 (PST) Received: from loki.anubis.local (localhost [127.0.0.1]) by smtp.anubisnetworks.com (Postfix) with ESMTP id 3jpH2C484gzD0Cp for ; Thu, 27 Nov 2014 11:34:59 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by loki.anubis.local (Postfix) with ESMTP id 3jpH2C0QNpzCrQf for ; Thu, 27 Nov 2014 11:34:57 +0000 (WET) Received: from zimbra2.anubis.via (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id 9B902383889 for ; Thu, 27 Nov 2014 11:34:57 +0000 (WET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id 86270383D83 for ; Thu, 27 Nov 2014 11:34:57 +0000 (WET) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra2.anubis.via 86270383D83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anubisnetworks.com; s=DE5D398A-DC66-11E3-92F6-76AE37576441; t=1417088097; bh=owt0vFfnq4vZZasSuTPIZ+kfDBs7ax6Z0GHU9JwgCVU=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=UAMZUyIc8U3ioPshzHHB/CGTpj3DEoYZ2pxzCmDakMLMFrQf/7ICZAcWt0pyVOLIw 464HEbv9bmnXsqTCzlmleHc6ix0FXr0BxBkDtlpzcgnEG+ASHlJ2+WW4BwpxW6gCya fOITfMRZzNSnNWpq5GVf1LZevHbiC5c4GuNPGODs= Received: from zimbra2.anubis.via ([127.0.0.1]) by localhost (zimbra2.anubis.via [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 21yGptX2hsin for ; Thu, 27 Nov 2014 11:34:57 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by zimbra2.anubis.via (Postfix) with ESMTP id 72992383889 for ; Thu, 27 Nov 2014 11:34:57 +0000 (WET) Date: Thu, 27 Nov 2014 11:34:57 +0000 (WET) From: =?utf-8?B?Sm9zw6k=?= Ferreira To: dmarc@ietf.org Message-ID: <2140954939.2054796.1417088097368.JavaMail.zimbra@anubisnetworks.com> In-Reply-To: <1614286553.2050289.1417079688432.JavaMail.zimbra@anubisnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.8_GA_6184 (ZimbraWebClient - GC39 (Linux)/8.0.8_GA_6184) Thread-Topic: DMARC and Bounces (was: Indirect Mail Flows) Thread-Index: Z9RANNyfpct7lFPOUJCkvSA8Pfobog== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TOZi_Fa5gKswhHasxGMPXYGFHjE Subject: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 11:35:05 -0000 >From: "Franck Martin" >Sent: Wednesday, November 26, 2014 10:29:35 PM > >Therefore it is important to read http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 on how to setup SPF to work with >bounces. > >I know (or have known) several large properties that did not have this setup. Unfortunately, bounces are not very visible >and it is hard to stop sending emails to an invalid address if you cannot receive bounces due to policy. So let's see how this must work in bounces ( DSN ): Requirements: * For the domain, the RFC5321.EHLO/HELO domain is used if the RFC5321.MailFrom is null. * RFC5321.MailFrom must have a domain. * alignment must exits between RFC5321.MailFrom domain, SPF identifier domain and DKIM's d= value. So a DMARC compliant DSN must: * Have a RFC5321.MailFrom with domain * Must present a HELO/EHLO hostname aligned domain and/or DKIM sign with d= of the same domain. Considerations: * This can be tricky in strict mode. Probably we should define a new specific field to define how this should align. * Some MTAs, at least Postfix, by default generate bounces with "From: MAILER-DAEMON (Mail Delivery System)". Am I missing something ? Jose Borges Ferreira From nobody Thu Nov 27 11:15:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BF11A013B for ; Thu, 27 Nov 2014 11:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWfDZpYrML41 for ; Thu, 27 Nov 2014 11:15:40 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id E48C21A00F4 for ; Thu, 27 Nov 2014 11:15:39 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 63D31564DDE; Thu, 27 Nov 2014 13:15:39 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5E2AF60346; Thu, 27 Nov 2014 13:15:39 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMUHeF7MlYCK; Thu, 27 Nov 2014 13:15:39 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 164B660388; Thu, 27 Nov 2014 13:15:39 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 164B660388 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1417115739; bh=T/p0ZcmaH4+xp5T+APfQq45R60ITZTpRZc0Zp3ioDW4=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=f+0GS7AXSL1XA+587Tb9vWKtCfel+3lSba4pTc7QF5k//7Lra0k3euvfk+qlzDXOZ MFh9lFpox6uApNjgTwJ6c5CYuXvEjMYTp9Gbo0F3+l1QVeLUDRjfOe3hY6+XnGucti TOYv1QHA3J+ORVsE2qxa+zrcr2nMQINzjUb4hSC0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 092E560385; Thu, 27 Nov 2014 13:15:39 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id izNacuYXvVzd; Thu, 27 Nov 2014 13:15:38 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id E397760346; Thu, 27 Nov 2014 13:15:38 -0600 (CST) Date: Thu, 27 Nov 2014 13:15:38 -0600 (CST) From: Franck Martin To: =?utf-8?Q?Jos=C3=A9_Ferreira?= Message-ID: <637340906.90688.1417115738606.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <872410169.52776.1417025296709.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com> <60281925.80653.1417036995112.JavaMail.zimbra@peachymango.org> <124240094.2046785.1417048535075.JavaMail.zimbra@anubisnetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_90687_2096667847.1417115738606" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: Indirect Mail Flows Thread-Index: 0cL60bIKy7dq83HduYwrDUQg0L6vPNZWHrN0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/avKsKUBLfJLs6N14eBXgY_ElVyY Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:15:42 -0000 ------=_Part_90687_2096667847.1417115738606 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Jos=C3=A9 Ferreira" > To: dmarc@ietf.org > Sent: Wednesday, November 26, 2014 4:35:35 PM > Subject: Re: [dmarc-ietf] Indirect Mail Flows > Funny you mention it > Postfix doesn't have that issue. It can sign bounces, opendkim rejects th= e > default From address provided by Postfix. > opendkim[5120]: 3jnzZZ1h1Lz2pG1f: can't parse From: header value ' > MAILER-DAEMON (Mail Delivery System)' > With DefaultSender set you can overcome this. see point 4 on http://www.postfix.org/MILTER_README.html#limitations=20 We are not talking about bounces passing through postfix, but bounces gener= ated by postfix (or sendmail)=20 ------=_Part_90687_2096667847.1417115738606 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Jos=C3=A9 Ferreira" <jose.ferrei= ra@anubisnetworks.com>
To: dmarc@ietf.org
Sent: Wedn= esday, November 26, 2014 4:35:35 PM
Subject: Re: [dmarc-ietf] Ind= irect Mail Flows


Funny= you mention it

Postfix doesn't have that issue. I= t can sign bounces, opendkim rejects the default From address provided by P= ostfix. 

opendkim[5= 120]: 3jnzZZ1h1Lz2pG1f: can't parse From: header value ' MAILER-DAEMON (Mai= l Delivery System)'


With DefaultSender set you= can overcome this.


We are not talking about bounces passing through postfix, but bounce= s generated by postfix (or sendmail)

<= /html> ------=_Part_90687_2096667847.1417115738606-- From nobody Thu Nov 27 11:35:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8921A013B for ; Thu, 27 Nov 2014 11:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 949okoUqNQOA for ; Thu, 27 Nov 2014 11:35:24 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2381A00F4 for ; Thu, 27 Nov 2014 11:35:24 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id C6CEC56507D; Thu, 27 Nov 2014 13:35:23 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id C1D8660346; Thu, 27 Nov 2014 13:35:23 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-6PRAdZkGqd; Thu, 27 Nov 2014 13:35:23 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 962B86038B; Thu, 27 Nov 2014 13:35:23 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 962B86038B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1417116923; bh=nhBWjd5JjUJuN+PNOJZp0OpSta3g0P7+B5shz9Z5/wM=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=eNsoDH3CmeCqAcqKcLIPRXA14yoIMTqmLj+PkkfLjTmMihOBLzx3AstCOp5yFamhs EZqsdThsrB03LP1MMNXIy6dQo/zr0DXx18aUZxgk074fwdjHwkYp2OdGIJxfnsldZV ZCZiXVBTeCdO1aFXsBOr6426id59w7curtuBCaN0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 8013E6038A; Thu, 27 Nov 2014 13:35:23 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Vh4x4aCQFh_L; Thu, 27 Nov 2014 13:35:23 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 66E6360346; Thu, 27 Nov 2014 13:35:23 -0600 (CST) Date: Thu, 27 Nov 2014 13:35:23 -0600 (CST) From: Franck Martin To: =?utf-8?Q?Jos=C3=A9_Ferreira?= Message-ID: <84727963.90926.1417116923261.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <2140954939.2054796.1417088097368.JavaMail.zimbra@anubisnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC and Bounces (was: Indirect Mail Flows) Thread-Index: Z9RANNyfpct7lFPOUJCkvSA8PfobovpEowJV Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Erly7qWWOBuEH9j29BZ2d8HZU1M Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:35:25 -0000 ----- Original Message ----- > From: "Jos=C3=A9 Ferreira" > To: dmarc@ietf.org > Sent: Thursday, November 27, 2014 3:34:57 AM > Subject: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) >=20 > >From: "Franck Martin" > >Sent: Wednesday, November 26, 2014 10:29:35 PM > > > >Therefore it is important to read > >http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 on how to setup S= PF > >to work with >bounces. > > > >I know (or have known) several large properties that did not have this > >setup. Unfortunately, bounces are not very visible >and it is hard to st= op > >sending emails to an invalid address if you cannot receive bounces due t= o > >policy. >=20 > So let's see how this must work in bounces ( DSN ): >=20 > Requirements: > * For the domain, the RFC5321.EHLO/HELO domain is used if the > RFC5321.MailFrom is null. > * RFC5321.MailFrom must have a domain. > * alignment must exits between RFC5321.MailFrom domain, SPF identifier > domain and DKIM's d=3D value. >=20 > So a DMARC compliant DSN must: > * Have a RFC5321.MailFrom with domain > * Must present a HELO/EHLO hostname aligned domain and/or DKIM sign wit= h d=3D > of the same domain. >=20 >=20 > Considerations: > * This can be tricky in strict mode. Probably we should define a new > specific field to define how this should align. > * Some MTAs, at least Postfix, by default generate bounces with "From: > MAILER-DAEMON (Mail Delivery System)". >=20 RFC5321.From (envelope from) must be a valid email address or be null <> RFC5322.From must have a domain (the From Header, not the envelope From RFC= 5321): http://tools.ietf.org/html/rfc5322#section-3.6.2 http://tools.ietf.org/html/rfc5322#section-3.4 from =3D "From:" mailbox-list CRLF mailbox-list =3D (mailbox *("," mailbox)) / obs-mbox-list mailbox =3D name-addr / addr-spec name-addr =3D [display-name] angle-addr angle-addr =3D [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr addr-spec =3D local-part "@" domain As such the construct you indicate is illegal: From: MAILER-DAEMON (Mail Delivery System) http://www.postfix.com/bounce.5.html, it is indeed a problem with postfix o= ut of the box and empty_address_recipient needs to be configured properly. Note: this rule for RFC5322.From may be relaxed by RFC6854 for EAI/SMTPUTF8= compatibility reasons only during the transition. From nobody Thu Nov 27 11:46:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670801A00A9 for ; Thu, 27 Nov 2014 11:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSc4T2Pwg1BR for ; Thu, 27 Nov 2014 11:46:17 -0800 (PST) Received: from smtp.anubisnetworks.com (smtp.anubisnetworks.com [195.22.26.198]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FEF1A013B for ; Thu, 27 Nov 2014 11:46:16 -0800 (PST) Received: from gaia.anubis.local (localhost [127.0.0.1]) by smtp.anubisnetworks.com (Postfix) with ESMTP id 3jpTx23lWtz4xhx; Thu, 27 Nov 2014 19:46:14 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by gaia.anubis.local (Postfix) with ESMTP id 3jpTx23DnDz4xZy; Thu, 27 Nov 2014 19:46:14 +0000 (WET) Received: from zimbra2.anubis.via (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id 13CAE383ADE; Thu, 27 Nov 2014 19:46:14 +0000 (WET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id F38C7383A31; Thu, 27 Nov 2014 19:46:13 +0000 (WET) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra2.anubis.via F38C7383A31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anubisnetworks.com; s=DE5D398A-DC66-11E3-92F6-76AE37576441; t=1417117574; bh=0/fanXUUk0XO/clXrDbi7BBoV98Lo6PmRazQRYl98uE=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=i3stzaeS+LEF0DGf8I39cRvf8xuRbrKp7DbzDTCv0sW1Wj5JpecCFaEKW3tj0hjKu 3ynJfHp5jhYqq32dh0PshcraKlIW3prf2OGQ5ma+xlucU2A/hmRCLC5mFHwCKc2t/m OZwOe2Wq+c0FDWObNXl/Q4exjAvdBuQU5b0Zrar4= Received: from zimbra2.anubis.via ([127.0.0.1]) by localhost (zimbra2.anubis.via [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 59i9W0mbJE3m; Thu, 27 Nov 2014 19:46:13 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by zimbra2.anubis.via (Postfix) with ESMTP id E168338398D; Thu, 27 Nov 2014 19:46:13 +0000 (WET) Date: Thu, 27 Nov 2014 19:46:13 +0000 (WET) From: =?utf-8?B?Sm9zw6k=?= Ferreira To: Franck Martin Message-ID: <2115021985.2113117.1417117573807.JavaMail.zimbra@anubisnetworks.com> In-Reply-To: <637340906.90688.1417115738606.JavaMail.zimbra@peachymango.org> References: <872410169.52776.1417025296709.JavaMail.yahoo@jws10001b.mail.ne1.yahoo.com> <60281925.80653.1417036995112.JavaMail.zimbra@peachymango.org> <124240094.2046785.1417048535075.JavaMail.zimbra@anubisnetworks.com> <637340906.90688.1417115738606.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2113116_746193374.1417117573806" X-Mailer: Zimbra 8.0.8_GA_6184 (ZimbraWebClient - GC39 (Linux)/8.0.8_GA_6184) Thread-Topic: Indirect Mail Flows Thread-Index: 0cL60bIKy7dq83HduYwrDUQg0L6vPNZWHrN0RrfbxMY= Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Emb4ldCATpI-rRVaM-oZtwYXUuc Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Indirect Mail Flows X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Nov 2014 19:46:20 -0000 ------=_Part_2113116_746193374.1417117573806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > From: "Franck Martin" > To: "Jos=C3=A9 Ferreira" > Cc: dmarc@ietf.org > Sent: Thursday, November 27, 2014 7:15:38 PM > > opendkim[5120]: 3jnzZZ1h1Lz2pG1f: can't parse From: header value ' > > MAILER-DAEMON (Mail Delivery System)' >=20 > > With DefaultSender set you can overcome this. >=20 > see point 4 on http://www.postfix.org/MILTER_README.html#limitations > We are not talking about bounces passing through postfix, but bounces > generated by postfix (or sendmail) Nice catch, I'll post that bug on Postfix list . check:=20 http://www.postfix.org/postconf.5.html#non_smtpd_milters=20 http://www.postfix.org/postconf.5.html#internal_mail_filter_classes=20 Here is the relevant parts in the postfix setup:=20 internal_mail_filter_classes =3D bounce=20 non_smtpd_milters =3D inet:127.0.0.1:8888=20 bounce_size_limit =3D 1=20 I use this dedicated openDKIM milter instance for this purpose to override = all DSNs unconditionally.=20 The From in the bounce message may be a problem for DMARC alignment and to = use with SigningTable/KeyTable in openDKIM.=20 To solve that you can copy /usr/share/doc/postfix-doc/examples/bounce.cf.de= fault to /etc/postfix/bounce.cf , edit the file and change the From header.= =20 Then add to main.cf :=20 bounce_template_file=3D/etc/postfix/bounce.cf=20 For openDKIM i use this config.=20 # /etc/opendkim-dsn.conf=20 Syslog yes=20 LogWhy yes=20 UMask 002=20 InternalHosts 127.0.0.1=20 Domain example.net=20 KeyFile /etc/postfix//dkim.key=20 Selector dsnFsdk9=20 Mode s=20 On-BadSignature accept=20 On-DNSError accept=20 On-InternalError accept=20 On-NoSignature accept=20 On-Security accept=20 Canonicalization relaxed/relaxed=20 SignHeaders date,from,subject,to,auto-submitted,mime-version,content-type,m= essage-id=20 AutoRestart True=20 AutoRestartRate 10/1m=20 LogResults yes=20 Hope it helps=20 Jos=C3=A9 Borges Ferreira=20 Anubisnetworks=20 ------=_Part_2113116_746193374.1417117573806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Franck Martin" <franck@peac= hymango.org>
To: "Jos=C3=A9 Ferreira" <jose.ferreira@anubis= networks.com>
Cc: dmarc@ietf.org
Sent: Thursday, Nov= ember 27, 2014 7:15:38 PM

opendkim[5120]: 3jnzZZ1h1Lz2pG1f: can't parse Fr= om: header value ' MAILER-DAEMON (Mail Delivery System)'


=
With DefaultSender set you can overcome this.


We are not talki= ng about bounces passing through postfix, but bounces generated by postfix = (or sendmail)

Nice catch, I'll = post that bug on  Postfix list . check:

Here is the relevant parts in the postfix setup:

=

internal_mail_fi= lter_classes =3D bounce

non_smtpd_milters =3D inet:127.0.0.1:8888
bounce= _size_limit =3D 1



I use this dedicated openDKIM milter instance for= this purpose to override all DSNs unconditionally. 
= The Fr= om in the bounce message may be a problem for DMARC alignment and to use wi= th SigningTable/KeyTable in openDKIM.
To solve that you can= copy /usr/share/doc/postfix-doc/examples/bounce.cf.default to /etc/po= stfix/bounce.cf , edit the file and change the From header.
Then=  add to main.cf :
=

bounce_template_file=3D/etc/post= fix/bounce.cf



For openDKIM i use this config.

# /etc/opendkim-dsn.conf

Syslog yes
LogWhy yes
= UMask 002

Inte= rnalHosts 127.0.0.1
Domain example.net
KeyFile /etc/postfix//dkim.key=
Selector dsnFsdk9

Mode s
On-BadSignature accept
On-DNSError accept
On-Intern= alError accept
On-NoSignature accept
On-Security accept

Canonicalization relaxed/= relaxed
SignHeaders date,from,subject,to,auto-submitted,mime-version,con= tent-type,message-id

AutoRestart True
AutoRestartRate 10/1m

LogResults yes



Hope it helps


Jos=C3=A9 Borges Ferreira

Anubisnetworks


------=_Part_2113116_746193374.1417117573806-- From nobody Fri Nov 28 01:21:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001AC1A1AE7 for ; Fri, 28 Nov 2014 01:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es-5ICGmkpF9 for ; Fri, 28 Nov 2014 01:21:50 -0800 (PST) Received: from smtp.anubisnetworks.com (smtp.anubisnetworks.com [195.22.26.198]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95781A1A94 for ; Fri, 28 Nov 2014 01:21:49 -0800 (PST) Received: from gaia.anubis.local (localhost [127.0.0.1]) by smtp.anubisnetworks.com (Postfix) with ESMTP id 3jpr221hCKz4xZy for ; Fri, 28 Nov 2014 09:21:46 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by gaia.anubis.local (Postfix) with ESMTP id 3jpr220w9bz4xkX for ; Fri, 28 Nov 2014 09:21:45 +0000 (WET) Received: from zimbra2.anubis.via (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id D54793839AD for ; Fri, 28 Nov 2014 09:21:45 +0000 (WET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id BFA4E383B0A for ; Fri, 28 Nov 2014 09:21:45 +0000 (WET) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra2.anubis.via BFA4E383B0A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anubisnetworks.com; s=DE5D398A-DC66-11E3-92F6-76AE37576441; t=1417166505; bh=xOj5WWAX89dmtmmej4SDqbvjAFIFoZzcm+wTWaaHZII=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=I53N49+viczHBaLlBrU0yiIlyrYLcGgKiN4EH4ZRoWy1I6qr/vQzKvYCtY7hvAwiz QR9witXjKD8npJ/vffWnDUI06zMyEDoup1lDwnLweV9surjOYRjRL0XvisqjA9hko/ 3ydVnK81dE9AbxQlOogSUYuTImXLx1FkNt9ad6ow= Received: from zimbra2.anubis.via ([127.0.0.1]) by localhost (zimbra2.anubis.via [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JdTvjZ8N0tOg for ; Fri, 28 Nov 2014 09:21:45 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by zimbra2.anubis.via (Postfix) with ESMTP id ABB953839AD for ; Fri, 28 Nov 2014 09:21:45 +0000 (WET) Date: Fri, 28 Nov 2014 09:21:45 +0000 (WET) From: =?utf-8?B?Sm9zw6k=?= Ferreira To: dmarc@ietf.org Message-ID: <604251448.2117889.1417166505526.JavaMail.zimbra@anubisnetworks.com> In-Reply-To: <84727963.90926.1417116923261.JavaMail.zimbra@peachymango.org> References: <2140954939.2054796.1417088097368.JavaMail.zimbra@anubisnetworks.com> <84727963.90926.1417116923261.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.0.8_GA_6184 (ZimbraWebClient - GC39 (Linux)/8.0.8_GA_6184) Thread-Topic: DMARC and Bounces (was: Indirect Mail Flows) Thread-Index: Z9RANNyfpct7lFPOUJCkvSA8PfobovpEowJVLKBSTjk= Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fMPXiB8nLJlltvjgcsoH7cWMl9o Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 09:21:53 -0000 ----- Original Message ----- > From: "Franck Martin" > To: "Jos=C3=A9 Ferreira" > Cc: dmarc@ietf.org > Sent: Thursday, November 27, 2014 7:35:23 PM > Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) >=20 >=20 > ----- Original Message ----- > > From: "Jos=C3=A9 Ferreira" > > To: dmarc@ietf.org > > Sent: Thursday, November 27, 2014 3:34:57 AM > > Subject: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) > >=20 > > >From: "Franck Martin" > > >Sent: Wednesday, November 26, 2014 10:29:35 PM > > > > > >Therefore it is important to read > > >http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 on how to setup= SPF > > >to work with >bounces. > > > > > >I know (or have known) several large properties that did not have this > > >setup. Unfortunately, bounces are not very visible >and it is hard to = stop > > >sending emails to an invalid address if you cannot receive bounces due= to > > >policy. > >=20 > > So let's see how this must work in bounces ( DSN ): > >=20 > > Requirements: > > * For the domain, the RFC5321.EHLO/HELO domain is used if the > > RFC5321.MailFrom is null. > > * RFC5321.MailFrom must have a domain. > > * alignment must exits between RFC5321.MailFrom domain, SPF identifier > > domain and DKIM's d=3D value. > >=20 > > So a DMARC compliant DSN must: > > * Have a RFC5321.MailFrom with domain > > * Must present a HELO/EHLO hostname aligned domain and/or DKIM sign w= ith > > d=3D > > of the same domain. > >=20 > >=20 > > Considerations: > > * This can be tricky in strict mode. Probably we should define a new > > specific field to define how this should align. > > * Some MTAs, at least Postfix, by default generate bounces with "From: > > MAILER-DAEMON (Mail Delivery System)". > >=20 > RFC5321.From (envelope from) must be a valid email address or be null <> >=20 > RFC5322.From must have a domain (the From Header, not the envelope From > RFC5321): > http://tools.ietf.org/html/rfc5322#section-3.6.2 > http://tools.ietf.org/html/rfc5322#section-3.4 >=20 > from =3D "From:" mailbox-list CRLF >=20 > mailbox-list =3D (mailbox *("," mailbox)) / obs-mbox-list >=20 > mailbox =3D name-addr / addr-spec >=20 > name-addr =3D [display-name] angle-addr >=20 > angle-addr =3D [CFWS] "<" addr-spec ">" [CFWS] / > obs-angle-addr >=20 > addr-spec =3D local-part "@" domain >=20 > As such the construct you indicate is illegal: > From: MAILER-DAEMON (Mail Delivery System) >=20 > http://www.postfix.com/bounce.5.html, it is indeed a problem with postfix= out > of the box and empty_address_recipient needs to be configured properly. >=20 > Note: this rule for RFC5322.From may be relaxed by RFC6854 for EAI/SMTPUT= F8 > compatibility reasons only during the transition. >=20 I think there should be a wider reference to bounces in the draft-kucherawy= -dmarc-base. I know bounces are rare and we try the most to avoid bounces but it happens= and have specific issues that should be addressed differently or , at leas= t, highlighted. Jos=C3=A9 Borges Ferreira AnubisNetworks From nobody Fri Nov 28 09:02:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26D21A01A9 for ; Fri, 28 Nov 2014 09:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBIB1OakDCen for ; Fri, 28 Nov 2014 09:02:09 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03191A008D for ; Fri, 28 Nov 2014 09:02:09 -0800 (PST) Received: from kitterman-optiplex-9020m.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D525AC40029 for ; Fri, 28 Nov 2014 11:02:08 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1417194128; bh=iKNTJh0SUcvmnBpGe8bRoc4wwU/7yWqH4aq4Wdu+kaI=; h=From:To:Subject:Date:From; b=G+bLC8QoDlKulAiNHdXhMQpR3e26KaWMD+VM5cZvWtWAS3QT90vP8t8vXwhPz3lDG c1whwYpyTIXow7MHOzu+Lc21StNaVjAD6DTHQJV1uclCjC4egviX2bZqXBkYlL1jva lMjIbeZSZukqo9ho8SIzlBjQe5EysPiyT+OQqt54= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 28 Nov 2014 12:03 -0500 Message-ID: <3166265.HRXnIIJG70@kitterman-optiplex-9020m> User-Agent: KMail/4.13.3 (Linux/3.13.0-37-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/N_afEPSsnUEemrgsO9AXFGjfc4E Subject: [dmarc-ietf] Using SPF 'Sends no mail' to QA Forwarder detection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Nov 2014 17:02:11 -0000 I was just looking at some data for a domain that's subject to ongoing spoofing. It publishes both a DMARC reject policy (p=reject) and an SPF sends no mail record (v=spf1 -all). I see a small, but persistent, level (< 0.1%) of mail purportedly from this domain marked as forwarded. It occurs to me that providers that are identifying forwarders via their internal processing might use the presence of a sends no mail SPF record as an indicator that something isn't forwarded and if their heuristics believe it is, then there's something not working quite right. This isn't something that is relevant to the current milestone we're working on, but when we get to best practices, it may be, so I wanted to go ahead and bring it up so that organizations identifying and marking forwarders have a chance to think it over in advance. Scott K From nobody Fri Nov 28 22:22:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45AA1A00A3 for ; Fri, 28 Nov 2014 22:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.808 X-Spam-Level: ** X-Spam-Status: No, score=2.808 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tteZP-ctOIqA for ; Fri, 28 Nov 2014 22:22:16 -0800 (PST) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 69D041A008F for ; Fri, 28 Nov 2014 22:22:15 -0800 (PST) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id BA1A81C395D; Sat, 29 Nov 2014 15:22:13 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 96C241A273D; Sat, 29 Nov 2014 15:22:13 +0900 (JST) From: "Stephen J. Turnbull" To: =?utf-8?Q?Jos=C3=A9?= Ferreira In-Reply-To: <604251448.2117889.1417166505526.JavaMail.zimbra@anubisnetworks.com> References: <2140954939.2054796.1417088097368.JavaMail.zimbra@anubisnetworks.com> <84727963.90926.1417116923261.JavaMail.zimbra@peachymango.org> <604251448.2117889.1417166505526.JavaMail.zimbra@anubisnetworks.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 29 Nov 2014 15:22:13 +0900 Message-ID: <871tomo7ai.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-2zIUVIYLrZHFkiEADUynM4FzAw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 06:22:18 -0000 Jos=C3=A9 Ferreira writes: > I think there should be a wider reference to bounces in the > draft-kucherawy-dmarc-base. I know bounces are rare and we try the > most to avoid bounces but it happens and have specific issues that > should be addressed differently or , at least, highlighted. They are "rare" in the context of email in general, perhaps, but in the case of mailing lists they aren't rare at all. (Note, I don't know if DMARC presents special issues for mailing list bounces, aside from the bounces already produced because of subscribers whose MTAs interpret "p=3Dreject" as "return to apparent Sender". I'm not talking about the latter, which is already well-known. I'm talking about issues where a user cancels a mailbox, and the receiving MTA generates bounces back to the list.) From nobody Sat Nov 29 04:04:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A171A066C for ; Sat, 29 Nov 2014 04:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id as5MDWpwbvKM for ; Sat, 29 Nov 2014 04:04:26 -0800 (PST) Received: from smtp.anubisnetworks.com (smtp.anubisnetworks.com [195.22.26.198]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685811A044D for ; Sat, 29 Nov 2014 04:04:25 -0800 (PST) Received: from loki.anubis.local (localhost [127.0.0.1]) by smtp.anubisnetworks.com (Postfix) with ESMTP id 3jqWbB0F2YzCrb2; Sat, 29 Nov 2014 12:04:22 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by loki.anubis.local (Postfix) with ESMTP id 3jqWb92nS6zCrQ3; Sat, 29 Nov 2014 12:04:21 +0000 (WET) Received: from zimbra2.anubis.via (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id 479F6383B0C; Sat, 29 Nov 2014 12:04:21 +0000 (WET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id 322F3383B32; Sat, 29 Nov 2014 12:04:21 +0000 (WET) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra2.anubis.via 322F3383B32 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anubisnetworks.com; s=DE5D398A-DC66-11E3-92F6-76AE37576441; t=1417262661; bh=yG7zdOlh7GlMfvwcxzpZz6m9mLP6h4BQLfgSPmnXWTc=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=gc+NGA9lXy5lVNO6xHs2d+fIp8P/XheLYXsyA43VJ8d8p5n7YeemLMwZsw+Ot1MDc NJwag7JrWNSncx422TVLmo2eVvrC6z9ympXr2aUQmIQ3vuhWr+M4cpm/EiR8YFJ159 jzEVax/Q+6NGYezcnmAgLJw7TrzJXgn5gkAxwvjc= Received: from zimbra2.anubis.via ([127.0.0.1]) by localhost (zimbra2.anubis.via [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mWKMuCe99ED0; Sat, 29 Nov 2014 12:04:21 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by zimbra2.anubis.via (Postfix) with ESMTP id 21A7A383B0C; Sat, 29 Nov 2014 12:04:21 +0000 (WET) Date: Sat, 29 Nov 2014 12:04:21 +0000 (WET) From: =?utf-8?B?Sm9zw6k=?= Ferreira To: "Stephen J. Turnbull" Message-ID: <473201342.2157870.1417262661092.JavaMail.zimbra@anubisnetworks.com> In-Reply-To: <871tomo7ai.fsf@uwakimon.sk.tsukuba.ac.jp> References: <2140954939.2054796.1417088097368.JavaMail.zimbra@anubisnetworks.com> <84727963.90926.1417116923261.JavaMail.zimbra@peachymango.org> <604251448.2117889.1417166505526.JavaMail.zimbra@anubisnetworks.com> <871tomo7ai.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.0.8_GA_6184 (ZimbraWebClient - GC39 (Linux)/8.0.8_GA_6184) Thread-Topic: DMARC and Bounces (was: Indirect Mail Flows) Thread-Index: 9TUl4xrYM7K6h7odgIGtEmPuMIbPrA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ls0ISnhs6dDH1F6KzsTTIA-McJU Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2014 12:04:32 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Jos=C3=A9 Ferreira" > Cc: dmarc@ietf.org > Sent: Saturday, November 29, 2014 6:22:13 AM > Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) >=20 > They are "rare" in the context of email in general, perhaps, but in > the case of mailing lists they aren't rare at all. (Note, I don't > know if DMARC presents special issues for mailing list bounces, aside > from the bounces already produced because of subscribers whose MTAs > interpret "p=3Dreject" as "return to apparent Sender". I'm not talking > about the latter, which is already well-known. I'm talking about > issues where a user cancels a mailbox, and the receiving MTA generates > bounces back to the list.) >=20 I probably should call it DSNs. The bounces you mention involve a third party ( the Ml or forwarder ) but I= was referring to DSN generated by the domain owner.=20 I'm talking about the scenario where you have a security gateway that accep= ts the email and them the message store reject it.This scenario the domain = owner is not depending on the goodwill of others but only from himself. Like is said, they are rare but important. And some domain owners may not a= dopt p=3Dreject for that reason. =20 Jose Borges Ferreira From nobody Sun Nov 30 07:42:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0C41A0235 for ; Sun, 30 Nov 2014 07:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.598 X-Spam-Level: * X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMzgjknayELP for ; Sun, 30 Nov 2014 07:42:28 -0800 (PST) Received: from winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C92021A0104 for ; Sun, 30 Nov 2014 07:42:27 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3238; t=1417362137; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=xyok19IAHC7Dp40If8WQwB9o4qM=; b=Fx+eizXCCjJeCzdbH+C/ 3O1qFe+sLbm4waCLN0a42ZC3yE8HD0vmim5iAP28ftb06BwjKEwFk9EbckG/LHHT xysZZ0P3svsLp5XivIRRbawGWf6cQ7iHrH6O7+VRrYuaLD5DCI9/yS/uX1p/E/4d D9eDbXEt1EXdlsi/ukt+nvs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 30 Nov 2014 10:42:17 -0500 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=fail author.d=isdg.net signer.d=beta.winserver.com (unauthorized signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3957186761.464.4168; Sun, 30 Nov 2014 10:42:16 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3238; t=1417362138; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4ETcAHB mJZjRGBORBq1d0Jd96nyoFUKo2isZrjnyIvA=; b=m/BBz3QdsIDmvFrWzoRCdZk A3W29AwKC8QcrCmOl0quzNU5DHEpvID76mlaPqJKH8jTK/1M1SYY0/v/Z2ncvQRE nXG+a5h9Xl91KsxNJApkb/8pu7Sor4l5SURLrplu9KUVjdTGlZl7My9dbD9mIMdN YoyS6MFSfSNN+oRrkvho= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 30 Nov 2014 10:42:18 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2549575486.9.3556; Sun, 30 Nov 2014 10:42:17 -0500 Message-ID: <547B3AD5.6080608@isdg.net> Date: Sun, 30 Nov 2014 10:42: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.5.0 MIME-Version: 1.0 To: =?UTF-8?B?Sm9zw6kgRmVycmVpcmE=?= References: <2140954939.2054796.1417088097368.JavaMail.zimbra@anubisnetworks.com> <84727963.90926.1417116923261.JavaMail.zimbra@peachymango.org> <604251448.2117889.1417166505526.JavaMail.zimbra@anubisnetworks.com> <871tomo7ai.fsf@uwakimon.sk.tsukuba.ac.jp> <473201342.2157870.1417262661092.JavaMail.zimbra@anubisnetworks.com> In-Reply-To: <473201342.2157870.1417262661092.JavaMail.zimbra@anubisnetworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4rwnW1lO56Lq0DnQT5gLE6DOYFc Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 15:42:30 -0000 On 11/29/2014 7:04 AM, José Ferreira wrote: > > Like is said, they are rare but important. And some domain owners may not adopt p=reject for that reason. > > Jose Borges Ferreira Domains that publish a p=reject and don 't understand its possible outcomes, shouldn't be our (IETF protocol standards development) problem. It helps to know they exist, but they should not be the reason for throwing out the proverbial baby out the window. That is not to say strong, exclusive, restrictive domain policies do not have their place. I am on the side that more than most (pareto's principle) do know what they are doing and purposely set these policies and if there is an indirect flow issue, fortunately, it has been a minor issue to them. The approach we (SSI) have taken since 2003 of implementing and deploying (and selling) strong ANTI-SPAM, SMTP REJECTION methods (meaning the PACKAGE OPTIONS were made available) is that: ONLY GOOD GUYS COMPLAIN, NOT BAD GUYS. The bad guy does not pick up the phone crying to you about your rejection policies. So if the good guys complain which has been extremely and seriously rare (for SSI, i.e. low support cost/overhead), the easiest solution to to LEARN YOUR PERSONAL/BUSINESS NETWORK and white list them and/or if possible, technically correct whatever protocol issue their might be. After all, all these protocols were really designed for the ANONYMOUS, UNSOLICITED TRANSACTION where A/A (Authentication/Authorization) HAS NOT been established. In order to be 100% backward compatible with SMTP Port 25 operations, YOU MUST STILL support ANONYMOUS, UNSOLICITED TRANSACTIONS at the very least for NON-OPEN RELAY operations, i.e. for local users and locally hosted domains. For Relays, A/A requirements kick in and that is what we are pretty much dealing with here. But for the most part, MOST were bad guys and that is why these strong SMTP LEVEL rejection protocols do have a very high payoff for those that CAN deploy them. We are not going to solve the mailing list problem UNTIL the mailing list folks (software developers) change their software TO SUPPORT Policy. We still have people that are trying to avoid it, FOR 10 YEARS, and that avoidance has not worked! Its really that simple, however, the complete integrated solution is COMPLEX (and costly) and for the most part, only a total system integration can handle it. If you (speaking in general) only have a MAILING LIST package, well, you need to wait for the other parts to fit in as well and vice versa. All I reading (and it seems to be subsiding) are ML folks trying to advocate avoiding domains with strong, restrictive policies. Well, can't have it both ways. Intentional ignorance and expectation that things will continue to work and integrate well, is in my strong technical software engineering opinion, unrealistic. All parts need to fit together and since its a multi-component integration problem, there are only a few packages that can do that. That is what makes this a long time difficult problem to solve. You have systems people, operations, networks, mailing list people, etc and most have different goals and agendas. -- HLS From nobody Sun Nov 30 11:58:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040D71A1A7D for ; Sun, 30 Nov 2014 11:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIbkZzWk5YO0 for ; Sun, 30 Nov 2014 11:58:39 -0800 (PST) Received: from smtp.anubisnetworks.com (smtp.anubisnetworks.com [195.22.26.198]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFB51A1A58 for ; Sun, 30 Nov 2014 11:58:38 -0800 (PST) Received: from loki.anubis.local (localhost [127.0.0.1]) by smtp.anubisnetworks.com (Postfix) with ESMTP id 3jrL3s48LMzCrRZ; Sun, 30 Nov 2014 19:58:33 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by loki.anubis.local (Postfix) with ESMTP id 3jrL3s1PszzCrNZ; Sun, 30 Nov 2014 19:58:32 +0000 (WET) Received: from zimbra2.anubis.via (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id EB017383A69; Sun, 30 Nov 2014 19:58:32 +0000 (WET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id D20DC383AEF; Sun, 30 Nov 2014 19:58:32 +0000 (WET) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra2.anubis.via D20DC383AEF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anubisnetworks.com; s=DE5D398A-DC66-11E3-92F6-76AE37576441; t=1417377512; bh=Lk5sh8Z13MA7GabVdPpFWCarNJH3HnX1jQuKUckUsjE=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=SDFDwjJ3e7gcfvliE5Al4WUhMZy7NgzY96McENkveis3tvwFCTTqd1z64nu8DdUmH A2St2zhBQvTmepfP42NP9zRCMpelMjqYb5/uwKZmqvGkUGt+tLrIYSEM5IcOaPg3/a iWZVvuoejli2TDSm+mPMT6A9HWV5oXA/EM87jnho= Received: from zimbra2.anubis.via ([127.0.0.1]) by localhost (zimbra2.anubis.via [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1thKPfsYv2KO; Sun, 30 Nov 2014 19:58:32 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by zimbra2.anubis.via (Postfix) with ESMTP id BE682383A69; Sun, 30 Nov 2014 19:58:32 +0000 (WET) Date: Sun, 30 Nov 2014 19:58:32 +0000 (WET) From: =?utf-8?B?Sm9zw6k=?= Ferreira To: Hector Santos Message-ID: <753576265.2170128.1417377512649.JavaMail.zimbra@anubisnetworks.com> In-Reply-To: <547B3AD5.6080608@isdg.net> References: <2140954939.2054796.1417088097368.JavaMail.zimbra@anubisnetworks.com> <84727963.90926.1417116923261.JavaMail.zimbra@peachymango.org> <604251448.2117889.1417166505526.JavaMail.zimbra@anubisnetworks.com> <871tomo7ai.fsf@uwakimon.sk.tsukuba.ac.jp> <473201342.2157870.1417262661092.JavaMail.zimbra@anubisnetworks.com> <547B3AD5.6080608@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.0.8_GA_6184 (ZimbraWebClient - GC39 (Linux)/8.0.8_GA_6184) Thread-Topic: DMARC and Bounces (was: Indirect Mail Flows) Thread-Index: pfmENhqJIyLdRCX/jPiggqXqKSG3+Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CSjrIwWQpDluAf9Bvs_oUmAyZpo Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 19:58:42 -0000 ----- Original Message ----- > From: "Hector Santos" > To: "Jos=C3=A9 Ferreira" > Cc: dmarc@ietf.org > Sent: Sunday, November 30, 2014 3:42:13 PM > Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) >=20 > All I reading (and it seems to be subsiding) are ML folks trying to > advocate avoiding domains with strong, restrictive policies. Well, > can't have it both ways. Intentional ignorance and expectation that > things will continue to work and integrate well, is in my strong > technical software engineering opinion, unrealistic. >=20 > All parts need to fit together and since its a multi-component > integration problem, there are only a few packages that can do that. > That is what makes this a long time difficult problem to solve. You > have systems people, operations, networks, mailing list people, etc > and most have different goals and agendas. >=20 Forget about ML. I'm not only talking about ML but for a specific situation= . Let me detail the issue. Most large system have several layers of defense. The edge system , after a= ll teh checks, accepts the mail. When trying to deliver to the message store, it bounces ( the common exampl= e is the mailbox full )!. So the edge system generates a bounce message (MDN). Knowing that RFC5321.M= ailFrom will "<>". To be DMARC compliant the RFC5321.HELO/.EHLO name must be align with the RF= C5322.From of the MDN. Again, this may be rare but should be referenced mainly because it can be e= asily overlooked.=20 I guess I'm support Franck Martin when he wrote. "I guess these two (sendmail and postfix) are the backbone of many applianc= es... Therefore it is important to read http://trac.tools.ietf.org/html/rfc7208#s= ection-10.1.3 on how to setup SPF to work with bounces." and adding that the RFC5321.MailFrom must be aligned. For Postfix, changing= the From in MDNs is not trivial but also not that complicated. =20 Jos=C3=A9 Borges Ferreira. From nobody Sun Nov 30 14:35:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C0A1A1AA8 for ; Sun, 30 Nov 2014 14:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ru9qFNx69_-n for ; Sun, 30 Nov 2014 14:35:39 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5D51A1AA7 for ; Sun, 30 Nov 2014 14:35:39 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 7FA295654EC; Sun, 30 Nov 2014 16:35:38 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 65DFBA02BC; Sun, 30 Nov 2014 16:35:38 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omXx_X0QuPsO; Sun, 30 Nov 2014 16:35:38 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 35B3BA0492; Sun, 30 Nov 2014 16:35:37 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 35B3BA0492 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1417386937; bh=OFlmw92mHQCvl+Ir4j4a/t02Xp5n9+APHfk8nyBcP9Q=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=PhaFsGXQZjzHRtyPi4kiAzhYacTxome1lUYJf8K7DzbfRDiTGS1CUoO0GgSWjH6FI 5xr0TLLH9pqgZCSwCQB4LkHsNulH9C1tE4vpeLBWRO68eqifB3zG8OEwtVkStCEVym 2PjAe6vRb3fLAGl6gLnt6iD5/qRMx6NIaCzcMLRQ= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 1FBBEA048F; Sun, 30 Nov 2014 16:35:37 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eeYIAb99oaZk; Sun, 30 Nov 2014 16:35:37 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id D45CDA02BC; Sun, 30 Nov 2014 16:35:36 -0600 (CST) Date: Sun, 30 Nov 2014 16:35:36 -0600 (CST) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <1922410092.4831.1417386936473.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <2140954939.2054796.1417088097368.JavaMail.zimbra@anubisnetworks.com> <84727963.90926.1417116923261.JavaMail.zimbra@peachymango.org> <604251448.2117889.1417166505526.JavaMail.zimbra@anubisnetworks.com> <871tomo7ai.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC and Bounces (was: Indirect Mail Flows) Thread-Index: k7ceeq3jfCGO3HTK13WEYb8LKvWb9g== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fXuyK_duAfioTowWBSLFIDFL4zE Cc: =?utf-8?Q?Jos=C3=A9_Ferreira?= , dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 22:35:42 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Jos=C3=A9 Ferreira" > Cc: dmarc@ietf.org > Sent: Friday, November 28, 2014 10:22:13 PM > Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) >=20 > Jos=C3=A9 Ferreira writes: >=20 > > I think there should be a wider reference to bounces in the > > draft-kucherawy-dmarc-base. I know bounces are rare and we try the > > most to avoid bounces but it happens and have specific issues that > > should be addressed differently or , at least, highlighted. >=20 > They are "rare" in the context of email in general, perhaps, but in > the case of mailing lists they aren't rare at all. (Note, I don't > know if DMARC presents special issues for mailing list bounces, aside > from the bounces already produced because of subscribers whose MTAs > interpret "p=3Dreject" as "return to apparent Sender". I'm not talking > about the latter, which is already well-known. I'm talking about > issues where a user cancels a mailbox, and the receiving MTA generates > bounces back to the list.) Besides mailing lists, bounces are very important for large senders, market= ing email companies, etc... The usual rule is to stop emailing any email address that generated a hard = bounce, but if you block such bounces due to the policy of the sender of th= e bounce... Well I guess they are going to be annoyed eventually and may no= t take the appropriate action, fix their bounces, and eventually block or l= imit the sender of the original message. From nobody Sun Nov 30 14:39:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764631A1AA8 for ; Sun, 30 Nov 2014 14:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GICZ-KsOaHg for ; Sun, 30 Nov 2014 14:39:12 -0800 (PST) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9BF1A1AA7 for ; Sun, 30 Nov 2014 14:39:12 -0800 (PST) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id D753B5654FC; Sun, 30 Nov 2014 16:39:11 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BED44A0492; Sun, 30 Nov 2014 16:39:11 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD-SKfFeSxn3; Sun, 30 Nov 2014 16:39:11 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 8B423A04AC; Sun, 30 Nov 2014 16:39:11 -0600 (CST) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 8B423A04AC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1417387151; bh=UOOwERmUGLQfT1BW+pTHrGlI9hyq+z/ewsO6uIUsRA0=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=paUSl+HYJAhj+sKXHPoKX8BZhx0LI0G0QZmJfQpQSAipO66MrIYB3qoFvjryHK90t ZLCqwpvPIMHTb/wQekrWpQRmIT2qFKxCDZKjHLQeZLK9XKdNdunIxRn6Db81N9j3iL YADFBhuoc62zf/YUHn2lPS6EC88y/WyDQg47qSW0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 6DD0AA04A9; Sun, 30 Nov 2014 16:39:11 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id n6rWakhSFqxe; Sun, 30 Nov 2014 16:39:11 -0600 (CST) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 4E212A0492; Sun, 30 Nov 2014 16:39:11 -0600 (CST) Date: Sun, 30 Nov 2014 16:39:11 -0600 (CST) From: Franck Martin To: =?utf-8?Q?Jos=C3=A9_Ferreira?= Message-ID: <514352407.4866.1417387151261.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <2140954939.2054796.1417088097368.JavaMail.zimbra@anubisnetworks.com> <84727963.90926.1417116923261.JavaMail.zimbra@peachymango.org> <604251448.2117889.1417166505526.JavaMail.zimbra@anubisnetworks.com> <871tomo7ai.fsf@uwakimon.sk.tsukuba.ac.jp> <473201342.2157870.1417262661092.JavaMail.zimbra@anubisnetworks.com> <547B3AD5.6080608@isdg.net> <753576265.2170128.1417377512649.JavaMail.zimbra@anubisnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF33 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC and Bounces (was: Indirect Mail Flows) Thread-Index: pfmENhqJIyLdRCX/jPiggqXqKSG3+TFeL4IT Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ylpfhc_QdX1ArPCjuLDwSgzj2XA Cc: dmarc@ietf.org, Hector Santos Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2014 22:39:13 -0000 ----- Original Message ----- > From: "Jos=C3=A9 Ferreira" > To: "Hector Santos" > Cc: dmarc@ietf.org > Sent: Sunday, November 30, 2014 11:58:32 AM > Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) >=20 > Forget about ML. I'm not only talking about ML but for a specific situati= on. >=20 > Let me detail the issue. >=20 > Most large system have several layers of defense. The edge system , after= all > teh checks, accepts the mail. > When trying to deliver to the message store, it bounces ( the common exam= ple > is the mailbox full )!. >=20 > So the edge system generates a bounce message (MDN). Knowing that > RFC5321.MailFrom will "<>". > To be DMARC compliant the RFC5321.HELO/.EHLO name must be align with the > RFC5322.From of the MDN. >=20 > Again, this may be rare but should be referenced mainly because it can be > easily overlooked. >=20 >=20 > I guess I'm support Franck Martin when he wrote. >=20 > "I guess these two (sendmail and postfix) are the backbone of many > appliances... >=20 > Therefore it is important to read > http://trac.tools.ietf.org/html/rfc7208#section-10.1.3 on how to setup SP= F > to work with bounces." >=20 > and adding that the RFC5321.MailFrom must be aligned. For Postfix, changi= ng > the From in MDNs is not trivial but also not that complicated. > =20 It seems to me these things should go in a BCP or operational guidelines.= =20 DMARC relies on underlying layers to work properly and postfix package shou= ld be fixed, not sure what Wietse thinks about it. From nobody Sun Nov 30 19:57:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7EA1A044D for ; Sun, 30 Nov 2014 19:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.363 X-Spam-Level: X-Spam-Status: No, score=0.363 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO2u7mwwuM1I for ; Sun, 30 Nov 2014 19:57:08 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344E01A039C for ; Sun, 30 Nov 2014 19:57:07 -0800 (PST) Received: (qmail 50334 invoked from network); 1 Dec 2014 03:57:02 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Dec 2014 03:57:02 -0000 Date: 1 Dec 2014 03:56:42 -0000 Message-ID: <20141201035642.30787.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <753576265.2170128.1417377512649.JavaMail.zimbra@anubisnetworks.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/A-q8hPE2zQRHiTk4-VG1ceE-_8E Cc: jose.ferreira@anubisnetworks.com Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 03:57:09 -0000 >So the edge system generates a bounce message (MDN). Knowing that RFC5321.MailFrom will "<>". >To be DMARC compliant the RFC5321.HELO/.EHLO name must be align with the RFC5322.From of the MDN. Why wouldn't you add a DKIM signature that matches the domain name in the message From: line? The envelope bounce return address is empty, but the From: line isn't. R's, John From nobody Sun Nov 30 20:11:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE751A039C for ; Sun, 30 Nov 2014 20:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeGkJauI7NZX for ; Sun, 30 Nov 2014 20:11:08 -0800 (PST) Received: from smtp.anubisnetworks.com (smtp.anubisnetworks.com [195.22.26.198]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CC931A0119 for ; Sun, 30 Nov 2014 20:11:08 -0800 (PST) Received: from gaia.anubis.local (localhost [127.0.0.1]) by smtp.anubisnetworks.com (Postfix) with ESMTP id 3jrY0B1dwFz4xLF; Mon, 1 Dec 2014 04:11:06 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by gaia.anubis.local (Postfix) with ESMTP id 3jrY0B1CGZz4wlM; Mon, 1 Dec 2014 04:11:06 +0000 (WET) Received: from zimbra2.anubis.via (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id 2569F38399C; Mon, 1 Dec 2014 04:11:06 +0000 (WET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id 0EE403839FC; Mon, 1 Dec 2014 04:11:06 +0000 (WET) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra2.anubis.via 0EE403839FC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anubisnetworks.com; s=DE5D398A-DC66-11E3-92F6-76AE37576441; t=1417407066; bh=CXMZW9dkSeuninhyjhxcAw8vTZmLohX9l/u/QGblpVo=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=oPEu1NitXyQVDBlyvrtx1/xP3O0eGC7ioEmtM+/lPYsdMYociWs7y9n1vIg4c8GuG iBVNtKBrM6VQbVYrBXxZaiDT0RKlk4EYGcuCcXWd0pwpQKILF5P/x+/cM2fHBQQ18s OpBnli/kwrSUQ3Xd3CVZRzpdH1l94lvZ7a4iMrOU= Received: from zimbra2.anubis.via ([127.0.0.1]) by localhost (zimbra2.anubis.via [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DWV4bCJbvBe8; Mon, 1 Dec 2014 04:11:05 +0000 (WET) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by zimbra2.anubis.via (Postfix) with ESMTP id EF15C38399C; Mon, 1 Dec 2014 04:11:05 +0000 (WET) Date: Mon, 1 Dec 2014 04:11:05 +0000 (WET) From: =?utf-8?B?Sm9zw6k=?= Ferreira To: John Levine Message-ID: <753885954.2173275.1417407065874.JavaMail.zimbra@anubisnetworks.com> In-Reply-To: <20141201035642.30787.qmail@ary.lan> References: <20141201035642.30787.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.0.8_GA_6184 (ZimbraWebClient - GC39 (Linux)/8.0.8_GA_6184) Thread-Topic: DMARC and Bounces (was: Indirect Mail Flows) Thread-Index: /3/khwTFdpXZjkwPI0CFEhfhNgNh1w== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/D4Prbbv7i8guDSsGoQnGNI_UtjM Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 04:11:10 -0000 ----- Original Message ----- > From: "John Levine" > To: dmarc@ietf.org > Cc: "jose ferreira" > Sent: Monday, December 1, 2014 3:56:42 AM > Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) >=20 > Why wouldn't you add a DKIM signature that matches the domain name in > the message From: line? The envelope bounce return address is empty, > but the From: line isn't. >=20 That's is what I'm doing.=20 Just pointing out that HELO must be aligned with From:. and in most cases i= t's not strict. =20 Jos=C3=A9 Borges Ferreira From nobody Sun Nov 30 20:20:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574F21A0636 for ; Sun, 30 Nov 2014 20:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOhPDyKr9_0N for ; Sun, 30 Nov 2014 20:20:34 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89E11A039C for ; Sun, 30 Nov 2014 20:20:34 -0800 (PST) Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E0C9CC40329; Sun, 30 Nov 2014 22:20:33 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1417407633; bh=TRjTH4StV7e3WzlOfY3ZSAovZpCe8xy+eLM5K9zJ8JQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=P8KAlTx+ll2PAqKiyt+p8uBaOzIUahgQamE9VR8ivl8vtIp794S1Q5U2I5f8u4y8g P7cPxI4tI8JL3GFr70ZZ9Saj0/S8cYPe/QPKmJ4w2HN+Knjmi0Aycum5YIXtoIDd7g 3yHEAafhlIN8rjR8Htx+4X54aM06UUE51ciu5dOM= From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 30 Nov 2014 23:20:30 -0500 Message-ID: <2393679.q8vFNfeKk2@scott-latitude-e6320> User-Agent: KMail/4.13.3 (Linux/3.13.0-39-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20141201035642.30787.qmail@ary.lan> References: <20141201035642.30787.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/aY6zzA0CfaZk04t9q_2qaWH-1M8 Subject: Re: [dmarc-ietf] DMARC and Bounces (was: Indirect Mail Flows) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 04:20:39 -0000 On Monday, December 01, 2014 03:56:42 John Levine wrote: > >So the edge system generates a bounce message (MDN). Knowing that > >RFC5321.MailFrom will "<>". To be DMARC compliant the RFC5321.HELO/.EHLO > >name must be align with the RFC5322.From of the MDN. > Why wouldn't you add a DKIM signature that matches the domain name in > the message From: line? The envelope bounce return address is empty, > but the From: line isn't. I think there was a missing "To get an SPF result that leads to a DMARC pass ..." in there. A DKIM signature will certainly do as well. Scott K