From Tom_McNamee@reyrey.com Thu Apr 3 09:50: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 9A9151A028E for ; Thu, 3 Apr 2014 09:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=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 rLvu-kbwp6qa for ; Thu, 3 Apr 2014 09:50:07 -0700 (PDT) Received: from dayis01iron01.ad.reyrey.com (Dayis01Iron01.keyregister.com [192.112.245.69]) by ietfa.amsl.com (Postfix) with ESMTP id 71F901A0279 for ; Thu, 3 Apr 2014 09:50:07 -0700 (PDT) Received: from is-exhc02-rp.ad.reyrey.com ([168.207.82.175]) by dayis01iron01.ad.reyrey.com with ESMTP; 03 Apr 2014 12:50:02 -0400 Received: from IS-EXMB01-RP.ad.reyrey.com ([168.207.82.176]) by IS-EXHC02-RP.ad.reyrey.com ([168.207.82.208]) with mapi; Thu, 3 Apr 2014 12:50:02 -0400 From: "McNamee, Tom" To: "'dmarc@ietf.org'" Date: Thu, 3 Apr 2014 12:50:00 -0400 Thread-Topic: No DMARC reports delivered by AOL Thread-Index: Ac9PXMENAzISzRsSS8eYgqm4+csH0w== Message-ID: <67C1678059C61F408194E53907AFB5CC10F29C3C28@IS-EXMB01-RP.ad.reyrey.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_67C1678059C61F408194E53907AFB5CC10F29C3C28ISEXMB01RPadr_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kzCh-oX_9pzb_2grQe-5TQjtRoA X-Mailman-Approved-At: Thu, 03 Apr 2014 15:15:48 -0700 Subject: [dmarc-ietf] No DMARC reports delivered by AOL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 16:56:36 -0000 --_000_67C1678059C61F408194E53907AFB5CC10F29C3C28ISEXMB01RPadr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I implemented DMARC on a production sending domain a few months ago. I hav= e received daily aggregate reports from Comcast, Google, yahoo, hotmail, 16= 3.com, 126.com, and mail.ru. I have not received a single DMARC report fro= m AOL. Here are my DNS records: ## dig txt _dmarc. _dmarc.. 3575 IN TXT = "v=3DDMARC1\; p=3Dnone\; pct=3D100\; rua=3Dmailto:\; sp=3Dnone\; adkim=3Dr\; aspf=3Dr" ## dig txt ._report._dmarc.. ._report._dmarc.. 13890 IN = TXT "v=3DDMARC1" Any thoughts?!??! Thanks! -Tom --_000_67C1678059C61F408194E53907AFB5CC10F29C3C28ISEXMB01RPadr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I implemented DM= ARC on a production sending domain a few months ago.  I have received = daily aggregate reports from Comcast, Google, yahoo, hotmail, 163.com, 126.= com, and mail.ru.  I have not received a single DMARC report from AOL.=

 

Here are my DNS records:

 <= /o:p>

## dig txt _dmarc.<dmarc_sending.domain>= ;

_dmarc.<dmarc_sending.domain>.&n= bsp;        3575    =    IN          = TXT         "v=3DDMARC1\; p= =3Dnone\; pct=3D100\; rua=3Dmailto:<address_on_domain-receiving-reports&= gt;\; sp=3Dnone\; adkim=3Dr\; aspf=3Dr"

 

## dig txt <dmarc_sendng.= domain>._report._dmarc.<domain-receiving-reports>.

=

<dmarc_sendng.domain>._report._dmarc.<domain-= receiving-reports>. 13890 IN       &n= bsp;    TXT "v=3DDMARC1"

 

Any thoughts?!??!<= /o:p>

 

Tha= nks!

-Tom

= --_000_67C1678059C61F408194E53907AFB5CC10F29C3C28ISEXMB01RPadr_-- From nobody Thu Apr 3 21:02: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 AD31D1A03AE for ; Thu, 3 Apr 2014 21:02:54 -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 ji3QWEeJpFTx for ; Thu, 3 Apr 2014 21:02:50 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2A80D1A0096 for ; Thu, 3 Apr 2014 21:02:50 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id h18so1475453igc.2 for ; Thu, 03 Apr 2014 21:02:45 -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=6UHxSQWxfocdVF/AyiIMhysMDNuoyik9+jHooBKsHoE=; b=LvRRyOXZQQF6DnmIfl86llWKbgdn2QCCt3SvBti0rX+R7q3P1Jsm04Ph6UBwJXfxyz DH5Y+aSvSKlIzv/KTE/RaORx4jeCG/hqAK0k1EAUC7t91iz1lbYTXYTp9abQ8bbCmX0t 7MgzzOK4VcRD8Cxybm0xgMpXz7T0Sz5QStoOQymk7YX1M2EO4sLTVnEGdAxRhm3wWVzT 3oI/M+fkLF2JCg5h1ZepR4zaTA97G8FRWkTJzOKKMEuKemHbCENl3ybLQELumTXtTTin iZY0hZmTpwm5SlDxwX+QT2RguSosjXbp3okX1SsD5GehhD+gMpXAETTXGISim7oUGmLg g4cA== MIME-Version: 1.0 X-Received: by 10.42.131.197 with SMTP id a5mr9617657ict.8.1396584165691; Thu, 03 Apr 2014 21:02:45 -0700 (PDT) Received: by 10.50.36.202 with HTTP; Thu, 3 Apr 2014 21:02:45 -0700 (PDT) In-Reply-To: <67C1678059C61F408194E53907AFB5CC10F29C3C28@IS-EXMB01-RP.ad.reyrey.com> References: <67C1678059C61F408194E53907AFB5CC10F29C3C28@IS-EXMB01-RP.ad.reyrey.com> Date: Thu, 3 Apr 2014 21:02:45 -0700 Message-ID: From: Steve Jones To: "McNamee, Tom" Content-Type: multipart/alternative; boundary=bcaec53969d818564b04f62f97ed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MdDoioIwcdPTIFkHTkZotmDtwkU Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] No DMARC reports delivered by AOL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 04:02:54 -0000 --bcaec53969d818564b04f62f97ed Content-Type: text/plain; charset=ISO-8859-1 > Any thoughts?!??! Yes. One: This would be better directed at the dmarc-discuss list, which deals with operational issues vs. specification issues. See http://www.dmarc.org/mailman/listinfo/dmarc-discuss for list details or subscription. I'd take the follow-ups there. Two: The minimum record for your domain would be "v=DMARC1; p=none; rua=mailto:address@example.com" -- if you must keep your domain secret, it may be instructive to lose the other options and see what happens. Three: You should share the actual domain which is seeing the problem. You're interested in how AOL sees and reacts to your records -- how are they to check what their systems see, which could differ from where ever you ran your queries? Nor can anybody else lookup what their systems see happening for your domain, as things stand. Perhaps XS4ALL sees the problem and knows the cause, but you've avoided that possibility coming to light. --S. On Thu, Apr 3, 2014 at 9:50 AM, McNamee, Tom wrote: > I implemented DMARC on a production sending domain a few months ago. I > have received daily aggregate reports from Comcast, Google, yahoo, hotmail, > 163.com, 126.com, and mail.ru. I have not received a single DMARC report > from AOL. > > > > Here are my DNS records: > > > > ## dig txt _dmarc. > > _dmarc.. 3575 IN TXT > "v=DMARC1\; p=none\; pct=100\; rua=mailto:\; > sp=none\; adkim=r\; aspf=r" > > > > ## dig txt > ._report._dmarc.. > > ._report._dmarc.. 13890 > IN TXT "v=DMARC1" > > > > Any thoughts?!??! > > > > Thanks! > > -Tom > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --bcaec53969d818564b04f62f97ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Any thoughts?!??!

Yes.

= One: This would be better directed at the dmarc-discuss list, which deals w= ith operational issues vs. specification issues. See http://www.dmarc.org/mailman/list= info/dmarc-discuss for list details or subscription.
=A0I'd take the follow-ups there.

Tw= o: The minimum record for your domain would be "v=3DDMARC1; p=3Dnone; = rua=3Dmailto:address@example.com= " -- if you must keep your domain secret, it may be instructive to los= e the other options and see what happens.

Three: You should share the actual domain which is seeing the= problem. You're interested in how AOL sees and reacts to your records = -- how are they to check what their systems see, which could differ from wh= ere ever you ran your queries? Nor can anybody else lookup what their syste= ms see happening for your domain, as things stand. Perhaps XS4ALL sees the = problem and knows the cause, but you've avoided that possibility coming= to light.

--S.


On Thu, Apr 3, 2014 at 9:50 AM, McNamee, To= m <Tom_McNamee@reyrey.com> wrote:

I implemented DMARC on a production send= ing domain a few months ago.=A0 I have received daily aggregate reports fro= m Comcast, Google, yahoo, hotmail, 163.com, 126.com,= and mail.ru.=A0 I have no= t received a single DMARC report from AOL.

=A0

Here are= my DNS records:

=A0<= /p>

## dig txt _dmarc.<dmarc_sending.domain>=

_dmarc.<dmarc_sending.domain>.=A0=A0=A0=A0=A0= =A0=A0=A0 3575=A0=A0=A0=A0=A0=A0 IN=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 TXT=A0=A0= =A0=A0=A0=A0=A0=A0 "v=3DDMARC1\; p=3Dnone\; pct=3D100\; rua=3Dmailto:&= lt;address_on_domain-receiving-reports>\; sp=3Dnone\; adkim=3Dr\; aspf= =3Dr"

=A0

## dig t= xt <dmarc_sendng.domain>._report._dmarc.<domain-receiving-reports&= gt;.

<dmarc_sendng.domain>._= report._dmarc.<domain-receiving-reports>. 13890 IN=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 TXT "v=3DDMARC1"

=A0

Any thou= ghts?!??!

=A0

Thanks!

-Tom =


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


--bcaec53969d818564b04f62f97ed-- From nobody Fri Apr 4 07:43: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 703F21A018C for ; Fri, 4 Apr 2014 07:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_CERTIFIED=-3, RCVD_IN_RP_SAFE=-2, 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 L_-o3JEs2z_p for ; Fri, 4 Apr 2014 07:43:52 -0700 (PDT) Received: from o1.corpout.returnpath.com (o1.corpout.returnpath.com [50.31.61.183]) by ietfa.amsl.com (Postfix) with SMTP id 38BB11A014E for ; Fri, 4 Apr 2014 07:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=returnpath.com; h=from:to:cc:subject:references:in-reply-to:content-type:mime-version; s=smtpapi; bh=8aWyYtnb9f5NDGHblQaWtlnWJJg=; b=G6lV8Mps+3d5wZYkI1 3k0+/hr5OjspEkhbL3ZQ94EPPjNtoLzHW7xGSo6q66tl3EUQD//IU+74wtx22w1T jHrADD5ppU07MqvCsJWK/1fcbQyxB2y4Sw/Q0FrkQg5fZk6Ow11KwdRyzIyXk2b+ wC0yEl4FxlIJ9W6sdM8wgf1AU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=returnpath.com; h=from:to:cc:subject:references:in-reply-to:content-type:mime-version; q=dns; s=smtpapi; b=tc8+9r0JNIpo4N5wyvZkg31IdMvLGqy2cHAeSoqsIj+6 hYZnrSIPqGrYNjwieJqthBpBlU4RQ4l3R316vViKkckbFMF5spf9Si26xMUcbXXt zNUrDGJHB81hCVvjbtzLmuy5J4ye+gDg0cGpjCtiLCnOGbBRjn88JKBMmOMPwSk= Received: by filter-158.sjc1.sendgrid.net with SMTP id filter-158.21568.533EC5215 Fri, 04 Apr 2014 14:43:45 +0000 (UTC) Received: from smtp.corp.returnpath.net (smtp.corp.returnpath.net [50.201.69.7]) by ismtpd-012 (SG) with ESMTP id 1452d320b0e.7a21.19da4b Fri, 04 Apr 2014 14:43:45 +0000 (GMT) Received: from rpcoex01.rpcorp.local ([10.0.1.142]) by rpcoex01.rpcorp.local ([10.0.1.142]) with mapi; Fri, 4 Apr 2014 08:43:45 -0600 From: Greg Colburn To: Steve Jones Date: Fri, 4 Apr 2014 08:43:43 -0600 Thread-Topic: [dmarc-ietf] No DMARC reports delivered by AOL Thread-Index: Ac9QFEciZKV64xrcQPi0XsPgxXITxg== Message-ID: <5375640B-1EF3-4319-808E-BB0D56B45BF2@returnpath.com> References: <67C1678059C61F408194E53907AFB5CC10F29C3C28@IS-EXMB01-RP.ad.reyrey.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5375640B1EF34319808EBB0D56B45BF2returnpathcom_" MIME-Version: 1.0 X-SG-EID: ttWHLwNw6rhAFWw30n9Iv9H9bTFVLrGYwa7KMAiUt5Jg1tehzpTAHV5A+RkFQVs2uWvBxOkLKonScYx0YKMuLKWmuXTUszDNE3j/PSJzdWqoSm4XldQm0jOsI2GFuSFhCe29nwJ4yE45E+/oUFw7ITAl/OWosttPxb9en2JLZlo= Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/W0N_sLkPsn6vcNOSjjPDjQSGGJ4 Cc: "dmarc@ietf.org" , "McNamee, Tom" Subject: Re: [dmarc-ietf] No DMARC reports delivered by AOL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 14:43:56 -0000 --_000_5375640B1EF34319808EBB0D56B45BF2returnpathcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tom AOL has implemented the DMARC feedback verification mechanism described in = Section 7.1 of the DMARC spec. You need to deploy a report record on the domain that intends to receive DM= ARC reports. In short, create a TXT record at the location: SENDING_DOMAIN._report._dmarc.DOMAIN_RECEIVING_REPORTS with this content: v=3DDMARC1 This record will indicate that DOMAIN_RECEIVING_REPORTS is authorized to re= ceive reports for SENDING_DOMAIN. Hope this helps! Greg C On Apr 3, 2014, at 10:02 PM, Steve Jones > wrote: > Any thoughts?!??! Yes. One: This would be better directed at the dmarc-discuss list, which deals w= ith operational issues vs. specification issues. See http://www.dmarc.org/m= ailman/listinfo/dmarc-discuss for list details or subscription. I'd take the follow-ups there. Two: The minimum record for your domain would be "v=3DDMARC1; p=3Dnone; rua= =3Dmailto:address@example.com" -- if you must k= eep your domain secret, it may be instructive to lose the other options and= see what happens. Three: You should share the actual domain which is seeing the problem. You'= re interested in how AOL sees and reacts to your records -- how are they to= check what their systems see, which could differ from where ever you ran y= our queries? Nor can anybody else lookup what their systems see happening f= or your domain, as things stand. Perhaps XS4ALL sees the problem and knows = the cause, but you've avoided that possibility coming to light. --S. On Thu, Apr 3, 2014 at 9:50 AM, McNamee, Tom > wrote: I implemented DMARC on a production sending domain a few months ago. I hav= e received daily aggregate reports from Comcast, Google, yahoo, hotmail, 16= 3.com, 126.com, and mail.ru. I have not received a single DMARC report from AOL. Here are my DNS records: ## dig txt _dmarc. _dmarc.. 3575 IN TXT = "v=3DDMARC1\; p=3Dnone\; pct=3D100\; rua=3Dmailto:\; sp=3Dnone\; adkim=3Dr\; aspf=3Dr" ## dig txt ._report._dmarc.. ._report._dmarc.. 13890 IN = TXT "v=3DDMARC1" Any thoughts?!??! Thanks! -Tom _______________________________________________ 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 --_000_5375640B1EF34319808EBB0D56B45BF2returnpathcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tom

A= OL has implemented the DMARC feedback verification mechanism described in S= ection 7.1 of the DMARC spec.
You need to deploy a report record = on the domain that intends to receive DMARC reports.

In short, create a TXT record at the location:

= SENDING_DOMAIN._report._dmarc.DOMAIN_RECEIVING_REPORTS

with this content:

v=3DDMARC1

This record will indicate that = DOMAIN_RECEIVING_REPORTS is authorized to receive reports for SENDING_DOMAI= N.

Hope this helps!

Greg = C

On Apr 3, 2014, at 10:02 PM, Steve Jones <steven.m.jones@gmail.com> wr= ote:

> Any thoughts?!??!

Yes.

One: This would be better directed at the dmarc-discuss list, which deals = with operational issues vs. specification issues. See http://www.dmarc.org/mailman/lis= tinfo/dmarc-discuss for list details or subscription.
 I'd take the follow-ups there.

Two= : The minimum record for your domain would be "v=3DDMARC1; p=3Dnone; rua=3D= mailto:address@example.com" -- i= f you must keep your domain secret, it may be instructive to lose the other= options and see what happens.

Three: You should share the actual domain which is seeing the= problem. You're interested in how AOL sees and reacts to your records -- h= ow are they to check what their systems see, which could differ from where = ever you ran your queries? Nor can anybody else lookup what their systems s= ee happening for your domain, as things stand. Perhaps XS4ALL sees the prob= lem and knows the cause, but you've avoided that possibility coming to ligh= t.

--S.


On Thu, Apr 3, 2014 at 9:50 AM, McNamee, To= m <Tom_McNamee@reyrey.com> wrote:

I implemented = DMARC on a production sending domain a few months ago.  I have receive= d daily aggregate reports from Comcast, Google, yahoo, hotmail, 163.com, 126.com, and mail.ru.  I have not received a single DMARC report from AO= L.

 

Here are my DNS records:

 

## dig txt _dmarc.<d= marc_sending.domain>

_dmarc.<= dmarc_sending.domain>.         3= 575       IN     &nb= sp;     TXT       &n= bsp; "v=3DDMARC1\; p=3Dnone\; pct=3D100\; rua=3Dmailto:<address_on_domai= n-receiving-reports>\; sp=3Dnone\; adkim=3Dr\; aspf=3Dr"

 

## = dig txt <dmarc_sendng.domain>._report._dmarc.<domain-receiving-rep= orts>.

<dmarc_sendng.domain&= gt;._report._dmarc.<domain-receiving-reports>. 13890 IN  &n= bsp;         TXT "v=3DDMARC1"

 

Any thoughts?!??!

&nb= sp;

Thanks!

-Tom =


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


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

= --_000_5375640B1EF34319808EBB0D56B45BF2returnpathcom_-- From nobody Fri Apr 4 10:52: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 E59F31A02D8 for ; Fri, 4 Apr 2014 10:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_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 hRh4eAJl1Yhz for ; Fri, 4 Apr 2014 10:52:14 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 92F3C1A0283 for ; Fri, 4 Apr 2014 10:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1396633930; x=1428169930; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rbElcww0AE3oIrCQIeWf/HU6wD3fobeI7aRlEKiCbYo=; b=IdCFs/xwTSyQWK4hA1mM5Mhy3XOQNZYimUx3pK7lqYF9YWVATUgv3D0y 6VkfZCd18rVfBM8mT4Hp/Jq4UmHqUv7yL6GdLLEtAUqGlbAhXMIxHTp9n qGFyv1FFucUaqYGdhfQD7muGO+qsMSVcCA2cdJL4wvAxJ7BlyybLfDukz g=; X-IronPort-AV: E=Sophos;i="4.97,796,1389772800"; d="asc'?scan'208";a="109876372" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by ESV4-HT02.linkedin.biz (172.18.46.236) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 4 Apr 2014 10:51:53 -0700 Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.03.0174.001; Fri, 4 Apr 2014 10:51:53 -0700 From: Franck Martin To: Greg Colburn Thread-Topic: [dmarc-ietf] No DMARC reports delivered by AOL Thread-Index: Ac9PXMENAzISzRsSS8eYgqm4+csH0wAmKcaAABZisIAABpIxAA== Date: Fri, 4 Apr 2014 17:51:52 +0000 Message-ID: <6FC5CCCD-94E9-49AD-8515-F042C7221481@linkedin.com> References: <67C1678059C61F408194E53907AFB5CC10F29C3C28@IS-EXMB01-RP.ad.reyrey.com> <5375640B-1EF3-4319-808E-BB0D56B45BF2@returnpath.com> In-Reply-To: <5375640B-1EF3-4319-808E-BB0D56B45BF2@returnpath.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.254] Content-Type: multipart/signed; boundary="Apple-Mail=_A9FB95AB-D44B-4EF9-9D6B-9F646817AC7E"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8ThWzePfKjcm3Id0S9YEl51dpGg Cc: "dmarc@ietf.org" , "McNamee, Tom" , Steve Jones Subject: Re: [dmarc-ietf] No DMARC reports delivered by AOL X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 17:52:19 -0000 --Apple-Mail=_A9FB95AB-D44B-4EF9-9D6B-9F646817AC7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 www.dmarcian.com has a nice tool to check your DMARC record is set = correctly. It does verify reporting is authorized. On Apr 4, 2014, at 7:43 AM, Greg Colburn = wrote: > Tom >=20 > AOL has implemented the DMARC feedback verification mechanism = described in Section 7.1 of the DMARC spec. > You need to deploy a report record on the domain that intends to = receive DMARC reports. >=20 > In short, create a TXT record at the location: >=20 > SENDING_DOMAIN._report._dmarc.DOMAIN_RECEIVING_REPORTS >=20 > with this content: >=20 > v=3DDMARC1 >=20 > This record will indicate that DOMAIN_RECEIVING_REPORTS is authorized = to receive reports for SENDING_DOMAIN. >=20 > Hope this helps! >=20 --Apple-Mail=_A9FB95AB-D44B-4EF9-9D6B-9F646817AC7E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJTPvE4AAoJEJHd9Bbysc+aLk0H/3uISA6ICK82iPHugSEo65Gc HMjeY1cej4OlBRKozMdcSeARdht6MsV4Rv7N5DTshNM4ELPxah27fmwIa5sBRP7h elVDAbWVMk/ucA4dTR1XcbgwhRqiS9OVxdcf0jqxQaU2DdnH2yljubA0oacatV8K a3IQ6DGya2uv3EVuAZzQX7eviGWb1DoRjQ09BCixpXlIbGg9jTGHRHy4X86vvxaY pEZSPh1eo7G0T+wNpBegEkIx7JZxr3JnlKe6X7vGnkyUw4Qu73LeY9OA/2vhUabJ nua45GnxeuW86IGpFlDmOGnkYmM79Mh1idVNVF4qxcr+NJ1ilgn2ZEUjS23hvBk= =wKsU -----END PGP SIGNATURE----- --Apple-Mail=_A9FB95AB-D44B-4EF9-9D6B-9F646817AC7E-- From SRS0=blZq=ZK=melix.net=pad@bounces.m4x.org Thu Apr 10 06:16: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 8D5811A021F for ; Thu, 10 Apr 2014 06:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 vjVgMM1ZDLjl for ; Thu, 10 Apr 2014 06:16:52 -0700 (PDT) Received: from mx1.polytechnique.org (mx1.polytechnique.org [129.104.30.34]) by ietfa.amsl.com (Postfix) with ESMTP id CE8A71A012D for ; Thu, 10 Apr 2014 06:16:51 -0700 (PDT) Received: from kulu.eltrai.net (kulu.eltrai.net [176.58.101.79]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id C17D91408EFA5 for ; Thu, 10 Apr 2014 15:16:48 +0200 (CEST) Received: from [172.23.42.121] (unknown [46.140.151.18]) by kulu.eltrai.net (Postfix) with ESMTPSA id 3D16B28AB33 for ; Thu, 10 Apr 2014 15:16:48 +0200 (CEST) Authentication-Results: kulu.eltrai.net; dkim=none reason="no signature"; dkim-adsp=none Message-ID: <534699BA.9010602@melix.net> Date: Thu, 10 Apr 2014 15:16:42 +0200 From: Pierre-Alain Dupont User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: multipart/alternative; boundary="------------070505090302070109070308" X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Thu Apr 10 15:16:48 2014 +0200 (CEST)) X-Org-Mail: pierre-alain.dupont.2010@polytechnique.org Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ReGZ2YtK3JEv3wpoCi6Zy3jRgoM Subject: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 13:18:02 -0000 This is a multi-part message in MIME format. --------------070505090302070109070308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi folks, After reading a few articles like http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html, I came to wonder as to why a soon-to-be standardized project came to on purpose break a huge part of the reality of today's emails. >From what I can read on this ML, the subject of forwarders/ML has been discussed here numerous times, and basically, the answer is somehow either of: * We do not care, forwarding shouldn't exist anyway. * Well, this is out of the scope of DMARC. * Maybe you could white-list the more prominent ones or implement a way to do it automatically. Neither of those answers is really acceptable. The only credible one is the third (that, or this protocol is not meant to be really used and is a purely academic work). Basically, it appears to me as if you are designing a protocol that would be, on purpose, only accessible to big firms that can have the manpower to do such a white-listing and/or do not really about their captive users. Many people appear to believe that it is acceptable to lose 2% legitimate emails... Well, it is not. Moreover, it will introduce a bias toward ML providers that are widely white-listed and others, that can in fact no longer appear as they are already blocked. Again, I see a pattern of saying "emailing would be better if there were only a few providers". I am really wondering as to what is your aim here. Reducing spam is a great goal, but not by sacrificing so much. I know there has been discussion as to whether this should be an IETF WG. Well, the answer is no. Definitely no. After all, the mission of the IETF is to make the Internet work better, and purposely excluding a section of the Internet is not a way to do it. Regards, PA.Dupont --------------070505090302070109070308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi folks,
After reading a few articles like http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html, I came to wonder as to why a soon-to-be standardized project came to on purpose break a huge part of the reality of today's emails.

From what I can read on this ML, the subject of forwarders/ML has been discussed here numerous times, and basically, the answer is somehow either of:
  • We do not care, forwarding shouldn't exist anyway.
  • Well, this is out of the scope of DMARC.
  • Maybe you could white-list the more prominent ones or implement a way to do it automatically.

Neither of those answers is really acceptable. The only credible one is the third (that, or this protocol is not meant to be really used and is a purely academic work).

Basically, it appears to me as if you are designing a protocol that would be, on purpose, only accessible to big firms that can have the manpower to do such a white-listing and/or do not really about their captive users. Many people appear to believe that it is acceptable to lose 2% legitimate emails... Well, it is not.
Moreover, it will introduce a bias toward ML providers that are widely white-listed and others, that can in fact no longer appear as they are already blocked. Again, I see a pattern of saying "emailing would be better if there were only a few providers".

I am really wondering as to what is your aim here. Reducing spam is a great goal, but not by sacrificing so much.

I know there has been discussion as to whether this should be an IETF WG. Well, the answer is no. Definitely no. After all, the mission of the IETF is to make the Internet work better, and purposely excluding a section of the Internet is not a way to do it.

Regards,
PA.Dupont

--------------070505090302070109070308-- From nobody Thu Apr 10 07:00: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 EFA8B1A023A for ; Thu, 10 Apr 2014 07:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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, 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 iR7Zltrm8gYH for ; Thu, 10 Apr 2014 07:00:02 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 734FB1A01DC for ; Thu, 10 Apr 2014 07:00:02 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ld13so3464542vcb.33 for ; Thu, 10 Apr 2014 07:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=TPjkJfbHDreR+pAF5OSzphdNYJE2Y/JqMhlKf/fZO6o=; b=l40XeTcsrhUdzL7EjYboDwlQfRNHNYfupeMT74jJEVz8oRHWCPkVCVDQ79rAOwp3ZD YjEeF7FygXYMlj2dtu4yq5EXp9tcMmSGWNPzmPc81XymF42+WtscXk3eJK6WXifr5nA2 Pod/T+GI8yjc0iDJX7kg8uQGxnT/L3FXJsATI= 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:content-type; bh=TPjkJfbHDreR+pAF5OSzphdNYJE2Y/JqMhlKf/fZO6o=; b=hBJdnwo56c5NvMU/C9b8/upDpyd3huqkwuIdCDiHPjTj/S2nptlrPwXE8C6NY7Z8V+ uzOHn3+NW9k5CbNoga7yYVqimekJypNbl25nVYIECAS82HSwj99o1LJ4rgD5XfurARuS MYDMm7IhDAWHpilKQnzPyEJe1u8zupT7rMBqIJnstWN2N+q32qa8mY+pk6zWlipUp/Bj uGrtDU8WZ/LSc+zqGJNYKQdN1Wra7Imu19HNVRd2lGvEn5v4iG/YstYdgtZ3uoZ8CpBu xkzKuMXkoTDvYFlthVuPC7S8sMdVLeY1o6gwfm0YOL+L7Gq/elxzRyGOQRJURHh2JUiq fRpw== X-Gm-Message-State: ALoCoQnW68WZ2xThVr9S6+Pm3wTS6/aE0EIa7PL8MdlcL4slZ/p4SP919+c9/18LIt7wYjdokzgU X-Received: by 10.52.78.231 with SMTP id e7mr1371224vdx.28.1397138401247; Thu, 10 Apr 2014 07:00:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.183.197 with HTTP; Thu, 10 Apr 2014 06:59:41 -0700 (PDT) X-Originating-IP: [205.217.25.189] In-Reply-To: <534699BA.9010602@melix.net> References: <534699BA.9010602@melix.net> From: John Sweet Date: Thu, 10 Apr 2014 06:59:41 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a1134044e1bdf7204f6b0a2c5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6Gw6Ijpan9AWajf1QwskTezwT9I Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 14:00:07 -0000 --001a1134044e1bdf7204f6b0a2c5 Content-Type: text/plain; charset=ISO-8859-1 I see the competing "answers" breaking down differently: - Mailing list implementation/practice must change to support From-header alignment - Never publish a p=reject policy for a domain with human (non-automated) senders "Whitelist known-good MLs" seems to me to be an effective way to eliminate the use of MLs entirely, since the number of lists, and of entities who must whitelist them, gets rather large rather quickly. In reaction to "MLs must change," I've seen, "Sure, I'll change -- to block all memberships/posts from addresses with p=reject policies." I've never heard DMARC proposed as a spam solution, only as a phishing solution. In that respect I think it's been very successful. On Thu, Apr 10, 2014 at 6:16 AM, Pierre-Alain Dupont wrote: > Hi folks, > After reading a few articles like > http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html, > I came to wonder as to why a soon-to-be standardized project came to on > purpose break a huge part of the reality of today's emails. > > From what I can read on this ML, the subject of forwarders/ML has been > discussed here numerous times, and basically, the answer is somehow either > of: > > - We do not care, forwarding shouldn't exist anyway. > - Well, this is out of the scope of DMARC. > - Maybe you could white-list the more prominent ones or implement a > way to do it automatically. > > Neither of those answers is really acceptable. The only credible one is > the third (that, or this protocol is not meant to be really used and is a > purely academic work). > > Basically, it appears to me as if you are designing a protocol that would > be, on purpose, only accessible to big firms that can have the manpower to > do such a white-listing and/or do not really about their captive users. > Many people appear to believe that it is acceptable to lose 2% legitimate > emails... Well, it is not. > Moreover, it will introduce a bias toward ML providers that are widely > white-listed and others, that can in fact no longer appear as they are > already blocked. Again, I see a pattern of saying "emailing would be better > if there were only a few providers". > > I am really wondering as to what is your aim here. Reducing spam is a > great goal, but not by sacrificing so much. > > I know there has been discussion as to whether this should be an IETF WG. > Well, the answer is no. Definitely no. After all, the mission of the IETF > is to make the Internet work better, and purposely excluding a section of > the Internet is not a way to do it. > > Regards, > PA.Dupont > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a1134044e1bdf7204f6b0a2c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I see the competing "answers= " breaking down differently:

=A0- Mailing list implementa= tion/practice must change to support From-header alignment
=A0- Ne= ver publish a p=3Dreject policy for a domain with human (non-automated) sen= ders

"Whitelist known-good MLs" seems to me to be an ef= fective way to eliminate the use of MLs entirely, since the number of lists= , and of entities who must whitelist them, gets rather large rather quickly= .

In reaction to "MLs must change," I've seen, "= Sure, I'll change -- to block all memberships/posts from addresses with= p=3Dreject policies."

I've never heard DMARC propose= d as a spam solution, only as a phishing solution. In that respect I think = it's been very successful.



On Thu, Apr 10, 2014 at 6:16 AM, Pierre-Alain Dupont <pad@melix.= net> wrote:
=20 =20 =20
Hi folks,
After reading a few articles like http://thehackernews.com/2014/04/yahoos= -new-dmarc-policy-destroys-every.html, I came to wonder as to why a soon-to-be standardized project came to on purpose break a huge part of the reality of today's emails.

From what I can read on this ML, the subject of forwarders/ML has been discussed here numerous times, and basically, the answer is somehow either of:
  • We do not care, forwarding shouldn't exist anyway.
  • Well, this is out of the scope of DMARC.
  • Maybe you could white-list the more prominent ones or implement a way to do it automatically.

Neither of those answers is really acceptable. The only credible one is the third (that, or this protocol is not meant to be really used and is a purely academic work).

Basically, it appears to me as if you are designing a protocol that would be, on purpose, only accessible to big firms that can have the manpower to do such a white-listing and/or do not really about their captive users. Many people appear to believe that it is acceptable to lose 2% legitimate emails... Well, it is not.
Moreover, it will introduce a bias toward ML providers that are widely white-listed and others, that can in fact no longer appear as they are already blocked. Again, I see a pattern of saying "emailing would be better if there were only a few providers&quo= t;.

I am really wondering as to what is your aim here. Reducing spam is a great goal, but not by sacrificing so much.

I know there has been discussion as to whether this should be an IETF WG. Well, the answer is no. Definitely no. After all, the mission of the IETF is to make the Internet work better, and purposely excluding a section of the Internet is not a way to do it.

Regards,
PA.Dupont


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


--001a1134044e1bdf7204f6b0a2c5-- From nobody Thu Apr 10 07:06: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 397F41A02E3 for ; Thu, 10 Apr 2014 07:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52Au-ELMjUAG for ; Thu, 10 Apr 2014 07:06:36 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 93DBA1A02A5 for ; Thu, 10 Apr 2014 07:06:36 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so3557182ykp.15 for ; Thu, 10 Apr 2014 07:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+8R/M7avEG55a7kkP1n0EjeLgraMyhMpzIprPvU0gSA=; b=SXFeevEaMsKjfd7/k0x/1tDuvmmEGm9HCHAP66DLyK/iL0u7zBI/JmQ/oYREGq1PpS 027RniJtNERCOz/p+QuW/gTPHNvWEcN8jfuPlDFW1nafIMehFxlQI7CR7qoZF3JoZFMq AoAL3UKzHPXJ0jfChJOpbN/j67iaT2ppT5pwUSsRra/vn0hLLVKKUNcxVZBXfUBt7YuK ntCrGwgBBtzu9Gv9UseATLdifDzYYqwhGRjsLQNCLuNRQ+H38e4vnGwEByZ8TVb6x6no mbr0zlqoG66X4ciTscO8iO/Kud+o4nnSpYh8dvWM8741tOC58W5E3kOrvijz6Extw7QK g54Q== X-Received: by 10.236.119.99 with SMTP id m63mr23085797yhh.65.1397138795494; Thu, 10 Apr 2014 07:06:35 -0700 (PDT) Received: from [10.168.69.12] (pool-71-164-185-121.dllstx.fios.verizon.net. [71.164.185.121]) by mx.google.com with ESMTPSA id l4sm7764945yhj.24.2014.04.10.07.06.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 07:06:34 -0700 (PDT) Message-ID: <5346A4F7.2080603@gmail.com> Date: Thu, 10 Apr 2014 09:04:39 -0500 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John Sweet , "dmarc@ietf.org" References: <534699BA.9010602@melix.net> 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/I8ew8DTqDijBJ0K8Jh0ni1VEWzw Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 14:06:44 -0000 On 4/10/2014 8:59 AM, John Sweet wrote: > I see the competing "answers" breaking down differently: > > - Mailing list implementation/practice must change to support > From-header alignment Just to be clear, WRT SPF, that means never being able to specify an address for return notifications, other than the author's address. No "delegating" the handling of such operational aspects of a message. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 10 07:55: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 45BA31A02C7 for ; Thu, 10 Apr 2014 07:55:43 -0700 (PDT) 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 E4TWzPmbIvdP for ; Thu, 10 Apr 2014 07:55:38 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id A41741A0224 for ; Thu, 10 Apr 2014 07:55:38 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id im17so3447588vcb.23 for ; Thu, 10 Apr 2014 07:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=K0cZ6cGKlE2KIUbmxyQLqTmBh40AQQ/Ahu0m1nhTrJM=; b=MANXgI0ZyyaJfc+48t0BVKRPTHhDtMmKYKPweLcNHjAQgfziT0th6bHWoIG12KjJFZ 972N6+zoOgd8K+PjIu22S8oqL8oZjzCPaWgxzb+yz1JUOhOgLHWAwOJwuduohod6V/i6 9fTfywZCShRUBvoui5jhYNbXE9Bd+3mmomSRo= 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:content-type; bh=K0cZ6cGKlE2KIUbmxyQLqTmBh40AQQ/Ahu0m1nhTrJM=; b=KBT642NvW2GkPGuy3xym5F46u9MQ6cas7tCWtzJMnXjI4I4PlQc1dpHV/ql5UHwbTi dnVwCBuVBrO1Jh6HoXFt+yGrEXMObJyNG7JUQ5g22ujbZ/ULPGjQPIh/hxDA2WNoBNR3 tc6dVLwMJUQ+jzWZUJF1HLwRVFqq9Wp8pZCpLcHX8NtL0mAkmOkI+MX/tRPrCWrsRM5t fEdt2971mwEvfLVnQYa5LBh2iAgn3ScGlFHjfAKToNhV6jfdtWYZIUbJrm+uFCg8EXVu dO7AywbjAVL9o30vVBWvSqbdAaRhoGljFr8H1Bv3h0PzLYkj+6lWpgU7OHal0EQSJbQS bCIA== X-Gm-Message-State: ALoCoQkIpy5KQ2YAxaxR19dssDnkgc+23v4qKNrUISL61P7XGK3HGABMo35K7A3PXkOgb6vAJbTD X-Received: by 10.221.20.199 with SMTP id qp7mr1503149vcb.24.1397141737419; Thu, 10 Apr 2014 07:55:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.183.197 with HTTP; Thu, 10 Apr 2014 07:55:17 -0700 (PDT) X-Originating-IP: [205.217.25.189] In-Reply-To: <5346A4F7.2080603@gmail.com> References: <534699BA.9010602@melix.net> <5346A4F7.2080603@gmail.com> From: John Sweet Date: Thu, 10 Apr 2014 07:55:17 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11339e2ef5feef04f6b16821 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/uWZXC5tHAMmcHmvWC5gFFkG6FlM Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 14:55:43 -0000 --001a11339e2ef5feef04f6b16821 Content-Type: text/plain; charset=ISO-8859-1 I thought that's what the Return-Path: was for. I understand that MLs want to field bounces so they can track and inhibit certain recipients, not to mention shield senders from (possibly very many) bounces in response to a single post. The vacation autoresponses alone can get very tedious very quickly. I'm not clear on how SPF alignment prevents this. My humblest apologies if you already covered the particulars in an earlier message, and I missed it. On Thu, Apr 10, 2014 at 7:04 AM, Dave Crocker wrote: > On 4/10/2014 8:59 AM, John Sweet wrote: > >> I see the competing "answers" breaking down differently: >> >> - Mailing list implementation/practice must change to support >> From-header alignment >> > > > Just to be clear, WRT SPF, that means never being able to specify an > address for return notifications, other than the author's address. No > "delegating" the handling of such operational aspects of a message. > > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --001a11339e2ef5feef04f6b16821 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I thought that's what the Return-Path: was for.
I understand that MLs want to field bounces so they can tr= ack and inhibit certain recipients, not to mention shield senders from (pos= sibly very many) bounces in response to a single post. The vacation autores= ponses alone can get very tedious very quickly. I'm not clear on how SP= F alignment prevents this.

My humblest apologies if you already covered the particulars= in an earlier message, and I missed it.


On Thu, Apr 10, 2014 at 7:04 AM,= Dave Crocker <dcrocker@gmail.com> wrote:
On 4/10/2014 8:59 AM, John S= weet wrote:
I see the competing "answers" breaking down differently:

=A0 - Mailing list implementation/practice must change to support
From-header alignment


Just to be clear, WRT SPF, that means never being able to specify an addres= s for return notifications, other than the author's address. =A0No &quo= t;delegating" the handling of such operational aspects of a message.



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--001a11339e2ef5feef04f6b16821-- From nobody Thu Apr 10 08:47: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 D45901A0285 for ; Thu, 10 Apr 2014 08:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, 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 J2lLNb-cKEhh for ; Thu, 10 Apr 2014 08:47:39 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2901A0297 for ; Thu, 10 Apr 2014 08:47:39 -0700 (PDT) Received: from [10.10.20.3] (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s3AFlRsd004748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 10 Apr 2014 08:47:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1397144858; bh=8AuramgZf87E0Bmm7+QiSA5UxJ1zYk7cAtbG0pVCPpY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=DMOtBbLvrtUw0qJ/9CVoYglygAHRZqTzv2c7pK++6yBN2QnjrGIztZTUHXQguoJdG /QvFU+nv/EsIqtSD2tszbFfg8/yTLstvgRmaIU43JiaeaGmW0hX7G2FN4Yb4UNSfDy 1a1Xf99rYmNSswS/V6Y+0Ax166B65Q8i1UXMQw7Y= Message-ID: <5346BD0F.8030600@bluepopcorn.net> Date: Thu, 10 Apr 2014 08:47:27 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <534699BA.9010602@melix.net> In-Reply-To: <534699BA.9010602@melix.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-tFCT1yy5RONiW1aeC3h4mibRXA Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 15:47:45 -0000 On 04/10/2014 06:16 AM, Pierre-Alain Dupont wrote: > After reading a few articles like > http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html, > I came to wonder as to why a soon-to-be standardized project came to > on purpose break a huge part of the reality of today's emails. This highlights one of the issues with the IETF publication process: many people assume that anything with an RFC number is an IETF standard. It was my understanding from Murray's message of March 26 that DMARC was being considered as an informational RFC, which of course is not a standard. More broadly: I'm not an expert on IETF publication criteria, but I hope that, especially given this confusion, controls are in place to protect against the publication of informational RFCs that might be harmful in some respect. -Jim From nobody Thu Apr 10 10:06:29 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 67E2E1A02FD for ; Thu, 10 Apr 2014 10:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.129 X-Spam-Level: * X-Spam-Status: No, score=1.129 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 SXSSaJ9qRRul for ; Thu, 10 Apr 2014 10:06:23 -0700 (PDT) Received: from nm49.bullet.mail.ne1.yahoo.com (nm49.bullet.mail.ne1.yahoo.com [98.138.120.56]) by ietfa.amsl.com (Postfix) with SMTP id 75C631A0327 for ; Thu, 10 Apr 2014 10:06:23 -0700 (PDT) Received: from [127.0.0.1] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 10 Apr 2014 17:06:22 -0000 Received: from [98.138.226.180] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 10 Apr 2014 17:03:34 -0000 Received: from [216.39.60.181] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 10 Apr 2014 17:03:34 -0000 Received: from [98.137.12.223] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 10 Apr 2014 17:03:34 -0000 Received: from [127.0.0.1] by omp1031.mail.gq1.yahoo.com with NNFMP; 10 Apr 2014 17:03:34 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 25696.55335.bm@omp1031.mail.gq1.yahoo.com Received: (qmail 35963 invoked by uid 60001); 10 Apr 2014 17:03:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397149413; bh=d8IeyBbFEyIIQsANRSSAUQz0N0/7Lodb+asb2TU1jOM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=XLELUFZzNqyk0C0M+6GG43N82Ef2q3dHDrZI+TPVEPi3abSQL38cybz3hsEOkuUW7Is5W4qo3p5u3bTHHdQg9t/Y8MnkcT6X9I+Hr67agY9ebzJBHtVhrj6x6nsVUpmFoKqxw+5h6LOim4r7J//d2JnUufJYqfSao2wgHa1rkfY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=yIaQ2SqHrMuURHM3fZ/NftKliVP+NyQAjF1VgxpoiWRA5Nwc/KG+IFeQhs70QjyUhwiSpoZCCax7vT7YvkQwJnd5tuID5s6hLI3UAJJxsfTBVS1sjUoqDpG8HZRsLG2ShwnOOTyOQ+laI0eqVslOLrOySlQibYvZcm5r8M1So+k=; X-YMail-OSG: hOuV1_kVM1mzn4h4CRgHAyokShbZfMD872yv3Ow8fZZNTY7 cvsR4ATykYlT0Fi86kOGzPXyGNKT4xwXKKtLn.WWa0OGAvpurN3Z6mfnUTvO YcA4O2Bhyzf5cEPDMFcs8aBkwPrI01nue8.IZacJMLbdjP7YaSWwYHZXbApr t1YRHLhsgfuZAmXxSXhlmsnLxX2Ut77EOiUieXk5GzEyufyJYXv9Sq9LDpKa N._BpUFqXlEj_ss25qARVxZmCcKfPG.k59DtIYofjas_HPWfJGmHhPJL8jev 1gDe9Rm0HWbCDWrObGda5t_zszDzv.b.zhgzBR6GEng.eEZU4P..XOOAFdL. aF.j7KfKrbMmdzoPTamPLe0UgSdeHHDX66AO2STobZZDhs_kQ4gpbXTw3SSN .uXVBJKr_xNf4DnsdCuCxTwAlE1dON6VZZwX1VsuVn96znUi33i4dlwiQ_ni .Yoj1FPvcZ2XMvqARCbpTldqzfm0CqtkL9ObYXpk2BWE.9iBZBgaW3FG.uR2 Jno62JEKpHBaDlmrkE2jsjerGZwpgCot6.KzR4KVAfGoWt.9K4qXrDU683B. 5z30TdFxWAn_lYIngbevT4UXTSOSB2ijG_YD3Y7qpFUYcLdMWXLJPfOA9Gg- - Received: from [77.105.60.164] by web164602.mail.gq1.yahoo.com via HTTP; Thu, 10 Apr 2014 10:03:33 PDT X-Rocket-MIMEInfo: 002.001, T24gVGh1cnNkYXksIEFwcmlsIDEwLCAyMDE0IDU6NDggUE0sIFBpZXJyZS1BbGFpbiBEdXBvbnQgd3JvdGU6Cj4gSSBhbSByZWFsbHkgd29uZGVyaW5nIGFzIHRvIHdoYXQgaXMgeW91ciBhaW0gaGVyZS4KCnVuZGVyc3RhbmRpbmcgZG1hcmMncyBhaW0gaXMgbXVjaCBlYXNpZXIgaWYgdSBzdHVkeSB0aGUgd2F5IGl0IGNhbWUgaW50byBiZWluZy4KCmluIHNob3J0LCBkbWFyYyBpcyBldm9sdXRpb24gb2YgcHJhY3RpY2Ugb2YgcmVwb3J0aW5nIG9uIHBoaXNoaW5nIGF0dGFja3MgYmlnIG1haWxib3ggcHJvdmkBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.182.648 References: Message-ID: <1397149413.28612.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Thu, 10 Apr 2014 10:03:33 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/snN8dX2ZxP37SH7hcbDrDfaW7Ac Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Apr 2014 17:06:27 -0000 On Thursday, April 10, 2014 5:48 PM, Pierre-Alain Dupont wrote: > I am really wondering as to what is your aim here. understanding dmarc's aim is much easier if u study the way it came into being. in short, dmarc is evolution of practice of reporting on phishing attacks big mailbox providers [yahoo, google] intercepted, on behalf of big email senders [facebook, paypal]. considering such two-way reporting helped big email senders, as well as mailbox providers, fight against phishing, they decided it's a good idea to standardise the entire protocol they devised for this purpose. however, while it was great for such a narrow playfield, in which none used forwarding, mailing lists, or anything of sort, it's rly bad for internet in wide, where all these practices r not only common, but natural, as clearly defined by their rfcs. the trouble is that, beyond fixing obvious problems with current dmarc protocol, ppl working on standardising this protocol don't rly imagine changing dmarc enough to account for all natures of internet emailing as seen today. instead, their tendency is to suggest fixes in those natures instead. i will agree with anyone who thinks such policy is inherently broken. it is, without talking too much, simple common sense to build new things while accounting for all old practices evolved thus far in the same domain. otherwise, what u r doing is introducing conflict, and when u do that, u need a strongly better reason than just domain-based email authentication and reporting. so, while phishing is a problem, dmarc will not solve it the way it's proposed today. dmarc will need to change greatly before domain owners start using p=reject widely. and its authors need to open up and start accepting new ideas. otherwise, all this effort won't mean much to anyone, but engineering teams in big email senders and big mailbox providers. and world isn't so small, and, i hope, will never be. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Thu Apr 10 10:07: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 406871A0219 for ; Thu, 10 Apr 2014 10:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 zYAB672WyKS8 for ; Thu, 10 Apr 2014 10:07:22 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id D48C71A01FF for ; Thu, 10 Apr 2014 10:07:21 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id D121D1C2153; Thu, 10 Apr 2014 19:07:19 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 910F31FE01CA; Thu, 10 Apr 2014 19:07:19 +0200 (CEST) Date: Thu, 10 Apr 2014 19:07:19 +0200 From: Kurt Roeckx To: John Sweet Message-ID: <20140410170719.GA22505@roeckx.be> References: <534699BA.9010602@melix.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Qjk75l2whjX2WfX4aWSNWUCU4fI Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 17:07:24 -0000 On Thu, Apr 10, 2014 at 06:59:41AM -0700, John Sweet wrote: > I see the competing "answers" breaking down differently: > > - Mailing list implementation/practice must change to support From-header > alignment So that would mean that all mails on a mailling listshould rewrite the From so that it's appears to come from someone in the domain of the maillinglist? Kurt From nobody Thu Apr 10 10:13:29 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 391F41A0219 for ; Thu, 10 Apr 2014 10:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v62_p4EHxxsl for ; Thu, 10 Apr 2014 10:13:24 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) by ietfa.amsl.com (Postfix) with ESMTP id A58151A01FF for ; Thu, 10 Apr 2014 10:13:24 -0700 (PDT) Received: by mail-yk0-f179.google.com with SMTP id 9so3799068ykp.38 for ; Thu, 10 Apr 2014 10:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TlH3G6iMtAZTsVBvktrmiX6SI3ZjSTsDTYKSZHnLrYU=; b=QQR7JyfovNOtuLft1ND6lps/Rib9pr1jkLpkLyVo1p0PUnn2Wkbw/BqoKdRwlkFLnw Uu6QlZETHvD16lFawOoR+23X/sTGB8qQx/ImPyI5SdxMZWdWuX4fa/6pUZ47Dco+cIvF 1/Uc1uWaiYFftWBWKxeVgg1/0PQE4a6C/nY3amIfmyZUS42FlRkKDEDUENKrQFYCavsV QgLEqRmwE2e2h4AvZWbszzYrEyg1kfHbfhh4APyTgToPHToUX32im07dCqzdS1GbTey0 YZcEPgjFFYBJI3ws5e2O7m7rws+SOePK/6viA05QH6kjLrqLzudab1eQP+fLbvN/ej12 3bJg== X-Received: by 10.236.135.104 with SMTP id t68mr24668095yhi.35.1397150003547; Thu, 10 Apr 2014 10:13:23 -0700 (PDT) Received: from [10.168.69.12] (pool-71-164-185-121.dllstx.fios.verizon.net. [71.164.185.121]) by mx.google.com with ESMTPSA id g26sm8648497yhk.3.2014.04.10.10.13.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 10:13:22 -0700 (PDT) Message-ID: <5346D0BF.5030708@gmail.com> Date: Thu, 10 Apr 2014 12:11:27 -0500 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John Sweet , "dmarc@ietf.org" References: <534699BA.9010602@melix.net> <5346A4F7.2080603@gmail.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/7WSARVc27ve7T9-I1T3lSRxMcB8 Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 17:13:29 -0000 On 4/10/2014 9:55 AM, John Sweet wrote: > I thought that's what the Return-Path: was for. Ignoring the SPF hack/enhancement to use rfc5321.EHLO rather than rfc5321.MailFrom, SPF aligns with MailFrom. Return-Path is an 822-level copy of MailFrom, created at delivery time. So, no, it no longer have a delegated address. > I understand that MLs want to field bounces so they can track and > inhibit certain recipients, not to mention shield senders from (possibly > very many) bounces in response to a single post. The vacation > autoresponses alone can get very tedious very quickly. I'm not clear on > how SPF alignment prevents this. My observation about this imposing a rigidity for the MailFrom command was meant as a universal effect, not merely one relevant to list processing. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 10 10:21: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 AB7951A030A for ; Thu, 10 Apr 2014 10:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyX1pxRRGXLc for ; Thu, 10 Apr 2014 10:21:06 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF541A0323 for ; Thu, 10 Apr 2014 10:21:06 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so2636833yha.26 for ; Thu, 10 Apr 2014 10:21:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1IZjWddO2Oe8Ld6DvfY8l4GUjsKvYpyscpY/UXStmnc=; b=Xs+eyVm7nrmfMA8wDmp6VAu30N4GFvC9Tju7Spl2UXOS5KJZESJYbOIW4qEKu9KNYn 6cc3+itXu2e4RRJC2EP7eCTC83lYXaxHUVl4c8HZEZwfFVCPPVhkno9y7HiQsW9C4s/W TgV5xl7I1wRtuZyZNyFOHQjUAQ/jlMMlgFSU7UFS803YqUCeO/XpoBOKPcsobKbp89V2 LxZV2SlneGrFtjqgkRhYsFZKtlaRQ2b3haQVqGGOIWPu4YEAmBYMkk4571pvGCJKzexn H5nuDOrqvakf3nEhPcWoHc/h5Uzj3oc11ctbz/NQSU0xGITI+rz3UjOuC5MIg4vqycbK I74A== X-Received: by 10.236.148.143 with SMTP id v15mr24861035yhj.58.1397150465399; Thu, 10 Apr 2014 10:21:05 -0700 (PDT) Received: from [10.168.69.12] (pool-71-164-185-121.dllstx.fios.verizon.net. [71.164.185.121]) by mx.google.com with ESMTPSA id u36sm8685918yhp.1.2014.04.10.10.21.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 10:21:04 -0700 (PDT) Message-ID: <5346D28D.4080505@gmail.com> Date: Thu, 10 Apr 2014 12:19:09 -0500 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jim Fenton , dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> In-Reply-To: <5346BD0F.8030600@bluepopcorn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ut32ykQfke3VmXOxRGNE5KbDDcY Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 17:21:11 -0000 On 4/10/2014 10:47 AM, Jim Fenton wrote: > On 04/10/2014 06:16 AM, Pierre-Alain Dupont wrote: >> After reading a few articles like >> http://thehackernews.com/2014/04/yahoos-new-dmarc-policy-destroys-every.html, >> I came to wonder as to why a soon-to-be standardized project came to >> on purpose break a huge part of the reality of today's emails. > > This highlights one of the issues with the IETF publication process: > many people assume that anything with an RFC number is an IETF standard. > It was my understanding from Murray's message of March 26 that DMARC was > being considered as an informational RFC, which of course is not a standard. Over the months there has been a variety of paths considered for the DMARC base spec. Someone thinking that it's intended for standards status isn't necessarily "misunderstanding"; they might merely not be current. > More broadly: I'm not an expert on IETF publication criteria, but I > hope that, especially given this confusion, controls are in place to > protect against the publication of informational RFCs that might be > harmful in some respect. 1. The confusion some people have about the meaning of RFC vs. IETF 'standard' is irrelevant to the current discussion. Yes, some people are confused. But as often as it gets cited over the years, it has never been demonstrated to cause real problems of any significance. 2. Publication of Informational RFCs submitted through the "Independent " stream -- which is independent of the IETF-managed stream -- is not based on the sorts of content control you postulate. Nor should it be. The kinds of control in place are roughly the same as they've been forever and, again, while some such documents cause some people discomfort, it, too, has not been demonstrated to cause serious problems. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 10 10:44: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 D02881A02FB for ; Thu, 10 Apr 2014 10:44:15 -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 RsAmLJrrfUs1 for ; Thu, 10 Apr 2014 10:44:10 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9A71A02C0 for ; Thu, 10 Apr 2014 10:44:09 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id r20so11146747wiv.9 for ; Thu, 10 Apr 2014 10:44:08 -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=InXnmVFmAVhKPl8chPKlG21Zb2IcCbJ/JiQaCehXEqc=; b=qUbZUvlnui41PJj08sit/klIlYXtVVGEOWSlwKRhlFuEJf9KFplY7j9ETd4ceHdvJ2 iYXNp6SxSdCOWI4i2eivlCc+/hGdoYtZ9XFXm29h9QhYoP1SwIrEl1dksqn7kZhVwUXD v7hZPimxGXd2CLlw9bj/84HH2d015M7uzJOTeR8Qjqes1vKX8+EGnXDoFuIcSAVw0iLL /Cl95rD7on6Y2HUg+TR/oiRan4i38d3O13aiFU7oEem0WJ2WsDwyf3GsN1zfGCq9997p +zmn6AaGa/HCmL6XFmuroFOpzrfqqh8AWPyE+cFc4RhCEL9sakAGkJg0ywmFZ1LOi9sw OoAQ== MIME-Version: 1.0 X-Received: by 10.194.109.227 with SMTP id hv3mr16710767wjb.10.1397151848358; Thu, 10 Apr 2014 10:44:08 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Thu, 10 Apr 2014 10:44:08 -0700 (PDT) In-Reply-To: <5346BD0F.8030600@bluepopcorn.net> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> Date: Thu, 10 Apr 2014 10:44:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: Jim Fenton Content-Type: multipart/alternative; boundary=089e0102ee289e6f9004f6b3c34a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FuybYAPMS7hog_W-d8ZsdvGqYdM Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 17:44:15 -0000 --089e0102ee289e6f9004f6b3c34a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 10, 2014 at 8:47 AM, Jim Fenton wrote: > More broadly: I'm not an expert on IETF publication criteria, but I > hope that, especially given this confusion, controls are in place to > protect against the publication of informational RFCs that might be > harmful in some respect. > I don't think it's a bad idea to publish things that have potentially negative side effects as long as they're well documented. If that's flatly disallowed, then a lot of good but incomplete ideas will never see the light of day. -MSK --089e0102ee289e6f9004f6b3c34a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 10, 2014 at 8:47 AM, Jim Fenton <fenton@= bluepopcorn.net> wrote:
More broadly: =A0I'm not an expert on IETF publication criteria, but I<= br> hope that, especially given this confusion, controls are in place to
protect against the publication of informational RFCs that might be
harmful in some respect.

I don't = think it's a bad idea to publish things that have potentially negative = side effects as long as they're well documented.=A0 If that's flatl= y disallowed, then a lot of good but incomplete ideas will never see the li= ght of day.

-MSK
--089e0102ee289e6f9004f6b3c34a-- From nobody Thu Apr 10 10:45: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 60E531A02C0 for ; Thu, 10 Apr 2014 10:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKtzxlqfLrd2 for ; Thu, 10 Apr 2014 10:45:42 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2281B1A02BC for ; Thu, 10 Apr 2014 10:45:42 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id q200so3796736ykb.22 for ; Thu, 10 Apr 2014 10:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TFjfsWnAHLlx6+KwMBOjz1D5+HPCD5tKqg5zD02lPCg=; b=AnxWwx3HgC9ANkJIq/DBVqpJFdf15h9YDLSo8MqobZ2IwQxvDV6OBAXX/Pj/u+OnDY lGATIkAwC2JI+YMauoQqSAbHI5qQtDTLWjU6B2Jcw2OBLF/L9EQvFuMk1CBR8XXs77NJ 5q7hBl3Eo1ASR2frrQs5vF99ed4S6nfLdrgxF2faV3UhENdq36/h50whvK1cYeNemTvq DeBFC/oOQ+bg1L+FxIyi6eBaOGdX6X3FDtzdGQqKmwiTzfRjpdTKyfM/howgI36t0Wi3 kLg2l7VPj9lUHT/YxEWpMYpokVyzjyREPiwp1SbxLGuSSKpdtkNlEas2a8TfqxCZwCs8 dgZw== X-Received: by 10.236.148.71 with SMTP id u47mr24850973yhj.82.1397151940966; Thu, 10 Apr 2014 10:45:40 -0700 (PDT) Received: from [10.168.69.12] (pool-71-164-185-121.dllstx.fios.verizon.net. [71.164.185.121]) by mx.google.com with ESMTPSA id h66sm8796594yhb.7.2014.04.10.10.45.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Apr 2014 10:45:40 -0700 (PDT) Message-ID: <5346D850.3050404@gmail.com> Date: Thu, 10 Apr 2014 12:43:44 -0500 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Jim Fenton References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> 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/JQEZx9jZLxe1cdn_72PTzalZHyk Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 17:45:43 -0000 On 4/10/2014 12:44 PM, Murray S. Kucherawy wrote: > I don't think it's a bad idea to publish things that have potentially > negative side effects as long as they're well documented. If that's > flatly disallowed, then a lot of good but incomplete ideas will never > see the light of day. Those are what get standardized... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Apr 10 10:46: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 6E6FB1A02BC for ; Thu, 10 Apr 2014 10:46:44 -0700 (PDT) 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 xC1Yz6AC9D2V for ; Thu, 10 Apr 2014 10:46:40 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDFC1A02C0 for ; Thu, 10 Apr 2014 10:46:40 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id pa12so3776759veb.15 for ; Thu, 10 Apr 2014 10:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=GfEnhpFy6xz7t7kjCz46J1jzD6LvJBXXAFj3Kak/7qk=; b=kTvcfUKA1mmYzV5YL5YuZJYuOC1h4Vr4Oxizmb93OTTTXkFV2Bp8JldHG0mqlZklO9 EYTf3RkQB7mU5EZVVYRVClaRQeNVNRVWwGU8eKlgfrPYPSCxMr7fcygHz9K+onpEYdEz IP3vbsd7D870X7CTKDxmWlACu2Scn9MlHhtL0= 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:content-type; bh=GfEnhpFy6xz7t7kjCz46J1jzD6LvJBXXAFj3Kak/7qk=; b=P7QyxU6ZmWqlE0vnKVW5m8OjXpX6G6B4gksPqf775lHhB4kBBrTqSH77ys/mWGpLJi xLQPWwQf+1WJsW5jet92m2/f5y4FF27QrSC5mDv0/TA/6gn3hzG+a41AgK5Tk40rsP4Z 7GLHZPgDXwC+twjoZSmmsM9kqUmHLYR6kI4HwzT0MhL0kniMHEYpNuBoLVNvJ+dT5/US OFds4cImXeHte0l4FYuCaHB7xK3iQIGajtgsGKHJ2fRUniLv14Dtf/ijciAdbBU1hboC VLcyBu5P2lcIi4df1oYr0O393WnLffPMFh8fl6Ckb+i7Xfvhy1w5KPikoU7WHa6fLzOg SnDg== X-Gm-Message-State: ALoCoQkNxQaJLu07dUlQhYXA4amCeHN9waOFqE1zAq7EV6HyXrN6XDa45ACqXcx2Eqgip6heYPeu X-Received: by 10.220.167.2 with SMTP id o2mr15436330vcy.8.1397151999337; Thu, 10 Apr 2014 10:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.183.197 with HTTP; Thu, 10 Apr 2014 10:46:19 -0700 (PDT) X-Originating-IP: [205.217.25.189] In-Reply-To: <20140410170719.GA22505@roeckx.be> References: <534699BA.9010602@melix.net> <20140410170719.GA22505@roeckx.be> From: John Sweet Date: Thu, 10 Apr 2014 10:46:19 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=089e011618ce9e39a004f6b3cce5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CetKC0DYKfAWndU5v00ooyx_mXE Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 17:46:44 -0000 --089e011618ce9e39a004f6b3cce5 Content-Type: text/plain; charset=ISO-8859-1 I was intentionally vague, since several distinct changes have been proposed along those lines. That's definitely one of them. The general objection covers all of them. On Thu, Apr 10, 2014 at 10:07 AM, Kurt Roeckx wrote: > On Thu, Apr 10, 2014 at 06:59:41AM -0700, John Sweet wrote: > > I see the competing "answers" breaking down differently: > > > > - Mailing list implementation/practice must change to support > From-header > > alignment > > So that would mean that all mails on a mailling listshould > rewrite the From so that it's appears to come from someone in the > domain of the maillinglist? > > > Kurt > > --089e011618ce9e39a004f6b3cce5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I was intentionally vague, since several distinct changes = have been=20 proposed along those lines. That's definitely one of them. The general= =20 objection covers all of them.


On Thu, Apr 10, 2014 at 10:07 AM, Kurt Roeckx <kurt@roe= ckx.be> wrote:
On Thu, Apr 10, 2014 at 06:5= 9:41AM -0700, John Sweet wrote:
> I see the competing "answers" breaking down differently:
>
> =A0- Mailing list implementation/practice must change to support From-= header
> alignment

So that would mean that all mails on a mailling listshould
rewrite the From so that it's appears to come from someone in the
domain of the maillinglist?


Kurt


--089e011618ce9e39a004f6b3cce5-- From nobody Thu Apr 10 10:47:53 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 8499B1A0309 for ; Thu, 10 Apr 2014 10:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCxXb8MiYUVg for ; Thu, 10 Apr 2014 10:47:47 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFA91A02D1 for ; Thu, 10 Apr 2014 10:47:47 -0700 (PDT) Received: (Haraka outbound); Thu, 10 Apr 2014 13:47:45 -0400 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=imac27.simerson.net; envelope-from= Received-SPF: None (mail.theartfarm.com: domain of imac27.simerson.net does not designate 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=helo; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Authentication-Results: mail.theartfarm.com; iprev=pass; auth=pass (plain); spf=pass smtp.mailfrom=tnpi.net Received: from imac27.simerson.net (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.4.0) with ESMTPSA id F3520C64-9577-45FF-85F7-58E065C55C28.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Thu, 10 Apr 2014 13:47:44 -0400 From: Matt Simerson Content-Type: multipart/alternative; boundary="Apple-Mail=_28C29929-01F8-41B2-9A88-395993ED1348" Message-Id: <7602AE9C-CFF1-43BD-864D-721A1F0E85B7@tnpi.net> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Thu, 10 Apr 2014 10:47:30 -0700 References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> To: "dmarc@ietf.org" In-Reply-To: X-Mailer: Apple Mail (2.1874) X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-ROUTEVIEWS: asn=7922 net=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-GeoIP: US, WA, Seattle, 2705km X-Haraka-GeoIP-Received: 50.159.99.59:US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Haraka-p0f: os="iOS iPhone or iPad" link_type="Ethernet or modem" distance=14 total_conn=3 shared_ip=N X-Spam-ASN: X-Spam-DCC: : messagesniffer 1102; 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-6343-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-6343-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 50.159.99.59, Ugly c=0.318533 p=-0.0909091 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-6343-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 5, history: 2, total_connects: 2, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors(-91), dnsbl.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=mBfkRVV/DI7OHrDtHoM9g52sArM+E/yxMRJBXYcVrQ4=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=l4KJVzsYRELRebU7XgfeKTGMVvT72p2kgVXgIMHF0pBov/r9qpKy8/GvM32aEX5RQ6ByQ/4PfAsJX2KoTy4qrV92U+n/HO6d8rYhUBZ6+9cCWU5Fw8t/+XPSEDfd+KFPKYz4IBwO96NbicPHDatAPNnJhKwaex1mFt1+787QXoDHgty8JWmoE2L5Z7sS09p96/7MO2wxoshBUJKM7Blpnxds3DRMuKIUHzmuNBSKa9P23ujElAFGoiyCT/0FwzQYjzFV7prurlvI81cd72rQtLPS7pRHI4tGoeQYdLHPfzNede+4EyuCpvepgFz+JlcqygxkcWuKx+IkNoBgQDE7Ww== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Hb7-ZENydVJbmB6o4GwOVBB6SZ4 Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 17:47:52 -0000 --Apple-Mail=_28C29929-01F8-41B2-9A88-395993ED1348 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 10, 2014, at 10:44 AM, Murray S. Kucherawy = wrote: > On Thu, Apr 10, 2014 at 8:47 AM, Jim Fenton = wrote: > More broadly: I'm not an expert on IETF publication criteria, but I > hope that, especially given this confusion, controls are in place to > protect against the publication of informational RFCs that might be > harmful in some respect. >=20 > I don't think it's a bad idea to publish things that have potentially = negative side effects as long as they're well documented. If that's = flatly disallowed, then a lot of good but incomplete ideas will never = see the light of day. +1 http://en.wikipedia.org/wiki/Tragedy_of_the_commons Matt --Apple-Mail=_28C29929-01F8-41B2-9A88-395993ED1348 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Apr 10, 2014, at 10:44 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Thu, Apr 10, 2014 at 8:47 AM, Jim Fenton <fenton@bluepopcorn.net> wrote:
More broadly:  I'm not an expert on IETF publication criteria, but I
hope that, especially given this confusion, controls are in place to
protect against the publication of informational RFCs that might be
harmful in some respect.

I don't think it's a bad idea to publish things that have potentially negative side effects as long as they're well documented.  If that's flatly disallowed, then a lot of good but incomplete ideas will never see the light of day.

+1


Matt

--Apple-Mail=_28C29929-01F8-41B2-9A88-395993ED1348-- From nobody Thu Apr 10 13:35: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 D24371A0162 for ; Thu, 10 Apr 2014 13:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 bc2lb4QgxZNw for ; Thu, 10 Apr 2014 13:35:49 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 724B61A0061 for ; Thu, 10 Apr 2014 13:35:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 40DE0295AFD for ; Thu, 10 Apr 2014 15:35:48 -0500 (CDT) 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 c74qBp5IZWHV for ; Thu, 10 Apr 2014 15:35:48 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 23852295AFF for ; Thu, 10 Apr 2014 15:35:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 173F0295AFE for ; Thu, 10 Apr 2014 15:35:48 -0500 (CDT) 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 m-sJnAwoSaqF for ; Thu, 10 Apr 2014 15:35:48 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id EDE0C295AFD for ; Thu, 10 Apr 2014 15:35:47 -0500 (CDT) Date: Thu, 10 Apr 2014 15:35:47 -0500 (CDT) From: Franck Martin To: "dmarc@ietf.org" Message-ID: <1842407775.120299.1397162147628.JavaMail.zimbra@peachymango.org> In-Reply-To: <998761114.117306.1397156970719.JavaMail.zimbra@peachymango.org> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <7602AE9C-CFF1-43BD-864D-721A1F0E85B7@tnpi.net> <998761114.117306.1397156970719.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_120298_342030621.1397162147627" X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC's purpose Thread-Index: LiZob60kMVU4eUwv+Dzz/ugiXXOOrKf9Yxxb Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LWM4Fl-ytRfWgzliWjmACPmFmtU Subject: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 10 Apr 2014 20:35:54 -0000 ------=_Part_120298_342030621.1397162147627 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Some random thoughts.... -Yahoo policy change did not break all mailing lists, for instance most lists at apache.org are fine. Creating hyperbole drama does not offer tools to solve problems. -I remember a time, when adding a tag in the subject line was frown upon at IETF... even sending email with a mime/HTML part would get you many angry emails. At that time, if DKIM had existed, everything would have been fine, but lists changed... -Some list management software are not taking advantage of extended SMTP error codes, something that any ESP do, the SOFT vs HARD bounce concept. -RFC like anything human, can be changed, overwritten, etc... There is nothing which is sacred. I'm not saying that change should be easy, I'm just saying that change is not impossible. Laws have been turned, overturned and returned... This is part of progress.... and change creates pain. -IETF recent focus is on pervasive monitoring, increasing security, prevent identity theft,... DMARC is a tool that helps, it is aligned with IETF recent goals. It is deployed, widely used, proven beneficial, has still some problems, lets' fix them. -DMARC is not a silver bullet, but denying any new technology, because bad behavior cannot be eradicated, but simply mitigated is really strange to me. -Convenience or Security, make a choice... -I heard of numbers that mailing lists traffic is 10% of overall legitimate traffic. Some DMARC adopters have seen it was less than 1%. Your mileage may vary. -The problem has been highlighted for a year at least. Saying you should not publish a policy p=reject for a domain with users is not useful, this is not a legal nor even a regulatory constraint and there is no such thing as the RFC police. It was bound to happen, it came earlier than expected... -At the time of ADSP, I don't think anyone spotted the unsubscribe collateral damage problem, people just said mailing lists cannot work with ADSP and there is nothing you can do. If the problem was limited to "you cannot receive my email when I post to the list", it would have been my problem. I experimented on DMARC.org lists and discovered the collateral damage. I shared my experience. -As DMARC is widely adopted (unless ADSP was), some of us decided to build tools to remediate this upcoming problem in advance. There is code in mailman 2.1.16 to make a list DMARC compliant via 2 options: one that please the people that the From: should be the original poster, one that displeases them. There is a patch to forbid people with a DMARC policy to subscribe/post to the list (not sure it is in the main code, this is not my hitch, but I respect people wanting to add it and I welcome them to work on it). I would have hoped we had a bit more time, because for instance this list is running on 2.1.15 and give or take 6 months, would have been upgraded naturally to 2.1.16 or even 2.1.17. It would have been easy for list admins to flip the switch. -A few lists have already been fixed very quickly, like the one run by Al, http://www.spamresource.com/2014/04/run-email-discussion-list-heres-how-to.html but there are other examples: http://groupserver.org/groups/development/messages/topic/5lLZaa1bSOyEmssFMFPeMX http://blog.threadable.com/how-threadable-solved-the-dmarc-problem , the "church list" has been fixed too, very quickly... -This could have been fixed a year ago, it is not like this was not a problem predicted... but until it is too late no one is motivated to fix issues in advance... -ISOC recently ran a survey on why operators are not present at IETF as they used to be... May be we prefer facts than judgements. We do also like bio-diversity: There is not one solution, but many, the standard is the solution most adopt eventually. IETF is making progress with anti-harassment and anti-bullying practices. So this is the IETF, we are engineers, we solve problems. Get working! ------=_Part_120298_342030621.1397162147627 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Some random thoughts....
-Yahoo policy change did not break all mailing lists, for insta= nce most lists at apache.org are fine. Creating hyperbole drama does not of= fer tools to solve problems.
-I remember a time, when adding = a tag in the subject line was frown upon at IETF... even sending email with= a mime/HTML part would get you many angry emails. At that time, if DKIM ha= d existed, everything would have been fine, but lists changed...
<= div>-Some list management software are not taking advantage of extended SMT= P error codes, something that any ESP do, the SOFT vs HARD bounce concept.<= br>
-RFC like anything human, can be changed, overwritten, etc...= There is nothing which is sacred. I'm not saying that change should be eas= y, I'm just saying that change is not impossible. Laws have been turned, ov= erturned and returned... This is part of progress.... and change creates pa= in.
-IETF recent focus is on pervasive monitoring, increasing= security, prevent identity theft,... DMARC is a tool that helps, it is ali= gned with IETF recent goals. It is deployed, widely used, proven beneficial= , has still some problems, lets' fix them.
-DMARC is not a si= lver bullet, but denying any new technology, because bad behavior cannot be= eradicated, but simply mitigated is really strange to me.
-C= onvenience or Security, make a choice...
-I heard of numbers = that mailing lists traffic is 10% of overall legitimate traffic. Some DMARC= adopters have seen it was less than 1%. Your mileage may vary.
-The problem has been highlighted for a year at least. Saying you should= not publish a policy p=3Dreject for a domain with users is not useful, thi= s is not a legal nor even a regulatory constraint and there is no such thin= g as the RFC police. It was bound to happen, it came earlier than expected.= ..
-At the time of ADSP, I don't think anyone spotted the uns= ubscribe collateral damage problem, people just said mailing lists cannot w= ork with ADSP and there is nothing you can do. If the problem was limited t= o "you cannot receive my email when I post to the list", it would have been= my problem. I experimented on DMARC.org lists and discovered the collatera= l damage. I shared my experience.
-As DMARC is widely adopted= (unless ADSP was), some of us decided to build tools to remediate this upc= oming problem in advance. There is code in mailman 2.1.16 to make a list DM= ARC compliant via 2 options: one that please the people that the From: shou= ld be the original poster, one that displeases them. There is a patch to fo= rbid people with a DMARC policy to subscribe/post to the list (not sure it = is in the main code, this is not my hitch, but I respect people wanting to = add it and I welcome them to work on it). I would have hoped we had a bit m= ore time, because for instance this list is running on 2.1.15 and give or t= ake 6 months, would have been upgraded naturally to 2.1.16 or even 2.1.17. = It would have been easy for list admins to flip the switch.
-= A few lists have already been fixed very quickly, like the one run by Al, <= a href=3D"http://www.spamresource.com/2014/04/run-email-discussion-list-her= es-how-to.html" data-mce-href=3D"http://www.spamresource.com/2014/04/run-em= ail-discussion-list-heres-how-to.html">http://www.spamresource.com/2014/04/= run-email-discussion-list-heres-how-to.html but there are other example= s: http://groupserver.org/groups/development/messages/topi= c/5lLZaa1bSOyEmssFMFPeMX http://blog.threadable.com/how-threadable-= solved-the-dmarc-problem , the "church list" has been fixed too, very q= uickly...
-This could have been fixed a year ago, it is not l= ike this was not a problem predicted... but until it is too late no one is = motivated to fix issues in advance...
-ISOC recently ran a su= rvey on why operators are not present at IETF as they used to be... May be = we prefer facts than judgements. We do also like bio-diversity: There is no= t one solution, but many, the standard is the solution most adopt eventuall= y. IETF is making progress with anti-harassment and anti-bullying practices= .

So this is the IETF, we are engineers, we so= lve problems. Get working!

------=_Part_120298_342030621.1397162147627-- From nobody Sat Apr 12 01:43:23 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 0CA2A1A0182 for ; Sat, 12 Apr 2014 01:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbE4sdHg4pw3 for ; Sat, 12 Apr 2014 01:43:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 495A71A00FC for ; Sat, 12 Apr 2014 01:43:21 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3C8h8SR013127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2014 01:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1397292194; bh=guysZQaUXeKpvUW+P5Z/eaemDGfRqyc3RmbW8LNDx40=; h=Date:To:From:Subject:In-Reply-To:References; b=AzvXwd5nFt1lx+MgBXIyqVvU4OE8Yz9JXUsWNQUT4XP1JQmuFpig7P8jM2kGUT67A rIwmZOdmHlaSN4QFQku8+p+Z47sBR/wv4OEOnlCbn5N0n+j5qoq33jicX0yVE79o4F mj2qL+7qBemh8Q7cQyYSXk+GBzRu5o1iRXmfyM+Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1397292194; i=@resistor.net; bh=guysZQaUXeKpvUW+P5Z/eaemDGfRqyc3RmbW8LNDx40=; h=Date:To:From:Subject:In-Reply-To:References; b=MNVcU4tXdzhcZ3mBvRCrxdF5bbnV4CZo+Eci54XvyS+FlFUzXHrEXa+/Wf5jsCQn6 qmg8ZH521jzehg3KoiFGs6w/Q4yTeDWUwLhOICg00Wyq4wrDhIoutLJCy9ubnxSMGC Pc72jGw1jOFnTafM8krFuIhN6zrnpb3netxgeFmw= Message-Id: <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 12 Apr 2014 01:41:24 -0700 To: Jim Fenton , dmarc@ietf.org From: SM In-Reply-To: <5346BD0F.8030600@bluepopcorn.net> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lj83AZJCh4xiKv6eZr5PAIOOyH4 Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 08:43:22 -0000 Hi Jim, At 08:47 10-04-2014, Jim Fenton wrote: >More broadly: I'm not an expert on IETF publication criteria, but I >hope that, especially given this confusion, controls are in place to >protect against the publication of informational RFCs that might be >harmful in some respect. It has been mentioned on this mailing list that publication of the DMARC specification will be sought through a non-IETF stream. There is a conflict review in such cases. BCP 92 describes the details. Regards, -sm From nobody Sat Apr 12 03:59: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 436941A0476 for ; Sat, 12 Apr 2014 03:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1dzQMoZDust for ; Sat, 12 Apr 2014 03:59:52 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 051501A0171 for ; Sat, 12 Apr 2014 03:59:51 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3CAxhZU028144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2014 03:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1397300390; bh=pb/lhEWu2CwzzDm1GxDNp23HJvWHh2kSOs+sSEpwDT4=; h=Date:To:From:Subject:In-Reply-To:References; b=bTj4qfZSN0CpETe8Z3CWNwk73A/zy2dH5Einjgj/lrXuQ1ilqeIna1V/UXS4hoaua 8V/LfURCb5AORn9Pwb9+pLvjejeqC4/jvOFU2LoGAzfE9wLfEOFiBuRLQi9OONThzR e3euVrc55jxfrMXFfEIKMlFfeoIgkKHoT392Y00s= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1397300390; i=@resistor.net; bh=pb/lhEWu2CwzzDm1GxDNp23HJvWHh2kSOs+sSEpwDT4=; h=Date:To:From:Subject:In-Reply-To:References; b=oQiBaZ4AzU5sIpds0eKX3Hg3tbp1DfaYjbek7qrzPzC8oevVFTixNrDdmCsYh5jhs bR/0nAe8C3AcqbZ+Xrq4UdKvg4nRtkGbNf+Zt3yX8x4jMdw4qO9JRi9G0nUSRUyGsa cMyxto9dgq3pvgnT44OjFTPOLqf1hg84oQTSZt54= Message-Id: <6.2.5.6.2.20140412034138.0babee90@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 12 Apr 2014 03:58:52 -0700 To: Franck Martin , dmarc@ietf.org From: SM In-Reply-To: <1842407775.120299.1397162147628.JavaMail.zimbra@peachymang o.org> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <7602AE9C-CFF1-43BD-864D-721A1F0E85B7@tnpi.net> <998761114.117306.1397156970719.JavaMail.zimbra@peachymango.org> <1842407775.120299.1397162147628.JavaMail.zimbra@peachymango.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kQolbb_T3RmgsI5-5gWPFZ0Ap_M Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 10:59:53 -0000 Hi Franck, At 13:35 10-04-2014, Franck Martin wrote: >Some random thoughts.... [snip] >-IETF recent focus is on pervasive monitoring, increasing security, >prevent identity theft,... DMARC is a tool that helps, it is aligned >with IETF recent goals. It is deployed, widely used, proven >beneficial, has still some problems, lets' fix them. How does DMARC help to in respect to pervasive monitoring, increasing security, prevent identity theft? Regards, -sm From nobody Sat Apr 12 05:29: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 611721A0108 for ; Sat, 12 Apr 2014 05:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pv1teGGHInwx for ; Sat, 12 Apr 2014 05:29:49 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id E58501A0104 for ; Sat, 12 Apr 2014 05:29:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id D516ECC0C2 for ; Sat, 12 Apr 2014 08:29:46 -0400 (EDT) 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 vnknwzdLcFK1 for ; Sat, 12 Apr 2014 08:29:38 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 25DACCC0BE for ; Sat, 12 Apr 2014 08:29:38 -0400 (EDT) Message-ID: <534931B1.4010407@meetinghouse.net> Date: Sat, 12 Apr 2014 08:29:37 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> In-Reply-To: <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tRh-luqz-dvt1QktSa9Zq88PAmY Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 12:29:50 -0000 SM wrote: > Hi Jim, > At 08:47 10-04-2014, Jim Fenton wrote: >> More broadly: I'm not an expert on IETF publication criteria, but I >> hope that, especially given this confusion, controls are in place to >> protect against the publication of informational RFCs that might be >> harmful in some respect. > > It has been mentioned on this mailing list that publication of the > DMARC specification will be sought through a non-IETF stream. There is > a conflict review in such cases. BCP 92 describes the details. > It does strike me that DMARC, which is currently an internet-draft, not even an RFC, is causing incredible disruption by its adoption, by a few very large players. Methinks this indicates a serious problem, and raises some questions about what measures might be taken when a big player breaks the Internet by not playing nice. It sure seems that IETF should play a role in this. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Apr 12 07:55: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 86E721A01C6 for ; Sat, 12 Apr 2014 07:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 h37ym9fTr4Vu for ; Sat, 12 Apr 2014 07:55:48 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 258AE1A0183 for ; Sat, 12 Apr 2014 07:55:48 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id c41so6527736yho.11 for ; Sat, 12 Apr 2014 07:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SwsRgA5WF2qRAfRzjFghOSgfk8knFryRX6Rq7lvPZ74=; b=dFuMSF9t5mNlABlnn6iAGTI4jh8EG3pEMf3coaDVvorqHhYULR58x6uztKOBnrwcue sgV7iFXbbs6zdpt1UHGDlbIuOVWnUdaYqRqPFZtRZiKLiqLjy2iVi0ghykBeOcuDHj22 zgkFmRaQSzLzYvziGJFO/NyZTkdkIszM93bXKct+ityEAW/bgir9+d+WCkAv7OiX1cEe cJo4FppH5K/lq1Lme6M7raP13NhYF7fU61mEFGbrKwVe1I+3vfJyae8PMwwhhXymled5 LoRs5yia6wEY8a8ojmhGNwLzC19I2J9p+I1QKUvJqydMBDK9PXQ2oPNxTJPamCNChxsQ PdXg== X-Received: by 10.236.119.99 with SMTP id m63mr41562150yhh.65.1397314546285; Sat, 12 Apr 2014 07:55:46 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id t63sm19742089yhm.32.2014.04.12.07.55.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Apr 2014 07:55:45 -0700 (PDT) Message-ID: <5349537A.8000604@gmail.com> Date: Sat, 12 Apr 2014 07:53:46 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Miles Fidelman , dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> In-Reply-To: <534931B1.4010407@meetinghouse.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/JUzR7yV9fNcIGO360Idh8TAfRGU Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 14:55:49 -0000 On 4/12/2014 5:29 AM, Miles Fidelman wrote: >> > It does strike me that DMARC, which is currently an internet-draft, not > even an RFC, is causing incredible disruption by its adoption, by a few > very large players. Methinks this indicates a serious problem, and > raises some questions about what measures might be taken when a big > player breaks the Internet by not playing nice. It sure seems that IETF > should play a role in this. 1. DMARC was developed by an ad hoc industry consortium. It is already deployed well enough to cover an estminated 60% of the world's email traffic. As such, it's status with the IETF is obviously not a gating factor. So the "not even an RFC" has some formal import, but limited practical import. 2. The spec is clear about how it works and what the implications are. The issue with mailing lists is well-documented. 3. A specification cannot be responsible for operators that choose to deploy something in a way that creates problems documented in the spec. 4. You don't say what you feel the IETF should do, nor is it obvious to me what role the IETF can reasonably have for this sort of deployment issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 12 08:10: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 38ED11A01C4 for ; Sat, 12 Apr 2014 08:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 wxAZjWNX2lyY for ; Sat, 12 Apr 2014 08:10:16 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6730E1A00B4 for ; Sat, 12 Apr 2014 08:10:16 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 9FFFF1C2121; Sat, 12 Apr 2014 17:10:13 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 731171FE015A; Sat, 12 Apr 2014 17:10:13 +0200 (CEST) Date: Sat, 12 Apr 2014 17:10:13 +0200 From: Kurt Roeckx To: Dave Crocker Message-ID: <20140412151013.GA29795@roeckx.be> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5349537A.8000604@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/95a6HDgB0wFAJ7UkzDY9kpK6OCU Cc: dmarc@ietf.org, Miles Fidelman Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 15:10:18 -0000 On Sat, Apr 12, 2014 at 07:53:46AM -0700, Dave Crocker wrote: > > 2. The spec is clear about how it works and what the implications are. The > issue with mailing lists is well-documented. I don't agree with this. Kurt From nobody Sat Apr 12 08:18: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 A01E91A01C8 for ; Sat, 12 Apr 2014 08:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlrPjvcAU1iw for ; Sat, 12 Apr 2014 08:17:56 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 666041A01D2 for ; Sat, 12 Apr 2014 08:17:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 5C140CC0B0 for ; Sat, 12 Apr 2014 11:17:54 -0400 (EDT) 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 2V30Ytvty5Cj for ; Sat, 12 Apr 2014 11:17:45 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 9060FCC0AA for ; Sat, 12 Apr 2014 11:17:45 -0400 (EDT) Message-ID: <53495919.50302@meetinghouse.net> Date: Sat, 12 Apr 2014 11:17:45 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> In-Reply-To: <5349537A.8000604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4aTRSfLbVlBroJ0XjYa_-nFKPko Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 15:17:58 -0000 Dave Crocker wrote: > On 4/12/2014 5:29 AM, Miles Fidelman wrote: >>> >> It does strike me that DMARC, which is currently an internet-draft, not >> even an RFC, is causing incredible disruption by its adoption, by a few >> very large players. Methinks this indicates a serious problem, and >> raises some questions about what measures might be taken when a big >> player breaks the Internet by not playing nice. It sure seems that IETF >> should play a role in this. > > > 1. DMARC was developed by an ad hoc industry consortium. It is > already deployed well enough to cover an estminated 60% of the world's > email traffic. As such, it's status with the IETF is obviously not a > gating factor. So the "not even an RFC" has some formal import, but > limited practical import. > So what happens to an infrastructure that is operated and governed by consensus, when a few large players can make major changes to the infrastructure while ignoring issues that don't directly effect their interests? > 2. The spec is clear about how it works and what the implications are. > The issue with mailing lists is well-documented. > Well documented, perhaps. But, see above. > 3. A specification cannot be responsible for operators that choose to > deploy something in a way that creates problems documented in the spec. > No. But a standards process can. (E.g., not just anybody can be domain registry, or enter records into the root nameservers). > 4. You don't say what you feel the IETF should do, nor is it obvious > to me what role the IETF can reasonably have for this sort of > deployment issue. > As to the practicalities of what IETF can do - I kind of agree. Which may point to a limit of Internet governance by consensus. (Consider the comparable case of a radio transmitter going off frequency and causing interference -- that will get a very rapid institutional response, possibly by people who carry guns, if, for example, you jam a police band.) As to what the IETF should do - well... at the very least the Internet operates on a set of standardized protocols, developed by consensus - and there is a formal process by which protocols develop from ideas, to experimental standards, to recommended, to mandatory (not many of those). At the very least, there is social pressure to conform to such standards. In some cases there are mechanisms that have more teeth (e.g., where registration of protocol numbers is required in a database under IANA "jurisdiction") - not just anybody can put records into the core nameservers, and those can always be removed (IETF sets the policies for a lot of the databases IANA maintains - I guess in theory IETF could establish a policy that says "if you don't follow these protocols properly, your DNS records get yanked"). I'm not sure I'm advocating such measures - but.... At the very least, it strikes me that the IETF should be visibly and publicly chastising the "ad hoc industry consortium that developed DMARC" and those who deployed it - as being exceptionally bad actors who: - roundly ignored issues of major impact in developing the standard - have deployed it in ways that are causing widespread havoc - are rather pointedly ignoring that havoc (have you seen anybody from Yahoo responding?) Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Apr 12 08:27:30 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 76A571A01DD for ; Sat, 12 Apr 2014 08:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQxTXbEk1FNR for ; Sat, 12 Apr 2014 08:27:25 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id EA0E91A01D8 for ; Sat, 12 Apr 2014 08:27:24 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id c41so6548365yho.11 for ; Sat, 12 Apr 2014 08:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Yu/lblX4mR/hmayzvA6/b9WqffrCgSjMIyfpnLmXJX8=; b=t9NdunWa190HhxRznsPz79Al9zr1VXDdQLWuQSFywWtx8qX8+vvYFDn3kW6g3Uhceu OLWx4mQ+Ez60aUHR/HPdM/V3kY+3ynxCSZUe4ZJ2bxlYJnSnMS1pAsCJIrRncE+Be5/g ZhaaHyxz+YBSjIJ1IufdWEo9XDWQA4ksKin1xnsnn0wtuFEGe5aVFv4PtaJ+LmbFnao3 ee/GLlhZJNptu/HcLGwlKxv0d0rpth938OGKX9pL5ZHghwsvKWcsghvcOMGxOTaaQN7+ kETqMxgk/mxd8S0sxOh5jq2W00Za2QLFmuMwsuNfILIqJeSOU4+Gek4PSIxbTMqA38mj JpYg== X-Received: by 10.236.94.103 with SMTP id m67mr1949744yhf.104.1397316443207; Sat, 12 Apr 2014 08:27:23 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id j76sm19875700yhi.33.2014.04.12.08.27.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Apr 2014 08:27:22 -0700 (PDT) Message-ID: <53495AE4.60703@gmail.com> Date: Sat, 12 Apr 2014 08:25:24 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Miles Fidelman , dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <53495919.50302@meetinghouse.net> In-Reply-To: <53495919.50302@meetinghouse.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IPn6Qe-6K0HM1LkqEzsYrhxb1eg Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 15:27:26 -0000 On 4/12/2014 8:17 AM, Miles Fidelman wrote: > Dave Crocker wrote: >> On 4/12/2014 5:29 AM, Miles Fidelman wrote: >> 1. DMARC was developed by an ad hoc industry consortium. It is >> already deployed well enough to cover an estminated 60% of the world's >> email traffic. As such, it's status with the IETF is obviously not a >> gating factor. So the "not even an RFC" has some formal import, but >> limited practical import. >> > So what happens to an infrastructure that is operated and governed by > consensus, when a few large players can make major changes to the > infrastructure while ignoring issues that don't directly effect their > interests? That's an excellent question. Worthy of discussion. Perhaps oddly, however, it is almost irrelevant to the work of the IETF, which is creation of technical specification. Your question is about enforcement, not about creation. That's an operations issue. >> 3. A specification cannot be responsible for operators that choose to >> deploy something in a way that creates problems documented in the spec. >> > No. But a standards process can. (E.g., not just anybody can be domain > registry, or enter records into the root nameservers). That's governed by operations organizations, not the IETF. > At the very least, it strikes me that the IETF should be visibly and > publicly chastising the "ad hoc industry consortium that developed > DMARC" and those who deployed it - as being exceptionally bad actors who: > - roundly ignored issues of major impact in developing the standard > - have deployed it in ways that are causing widespread havoc > - are rather pointedly ignoring that havoc (have you seen anybody from > Yahoo responding?) I believe the IETF has never done such a thing. I'm pretty sure it shouldn't. The more a technical organization delves into public policy and politics, the less it is a technical organization. Policy and politics issues come to dominate. At the least, they confuse perception of the organization. So while there well might be worthy statements and/or actions to be taken, when a major actor introduces major disruption, that's not a task for the IETF. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 12 08:42: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 4F61F1A01DD for ; Sat, 12 Apr 2014 08:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY7I-cRWjWCe for ; Sat, 12 Apr 2014 08:42:31 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7981A017D for ; Sat, 12 Apr 2014 08:42:31 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3CFgNvO021288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2014 08:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1397317349; bh=ZSGYZft093CA/skJInYT1/MTTQLu5hQE/9Fuwe88wIk=; h=Date:To:From:Subject:In-Reply-To:References; b=UVUOHs85BgnhF9q0iBBSTDC1iQ/wNpk20Yd9wUhQ7/1e1HnLbQ9V+lYoVwTw+43jw QHiYcKOrJwlhzLQepzyoC52Bbh54bJsaGHzrQFtgqEEtObpkym65KpBYj1g/4Q/u+k Rx9jhZ6iKay5fKRp3GBTYQXk01Cmn5VS9K7Fh1Pg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1397317349; i=@resistor.net; bh=ZSGYZft093CA/skJInYT1/MTTQLu5hQE/9Fuwe88wIk=; h=Date:To:From:Subject:In-Reply-To:References; b=f3dPWoGN4Q8Q+vtRn9Mn7+pdzALDeh99lVTH2vMJzQY7pLb+DPluhoTURC1joYl3B 2ISm9QqWOXP7j14f5J305nX58oyNUsmFQOTBGDtXF5l9+VUzKXjScdmceh92RKrdPn kgvjED4HZpwp8N9kyHVr7t6qFt/y4zrRI+gPIyx0= Message-Id: <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 12 Apr 2014 08:37:28 -0700 To: Miles Fidelman , dmarc@ietf.org From: SM In-Reply-To: <534931B1.4010407@meetinghouse.net> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MSKu0VcJDKRbIqYB8uJaq9RHg7c Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 15:42:32 -0000 Hi Miles, At 05:29 12-04-2014, Miles Fidelman wrote: >It does strike me that DMARC, which is currently an internet-draft, >not even an RFC, is causing incredible disruption by its adoption, >by a few very large players. Methinks this indicates a serious >problem, and raises some questions about what measures might be >taken when a big player breaks the Internet by not playing nice. It >sure seems that IETF should play a role in this. I do not see what IETF participants could do as the internet-draft is not being reviewed by the IETF. The big player is breaking email sent to mailing lists. It is not breaking the internet. I would not expect any company to play nice as it is a business after all. Regards, -sm From nobody Sat Apr 12 08:52: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 EFCA81A01ED for ; Sat, 12 Apr 2014 08:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9dQMHeyQkTP for ; Sat, 12 Apr 2014 08:52:13 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 36E3E1A01DD for ; Sat, 12 Apr 2014 08:52:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 21777CC0C1 for ; Sat, 12 Apr 2014 11:52:11 -0400 (EDT) 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 bk2cEykblu4h for ; Sat, 12 Apr 2014 11:52:02 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 4A0BBCC0C2 for ; Sat, 12 Apr 2014 11:52:02 -0400 (EDT) Message-ID: <53496121.9070305@meetinghouse.net> Date: Sat, 12 Apr 2014 11:52:01 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <53495919.50302@meetinghouse.net> <53495AE4.60703@gmail.com> In-Reply-To: <53495AE4.60703@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DgzI-Hkgbj4_7Evuj5RiNEFi_mc Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 15:52:15 -0000 Dave Crocker wrote: > On 4/12/2014 8:17 AM, Miles Fidelman wrote: >> Dave Crocker wrote: >>> On 4/12/2014 5:29 AM, Miles Fidelman wrote: >>> 1. DMARC was developed by an ad hoc industry consortium. It is >>> already deployed well enough to cover an estminated 60% of the world's >>> email traffic. As such, it's status with the IETF is obviously not a >>> gating factor. So the "not even an RFC" has some formal import, but >>> limited practical import. >>> >> So what happens to an infrastructure that is operated and governed by >> consensus, when a few large players can make major changes to the >> infrastructure while ignoring issues that don't directly effect their >> interests? > > That's an excellent question. Worthy of discussion. > > Perhaps oddly, however, it is almost irrelevant to the work of the > IETF, which is creation of technical specification. > > Your question is about enforcement, not about creation. > > That's an operations issue. > > >>> 3. A specification cannot be responsible for operators that choose to >>> deploy something in a way that creates problems documented in the spec. >>> >> No. But a standards process can. (E.g., not just anybody can be domain >> registry, or enter records into the root nameservers). > > That's governed by operations organizations, not the IETF. Well, yes and no. It's fairly typical in the standards world for one organization to set standards, and designate a "registration" authority to administer aspects of a standard. In the current discussion about the NTIA/ICANN transition, two examples of this have come up, and there are 100s more: - ISO defines the numbering scheme for bank card and credit card numbers, ANSI maintains the "Issuer Identification Database" - ISBN numbers are similarly standardized by one body, with delegated authority for issuing the numbers (ANSI by the way, is a voluntary, non-profit, originally formed by a bunch of engineering societies. ISO is a consortium of ANSI and other national level standards bodies.) Standards bodies also commonly define certification requirements and mechanisms, accredit certification bodies in various ways, and establish remedies for false representation of certification status. In the case of Internet protocols, IETF is the primary standards body, and through various MOUs has designated registration authorities for various things (mostly IANA). So yes, IETF has some governance authority (technical, moral, and legal) in this matter, if it chooses to exercise it. >> At the very least, it strikes me that the IETF should be visibly and >> publicly chastising the "ad hoc industry consortium that developed >> DMARC" and those who deployed it - as being exceptionally bad actors >> who: >> - roundly ignored issues of major impact in developing the standard >> - have deployed it in ways that are causing widespread havoc >> - are rather pointedly ignoring that havoc (have you seen anybody from >> Yahoo responding?) > > I believe the IETF has never done such a thing. I'm pretty sure it > shouldn't. Well - arguably, the IETF (or members thereof) were pretty vocal when the TCP/IP vs. ISO wars were going on. > > The more a technical organization delves into public policy and > politics, the less it is a technical organization. Policy and > politics issues come to dominate. > > At the least, they confuse perception of the organization. > Well, IEEE and ACM both have policy arms. IEEE is both a standards maker and very visible on some policy issues - including some that are technopolitical. (Granted that IEEEs standards efforts are relatively removed from their policy efforts). > So while there well might be worthy statements and/or actions to be > taken, when a major actor introduces major disruption, that's not a > task for the IETF. > Which then begs the question: Who's task is it? Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Apr 12 08:59: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 645A11A01EA for ; Sat, 12 Apr 2014 08:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ypBztJ0b1Iq for ; Sat, 12 Apr 2014 08:59:06 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7011A0159 for ; Sat, 12 Apr 2014 08:59:06 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so6541193yha.24 for ; Sat, 12 Apr 2014 08:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7ZeGmINxzArgV/qVUfImAA2SGETQauhZEBqYUr4EJ7I=; b=GWXRUymIw1sAnxM5VYpzyOS1y67BeoB2s2T+gMwPnQtyhFQ0+Jdl9pn6o0hZIgSoW8 ArDzeHyY3+dpGRBeSoxCkkFObh6iuBb7xP8gzHFtX6yIgW7DxIcXdu5ny7cGZXap6BbD 9LtzHv/E2rqTyDPCqRClrykwf2apSHumqPu1tCkQmddI2hRSiw3Loitw2ojLjMdIbTz2 eHYrW8JcZJri/uAkKJY+DSPIn+m145CDTYYNRYMmAjbxIPxMPNaAf4HGFq9S53kRh+0U 7UIE8TQolqMMC9pF7ns2R4xlDu6bKsBqGfUMFfnoQScKeKHx49CTOMKcl3NRpC07dVUJ 1myQ== X-Received: by 10.236.93.16 with SMTP id k16mr1159276yhf.140.1397318344610; Sat, 12 Apr 2014 08:59:04 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id q66sm20003935yhj.44.2014.04.12.08.59.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Apr 2014 08:59:03 -0700 (PDT) Message-ID: <53496251.60701@gmail.com> Date: Sat, 12 Apr 2014 08:57:05 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Miles Fidelman , dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <53495919.50302@meetinghouse.net> <53495AE4.60703@gmail.com> <53496121.9070305@meetinghouse.net> In-Reply-To: <53496121.9070305@meetinghouse.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hGHKuJJKOL1zak8ZBIBedrCDEx0 Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 15:59:07 -0000 On 4/12/2014 8:52 AM, Miles Fidelman wrote: > Dave Crocker wrote: >> That's governed by operations organizations, not the IETF. > > Well, yes and no. Your lengthy treatise does not appear to contain a specific proposal. So while the tutorial information is all well and good, how is it relevant to the current situation? >> I believe the IETF has never done such a thing. I'm pretty sure it >> shouldn't. > > Well - arguably, the IETF (or members thereof) were pretty vocal when > the TCP/IP vs. ISO wars were going on. It was? What specifics are you referring to? I don't recall the IETF doing anything but facilitating work on both technologies, both with ISODE and for network management, and later when considering choices in IPv6. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 12 09: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 9E4DC1A01FB for ; Sat, 12 Apr 2014 09:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 By5Apn12VkLL for ; Sat, 12 Apr 2014 09:23:09 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1167E1A01DD for ; Sat, 12 Apr 2014 09:23:08 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 16C90CC09F for ; Sat, 12 Apr 2014 12:23:07 -0400 (EDT) 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 PvEaCWYW7cSC for ; Sat, 12 Apr 2014 12:23:03 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id A61F0CC0AA for ; Sat, 12 Apr 2014 12:23:02 -0400 (EDT) Message-ID: <53496866.8000807@meetinghouse.net> Date: Sat, 12 Apr 2014 12:23:02 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> In-Reply-To: <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tIPN7uh50AXW8R9yeq-JV73xvCo Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 16:23:10 -0000 SM wrote: > Hi Miles, > At 05:29 12-04-2014, Miles Fidelman wrote: >> It does strike me that DMARC, which is currently an internet-draft, >> not even an RFC, is causing incredible disruption by its adoption, by >> a few very large players. Methinks this indicates a serious problem, >> and raises some questions about what measures might be taken when a >> big player breaks the Internet by not playing nice. It sure seems >> that IETF should play a role in this. > > I do not see what IETF participants could do as the internet-draft is > not being reviewed by the IETF. The big player is breaking email sent > to mailing lists. It is not breaking the internet. I would not > expect any company to play nice as it is a business after all. > Well, let's see: - DMARC is an ad-hoc group that assembled with a "common goal was to develop an operational specification to be introduced to the IETF for standardization" (http://dmarc.org/about.html) - DMARC.org defines the "DMARC Base Specification" with a link to https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF document - they published an information Internet draft, that expires in October of this year, that starts with "This memo presents a proposal for a scalable mechanism by which a mail sending organization can express,....." https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - by implication, they are representing DMARC as a standards-track IETF specification Publication of a "proposal" as an information Internet draft, is barely the first step toward an operational specification standardized by the IETF - yet DEMARC proponents are representing it as an IETF standard (or at least as going through the process). Beyond that, let me note that the draft includes this line: "The enclosed proposal is not intended to introduce mechanisms that provide elevated delivery privilege of authenticated email." -- which, of course is exactly what has been done by Yahoo by publishing "p=reject" in its DMARC policy, and by those who've chosen to honor it. So, it seems to me that it is entirely legitimate for IETF to officially be on the record that: 1. DMARC is NOT even close to an IETF standard 2. It has not been subject to any of the technical and operational vetting associated with the progression of a specification through the IETF standardization process 3. The means by which Yahoo has deployed DMARC, and the choice of several other large ISPs to honor the p=reject policy, is not in keeping with the practice of measured testing and incremental deployment of IETF standards, as they progress from proposal, to experimental, to optional, to recommended, to mandatory For reasons of technical and professional integrity, IETF should be distancing itself from this debacle, very loudly and very clearly. If nothing else, IETF should be defending its legitimacy as the Internet's standards body - in the same way that Xerox and Kleenex defend their trademarks. Beyond that - perhaps a strong position by IETF might have an impact on Yahoo's decision making. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Apr 12 09:26: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 897201A0159 for ; Sat, 12 Apr 2014 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl7IQ12dpdCn for ; Sat, 12 Apr 2014 09:26:33 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4122D1A001D for ; Sat, 12 Apr 2014 09:26:33 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 49E35CC0B0 for ; Sat, 12 Apr 2014 12:26:31 -0400 (EDT) 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 RUgPt8lyGsDs for ; Sat, 12 Apr 2014 12:26:22 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 9B7DDCC0A0 for ; Sat, 12 Apr 2014 12:26:22 -0400 (EDT) Message-ID: <5349692E.1030303@meetinghouse.net> Date: Sat, 12 Apr 2014 12:26:22 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <53495919.50302@meetinghouse.net> <53495AE4.60703@gmail.com> <53496121.9070305@meetinghouse.net> <53496251.60701@gmail.com> In-Reply-To: <53496251.60701@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ffnUc5BbS1bTYnkRCyqj6F9ECQg Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 16:26:34 -0000 Dave Crocker wrote: > On 4/12/2014 8:52 AM, Miles Fidelman wrote: >> Dave Crocker wrote: >>> That's governed by operations organizations, not the IETF. >> >> Well, yes and no. > > Your lengthy treatise does not appear to contain a specific proposal. > So while the tutorial information is all well and good, how is it > relevant to the current situation? > > >>> I believe the IETF has never done such a thing. I'm pretty sure it >>> shouldn't. >> >> Well - arguably, the IETF (or members thereof) were pretty vocal when >> the TCP/IP vs. ISO wars were going on. > > It was? What specifics are you referring to? I don't recall the IETF > doing anything but facilitating work on both technologies, both with > ISODE and for network management, and later when considering choices > in IPv6. > All I can speak for is observing some rather load and vociferous commentary, and agitation, from my BBN colleagues, many of whom were active in IETF, during the period where GSA and DoD were trying to foist OSI down everyone's throats. The technical and policy papers were flying fast and furious - though I can't say that any were official IETF documents or positions. Miles -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Apr 12 09:53: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 8097C1A01F8 for ; Sat, 12 Apr 2014 09:53:31 -0700 (PDT) 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 b__0upaPKZ9n for ; Sat, 12 Apr 2014 09:53:31 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id D82AB1A01DD for ; Sat, 12 Apr 2014 09:53:30 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so5023317yha.40 for ; Sat, 12 Apr 2014 09:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WSmCgKSkTU62IDYJ5ay/d2oE8iSIAbQwmD/Z+a5hIPk=; b=yc+DHvrrMl7A6n0b1+60hnJx6qpJuLtgWMVv9xb0duXPPXKI8gUuRnGeEzf2+SSSlm jnBCmg1zzXBzHXXx6mRUsGWMM5xi5L1o5rLO0YiSbN0ie5YQG155L6buhbFgf8PVwlsr VBquK2t5INiLI+UOiHOtG2EbjEej72dNkgiYWH1m9G32s6k7GA1dP9zfuhF3DVNdvrmc i/sLRKmDcaDOGfPh7AFSD6FgDCPpdGTbCevcUPVc2UEP1mG7EaVBCHOSIRW44xVbka0A t9xFL21TDrHvSG5qIhtUoUHysUVFjqe13uUdgMplHZgNIQx2sh0FyLO8X605QcJwlr/I 6X6w== X-Received: by 10.236.0.200 with SMTP id 48mr19571633yhb.72.1397321609065; Sat, 12 Apr 2014 09:53:29 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id z69sm20250563yha.26.2014.04.12.09.53.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Apr 2014 09:53:27 -0700 (PDT) Message-ID: <53496F11.5070306@gmail.com> Date: Sat, 12 Apr 2014 09:51:29 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Miles Fidelman References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> <53496866.8000807@meetinghouse.net> In-Reply-To: <53496866.8000807@meetinghouse.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/W4uPNesvcJsaJMKZNSxQRP09qbo Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 16:53:31 -0000 On 4/12/2014 9:23 AM, Miles Fidelman wrote: > > 1. DMARC is NOT even close to an IETF standard > 2. It has not been subject to any of the technical and operational > vetting associated with the progression of a specification through the > IETF standardization process > 3. The means by which Yahoo has deployed DMARC, and the choice of > several other large ISPs to honor the p=reject policy, is not in keeping > with the practice of measured testing and incremental deployment of IETF > standards, as they progress from proposal, to experimental, to optional, > to recommended, to mandatory The IETF doesn't do that sort of thing. If it did, it would be spending all of its time making similar statements about a great many other technologies and implementations. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 12 09:54:53 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 638271A01F8 for ; Sat, 12 Apr 2014 09:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFDvtSiCEs2K for ; Sat, 12 Apr 2014 09:54:50 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) by ietfa.amsl.com (Postfix) with ESMTP id 35F3E1A01DD for ; Sat, 12 Apr 2014 09:54:50 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 142so6027128ykq.41 for ; Sat, 12 Apr 2014 09:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qVm6SAjoDDoiHPyX2qTe6KponAby9/nUkyBafm7C70Q=; b=a8d1qK9P5JaNEcJUQr18eKbqbd1ZyeKIuNh0QX8TT5jj4Jcwtkpms494eMBf+eLx4O 1jjuKit6yxk0oIPvAhnZx2ofYJ153MItMBUueKwiIl7A1jgDmOuuMZRvjR5jUOZ4EYCu uJSGnBDN6fO00TkMWktKdCOnpS3RyJI7Ol9kWJPoe+yiiWygFTZUUa2L5KjD3GHdLOhM +gInK7S0PPwlDYrEfSDwK2H5gu7ffRfu4vBb6zSmWta8wFIcV1dk57vVIBgA2/BmvI+9 mPTv/SybQF9xFxQzZFFrAFekqgT8XfxcuwcEsca5mQbl3u3ngRduud5+KUi+/I2YY3hQ cm9w== X-Received: by 10.236.139.70 with SMTP id b46mr42356709yhj.63.1397321688448; Sat, 12 Apr 2014 09:54:48 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id t63sm20251525yhm.32.2014.04.12.09.54.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Apr 2014 09:54:47 -0700 (PDT) Message-ID: <53496F61.2090106@gmail.com> Date: Sat, 12 Apr 2014 09:52:49 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Miles Fidelman , dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <53495919.50302@meetinghouse.net> <53495AE4.60703@gmail.com> <53496121.9070305@meetinghouse.net> <53496251.60701@gmail.com> <5349692E.1030303@meetinghouse.net> In-Reply-To: <5349692E.1030303@meetinghouse.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/r5PkO_Yuqzeit8B4KeKqucvP2ng Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 16:54:51 -0000 On 4/12/2014 9:26 AM, Miles Fidelman wrote: > > All I can speak for is observing some rather load and vociferous > commentary, and agitation, from my BBN colleagues, many of whom were > active in IETF, during the period where GSA and DoD were trying to foist > OSI down everyone's throats. The technical and policy papers were > flying fast and furious - though I can't say that any were official IETF > documents or positions. Many /people/ who participated in the IETF, as were their /employers/. The /IETF/ itself wasn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Apr 12 09:57: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 7B68F1A01F8 for ; Sat, 12 Apr 2014 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 j8cLx9ItNvxp for ; Sat, 12 Apr 2014 09:57:55 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 38DC41A01DD for ; Sat, 12 Apr 2014 09:57:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 23EC2CC0B6 for ; Sat, 12 Apr 2014 12:57:53 -0400 (EDT) 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 MyYKpNAb-l5p for ; Sat, 12 Apr 2014 12:57:44 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 67D9ECC0B5 for ; Sat, 12 Apr 2014 12:57:44 -0400 (EDT) Message-ID: <53497088.2020904@meetinghouse.net> Date: Sat, 12 Apr 2014 12:57:44 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <53495919.50302@meetinghouse.net> <53495AE4.60703@gmail.com> <53496121.9070305@meetinghouse.net> <53496251.60701@gmail.com> <5349692E.1030303@meetinghouse.net> <53496F61.2090106@gmail.com> In-Reply-To: <53496F61.2090106@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XjnN7B-_ltHh6HI-5SiqsoIipWg Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 16:57:56 -0000 Dave Crocker wrote: > On 4/12/2014 9:26 AM, Miles Fidelman wrote: >> >> All I can speak for is observing some rather load and vociferous >> commentary, and agitation, from my BBN colleagues, many of whom were >> active in IETF, during the period where GSA and DoD were trying to foist >> OSI down everyone's throats. The technical and policy papers were >> flying fast and furious - though I can't say that any were official IETF >> documents or positions. > > > Many /people/ who participated in the IETF, as were their /employers/. > > The /IETF/ itself wasn't. > I believe what I said was "Well - arguably, the IETF (or members thereof) were pretty vocal when the TCP/IP vs. ISO wars were going on. " MF -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Apr 12 10:57: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 448671A020A for ; Sat, 12 Apr 2014 10:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.51 X-Spam-Level: * X-Spam-Status: No, score=1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_16=0.6, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muuc5o00PUxl for ; Sat, 12 Apr 2014 10:57:38 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E950C1A0211 for ; Sat, 12 Apr 2014 10:57:37 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3CHvSIK025576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2014 10:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1397325455; bh=/vWxC1H7wSdeIyqFL8M5TrUQEsRpAz3JD1/6Stn6wzo=; h=Date:To:From:Subject:In-Reply-To:References; b=fDPTMW+S8wk6AbHVWoy9YG7594rSRGgqSQHu+XR5KAoK6hrcUpyNLU/z/mI86MhGc Pmy9SW8fvNYj2fNiVE7akw2MrYwnBFMZf/taoEMC0Znc17cZp9F5c5O3jiJVOQMark Mx4dBXFJeWEm/jHW6i89G1kka3HC4JdN6moPOtwo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1397325455; i=@resistor.net; bh=/vWxC1H7wSdeIyqFL8M5TrUQEsRpAz3JD1/6Stn6wzo=; h=Date:To:From:Subject:In-Reply-To:References; b=ttuzLNbwoDQReHG9RDjqtxoPb2E0WOhVpevJV9QgT1zCrV1VbTMenfOIhATw2eE7m BOyp69lS75I5dvadoEoxYfmYHpVrbWxWxC5sFb84vEbfwKqpLzaw+jeUD2slj2AAE7 FnXvRrsIu9m/6TX/Vm4qT7IOCrQC09QZAXLf2iT4= Message-Id: <6.2.5.6.2.20140412095307.0baed408@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 12 Apr 2014 10:43:55 -0700 To: Miles Fidelman , dmarc@ietf.org From: SM In-Reply-To: <53496866.8000807@meetinghouse.net> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> <53496866.8000807@meetinghouse.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cgvhgXrM_tKuUv1RVWCGqlS1wXw Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 17:57:39 -0000 Hi Miles, At 09:23 12-04-2014, Miles Fidelman wrote: >Well, let's see: >- DMARC is an ad-hoc group that assembled with a "common goal was to >develop an operational specification to be introduced to the IETF >for standardization" >(http://dmarc.org/about.html) >- DMARC.org defines the "DMARC Base Specification" with a link to >https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF document >- they published an information Internet draft, that expires in >October of this year, that starts with "This memo presents a >proposal for a scalable mechanism by which a mail sending >organization can express,....." >https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ >- by implication, they are representing DMARC as a standards-track >IETF specification According to an article in the IETF Journal: "The amazing show of support changed the anticipated trajectory of the standardization plan. Rather than request the formation of an IETF working group (WG) to rework the specification, the authors discussed possible options with the IETF Applications Area WG and its Area Directors. Through conversation it became clear that there were some paths worth considering that would more closely follow the accelerated adoption curve associated with the draft DMARC specification. The end result was to ask an Applications Area Director to sponsor the specification as a candidate for the Standards Track, at the same time convening a Birds of a Feather (BoF) at IETF 87 in Berlin to discuss DMARC extensions and supporting materials. At the BoF, a charter for a proposed DMARC WG was presented, which drove a discussion about potential work items for the WG. Barry Leiba, one of the Application Area Directors, agreed to sponsor the specification with the caveat that messages sent to the IETF DMARC discussion list clearly said that community experts validated that the specification was ready to move to the Standards Track. Within a month of the BoF in Berlin, a handful of supportive comments by industry experts were sent to the discussion list. A few items were called out for further work on the DMARC specification, but many could be disposed of during the final-call phase of the Standards Track. While the DMARC specification could be tuned up, it's clearly functional for its intended purpose and the community supports the process for standardizing it." A message was posted to this mailing list this year. It was stated that: "We have chosen to submit the DMARC specification via the Independent Submission Editor (ISE). This will have three primary effects: (1) it will be published with a permanent reference location; (2) it will be classified as Informational rather than as a Proposed Standard; (3) the ISE process is a much more direct path to publication." >Publication of a "proposal" as an information Internet draft, is >barely the first step toward an operational specification >standardized by the IETF - yet DEMARC proponents are representing it >as an IETF standard (or at least as going through the process). I think that the web page mentioned above is out-of-date. As for the memo (I reviewed an old version last year) it represents the views of the authors. >Beyond that, let me note that the draft includes this line: "The >enclosed proposal is not intended to introduce mechanisms that >provide elevated delivery privilege of authenticated email." -- >which, of course is exactly what has been done by Yahoo by >publishing "p=reject" in its DMARC policy, and by those who've >chosen to honor it. Noted. >So, it seems to me that it is entirely legitimate for IETF to >officially be on the record that: >1. DMARC is NOT even close to an IETF standard >2. It has not been subject to any of the technical and operational >vetting associated with the progression of a specification through >the IETF standardization process >3. The means by which Yahoo has deployed DMARC, and the choice of >several other large ISPs to honor the p=reject policy, is not in >keeping with the practice of measured testing and incremental >deployment of IETF standards, as they progress from proposal, to >experimental, to optional, to recommended, to mandatory > >For reasons of technical and professional integrity, IETF should be >distancing itself from this debacle, very loudly and very clearly. >If nothing else, IETF should be defending its legitimacy as the >Internet's standards body - in the same way that Xerox and Kleenex >defend their trademarks. > >Beyond that - perhaps a strong position by IETF might have an impact >on Yahoo's decision making. The IETF would have to publish a RFC to be officially on record. A person would have to write a draft and get it through the process for such a RFC to be published. The above points looks like issues for the ietf@ietf.org mailing list as they are about IETF standardization and trademarks. Regards, -sm From nobody Sat Apr 12 11:31: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 9F5A71A021A for ; Sat, 12 Apr 2014 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.539 X-Spam-Level: X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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.272, 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 I7rQTVUKWoWR for ; Sat, 12 Apr 2014 11:31:52 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id F32B91A0215 for ; Sat, 12 Apr 2014 11:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1397327510; x=1428863510; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VQON2VDtArW7LJft8/wRo2OupSGGhy1Q2BTHQ5UMwS0=; b=Tris9YvlJTZUg31VFfWXGcNfl7pHCvXZUIbXGr2JvT4jTqzbdO/4943x 2VtuNtSlbthy2CfWub+J7UpI57RksFEIr+u0qXbls2PBSNpgBvaUSv7zw 54O7MLT/QCkHQQ3UuO7x9s0J/dCP+l4tvidBuXSDEx5sRRegN/xKGsLE5 M=; X-IronPort-AV: E=Sophos;i="4.97,848,1389772800"; d="scan'208";a="110718280" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 12 Apr 2014 11:30:39 -0700 Received: from ESV4-MBX02.linkedin.biz ([fe80::20f1:6264:6880:7fc7]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.03.0174.001; Sat, 12 Apr 2014 11:30:39 -0700 From: Franck Martin To: SM Thread-Topic: [dmarc-ietf] Fwd: DMARC's purpose Thread-Index: AQHPVPyDQW4x5nQHMEitpOTommn2pZsN0rdUgAB966g= Date: Sat, 12 Apr 2014 18:30:39 +0000 Message-ID: References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <7602AE9C-CFF1-43BD-864D-721A1F0E85B7@tnpi.net> <998761114.117306.1397156970719.JavaMail.zimbra@peachymango.org> <1842407775.120299.1397162147628.JavaMail.zimbra@peachymango.org>, <6.2.5.6.2.20140412034138.0babee90@resistor.net> In-Reply-To: <6.2.5.6.2.20140412034138.0babee90@resistor.net> 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/YdFwuGqB8PVKyvd3lUHtUnxp5X0 Cc: "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 18:31:53 -0000 Printed on recycled paper! > On Apr 12, 2014, at 3:59, "SM" wrote: >=20 > Hi Franck, > At 13:35 10-04-2014, Franck Martin wrote: >> Some random thoughts.... >=20 > [snip] >=20 >> -IETF recent focus is on pervasive monitoring, increasing security, prev= ent identity theft,... DMARC is a tool that helps, it is aligned with IETF = recent goals. It is deployed, widely used, proven beneficial, has still som= e problems, lets' fix them. >=20 > How does DMARC help to in respect to pervasive monitoring, increasing sec= urity, prevent identity theft? >=20 http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white= -papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf The recent target problem started with an email, say Krebs... A bit of research on security and email will give you a better picture on w= hy legitimate emails need to be better recognized.= From nobody Sat Apr 12 12:17: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 33D4D1A0221 for ; Sat, 12 Apr 2014 12:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BWXpypWy4UY for ; Sat, 12 Apr 2014 12:17:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA121A021C for ; Sat, 12 Apr 2014 12:17:27 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3CJHHDj027875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2014 12:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1397330245; bh=uPSNHu4txtLnP1+VPRIABm5XnlzDVz/wrPZqWHt3KJw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UINS3PrZyzf3ZexbXN384gXQoqFaF0g3wOwOI3aN+/CUAM+Z1abYmoqq56EAnPV3G uVCbwxbjVISyKFhs/Opa4Yb2LyMzT/yBEqMsyD9xSKvQOqxJWxVm3Y3nXv0qXe1tEm OkEI+6dCcHUIzwx+4Y6Dca4CtgnCiQpwOv+xEgaQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1397330245; i=@resistor.net; bh=uPSNHu4txtLnP1+VPRIABm5XnlzDVz/wrPZqWHt3KJw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=l2vg321F2pjm2PyHPgS2+/3ABKT05VrTTyBoaK7MEM3tl9R1xQlgXa4EEUy70AC0u qAegC537BBgVfFfIkvsxuYCQNi4zbHbO+S+i3oBctmN2h/Uq3j606+A7hQbokAHF7g iSII+9T1LV+ZDdZfGucyBR9AxoM6zSG+EFtEdg5E= Message-Id: <6.2.5.6.2.20140412120306.0bf54878@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 12 Apr 2014 12:16:13 -0700 To: Franck Martin From: SM In-Reply-To: References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <7602AE9C-CFF1-43BD-864D-721A1F0E85B7@tnpi.net> <998761114.117306.1397156970719.JavaMail.zimbra@peachymango.org> <1842407775.120299.1397162147628.JavaMail.zimbra@peachymango.org> <6.2.5.6.2.20140412034138.0babee90@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8VlkusCXHQXgK5PN9A1xA_ppJAk Cc: dmarc@ietf.org, Franck Martin Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 19:17:29 -0000 Hi Franck, At 11:30 12-04-2014, Franck Martin wrote: >http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf The above points me to an article from trendmicro.com. I was interested in reading your opinion. >The recent target problem started with an email, say Krebs... > >A bit of research on security and email will give you a better >picture on why legitimate emails need to be better recognized. Ok. Regards, -sm From nobody Sat Apr 12 12:25: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 08F161A0219 for ; Sat, 12 Apr 2014 12:25:25 -0700 (PDT) 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 fihgQS6IOVT7 for ; Sat, 12 Apr 2014 12:25:23 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 465E91A01F3 for ; Sat, 12 Apr 2014 12:25:23 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 537A9956100; Sat, 12 Apr 2014 15:25:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1397330720; bh=xkKq2xSoiUg5jQ1M2zDMwSQz2YUenb3tDCZ1StdZKYo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Q1yZl5ukiL5zU2F+S/CoZuht2yalmA1nJfq5rWi6qhBptz9j6/Dc/Ik5uVLJk0GEu f3kU90bk7+3lhhFWMQnRxGIw2KijZLJgrOxZXoexf1GeP66NB/qcLM8FWkHCb/4xtv TVhXvfPH9GHQ80Wsx54Cw6Dw0npZSInyDC2fxSHo= 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 28D5AD044DF; Sat, 12 Apr 2014 15:25:19 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 12 Apr 2014 15:25:18 -0400 Message-ID: <1585040.UfBqMe5fMm@scott-latitude-e6320> User-Agent: KMail/4.11.5 (Linux/3.11.0-19-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <534699BA.9010602@melix.net> <6.2.5.6.2.20140412034138.0babee90@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/auwxWbcUKA8iCqRq1Zz9U4PP4Vw Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 19:25:25 -0000 On Saturday, April 12, 2014 18:30:39 Franck Martin wrote: > Printed on recycled paper! > > > On Apr 12, 2014, at 3:59, "SM" wrote: > > > > Hi Franck, > > > > At 13:35 10-04-2014, Franck Martin wrote: > >> Some random thoughts.... > > > > [snip] > > > >> -IETF recent focus is on pervasive monitoring, increasing security, > >> prevent identity theft,... DMARC is a tool that helps, it is aligned > >> with IETF recent goals. It is deployed, widely used, proven beneficial, > >> has still some problems, lets' fix them.> > > How does DMARC help to in respect to pervasive monitoring, increasing > > security, prevent identity theft? > http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-> papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf > > The recent target problem started with an email, say Krebs... > > A bit of research on security and email will give you a better picture on > why legitimate emails need to be better recognized. I don't think anyone is disputing that. The problem is that legitimate emails are being treated as illegitimate. Scott K From nobody Sat Apr 12 12:58: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 4B6361A0227 for ; Sat, 12 Apr 2014 12:57:59 -0700 (PDT) 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 dxU3JSj_cH0g for ; Sat, 12 Apr 2014 12:57:58 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 29DD21A0224 for ; Sat, 12 Apr 2014 12:57:58 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 499C3CC0C0 for ; Sat, 12 Apr 2014 15:57:56 -0400 (EDT) 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 PHxXe1n2HezC for ; Sat, 12 Apr 2014 15:57:52 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id D7F87CC0B0 for ; Sat, 12 Apr 2014 15:57:51 -0400 (EDT) Message-ID: <53499ABF.7000901@meetinghouse.net> Date: Sat, 12 Apr 2014 15:57:51 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 CC: dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <7602AE9C-CFF1-43BD-864D-721A1F0E85B7@tnpi.net> <998761114.117306.1397156970719.JavaMail.zimbra@peachymango.org> <1842407775.120299.1397162147628.JavaMail.zimbra@peachymango.org> <6.2.5.6.2.20140412034138.0babee90@resistor.net> <6.2.5.6.2.20140412120306.0bf54878@resistor.net> In-Reply-To: <6.2.5.6.2.20140412120306.0bf54878@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/seiW7YKO4RXi65lBpU4FBsHqdfc Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 19:57:59 -0000 SM wrote: > Hi Franck, > At 11:30 12-04-2014, Franck Martin wrote: >> http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf >> > > The above points me to an article from trendmicro.com. I was > interested in reading your opinion. > >> The recent target problem started with an email, say Krebs... >> >> A bit of research on security and email will give you a better >> picture on why legitimate emails need to be better recognized. > > Ok. > Gee.... and how does this help from all those spams our server keeps receiving, from compromised Yahoo addresses that pass all the SPF, DKIM, and DMARC tests? Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Apr 12 13:21: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 4D4FB1A0237 for ; Sat, 12 Apr 2014 13:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 MVucG_HEVFtd for ; Sat, 12 Apr 2014 13:21:03 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3C97D1A0233 for ; Sat, 12 Apr 2014 13:21:03 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 013CC1C2121; Sat, 12 Apr 2014 22:21:01 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id CD9EC1FE015A; Sat, 12 Apr 2014 22:21:00 +0200 (CEST) Date: Sat, 12 Apr 2014 22:21:00 +0200 From: Kurt Roeckx To: Miles Fidelman Message-ID: <20140412202100.GA6327@roeckx.be> References: <5346BD0F.8030600@bluepopcorn.net> <7602AE9C-CFF1-43BD-864D-721A1F0E85B7@tnpi.net> <998761114.117306.1397156970719.JavaMail.zimbra@peachymango.org> <1842407775.120299.1397162147628.JavaMail.zimbra@peachymango.org> <6.2.5.6.2.20140412034138.0babee90@resistor.net> <6.2.5.6.2.20140412120306.0bf54878@resistor.net> <53499ABF.7000901@meetinghouse.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53499ABF.7000901@meetinghouse.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6FgW6fTvYoMkx63FjmvHyBSraJk Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 20:21:05 -0000 On Sat, Apr 12, 2014 at 03:57:51PM -0400, Miles Fidelman wrote: > SM wrote: > >Hi Franck, > >At 11:30 12-04-2014, Franck Martin wrote: > >>http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf > >> > > > >The above points me to an article from trendmicro.com. I was interested > >in reading your opinion. > > > >>The recent target problem started with an email, say Krebs... > >> > >>A bit of research on security and email will give you a better picture > >>on why legitimate emails need to be better recognized. > > > >Ok. > > > Gee.... and how does this help from all those spams our server keeps > receiving, from compromised Yahoo addresses that pass all the SPF, DKIM, and > DMARC tests? It's my understanding that Yahoo now claims to have no users anymore, only sends spam and advertises that by saying you can now reject all their mail. Seriously, DMARC does not try to do something about spam but about phishing, and by doing that has no problem rejecting otherwise real e-mail. kurt From nobody Sat Apr 12 13:24: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 E18811A0237 for ; Sat, 12 Apr 2014 13:24:52 -0700 (PDT) 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_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 5tX-PrwahzY9 for ; Sat, 12 Apr 2014 13:24:50 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id D6B521A0233 for ; Sat, 12 Apr 2014 13:24:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id EC2BC295F68; Sat, 12 Apr 2014 15:24:48 -0500 (CDT) 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 zDwp1LYBy1P1; Sat, 12 Apr 2014 15:24:48 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id CDC99295F6E; Sat, 12 Apr 2014 15:24:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B8DAB295F6D; Sat, 12 Apr 2014 15:24:48 -0500 (CDT) 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 a50xiaDv-SXP; Sat, 12 Apr 2014 15:24:48 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 95F2B295F68; Sat, 12 Apr 2014 15:24:48 -0500 (CDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Franck Martin Mime-Version: 1.0 Message-Id: <8DDD191B-F0FD-4B7B-938A-F303F9615125@peachymango.org> Date: Sat, 12 Apr 2014 15:24:48 -0500 (CDT) References: <534699BA.9010602@melix.net> <6.2.5.6.2.20140412034138.0babee90@resistor.net> <1585040.UfBqMe5fMm@scott-latitude-e6320> To: Scott Kitterman In-Reply-To: <1585040.UfBqMe5fMm@scott-latitude-e6320> X-Mailer: Zimbra 8.0.5_GA_5839 (MobileSync - Apple-iPad4C1/1104.167) Thread-Topic: DMARC's purpose Thread-Index: irVOS/AEIW+hO9yAtGlSSaXAxP12WA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rRDpDq3SrebTWlbHwh7kjl1OUwY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 20:24:53 -0000 Printed on recycled paper! > On Apr 12, 2014, at 12:25, "Scott Kitterman" wrote:= >=20 >> On Saturday, April 12, 2014 18:30:39 Franck Martin wrote: >> Printed on recycled paper! >>=20 >>> On Apr 12, 2014, at 3:59, "SM" wrote: >>>=20 >>> Hi Franck, >>>=20 >>> At 13:35 10-04-2014, Franck Martin wrote: >>>> Some random thoughts.... >>>=20 >>> [snip] >>>=20 >>>> -IETF recent focus is on pervasive monitoring, increasing security, >>>> prevent identity theft,... DMARC is a tool that helps, it is aligned >>>> with IETF recent goals. It is deployed, widely used, proven beneficial,= >>>> has still some problems, lets' fix them.> >>> How does DMARC help to in respect to pervasive monitoring, increasing >>> security, prevent identity theft? >> http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/whi= te-> papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf >>=20 >> The recent target problem started with an email, say Krebs... >>=20 >> A bit of research on security and email will give you a better picture on= >> why legitimate emails need to be better recognized. >=20 > I don't think anyone is disputing that. The problem is that legitimate em= ails=20 > are being treated as illegitimate. >=20 If you are not disputing that, then you know you need a driving license beca= use it increase security on the road, and if you don't have one then you can= feel some pain... We use to keep our doors open, we used to drive without license, we used to n= ot need TLS, we used to not need anti-spam software,... Machine learning is not as capable as human learning, algorithms are more re= strictive... Feel free to propose a better solution.. Quickly..=20 History in reboot, it all looks like SPF and DKIM IETF wars again....= From nobody Sat Apr 12 13:34: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 8E2621A0239 for ; Sat, 12 Apr 2014 13:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.119 X-Spam-Level: * X-Spam-Status: No, score=1.119 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_16=0.6, 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 7n00hNu6WrQM for ; Sat, 12 Apr 2014 13:34:22 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 74BD71A0233 for ; Sat, 12 Apr 2014 13:34:22 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 7EA4ACC0C0 for ; Sat, 12 Apr 2014 16:34:20 -0400 (EDT) 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 QlQUxWSh3RUN for ; Sat, 12 Apr 2014 16:34:16 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 10126CC0B5 for ; Sat, 12 Apr 2014 16:34:16 -0400 (EDT) Message-ID: <5349A347.2020609@meetinghouse.net> Date: Sat, 12 Apr 2014 16:34:15 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 CC: dmarc@ietf.org References: <5346BD0F.8030600@bluepopcorn.net> <7602AE9C-CFF1-43BD-864D-721A1F0E85B7@tnpi.net> <998761114.117306.1397156970719.JavaMail.zimbra@peachymango.org> <1842407775.120299.1397162147628.JavaMail.zimbra@peachymango.org> <6.2.5.6.2.20140412034138.0babee90@resistor.net> <6.2.5.6.2.20140412120306.0bf54878@resistor.net> <53499ABF.7000901@meetinghouse.net> <20140412202100.GA6327@roeckx.be> In-Reply-To: <20140412202100.GA6327@roeckx.be> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/csAkZj_iKP0sG-7_8YaYvLMIotA Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 20:34:23 -0000 Kurt Roeckx wrote: > On Sat, Apr 12, 2014 at 03:57:51PM -0400, Miles Fidelman wrote: >> SM wrote: >>> Hi Franck, >>> At 11:30 12-04-2014, Franck Martin wrote: >>>> http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white-papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf >>>> >>> The above points me to an article from trendmicro.com. I was interested >>> in reading your opinion. >>> >>>> The recent target problem started with an email, say Krebs... >>>> >>>> A bit of research on security and email will give you a better picture >>>> on why legitimate emails need to be better recognized. >>> Ok. >>> >> Gee.... and how does this help from all those spams our server keeps >> receiving, from compromised Yahoo addresses that pass all the SPF, DKIM, and >> DMARC tests? > It's my understanding that Yahoo now claims to have no users > anymore, only sends spam and advertises that by saying you can > now reject all their mail. > > Seriously, DMARC does not try to do something about spam but about > phishing, and by doing that has no problem rejecting otherwise > real e-mail. > It has just occurred to me that one might consider that by publishing it's p=reject policy into the DNS systems, one might consider that Yahoo has launched a DDoS attack on most of the world's list servers - which is illegal under a bunch of statutes (“knowingly caus[ing] the transmission of a program, information code, or command, and as a result of such conduct, intentionally causes damages without authorization to a protected computer”). One might also have a case that Yahoo is engaging in restraint of trade (by causing the rejection of valid emails), and that ISPs that honor the p=reject policy might be engaging in a criminal conspiracy. Hmmm...... Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Apr 12 13:36:11 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 639201A0233 for ; Sat, 12 Apr 2014 13:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 RpNKnW9sgGTW for ; Sat, 12 Apr 2014 13:36:08 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD881A023A for ; Sat, 12 Apr 2014 13:36:08 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 409E81C2121; Sat, 12 Apr 2014 22:36:06 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 159A11FE015A; Sat, 12 Apr 2014 22:36:06 +0200 (CEST) Date: Sat, 12 Apr 2014 22:36:05 +0200 From: Kurt Roeckx To: Franck Martin Message-ID: <20140412203605.GA7052@roeckx.be> References: <534699BA.9010602@melix.net> <6.2.5.6.2.20140412034138.0babee90@resistor.net> <1585040.UfBqMe5fMm@scott-latitude-e6320> <8DDD191B-F0FD-4B7B-938A-F303F9615125@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8DDD191B-F0FD-4B7B-938A-F303F9615125@peachymango.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/n11B9AdNmFHmrS66JVZkrIREwQc Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 20:36:09 -0000 On Sat, Apr 12, 2014 at 03:24:48PM -0500, Franck Martin wrote: > Feel free to propose a better solution.. Quickly.. It's actually not that hard. The technology already exists for over 20 years and is widely deployed already. Kurt From nobody Sat Apr 12 14:18: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 0426A1A0246 for ; Sat, 12 Apr 2014 14:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_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 naB1Gni4wA5N for ; Sat, 12 Apr 2014 14:18:37 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 383561A0243 for ; Sat, 12 Apr 2014 14:18:36 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 05618D045A1; Sat, 12 Apr 2014 17:18:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1397337515; bh=c9UKOAXYfmW0FZr+0Jr7qDTl29g6+Ph4mq7gqJ3DT/0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SVlVELqIMjDA68dXs9F7P5XCl4GfKoCd3mUn7/XXzR0LQRnRbcXtDCB09ghDSHOmK fMQKG2g47pHGss39lkSirn2ZqhCFH59Q314bQBjQl1HT1i71Rp1BD1Yo7Tq5DnRPD4 mwXZLjLkwdEbjzWimiqR4CUZlwlsZP7QDGfq2ndU= 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 CA318D0459A; Sat, 12 Apr 2014 17:18:34 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 12 Apr 2014 17:18:33 -0400 Message-ID: <2082417.kQeaGx1R5Z@scott-latitude-e6320> User-Agent: KMail/4.11.5 (Linux/3.11.0-19-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <8DDD191B-F0FD-4B7B-938A-F303F9615125@peachymango.org> References: <534699BA.9010602@melix.net> <1585040.UfBqMe5fMm@scott-latitude-e6320> <8DDD191B-F0FD-4B7B-938A-F303F9615125@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8IqFPkEr000EvtfJdZ85POGieSg Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 21:18:39 -0000 On Saturday, April 12, 2014 15:24:48 Franck Martin wrote: > Printed on recycled paper! > > > On Apr 12, 2014, at 12:25, "Scott Kitterman" wrote: > >> On Saturday, April 12, 2014 18:30:39 Franck Martin wrote: > >> Printed on recycled paper! > >> > >>> On Apr 12, 2014, at 3:59, "SM" wrote: > >>> > >>> Hi Franck, > >>> > >>> At 13:35 10-04-2014, Franck Martin wrote: > >>>> Some random thoughts.... > >>> > >>> [snip] > >>> > >>>> -IETF recent focus is on pervasive monitoring, increasing security, > >>>> prevent identity theft,... DMARC is a tool that helps, it is aligned > >>>> with IETF recent goals. It is deployed, widely used, proven beneficial, > >>>> has still some problems, lets' fix them.> > >>> > >>> How does DMARC help to in respect to pervasive monitoring, increasing > >>> security, prevent identity theft? > >> > >> http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/whi > >> te-> papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf > >> > >> The recent target problem started with an email, say Krebs... > >> > >> A bit of research on security and email will give you a better picture on > >> why legitimate emails need to be better recognized. > > > > I don't think anyone is disputing that. The problem is that legitimate > > emails are being treated as illegitimate. > > If you are not disputing that, then you know you need a driving license > because it increase security on the road, and if you don't have one then > you can feel some pain... > > We use to keep our doors open, we used to drive without license, we used to > not need TLS, we used to not need anti-spam software,... > > Machine learning is not as capable as human learning, algorithms are more > restrictive... > > Feel free to propose a better solution.. Quickly.. > > History in reboot, it all looks like SPF and DKIM IETF wars again.... No. This seems different. Having been involved in these discussions, writing and reviewing specs, writing code, and helping educate people about email authentication since 2004, I don't recall anything like this. The closes was the discussion about ADSP, but there was a clear understanding that ADSP was only appropriate for certain types of domains. The same is true of DMARC p=reject. It wasn't a problem until Yahoo stepped outside the generally understood scope of what p=reject was safe for with no notice and clearly absolutely no care for impact on third parties. There was also a fair amount of heat around the impact of SPF on transparent forwarding, but there was never the same kind of "screw you - your problem" attitude. If you look at the text of the soon to be published RFC 4408bis there is a ton (too much some people thought) of information about what can be done as a sender, mediator, or receiver to mitigate the problem. I think DMARC is a good idea (that's why I have DMARC records published), but you have to be careful how you use it. If they were going to make a change like this, despite the predictable and predicted negative impacts, it would have been a lot better to give notice so that administrators could be better prepared. As the confused discussion around what mailing lists should do now makes quite clear, there is no consensus on design or operational guidance to mitigate this issue. "mailman has a new feature" covers about 1% of the problem space. When I look at the feedback I get on my DMARC reports about 90% of the mail I send fails DMARC despite good SPF and DKIM deployments due to mailing lists, bug trackers, web site sharing, etc. For me and many others this is not about a trivial piece of the mail stream. Scott K From nobody Sat Apr 12 14:25:23 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 3C6201A0243 for ; Sat, 12 Apr 2014 14:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 pa0vs7SKQw6w for ; Sat, 12 Apr 2014 14:25:18 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id A5AE81A023C for ; Sat, 12 Apr 2014 14:25:18 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 19A121C215E; Sat, 12 Apr 2014 23:25:16 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id F0F201FE015A; Sat, 12 Apr 2014 23:25:15 +0200 (CEST) Date: Sat, 12 Apr 2014 23:25:15 +0200 From: Kurt Roeckx To: Scott Kitterman Message-ID: <20140412212515.GA8768@roeckx.be> References: <534699BA.9010602@melix.net> <1585040.UfBqMe5fMm@scott-latitude-e6320> <8DDD191B-F0FD-4B7B-938A-F303F9615125@peachymango.org> <2082417.kQeaGx1R5Z@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2082417.kQeaGx1R5Z@scott-latitude-e6320> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cVbBozP_lFtoPGImyQIPFdQggYE Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 21:25:20 -0000 On Sat, Apr 12, 2014 at 05:18:33PM -0400, Scott Kitterman wrote: > > When I look at the feedback I get on my DMARC reports about 90% of the mail I > send fails DMARC despite good SPF and DKIM deployments due to mailing lists, > bug trackers, web site sharing, etc. For me and many others this is not about > a trivial piece of the mail stream. Just as a reminder, of the mails I receive with DMARC records 90% fails. I'm glad I'm not the only one seeing such numbers. Kurt From nobody Sat Apr 12 14:29: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 59B731A0243 for ; Sat, 12 Apr 2014 14:29:13 -0700 (PDT) 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 BNZJ8EQw_FFU for ; Sat, 12 Apr 2014 14:29:12 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 168A51A022E for ; Sat, 12 Apr 2014 14:29:12 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 21AE8956112; Sat, 12 Apr 2014 17:29:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1397338150; bh=DEYK/DP6G6rpQm0JiEBIbM9ODY93qnz71rrrMT6+rHU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=J3kCvcGx0+yLMCHU/vFMXABGVGx6I45HqVHYgGhZUgNcPldvn3NWfrWyn4qCPBRV2 /ApfgS6V2QiPt+uvWN6nBSDSEra+9vsrMlDoOV58Mhk4iZ/HahNQ+11PU5R4KsAePh WJDyWQTKHVDc/sawycvbMn6q1l8fwkIQT737e1RI= 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 E814AD041D5; Sat, 12 Apr 2014 17:29:09 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 12 Apr 2014 17:29:08 -0400 Message-ID: <2046045.ifhvNey4Iy@scott-latitude-e6320> User-Agent: KMail/4.11.5 (Linux/3.11.0-19-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20140412212515.GA8768@roeckx.be> References: <534699BA.9010602@melix.net> <2082417.kQeaGx1R5Z@scott-latitude-e6320> <20140412212515.GA8768@roeckx.be> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/76S0bnxQmBObL7USymCczgJn5wg Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 21:29:13 -0000 On Saturday, April 12, 2014 23:25:15 Kurt Roeckx wrote: > On Sat, Apr 12, 2014 at 05:18:33PM -0400, Scott Kitterman wrote: > > When I look at the feedback I get on my DMARC reports about 90% of the > > mail I send fails DMARC despite good SPF and DKIM deployments due to > > mailing lists, bug trackers, web site sharing, etc. For me and many > > others this is not about a trivial piece of the mail stream. > > Just as a reminder, of the mails I receive with DMARC records 90% > fails. I'm glad I'm not the only one seeing such numbers. Although it's hard to tell what the numbers really mean. If I send a mail to a list such as debian-devel@lists.debian.org then that mail shows up in the Gmail feedback report as one failed message per Gmail using subscriber of the list. So the number of messages reported as failed is much larger than the actual number of messages you sent for a large mailing list. Scott K From nobody Sat Apr 12 14:54: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 D04A31A0251 for ; Sat, 12 Apr 2014 14:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 roz1C4qbWXv9 for ; Sat, 12 Apr 2014 14:54:19 -0700 (PDT) Received: from nm9-vm9.bullet.mail.gq1.yahoo.com (nm9-vm9.bullet.mail.gq1.yahoo.com [98.136.218.248]) by ietfa.amsl.com (Postfix) with ESMTP id 968001A0250 for ; Sat, 12 Apr 2014 14:54:19 -0700 (PDT) Received: from [216.39.60.184] by nm9.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2014 21:54:17 -0000 Received: from [98.137.12.226] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 12 Apr 2014 21:54:17 -0000 Received: from [127.0.0.1] by omp1034.mail.gq1.yahoo.com with NNFMP; 12 Apr 2014 21:54:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 879465.34407.bm@omp1034.mail.gq1.yahoo.com Received: (qmail 20458 invoked by uid 60001); 12 Apr 2014 21:54:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397339657; bh=IoJiBO/tBn+TMKl1E+GMKnvneZ7rBJz4MH9PPoieUHw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Q3fNVplHxwTrJirLBlte7j1TlJn6cuKLmNJUqnMnyOTXKTTbENyxGgOtg269H2EaYVTJZS7dn2osTzk+1esGwJxyqErWfjELAEOb7REw5JX8fZJ975QSvvQQDPKl9FvaGjqOk39E47Ld4po95Zx7AYKQKUR4eO2ogsqhRYMr8d0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Wmz68tmxjGiLsjpKQGhmEnc0evT40qVlE3Ky0og7iqgrdXFIPWLsE6fKVImGDhEAwwdrbLoN4DzeENbSuvjWmkhbnMKcaQJ5kWD5sNCHDa0bQuYKeMdOmrmwkmMgtTQE/MKJSOsNZhbCOjTiDEc3eI8JhfBazrtmVWLMu1a9sRg=; X-YMail-OSG: K6RGDu4VM1ntBhHHzq5dMkklEv5XY_5b9ReLg9B1UBZJuUh pTpTuT8D3FJ_ujIFxdsc3wCHECcNZJIhhs13_6RkFLy0DdHrnF_zTo..9jai iaU0UHtNR0kWf6Uwr9zLCFDsQIIZPNU4XNx3dnTv_TQzjLmUJuJShndkgiy8 .wVwuPoi46w8STi4MG5i5sjYH6ZdQzBzKDuVgy0p9Ma3gT3YI_FL6EBeN5kp kkdMTjomiVH7NXrxJFE92AnUG7BSK5Wl028o_jii6HQb3upMoZ_5iOyzsvF_ 5fQ4DoUVM4Oymi2vjItbiRyPYMgVa04aQsWeTmQ3ViqpXGH.JfFPIkKbKH9G LKmbIuO9xAqshceKbubf.7kiRAwTGJ1IjO1.0M0RZCLq0U4kLuxoAOV2Y96A 2GEgW01ce0QmP98IHgyFVrb7mFFsAdi64fUBLEj2q.5NmA0x9BKkdHzuQJy8 TBiDA2WZ28qqMdTWDGwqA3gLIeEnL_8ojT6zuXt3E7m6r1maFmeOKCTgpdyU bKgMkgc5wsK9KNu3tNFYsLVvuss0Yr3lF9WzE9KUiI2DjA2MAxyjJ_REZYbH exxgP1rgktAMTGWRvBhMGZyu2uBjUPTDU4dqpYPGT5OnSXsxsVa2YIBC1ss3 ..gzpZ8QC2.x9MDk- Received: from [77.105.60.164] by web164601.mail.gq1.yahoo.com via HTTP; Sat, 12 Apr 2014 14:54:17 PDT X-Rocket-MIMEInfo: 002.001, T24gU2F0dXJkYXksIEFwcmlsIDEyLCAyMDE0IDExOjE5IFBNLCBTY290dCBLaXR0ZXJtYW4gd3JvdGU6Cgo.IFdoZW4gSSBsb29rIGF0IHRoZSBmZWVkYmFjayBJIGdldCBvbiBteSBETUFSQyByZXBvcnRzIGFib3V0IDkwJSBvZiB0aGUgbWFpbAo.IEkgc2VuZCBmYWlscyBETUFSQyBkZXNwaXRlIGdvb2QgU1BGIGFuZCBES0lNIGRlcGxveW1lbnRzIGR1ZSB0byBtYWlsaW5nIGxpc3RzLAo.IGJ1ZyB0cmFja2Vycywgd2ViIHNpdGUgc2hhcmluZywgZXRjLiBGb3IgbWUgYW5kIG1hbnkgb3RoZXJzIHRoaXMgaXMBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.182.648 References: Message-ID: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Sat, 12 Apr 2014 14:54:17 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/s0VyUhX4RSPPQJkjLhMOLEmAr3Q Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 12 Apr 2014 21:54:20 -0000 On Saturday, April 12, 2014 11:19 PM, Scott Kitterman wrote: > When I look at the feedback I get on my DMARC reports about 90% of the mail > I send fails DMARC despite good SPF and DKIM deployments due to mailing lists, > bug trackers, web site sharing, etc. For me and many others this is not about > a trivial piece of the mail stream. +1 my email actually fails 98%. but who cares about me, i'm no facebook sending to yahoo, right? or yahoo sending to google... or some other big sending to some other big... or whatever. wrong. come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well but in very narrow field. this is what happens when a good idea gets half done, almost like a true recipe for developing a quitter personal trait. or eating half baked bread. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Sat Apr 12 16:27: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 D4A0F1A0228 for ; Sat, 12 Apr 2014 16:27:51 -0700 (PDT) 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_20=-0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 peW2PNAuSxV4 for ; Sat, 12 Apr 2014 16:27:50 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id EC43A1A01EC for ; Sat, 12 Apr 2014 16:27:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id EA217295F9C; Sat, 12 Apr 2014 18:27:47 -0500 (CDT) 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 uTQcPp241QsC; Sat, 12 Apr 2014 18:27:47 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C8DA7295FA3; Sat, 12 Apr 2014 18:27:47 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B2A21295FA2; Sat, 12 Apr 2014 18:27:47 -0500 (CDT) 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 vGNVNG21Oc87; Sat, 12 Apr 2014 18:27:47 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 94AB7295F9C; Sat, 12 Apr 2014 18:27:47 -0500 (CDT) Date: Sat, 12 Apr 2014 18:27:46 -0500 (CDT) From: Franck Martin To: Scott Kitterman Message-ID: <1801753381.158442.1397345266771.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <534699BA.9010602@melix.net> <1585040.UfBqMe5fMm@scott-latitude-e6320> <8DDD191B-F0FD-4B7B-938A-F303F9615125@peachymango.org> <2082417.kQeaGx1R5Z@scott-latitude-e6320> 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 - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC's purpose Thread-Index: BfbQJtIFiqVcG0sD8jLQqzXc5thn4g== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8dTs-zsTodeIYsi9led1K0RvAZU Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 23:27:52 -0000 ----- Original Message ----- > From: "Scott Kitterman" > To: dmarc@ietf.org > Sent: Saturday, April 12, 2014 2:18:33 PM > Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose >=20 > On Saturday, April 12, 2014 15:24:48 Franck Martin wrote: > > Printed on recycled paper! > >=20 > > > On Apr 12, 2014, at 12:25, "Scott Kitterman" > > > wrote: > > >> On Saturday, April 12, 2014 18:30:39 Franck Martin wrote: > > >> Printed on recycled paper! > > >>=20 > > >>> On Apr 12, 2014, at 3:59, "SM" wrote: > > >>>=20 > > >>> Hi Franck, > > >>>=20 > > >>> At 13:35 10-04-2014, Franck Martin wrote: > > >>>> Some random thoughts.... > > >>>=20 > > >>> [snip] > > >>>=20 > > >>>> -IETF recent focus is on pervasive monitoring, increasing security= , > > >>>> prevent identity theft,... DMARC is a tool that helps, it is align= ed > > >>>> with IETF recent goals. It is deployed, widely used, proven > > >>>> beneficial, > > >>>> has still some problems, lets' fix them.> > > >>>=20 > > >>> How does DMARC help to in respect to pervasive monitoring, increasi= ng > > >>> security, prevent identity theft? > > >>=20 > > >> http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligenc= e/whi > > >> te-> papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf > > >>=20 > > >> The recent target problem started with an email, say Krebs... > > >>=20 > > >> A bit of research on security and email will give you a better pictu= re > > >> on > > >> why legitimate emails need to be better recognized. > > >=20 > > > I don't think anyone is disputing that. The problem is that legitima= te > > > emails are being treated as illegitimate. > >=20 > > If you are not disputing that, then you know you need a driving license > > because it increase security on the road, and if you don't have one the= n > > you can feel some pain... > >=20 > > We use to keep our doors open, we used to drive without license, we use= d to > > not need TLS, we used to not need anti-spam software,... > >=20 > > Machine learning is not as capable as human learning, algorithms are mo= re > > restrictive... > >=20 > > Feel free to propose a better solution.. Quickly.. > >=20 > > History in reboot, it all looks like SPF and DKIM IETF wars again.... >=20 > No. This seems different. Having been involved in these discussions, > writing > and reviewing specs, writing code, and helping educate people about email > authentication since 2004, I don't recall anything like this. >=20 > The closes was the discussion about ADSP, but there was a clear understan= ding > that ADSP was only appropriate for certain types of domains. The same is > true > of DMARC p=3Dreject. It wasn't a problem until Yahoo stepped outside the > generally understood scope of what p=3Dreject was safe for with no notice= and > clearly absolutely no care for impact on third parties. >=20 > There was also a fair amount of heat around the impact of SPF on transpar= ent > forwarding, but there was never the same kind of "screw you - your proble= m" > attitude. If you look at the text of the soon to be published RFC 4408bi= s > there is a ton (too much some people thought) of information about what c= an > be > done as a sender, mediator, or receiver to mitigate the problem. >=20 > I think DMARC is a good idea (that's why I have DMARC records published),= but > you have to be careful how you use it. >=20 > If they were going to make a change like this, despite the predictable an= d > predicted negative impacts, it would have been a lot better to give notic= e so > that administrators could be better prepared. As the confused discussion > around what mailing lists should do now makes quite clear, there is no > consensus on design or operational guidance to mitigate this issue. "mai= lman > has a new feature" covers about 1% of the problem space. >=20 > When I look at the feedback I get on my DMARC reports about 90% of the ma= il I > send fails DMARC despite good SPF and DKIM deployments due to mailing lis= ts, > bug trackers, web site sharing, etc. For me and many others this is not > about > a trivial piece of the mail stream. I do agree with you, a bit more time would have helped=E2=80=A6 but then, I= was bullied (not by you) for wanting to put new features in mailing lists = to avoid this predicted collateral damage=E2=80=A6 So I did it when I had t= ime on the software I could=E2=80=A6 Now people are feeling way more motiva= ted=E2=80=A6 ;) This is true with all the other examples you gave, I told people, everywher= e I would find something like this.. The mistake what to not see it would h= appen sooner or later.. Security fixes always happen sooner than later... Sounds like the =E2=80=9Cyou should do TLS - yeah=E2=80=A6 yeah=E2=80=A6 wh= atever=E2=80=A6" anyhow, I think we should stop this thread, this is an IETF list, it is abo= ut working on protocols.=20 (and apparently french people are not supposed to do email outside working = hours :P ) From nobody Sat Apr 12 16:31: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 9BAB41A0228 for ; Sat, 12 Apr 2014 16:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 lm1q9LV7KmMo for ; Sat, 12 Apr 2014 16:31:55 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3CE1A01EC for ; Sat, 12 Apr 2014 16:31:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id EA71A294FEA; Sat, 12 Apr 2014 18:31:53 -0500 (CDT) 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 M5KC0WVI4fxG; Sat, 12 Apr 2014 18:31:53 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id CA326295FA2; Sat, 12 Apr 2014 18:31:53 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BD962295F9C; Sat, 12 Apr 2014 18:31:53 -0500 (CDT) 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 70njDaOavNJb; Sat, 12 Apr 2014 18:31:53 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id A6F55294FEA; Sat, 12 Apr 2014 18:31:53 -0500 (CDT) Date: Sat, 12 Apr 2014 18:31:53 -0500 (CDT) From: Franck Martin To: Vlatko Salaj Message-ID: <801640749.158448.1397345513483.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.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 - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC's purpose Thread-Index: hcWtHmLAqs5m2VyV21xooKEnpJkDrA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oXjipg4FM6mS-4UkONdUds6pnJw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 23:31:57 -0000 ----- Original Message ----- > From: "Vlatko Salaj" > To: dmarc@ietf.org > Sent: Saturday, April 12, 2014 2:54:17 PM > Subject: Re: [dmarc-ietf] DMARC's purpose > > On Saturday, April 12, 2014 11:19 PM, Scott Kitterman wrote: > > > When I look at the feedback I get on my DMARC reports about 90% of the mail > > I send fails DMARC despite good SPF and DKIM deployments due to mailing > > lists, > > bug trackers, web site sharing, etc. For me and many others this is not > > about > > a trivial piece of the mail stream. > > +1 > my email actually fails 98%. but who cares about me, i'm no facebook sending > to yahoo, right? or yahoo sending to google... or some other big sending to > some other big... or whatever. > Don't publish a DMARC policy which is detrimental to you... Also please correct your DMARC record, it is invalid: https://dmarcian.com/dmarc-inspector/goodone.tk From nobody Sat Apr 12 16:42: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 509F61A023F for ; Sat, 12 Apr 2014 16:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.281 X-Spam-Level: X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, 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 4VXZiYrtwnV3 for ; Sat, 12 Apr 2014 16:42:30 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB941A023E for ; Sat, 12 Apr 2014 16:42:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id B6752CC0BE for ; Sat, 12 Apr 2014 19:42:25 -0400 (EDT) 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 YiTxkZR+5XIh for ; Sat, 12 Apr 2014 19:42:21 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 3265ACC0B9 for ; Sat, 12 Apr 2014 19:42:21 -0400 (EDT) Message-ID: <5349CF5C.9070902@meetinghouse.net> Date: Sat, 12 Apr 2014 19:42:20 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 CC: dmarc@ietf.org References: <534699BA.9010602@melix.net> <1585040.UfBqMe5fMm@scott-latitude-e6320> <8DDD191B-F0FD-4B7B-938A-F303F9615125@peachymango.org> <2082417.kQeaGx1R5Z@scott-latitude-e6320> <1801753381.158442.1397345266771.JavaMail.zimbra@peachymango.org> In-Reply-To: <1801753381.158442.1397345266771.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/k17---BvkWVNbaDKmZ2U61Wo5No Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 12 Apr 2014 23:42:31 -0000 Franck Martin wrote: > ----- Original Message ----- >> From: "Scott Kitterman" >> To: dmarc@ietf.org >> Sent: Saturday, April 12, 2014 2:18:33 PM >> Subject: Re: [dmarc-ietf] Fwd: DMARC's purpose >> >> On Saturday, April 12, 2014 15:24:48 Franck Martin wrote: >>> Printed on recycled paper! >>> >>>> On Apr 12, 2014, at 12:25, "Scott Kitterman" >>>> wrote: >>>>> On Saturday, April 12, 2014 18:30:39 Franck Martin wrote: >>>>> Printed on recycled paper! >>>>> >>>>>> On Apr 12, 2014, at 3:59, "SM" wrote: >>>>>> >>>>>> Hi Franck, >>>>>> >>>>>> At 13:35 10-04-2014, Franck Martin wrote: >>>>>>> Some random thoughts.... >>>>>> [snip] >>>>>> >>>>>>> -IETF recent focus is on pervasive monitoring, increasing security, >>>>>>> prevent identity theft,... DMARC is a tool that helps, it is aligned >>>>>>> with IETF recent goals. It is deployed, widely used, proven >>>>>>> beneficial, >>>>>>> has still some problems, lets' fix them.> >>>>>> How does DMARC help to in respect to pervasive monitoring, increasing >>>>>> security, prevent identity theft? >>>>> http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/whi >>>>> te-> papers/wp-spear-phishing-email-most-favored-apt-attack-bait.pdf >>>>> >>>>> The recent target problem started with an email, say Krebs... >>>>> >>>>> A bit of research on security and email will give you a better picture >>>>> on >>>>> why legitimate emails need to be better recognized. >>>> I don't think anyone is disputing that. The problem is that legitimate >>>> emails are being treated as illegitimate. >>> If you are not disputing that, then you know you need a driving license >>> because it increase security on the road, and if you don't have one then >>> you can feel some pain... >>> >>> We use to keep our doors open, we used to drive without license, we used to >>> not need TLS, we used to not need anti-spam software,... >>> >>> Machine learning is not as capable as human learning, algorithms are more >>> restrictive... >>> >>> Feel free to propose a better solution.. Quickly.. >>> >>> History in reboot, it all looks like SPF and DKIM IETF wars again.... >> No. This seems different. Having been involved in these discussions, >> writing >> and reviewing specs, writing code, and helping educate people about email >> authentication since 2004, I don't recall anything like this. >> >> The closes was the discussion about ADSP, but there was a clear understanding >> that ADSP was only appropriate for certain types of domains. The same is >> true >> of DMARC p=reject. It wasn't a problem until Yahoo stepped outside the >> generally understood scope of what p=reject was safe for with no notice and >> clearly absolutely no care for impact on third parties. >> >> There was also a fair amount of heat around the impact of SPF on transparent >> forwarding, but there was never the same kind of "screw you - your problem" >> attitude. If you look at the text of the soon to be published RFC 4408bis >> there is a ton (too much some people thought) of information about what can >> be >> done as a sender, mediator, or receiver to mitigate the problem. >> >> I think DMARC is a good idea (that's why I have DMARC records published), but >> you have to be careful how you use it. >> >> If they were going to make a change like this, despite the predictable and >> predicted negative impacts, it would have been a lot better to give notice so >> that administrators could be better prepared. As the confused discussion >> around what mailing lists should do now makes quite clear, there is no >> consensus on design or operational guidance to mitigate this issue. "mailman >> has a new feature" covers about 1% of the problem space. >> >> When I look at the feedback I get on my DMARC reports about 90% of the mail I >> send fails DMARC despite good SPF and DKIM deployments due to mailing lists, >> bug trackers, web site sharing, etc. For me and many others this is not >> about >> a trivial piece of the mail stream. > > I do agree with you, a bit more time would have helped… but then, I was bullied (not by you) for wanting to put new features in mailing lists to avoid this predicted collateral damage… So I did it when I had time on the software I could… Now people are feeling way more motivated… ;) > > This is true with all the other examples you gave, I told people, everywhere I would find something like this.. The mistake what to not see it would happen sooner or later.. Security fixes always happen sooner than later... > > Sounds like the “you should do TLS - yeah… yeah… whatever…" > > anyhow, I think we should stop this thread, this is an IETF list, it is about working on protocols. > Silly me - I thought we were talking about the DMARC protocol, on the dmarc@ietf.org list. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Sat Apr 12 19:49: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 B7E041A01C7 for ; Sat, 12 Apr 2014 19:49:20 -0700 (PDT) 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 1xiC_qBHF_Th for ; Sat, 12 Apr 2014 19:49:19 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4E71A0198 for ; Sat, 12 Apr 2014 19:49:19 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2A7ADD04524; Sat, 12 Apr 2014 22:49:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1397357357; bh=+ASr0fOn2ieOBUtEfeYDiI4bxcSYiPyBRJ2GC165feI=; h=In-Reply-To:References:Subject:From:Date:To:From; b=smAkb2olXK+vyxsfKi5j3PrLCCps0sjr2SVDunPR0s2b0i8Vz9QR//uhCbny5/mcp bJHLFFQIusmXxmRElmGYUDVeWvieNujA8QZ7aFNfTM6r+qtmWDWNS4f/tsa96wKl1K I3wodPcSoLvG+PNOoyGFfs3rvJ+BPzTBW9CIsAE4= Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E3C4CD04522; Sat, 12 Apr 2014 22:49:16 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <801640749.158448.1397345513483.JavaMail.zimbra@peachymango.org> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <801640749.158448.1397345513483.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sat, 12 Apr 2014 22:49:15 -0400 To: dmarc@ietf.org Message-ID: <42f41c65-776c-4597-95c8-6aa3cba9dee1@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/RETJX9FBUaafuPWvjiLBJPFS-Oc Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 02:49:20 -0000 On April 12, 2014 7:31:53 PM EDT, Franck Martin wrote: > >----- Original Message ----- >> From: "Vlatko Salaj" >> To: dmarc@ietf.org >> Sent: Saturday, April 12, 2014 2:54:17 PM >> Subject: Re: [dmarc-ietf] DMARC's purpose >> >> On Saturday, April 12, 2014 11:19 PM, Scott Kitterman wrote: >> >> > When I look at the feedback I get on my DMARC reports about 90% of >the mail >> > I send fails DMARC despite good SPF and DKIM deployments due to >mailing >> > lists, >> > bug trackers, web site sharing, etc. For me and many others this is >not >> > about >> > a trivial piece of the mail stream. >> >> +1 >> my email actually fails 98%. but who cares about me, i'm no facebook >sending >> to yahoo, right? or yahoo sending to google... or some other big >sending to >> some other big... or whatever. >> > >Don't publish a DMARC policy which is detrimental to you... What DMARC record would I need to make the Google Group I administer work correctly with Yahoo subscribers? I am anxious to avoid detrimental DMARC policies. Scott K From nobody Sat Apr 12 22:51:03 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 8D4591A0269 for ; Sat, 12 Apr 2014 22:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 mCpswjycQWUd for ; Sat, 12 Apr 2014 22:51:00 -0700 (PDT) Received: from nm9-vm8.bullet.mail.gq1.yahoo.com (nm9-vm8.bullet.mail.gq1.yahoo.com [98.136.218.247]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7CA1A019B for ; Sat, 12 Apr 2014 22:51:00 -0700 (PDT) Received: from [98.137.12.59] by nm9.bullet.mail.gq1.yahoo.com with NNFMP; 13 Apr 2014 05:50:58 -0000 Received: from [98.137.12.227] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 13 Apr 2014 05:50:58 -0000 Received: from [127.0.0.1] by omp1035.mail.gq1.yahoo.com with NNFMP; 13 Apr 2014 05:50:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 402406.19581.bm@omp1035.mail.gq1.yahoo.com Received: (qmail 90265 invoked by uid 60001); 13 Apr 2014 05:50:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397368258; bh=Ct3jwCqC76aAy9/9cYQ6FIwjqjk8jJm7WrqAMw20x9E=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=X6Nup1Ack2hQNgBXh+aO1DTAEPtRvluE0VMFeXi6aZ+YVCbqzpT5oj3I+pTQHpTVv27YizxGq4M3YTKa7Ds4ZXPgZVUIK9zTXgWNMsC2EBpNtSyWyCbvFh0cXEXD/4Y7225T1jGA6p7wYIpJy+Gmm2sZEfb+jSxOS1NV60Kz8oA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IQADoQZWCn6aRfgMRcl33GBM4OXOpmAzvc+prE0U1bkU33AHPT6WmDUPj52XWAIksySWON660Y8VDt9a+3eDpIXk8Ji+Ros5/yGvM2e7tHYph62sipsbx21js36dNnm/QrdfX4JvWAfTGJrQHbMg3q+ZUDysm67gqN6pJ5mSGyM=; X-YMail-OSG: 76IABoQVM1kLvpX1SCsMrDHDDl3fibkJUgGp.qrVcnBVVHg oB7Y8CKJDWweGqUZdvtswbsekkIK_4datC22o72aprmoW0.HU5BzEzcMFaLD XjjtrTRt9MuXAddt_hSvfPjzzZT5nM_ug045fOj.cPVBSxbpxYu_oeXpLgTx qhkxu5zlaXn4BLCQ_lDpdS13GXQpSvXYGhnWkYh3sADg_MK7neD6ZU_UPg9N gJeWIJ.RrxZL9SC_R9sQLpazJ6eLil75xjECPnXpEQTngIw.9LEDBa5BTpf3 pvtmHi7XH4sXpOtEc97BuMZlT6oo2Q7XmnwAexJ16MURmmH2CBXzB_kBZPTq qFz6bY6kymDF50SpE6eXBhWIl_VJs3_wAhaHSg5RZx4x4f44AA6Tm2TqDbs3 mwy6f8evqVNMP4XxxFlqRzrmh1NFn13_BSFZqCwCHpW8eW_Wll6RChKBBuQ5 aZHBMYDbc.2zWoBpMUQaZHyoj.hgBIO8lPd_LCTL.0zYkcNPUqaS9m8OcNG. Re_nb2R3whFXiWgmK_K39JBoDiHnp_HsBXrRtZtvVUNI8.XbCkZuK10GPagr dQ3.HNR_AlSb3oiqAuT7dfscUSg4B9t2qTWwmCNFUYdHKlSrLHrNRE1iVlPz x1eyI_V73sdyy Received: from [77.105.60.164] by web164601.mail.gq1.yahoo.com via HTTP; Sat, 12 Apr 2014 22:50:58 PDT X-Rocket-MIMEInfo: 002.001, T24gU3VuZGF5LCBBcHJpbCAxMywgMjAxNCAxOjMxIEFNLCBGcmFuY2sgTWFydGluIHdyb3RlOgoKCj4.IG15IGVtYWlsIGFjdHVhbGx5IGZhaWxzIDk4JS4gYnV0IHdobyBjYXJlcyBhYm91dCBtZSwgaSdtIG5vIGZhY2Vib29rIHNlbmRpbmcKPj4gdG8geWFob28sIHJpZ2h0PyBvciB5YWhvbyBzZW5kaW5nIHRvIGdvb2dsZS4uLiBvciBzb21lIG90aGVyIGJpZyBzZW5kaW5nIHRvCj4.IHNvbWUgb3RoZXIgYmlnLi4uIG9yIHdoYXRldmVyLgo.IERvbid0IHB1Ymxpc2ggYSBETUFSQyBwb2xpY3kgd2hpY2ggaXMBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.182.648 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <801640749.158448.1397345513483.JavaMail.zimbra@peachymango.org> Message-ID: <1397368258.79484.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Sat, 12 Apr 2014 22:50:58 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <801640749.158448.1397345513483.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/a1v4MlNEDt1Vy9-ddWBg798kGGc Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Apr 2014 05:51:01 -0000 On Sunday, April 13, 2014 1:31 AM, Franck Martin wrote: >> my email actually fails 98%. but who cares about me, i'm no facebook sending >> to yahoo, right? or yahoo sending to google... or some other big sending to >> some other big... or whatever. > Don't publish a DMARC policy which is detrimental to you... it's "p=none". how is that detrimental to me? i don't plan changing it to "reject" anytime soon. dmarc still fails. and who will warrant me that some big esp doesn't get all self-righteous and simply ignores my dmarc policy, instead choosing to process my email according to its dmarc fail status? who says yahoo won't just decide my email is a spam, that my domain is publishing "none" as any good phisher would, and then simply process my email using dmarc filters, regardless of my dmarc policy? obviously a spec that isn't even a standard can't rly warrant me such a thing, similarly to how yahoo doesn't care about obvious shortcoming in the current spec, or even less, its recommendations. let's all force our beliefs on world like yahoo did, and hope tranquility will be the result. pretty childish thinking. > Also please correct your DMARC record, it is invalid: > https://dmarcian.com/dmarc-inspector/goodone.tk my dmarc record is perfectly valid, as per current spec. what's broken is dmarcian.com check algorithm, which i reported to them two months ago, and they acknowledged it. why they didn't fix it yet, isn't my problem, but my record is following current spec. i expected more from ppl on this list... u don't even know the spec, yet u argue about it. great work all. just wonderful. the only benefit from all dmarc crap for me is "fo=d:s" reporting policy. at least i get reports when spf and/or dkim fail. dmarc alignment will always fail for me. yet my infrastructure isn't at all rare, unique or uncommon, but actually pretty used practice. so, at least i can disable dmarc processing with "p=none" and that's my recommendation to all who believe in wide legitimacy of email natures. you never know if recipients use forwarding without SRS, or whether their infrastructure breaks DKIM, or even what type of SPF check they r doing, cause even current SPF spec is defining evaluation uncertainties. with "p=reject" policy your important email to some geeky admin on another side of the planet may simply get lost, just because u have no control on how ur email gets delivered or validated on their side. one forward here, one anti-spam added header there, and walla, u r phishing from ur own email account. congratulations. no phisher would do it better. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Mon Apr 14 00:42:36 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 8345B1A027A for ; Mon, 14 Apr 2014 00:42:33 -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 T8fX90KDAczc for ; Mon, 14 Apr 2014 00:42:28 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4279A1A0220 for ; Mon, 14 Apr 2014 00:42:28 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so7674971wgh.4 for ; Mon, 14 Apr 2014 00:42:25 -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=gc+DV5WQWEoOCTBQms0M8aOztT9p9GoFrRAVJ6y+mSc=; b=eUfxhJKAUQ5wDPFDMnVpo/HI11vttNxhwf5NlGrcr6Er8u2AgJClOOhPvj2OFb8Kd/ jtByuNxe9c/cmKFnxV2gmfb0GPdCnGl3ckrWiz6myYmOXvPN6i5OtVAV3oXqhkXB1oSQ 8orFbUwSHLz73BnfN9CT/0bC6OG+3Htw0vc6xnE4FZEF9yEIVAFJUwfXLcDDEYNcGs+q MEL5LsEc9XYwBn2DoviCSN4dwxaNxo9FSql6RX8lBvIpiP9eCR6X9170hWN+3VOCOTLj 631vAaxRE/xZ4Gge1b9ZDW/dYDJzX9PPUARhQ5pkHzN3GG7vU/02lPAFw1p8icoxiVtz HoDg== MIME-Version: 1.0 X-Received: by 10.194.110.100 with SMTP id hz4mr886462wjb.50.1397461345395; Mon, 14 Apr 2014 00:42:25 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Mon, 14 Apr 2014 00:42:25 -0700 (PDT) In-Reply-To: <20140412151013.GA29795@roeckx.be> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <20140412151013.GA29795@roeckx.be> Date: Mon, 14 Apr 2014 00:42:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: Kurt Roeckx Content-Type: multipart/alternative; boundary=047d7bf1987e14698404f6fbd3af Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/44JuXzhlTs7xEzHL-VgkxvFq0aM Cc: Dave Crocker , "dmarc@ietf.org" , Miles Fidelman Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:42:33 -0000 --047d7bf1987e14698404f6fbd3af Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx wrote: > > 2. The spec is clear about how it works and what the implications are. > The > > issue with mailing lists is well-documented. > > I don't agree with this. > If you have any specific suggestions for how it can be improved, now would be a good time to make them. -MSK --047d7bf1987e14698404f6fbd3af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx <kurt@roeckx.be= > wrote:
> 2. =A0The spec is clear about how it works and what th= e implications are. =A0The
> issue with mailing lists is well-documented.

I don't agree with this.

If you have = any specific suggestions for how it can be improved, now would be a good ti= me to make them.

-MSK
--047d7bf1987e14698404f6fbd3af-- From nobody Mon Apr 14 00:51: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 37C701A039B for ; Mon, 14 Apr 2014 00:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 PbKSBn3sio5g for ; Mon, 14 Apr 2014 00:51:51 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 30B3F1A0395 for ; Mon, 14 Apr 2014 00:51:51 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id t60so7588709wes.5 for ; Mon, 14 Apr 2014 00:51:48 -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=/gv5bspxDtzOLBURoHS5L/6J7Io0S9EkDBs5Jcqhr+I=; b=EsUEzdCfsJPaeJkZwN0+cakallYQ/TWxy3AG27jqyj3IVWxRon3vs8SVQuyzRuSQcA LCmYKJCy9R4z7XAsRCCaZPXKAK7B7MsJwFJwrqCycEf3aH5NpK/+Auhd/QNvX/ujGfdH DYrgtJo7RQCTbi7u58jLtc0i/nO5Qf4bQVHtt+m3IcckKjgTEEize1MC9ixSwtyki+dO q7S0c66vhMG0jKT3s3Qn6yWudIqF4pgtFYLyX1R4DJf3LD6cldMZZOz0mfi4oAEhQ4d+ L0sY3DOLZqR8Bm6UC/+2J6yIl+bGZ5YdxZ1sPjdRlRQ4eS87I+07aPZzpJVZ8seGftO2 F/YA== MIME-Version: 1.0 X-Received: by 10.180.211.116 with SMTP id nb20mr8438207wic.5.1397461908386; Mon, 14 Apr 2014 00:51:48 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Mon, 14 Apr 2014 00:51:48 -0700 (PDT) In-Reply-To: <53496866.8000807@meetinghouse.net> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> <53496866.8000807@meetinghouse.net> Date: Mon, 14 Apr 2014 00:51:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Miles Fidelman Content-Type: multipart/alternative; boundary=001a11c26ab4a2fa8004f6fbf40a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/yiSzcoF8Uj_w3TXxqOIeWRDlVGs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:51:53 -0000 --001a11c26ab4a2fa8004f6fbf40a Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 12, 2014 at 9:23 AM, Miles Fidelman wrote: > > Well, let's see: > - DMARC.org defines the "DMARC Base Specification" with a link to > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF > document > - they published an information Internet draft, that expires in October of > this year, that starts with "This memo presents a proposal for a scalable > mechanism by which a mail sending organization can express,....." > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ > - by implication, they are representing DMARC as a standards-track IETF > specification > > That's your inference, not their implication. None of "base specification", "informational Internet draft" or "proposal for a scalable mechanism" automatically mean "standard". In fact, the document is not on a path for the standards track. Publication of a "proposal" as an information Internet draft, is barely the > first step toward an operational specification standardized by the IETF - > yet DEMARC proponents are representing it as an IETF standard (or at least > as going through the process). > See above; this is incorrect. > So, it seems to me that it is entirely legitimate for IETF to officially > be on the record that: > 1. DMARC is NOT even close to an IETF standard > ...nor is it currently seeking that status. > 2. It has not been subject to any of the technical and operational vetting > associated with the progression of a specification through the IETF > standardization process > Correct, at least formally in IETF terms, which is why it is on track to be Informational. Informally, there has been open community dialog about it for quite some time now, not limited to this mailing list. > 3. The means by which Yahoo has deployed DMARC, and the choice of several > other large ISPs to honor the p=reject policy, is not in keeping with the > practice of measured testing and incremental deployment of IETF standards, > as they progress from proposal, to experimental, to optional, to > recommended, to mandatory > DMARC includes mechanisms to be incremental and do live testing and reporting as key components, and has since its inception since gradual rollout capabilities were established as a requirement early on. That one operator may have chosen to do something in a way people found disruptive is not, to me, a valid cause through which the specification should be invalidated. DNSBLs can be just as or even more disruptive (and have been), yet they are also described in Informational RFCs. There are likely many other examples. -MSK --001a11c26ab4a2fa8004f6fbf40a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 12, 2014 at 9:23 AM, Miles Fidelman <mfidelman@meetinghouse.net> wrote:

=
Well, let's see:
- DMARC.org defines the "DMARC Base Specification" with a link to= https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-bas= e/ - an IETF document
- they published an information Internet draft, that expires in October of = this year, that starts with "This memo presents a proposal for a scala= ble mechanism by which a mail sending organization can express,....." = https://datatracker.ietf.org/doc/draft-kucherawy-dma= rc-base/
- by implication, they are representing DMARC as a standards-track IETF spe= cification


That's your in= ference, not their implication.=A0 None of "base specification", = "informational Internet draft" or "proposal for a scalable m= echanism" automatically mean "standard".=A0 In fact, the doc= ument is not on a path for the standards track.

Publication of a "proposal" as an information Internet draft, is = barely the first step toward an operational specification standardized by t= he IETF - yet DEMARC proponents are representing it as an IETF standard (or= at least as going through the process).

See above; this is incorrect.
=A0=
So, it seems to me that it is entirely legitimate for IETF to officially be= on the record that:
1. DMARC is NOT even close to an IETF standard
<= br>
...nor is it currently seeking that status.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
2. It has not been subject to any of the technical and operational vetting = associated with the progression of a specification through the IETF standar= dization process

Correct, at leas= t formally in IETF terms, which is why it is on track to be Informational.= =A0 Informally, there has been open community dialog about it for quite som= e time now, not limited to this mailing list.
=A0
3. The means by which Yahoo has deployed DMARC, and the choice of several o= ther large ISPs to honor the p=3Dreject policy, is not in keeping with the = practice of measured testing and incremental deployment of IETF standards, = as they progress from proposal, to experimental, to optional, to recommende= d, to mandatory

DMARC includes mechanisms to be incr= emental and do live testing and reporting as key components, and has since = its inception since gradual rollout capabilities were established as a requ= irement early on.

That one operator may have chosen to do something in a way people found= disruptive is not, to me, a valid cause through which the specification sh= ould be invalidated.=A0 DNSBLs can be just as or even more disruptive (and = have been), yet they are also described in Informational RFCs.=A0 There are= likely many other examples.

-MSK
--001a11c26ab4a2fa8004f6fbf40a-- From nobody Mon Apr 14 00: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 ED5F51A038E for ; Mon, 14 Apr 2014 00:59:21 -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 OcEVV2U11ISE for ; Mon, 14 Apr 2014 00:59:18 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C77C01A0395 for ; Mon, 14 Apr 2014 00:59:17 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id w61so7857313wes.32 for ; Mon, 14 Apr 2014 00:59:15 -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=lBJtP5IyBxZh/MgLvS/NsAYVc+k+P5SBC+HzTJ394Vc=; b=hZGITIkTb+pqchp0bzj5lUgzmm+/SaYJLQ+nZQru2MBhKDP2N2TZHopbM+aoAdFgMW Bas+D9DNjo1ShRr3MSaZszMKFAzFoOnojrxrXBn1rnHlY3DVneaPrTMuKEQAqmL5mgFR O3VEVe6uFhDnVogK/SouFfIJtvXmDdDyUMe+tT+4XYzBVtNgwrCmnj7odK1w238AS5hp RbMUdwEWW1CcWFZJv8tYpuqKLIDKdwIGJIj2+t4r/O85BX2K7qNfErMfS82tNju+rL8I ll0HLAp2yvMq31G/kwuysTgoPEnSeH64sAnxPq2wmTJnhaMd47gGnDjOIx8+DR/f+xe6 0oyw== MIME-Version: 1.0 X-Received: by 10.180.84.129 with SMTP id z1mr8430217wiy.8.1397462354855; Mon, 14 Apr 2014 00:59:14 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Mon, 14 Apr 2014 00:59:14 -0700 (PDT) In-Reply-To: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Mon, 14 Apr 2014 00:59:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=f46d043bdec03fe2f804f6fc0f3e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/W52jrH4-gtacN_2fcXmhHHgHPqs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 07:59:22 -0000 --f46d043bdec03fe2f804f6fc0f3e Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 12, 2014 at 2:54 PM, Vlatko Salaj wrote: > come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well > but > in very narrow field. > Do you have any specific suggestions? -MSK --f46d043bdec03fe2f804f6fc0f3e Content-Type: text/html; charset=ISO-8859-1
On Sat, Apr 12, 2014 at 2:54 PM, Vlatko Salaj <vlatko.salaj@goodone.tk> wrote:
come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well but
in very narrow field.

Do you have any specific suggestions?

-MSK
--f46d043bdec03fe2f804f6fc0f3e-- From nobody Mon Apr 14 10:10: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 246991A0656 for ; Mon, 14 Apr 2014 10:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 4B1ZNpl4e0bx for ; Mon, 14 Apr 2014 10:10:41 -0700 (PDT) Received: from nm15-vm6.bullet.mail.gq1.yahoo.com (nm15-vm6.bullet.mail.gq1.yahoo.com [98.137.176.78]) by ietfa.amsl.com (Postfix) with ESMTP id 50A5D1A04C1 for ; Mon, 14 Apr 2014 10:10:41 -0700 (PDT) Received: from [98.137.12.189] by nm15.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2014 17:10:38 -0000 Received: from [216.39.60.213] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 14 Apr 2014 17:10:38 -0000 Received: from [127.0.0.1] by omp1100.mail.gq1.yahoo.com with NNFMP; 14 Apr 2014 17:10:38 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 920906.80543.bm@omp1100.mail.gq1.yahoo.com Received: (qmail 28156 invoked by uid 60001); 14 Apr 2014 17:10:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397495438; bh=AuQfxKEF3zyS27VYEPO8bNpeOV6nvyxN3cpA7mO9Ntw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hRbjDwvU/5qDYJsa0OAT8R83ZHvXXXsndQDMm9QXU2/pqxLcHlTkTRDSFO0cUQ/Lo+H/T0nEEZhGHaB95ouKKZnZ+f6di9C+S9eWHNyHnMMlWrkLoH2a3uwE17MVFMmx9GiTxnZEdc9IayoYSPSYxJW1K9VEYcWeQSBokoJBs1A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=VMvNqYY3vvg40gyB/EJxrrxvHWqZ/OgTF58UGXnNpwCJjQKQgfvtQYIAa3wTD8NnwlUpprG6ffupxUhdvPd7Orq91druU1BIjiIYtye1eTefi3ILHLZQmt0r7kuOaXXAOnId8eECRe5cWEDrazzqfafLzi/xqzTz9eUqg6TjIs0=; X-YMail-OSG: OPT9LvkVM1kM0pM7ybP24pfn.YJ2zvvtacNVSgSg5EhHmKk dXB73ndBE3ZAG_zQRMyVrw1sONfrA5KyjoImRlXRTTd9V1Yz66Dr9Fmd6Bxx 8sAje1OoH9gDBkq.QZeof8MxLpUDZHIOoUxXtNJGUe1u2mQpFYueD9gq.I5D iyV8elRmwIdsg6D8IuWKzTBZ0ab_aTxXCvj_.DewpE1rhx_yW5XSghIRHr7I icVlB65K.0UaiOxkyXyP66IMMsbzoAXmWP0jm3UnyvuidAKli73hMU4QX8Gw krJH5jpGLizCf19BTVx7kWvTB2L8N8HJJ59zEAHsn3vEB7COZYUQOPtE27fA WrulEg6B4FzDWWaWQDe1RVHdCA6fKr7mVU4IAeC6ESzxc.j7GVes4sBSgMyw Gj.EJ2otOmKtQkYmQI3kxKmZTafL_ECDJ8AvCJ9JSqjVfv.NAcdkIvd2rVkq bzDVtL.MykpnDCdw_PF_SfCOZn.UfLVa7_GY2pTt44TdAPUz7wZWyfxTx8Kw dSA0nu7TIqM4Fr9LQ2Fs4AzrLS02fEVdfE46D0tsB2HTAqu_jUaoaFs26luj tp6q0e3tOOGpOw.luAQ.0ChHoaxP4_G9K5KfMkWh43mO_eg-- Received: from [79.175.99.53] by web164605.mail.gq1.yahoo.com via HTTP; Mon, 14 Apr 2014 10:10:38 PDT X-Rocket-MIMEInfo: 002.001, T24gTW9uZGF5LCBBcHJpbCAxNCwgMjAxNCA5OjU5IEFNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IHdyb3RlOgoKPj4gY29tZSBvbiwgcHBsLCBkbWFyYyBuZWVkcyB0byBiZSBmaXhlZC4gaXQncyBicm9rZW4sIGl0IGRvZXNuJ3Qgd29yayB3ZWxsIGJ1dAo.PiBpbiB2ZXJ5IG5hcnJvdyBmaWVsZC4KPiBEbyB5b3UgaGF2ZSBhbnkgc3BlY2lmaWMgc3VnZ2VzdGlvbnMgCgphcyBhIG1hdHRlciBvZiBmYWN0LCB5ZXMsIGkgZG8uCgppIGFscmVhZHkgbWVudGlvbmVkIGluY2x1ZGluZyBTUlMgaW4gY2hlY2sgbG9naWMBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> Message-ID: <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Mon, 14 Apr 2014 10:10:38 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oIkne3fIoXM0gt4EcAsmK8yTPEo Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:10:45 -0000 On Monday, April 14, 2014 9:59 AM, Murray S. Kucherawy wrote: >> come on, ppl, dmarc needs to be fixed. it's broken, it doesn't work well but >> in very narrow field. > Do you have any specific suggestions as a matter of fact, yes, i do. i already mentioned including SRS in check logic. unfortunately, no dmarc author rly added much to the topic, and i work alone only on my own projects, not on collaborative things as these. also, my 2nd suggestion, independent from 1st, if we mark SRS as 1st, would be: a. dmarc alignment is a big issue. read: huge issue. b. since alignment is an issue, make it policy optional. c. by "make it policy optional" i mean: include an option in dmarc dns policy, so that domain owners could turn dmarc alignment check on/off. this could be useful for: domains using high volume ML participation, domains that use 3rd party services for their email infrastructure, domains that use forwarders, bunch of other special cases u can find on internet today and in future. my 3rd suggestion, which would go nicely together with 2nd, is: 1. current dmarc spec uses OR logic while processing SPF and DKIM; why? 2. make this policy processing logic selectable. 3. by "make it selectable" i mean: include an option in dmarc dns policy, so that domain owners could turn dmarc processing logic either to OR or AND. my 2nd and 3rd suggestion, in combo, would deal much better with stuff that, originally, dmarc spec had OR processing logic meant for, and while doing that, it would also add so much needed wideness to dmarc rigidity. and i could even pass dmarc finally. imagine that. while still getting some benefit from dmarc processing. is there a weakness in this proposal. probably. is it huge. i don't think so. u disagree? elaborate, plz. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Mon Apr 14 10:44: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 F0E0D1A0564 for ; Mon, 14 Apr 2014 10:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 IdsSuA1Xoa-m for ; Mon, 14 Apr 2014 10:44:03 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id DDEB11A01FB for ; Mon, 14 Apr 2014 10:44:02 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id E74261C2230; Mon, 14 Apr 2014 19:43:58 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id CD5111FE015A; Mon, 14 Apr 2014 19:43:58 +0200 (CEST) Date: Mon, 14 Apr 2014 19:43:58 +0200 From: Kurt Roeckx To: "Murray S. Kucherawy" Message-ID: <20140414174358.GA23168@roeckx.be> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <20140412151013.GA29795@roeckx.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3omwgrzNNF3wxCLIvDjnz-HNqIA Cc: Dave Crocker , "dmarc@ietf.org" , Miles Fidelman Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:44:05 -0000 On Mon, Apr 14, 2014 at 12:42:25AM -0700, Murray S. Kucherawy wrote: > On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx wrote: > > > > 2. The spec is clear about how it works and what the implications are. > > The > > > issue with mailing lists is well-documented. > > > > I don't agree with this. > > > > If you have any specific suggestions for how it can be improved, now would > be a good time to make them. I thought I made my comments about this in the past, but I can't actually find them. Some of them are: - It does not describe how it (ab)uses existing technology and breaks existing things. It's not clear what the effects of the alignment is. - It does not say anything about how participating mailinglists should behave - It's not clear in how reports should look like for messages that don't pass. It would help that there were examples in it. What would also help is: - Implementations that actually follow the spec. So far I have received 0 report mails that follow the specification. Kurt From nobody Mon Apr 14 10:53:11 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 8105A1A0564 for ; Mon, 14 Apr 2014 10:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.803 X-Spam-Level: X-Spam-Status: No, score=-2.803 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7, 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 2s0Px_4sbqIa for ; Mon, 14 Apr 2014 10:52:59 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with ESMTP id 8F53E1A0208 for ; Mon, 14 Apr 2014 10:52:56 -0700 (PDT) Received: (Haraka outbound); Mon, 14 Apr 2014 13:52:52 -0400 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=imac27.simerson.net; envelope-from= Received-SPF: None (mail.theartfarm.com: domain of imac27.simerson.net does not designate 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=helo; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Authentication-Results: mail.theartfarm.com; iprev=pass; auth=pass (plain); spf=pass smtp.mailfrom=tnpi.net Received: from imac27.simerson.net (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.4.0) with ESMTPSA id 7C6318A2-C67F-4B0C-A2E8-EEEB58F04B61.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Mon, 14 Apr 2014 13:52:50 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Matt Simerson In-Reply-To: <20140414174358.GA23168@roeckx.be> Date: Mon, 14 Apr 2014 10:52:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <20140412151013.GA29795@roeckx.be> <20140414174358.GA23168@roeckx.be> To: Kurt Roeckx , "dmarc@ietf.org" X-Mailer: Apple Mail (2.1874) X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-ROUTEVIEWS: asn=7922 net=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-GeoIP: US, WA, Seattle, 2705km X-Haraka-GeoIP-Received: 50.159.99.59:US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Haraka-p0f: os="iOS iPhone or iPad" link_type="Ethernet or modem" distance=14 total_conn=3 shared_ip=N X-Spam-ASN: X-Spam-DCC: : messagesniffer 1102; 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-4240-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-4240-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 50.159.99.59, Ugly c=0.214287 p=-0.25 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-4240-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 5, history: 27, total_connects: 27, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors(-109), dnsbl.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=EpKDkkz2KRBhWjDWxZR2va8mpySsc47Flmf9Fx0GZ6M=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=IaMApXfqrTfGGkmUjPLgQMRElB91zH3j4m7ACY2R+nst3+QRn8N21S24YPX6dEvhxXxMIaOY6G95hRawmqJl6NynpwzxTTWn86TSEx6TvJCE6MW27Pry/52gxS+9t5s+H8Oa2c+VJ8Es9WFr7HmvO6Yu/4O1imCTGkeEtvHRsXsP7ZBhr2mHtQrT3xOKhXLlOyNEO/WXIC8ieqvU7+VbzXrN8IgPGeCz2+yq1dofZnjyO1LeB920N+wi9TiJ//5f6ePVDHEUxi8tnaWjyaD5XY5XMWNRYBZc4AtmRGhkb7pcC1R9H5P9WGNEejaF9DsaTkBSXGMk5Klu7mp0gRD3+Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Qc0jMXlI1hQYkMFkKpZsEuTkPIA Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 17:53:04 -0000 On Apr 14, 2014, at 10:43 AM, Kurt Roeckx wrote: > What would also help is: > - Implementations that actually follow the spec. So far I have > received 0 report mails that follow the specification. http://search.cpan.org/dist/Mail-DMARC/ and the report format definition: = http://search.cpan.org/dist/Mail-DMARC/lib/Mail/DMARC/Report/Aggregate.pm If you received a report from me (or another site that uses = Mail::DMARC), you'd get a report that follows the 2013 draft. To the = letter. I haven't read the latest draft in enough detail to assure that = is still the case. While writing Mail::DMARC, I noticed a number of anomalies in the = reports I was receiving. Upon reporting on those issues to the = dmarc-users mailing list, all of them (except a hotmail issue) got a = "oops, we'll fix that," response. I haven't gone back to see if I can = remove the "tolerate this malformation in a report" shims, but my = assumption is that I can remove most of them. Matt= From nobody Mon Apr 14 11:13: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 284651A0203 for ; Mon, 14 Apr 2014 11:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 btweEwn7kCe7 for ; Mon, 14 Apr 2014 11:13:00 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3EA1A0262 for ; Mon, 14 Apr 2014 11:13:00 -0700 (PDT) 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.0.929.7; Mon, 14 Apr 2014 16:38:05 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.185]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.185]) with mapi id 15.00.0929.001; Mon, 14 Apr 2014 16:38:05 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] DMARC's purpose Thread-Index: AQHPVL9Q/ZKZjgpL2U+wjHPFvRYzC5sK/tmAgAKtoQCAAD/DgIAAKEYAgAAEmYCAAqeMgIAAlJdw Date: Mon, 14 Apr 2014 16:38:04 +0000 Message-ID: <24ec8410af2d40dca1fb919950a1f0be@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <20140412151013.GA29795@roeckx.be> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.69] x-exchange-organization-antispam-internal: BULK:None; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:(2001) x-forefront-prvs: 0181F4652A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(24454002)(199002)(189002)(377454003)(83322001)(19580405001)(85852003)(16236675003)(74876001)(19300405004)(74706001)(92566001)(19580395003)(83072002)(93136001)(85306002)(76796001)(81542001)(76786001)(77096001)(81816001)(87266001)(2656002)(81342001)(47976003)(90146001)(94946001)(56776002)(80022001)(59766002)(46102001)(66066001)(74662001)(56816006)(74502001)(31966008)(53806002)(50986002)(95666003)(20776003)(87936001)(80976001)(95416001)(54356002)(77982001)(69226001)(47736002)(97186001)(15975445006)(54316003)(97336001)(93886001)(81686001)(99396002)(93516002)(33646001)(76482001)(19609705001)(49866002)(79102001)(65816002)(15202345003)(98676001)(51856002)(74366001)(47446003)(4396001)(63696004)(94316002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:FBA5F8ED.AFB58CC1.3EDDB9F8.901D8AE8.20299; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_24ec8410af2d40dca1fb919950a1f0beBL2SR01MB605namsdf01sdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8D_A2fquxJIMHEwBqYVYB1u8HKw Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 18:13:05 -0000 --_000_24ec8410af2d40dca1fb919950a1f0beBL2SR01MB605namsdf01sdf_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Murray's response is the key point. Large email providers like DMARC becaus= e it helps cut down on phishing (which results in fewer compromised account= s), user complaints (which reduces support calls) and is fairly straightfor= ward to implement (which makes the codebase more maintainable). They realiz= e, however, that there are some scenarios that DMARC breaks. However, unles= s that pain is greater than the magnitude of pain that it solves, they are = unlikely to reverse their DMARC implementations. However, I'm sure they'd be amenable to updating it to fix the scenarios th= at is does break. So, what are the options? There are hundreds of years of = email experience on this list, I'm sure we can come up with something. -- Terry From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Murray S. Kucheraw= y Sent: Monday, April 14, 2014 12:42 AM To: Kurt Roeckx Cc: Dave Crocker; dmarc@ietf.org; Miles Fidelman Subject: Re: [dmarc-ietf] DMARC's purpose On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx > wrote: > 2. The spec is clear about how it works and what the implications are. = The > issue with mailing lists is well-documented. I don't agree with this. If you have any specific suggestions for how it can be improved, now would = be a good time to make them. -MSK --_000_24ec8410af2d40dca1fb919950a1f0beBL2SR01MB605namsdf01sdf_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Murray’s response is the key point. Large email providers like DMARC= because it helps cut down on phishing (which results in fewer compromised accounts), user complaints (which reduces support calls) and is fairly str= aightforward to implement (which makes the codebase more maintainable). The= y realize, however, that there are some scenarios that DMARC breaks. Howeve= r, unless that pain is greater than the magnitude of pain that it solves, they are unlikely to reverse their D= MARC implementations.

 

However, I’m sure the= y’d be amenable to updating it to fix the scenarios that is does brea= k. So, what are the options? There are hundreds of years of email experienc= e on this list, I’m sure we can come up with something.

-- Terry<= /p>

 

From: dmarc = [mailto:dmarc-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Monday, April 14, 2014 12:42 AM
To: Kurt Roeckx
Cc: Dave Crocker; dmarc@ietf.org; Miles Fidelman
Subject: Re: [dmarc-ietf] DMARC's purpose

 

On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx <kurt@roeckx.be> wro= te:

> 2.  The spe= c is clear about how it works and what the implications are.  The
> issue with mailing lists is well-documented.

I don't agree with this.

 

If you have any specific suggestions for how it can = be improved, now would be a good time to make them.

-MSK

--_000_24ec8410af2d40dca1fb919950a1f0beBL2SR01MB605namsdf01sdf_-- From nobody Mon Apr 14 11:17: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 62A9E1A0203 for ; Mon, 14 Apr 2014 11:17:03 -0700 (PDT) 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 kHREsi1ujjmO for ; Mon, 14 Apr 2014 11:16:59 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id A92EF1A0673 for ; Mon, 14 Apr 2014 11:16:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id CE0A7CC0B3 for ; Mon, 14 Apr 2014 14:16:56 -0400 (EDT) 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 kxXGyS-uH98M for ; Mon, 14 Apr 2014 14:16:52 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 4FD75CC0BF for ; Mon, 14 Apr 2014 14:16:52 -0400 (EDT) Message-ID: <534C2614.6090400@meetinghouse.net> Date: Mon, 14 Apr 2014 14:16:52 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <20140412151013.GA29795@roeckx.be> <20140414174358.GA23168@roeckx.be> In-Reply-To: <20140414174358.GA23168@roeckx.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zc2084YOUuFKGvKghpGgF963GlE Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 18:17:03 -0000 Kurt Roeckx wrote: > On Mon, Apr 14, 2014 at 12:42:25AM -0700, Murray S. Kucherawy wrote: >> On Sat, Apr 12, 2014 at 8:10 AM, Kurt Roeckx wrote: >> >>>> 2. The spec is clear about how it works and what the implications are. >>> The >>>> issue with mailing lists is well-documented. >>> I don't agree with this. >>> >> If you have any specific suggestions for how it can be improved, now would >> be a good time to make them. > I thought I made my comments about this in the past, but I can't > actually find them. Some of them are: > - It does not describe how it (ab)uses existing technology and > breaks existing things. It's not clear what the effects of the > alignment is. > - It does not say anything about how participating mailinglists > should behave > - It's not clear in how reports should look like for messages that > don't pass. It would help that there were examples in it. > > What would also help is: > - Implementations that actually follow the spec. So far I have > received 0 report mails that follow the specification. > And a definitive statement as to whether or not Yahoo's implementation recognizes Original-Authentication-Results - which would represent a low-impact way to interoperate with DMARC. Kind of trying to decide whether to invest time and energy in patching our Sympa installation to generate OAR headers - but so far, the only folks who claim to support it are Google - and I've received multiple anecdotal statements that "nobody has implemented it." The dmarc.org faq recommends: "Add an Original Authentication Results (OAR) header to indicate that the list operator has performed authentication checks on the submitted message and share the results. " but a few days ago this was added: "*This is not a short term solution.* Assumes a mechanism to establish trust between the list operator and the receiver. No such mechanism is known to be in use for this purpose at this time. Without such a mechanism, bad actors could simply add faked OAR headers to their messages to circumvent such measures. OAR was only described as a draft document, which expired in 2012. No receivers implementing DMARC are currently known to make use of OAR from external sources. " -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Wed Apr 16 09:39: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 458361A024F for ; Wed, 16 Apr 2014 09:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 lG5C3IKhWBGc for ; Wed, 16 Apr 2014 09:39:47 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AC0171A0243 for ; Wed, 16 Apr 2014 09:39:47 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jy13so11017911veb.16 for ; Wed, 16 Apr 2014 09:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OAx63DhGPDJjMM2IBMK5AtcbSkE3QtsvTNjH07KqOaw=; b=e34w5ddwr+g1AkqmULoI49lcLOb9Muy77KdkBOCV6mlwNyYtd45RADuF7R0J5cl6WN qJ15LV8Kj+ZTQzQA3m4Ek1URYveukbqU9UIuZraG9VgkYPAAMxGJ7Z2G2GFH1CzDNkTi Pv4Op+aCBYNfgZgvD++oatoPsFwUY1uPqqgVteibqTJFqc6bwEw8g1PlCgdmMSqncHAu i+1asFAYMYf6WSN/atL02r6NpOey0/kivlMXIn0GB8FlFzrnrWS6Uhwd6krxtEGBjN1p iIp/vCmSdHegu2IO622dlrDZPw5TJqlT2QYyZpsrF71r2T5Cn4MIXOTvuWhIsEnJFqxZ jnsg== MIME-Version: 1.0 X-Received: by 10.58.211.69 with SMTP id na5mr1510930vec.30.1397666384241; Wed, 16 Apr 2014 09:39:44 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Wed, 16 Apr 2014 09:39:44 -0700 (PDT) In-Reply-To: <53496866.8000807@meetinghouse.net> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> <53496866.8000807@meetinghouse.net> Date: Wed, 16 Apr 2014 12:39:44 -0400 X-Google-Sender-Auth: LYCy70Dk21_DzRQr-U4ppkcIES8 Message-ID: From: Barry Leiba To: Miles Fidelman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MzukfVGKZ2REkPZS2l3OF3QYYbQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:39:52 -0000 Just clearing up one point here: > Well, let's see: ... > - DMARC.org defines the "DMARC Base Specification" with a link to > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF > document It is not "an IETF document". One of those would have a name that starts with "draft-ietf-", followed by the name of the working group it's part of. And even then, it's just a "work in progress." IETF documents have RFC numbers. IETF work in progress has "draft-ietf-". draft-kucherawy-dmarc-base is an individually posted Internet draft. Anyone can post one of those (go ahead: try it). They aren't IETF documents. That distinction is important. Barry From nobody Wed Apr 16 09:45: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 20AB51A0243 for ; Wed, 16 Apr 2014 09:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, 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 038YlTojE4vu for ; Wed, 16 Apr 2014 09:45:27 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id B4D621A01F2 for ; Wed, 16 Apr 2014 09:45:27 -0700 (PDT) Received: from splunge.local (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s3GGjNri020241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 16 Apr 2014 09:45:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1397666724; bh=rlhO3WxGxheSvZtXcXkfPDZ5Wkw4BbbKgovoH1WzZrU=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GCU1+VoJNXS4TpEcAmpnXCIvMeINrFmsIctRpPQbLdeZYjqvhlGjhPXLtgSP5k36Y 4M3sYxnS01sJek8PKRVFZqT80eTw9mS83oqOGYt6eaeRs75eAA6D9bNzcUTAOwqK6M Cfxd+zZLglWHybIn69sRnYOoqshRUrDVmObZo6CM= Message-ID: <534EB3A3.2030407@bluepopcorn.net> Date: Wed, 16 Apr 2014 09:45:23 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> <53496866.8000807@meetinghouse.net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QCIXHwXKGJLxZJidwFbn_RxvqpU Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:45:32 -0000 On 4/16/14 9:39 AM, Barry Leiba wrote: > Just clearing up one point here: > >> Well, let's see: > ... >> - DMARC.org defines the "DMARC Base Specification" with a link to >> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF >> document > It is not "an IETF document". One of those would have a name that > starts with "draft-ietf-", followed by the name of the working group > it's part of. And even then, it's just a "work in progress." IETF > documents have RFC numbers. IETF work in progress has "draft-ietf-". > > draft-kucherawy-dmarc-base is an individually posted Internet draft. > Anyone can post one of those (go ahead: try it). They aren't IETF > documents. That distinction is important. Yes, but the boilerplate doesn't help. From the second paragraph of "Status of this Memo": Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. So it's an IETF document in addition to possibly being someone else's. -Jim From nobody Wed Apr 16 09:53: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 A0ECF1A0271 for ; Wed, 16 Apr 2014 09:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 EeyWPrJKA_j0 for ; Wed, 16 Apr 2014 09:53:19 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C56701A025A for ; Wed, 16 Apr 2014 09:53:18 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id lg15so10871702vcb.2 for ; Wed, 16 Apr 2014 09:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iqET9D+Wt3DEfgInoiFxdZdgydk34fA42HJoTORSw5Y=; b=dneDtpedhmqYNLETdsq+cHTT2pC+qm3klfjfbYgee18WxrwJ3oLMkqNCNZKShLlV9i Tthrc0st5r7TLx6iHrQ4s0r3uAb05BPKq0RmsFzik9SgO4eiGyAq8UhgXLqk+lKsl8R7 zigsm77sYhk24vUFGycwad6WHSnrmXJ1hHwXsRfu4Iq3zdDjDz9IJJcz9hVx5Cz5QNZK ApPbeJAMJ4K/NiePCJtmEX/tY8rtXO2XYiQmrNYIkdeJR+gkF+BPb+89GRf8vDjBRlF3 bhc65mcklKXzyD5X0Iga5l73ThjhPFrVKuULeyeMV23Ii8roSdqsNxj9t3+1WkQGC2cG vKDg== MIME-Version: 1.0 X-Received: by 10.52.12.36 with SMTP id v4mr2460133vdb.20.1397667195415; Wed, 16 Apr 2014 09:53:15 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Wed, 16 Apr 2014 09:53:15 -0700 (PDT) In-Reply-To: <5349537A.8000604@gmail.com> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> Date: Wed, 16 Apr 2014 12:53:15 -0400 X-Google-Sender-Auth: 20AMeCLgabmrjcclA0-hfeLgnmQ Message-ID: From: Barry Leiba To: Dave Crocker , Murray Kucherawy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kVFN-lG8N1traXdm8rFFnVVQgMk Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 16:53:19 -0000 > 2. The spec is clear about how it works and what the implications are. The > issue with mailing lists is well-documented. aI'm not sure that any issue with mailing lists is documented in draft-kucherawy-dmarc-base at all, well or otherwise. A search for "mailing list" (or even "mailing") shows hits in three places, all in back matter, none of substance. There's nothing that I can see anywhere that warns of possible consequences (neither considerations for the domain publishing the policy nor discussion of collateral damage to mailing lists) of using "p=reject" -- not in the explanation of "p=reject", not in Section 6 ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting Messages"), not in the Security Considerations. Where is is well documented? Barry From nobody Wed Apr 16 10:05: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 4472F1A0243 for ; Wed, 16 Apr 2014 10:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 HW51el8hE85w for ; Wed, 16 Apr 2014 10:04:55 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 93B331A01DF for ; Wed, 16 Apr 2014 10:04:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5A1FF29C3FD; Wed, 16 Apr 2014 12:04:52 -0500 (CDT) 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 dS0ibDNHGUFp; Wed, 16 Apr 2014 12:04:52 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3710C29C408; Wed, 16 Apr 2014 12:04:52 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 2134D29C407; Wed, 16 Apr 2014 12:04:52 -0500 (CDT) 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 OZxVG-Ke4G8e; Wed, 16 Apr 2014 12:04:52 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 007B629C3FD; Wed, 16 Apr 2014 12:04:51 -0500 (CDT) Date: Wed, 16 Apr 2014 12:04:50 -0500 (CDT) From: Franck Martin To: Barry Leiba Message-ID: <610289312.88482.1397667890896.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.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 - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC's purpose Thread-Index: 1+YVUWxFgH9p2ckpzSKBxegWH0eaVg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gYhS0vv_Dh46EMCUsgthA9r63K0 Cc: Dave Crocker , dmarc@ietf.org, Murray Kucherawy Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:04:59 -0000 ----- Original Message ----- > From: "Barry Leiba" > To: "Dave Crocker" , "Murray Kucherawy" > Cc: dmarc@ietf.org > Sent: Wednesday, April 16, 2014 9:53:15 AM > Subject: Re: [dmarc-ietf] DMARC's purpose > > > 2. The spec is clear about how it works and what the implications are. > > The > > issue with mailing lists is well-documented. > > aI'm not sure that any issue with mailing lists is documented in > draft-kucherawy-dmarc-base at all, well or otherwise. A search for > "mailing list" (or even "mailing") shows hits in three places, all in > back matter, none of substance. > > There's nothing that I can see anywhere that warns of possible > consequences (neither considerations for the domain publishing the > policy nor discussion of collateral damage to mailing lists) of using > "p=reject" -- not in the explanation of "p=reject", not in Section 6 > ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting > Messages"), not in the Security Considerations. > > Where is is well documented? > In the upcoming BCP Should we also document in this Murray's draft that MS-Exchange breaks DKIM on forwarding, inventory all the operational cases? I don't think so. The draft is to describe the protocol, the BCP is here to document on how to operationally deploy and use it. The reviews if I recall suggested to limit the draft to the protocol bits strictly. From nobody Wed Apr 16 10:06: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 6553C1A0250 for ; Wed, 16 Apr 2014 10:06:38 -0700 (PDT) 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 rOVh02uG70zu for ; Wed, 16 Apr 2014 10:06:34 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9E69D1A0243 for ; Wed, 16 Apr 2014 10:06:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id E430FCC092 for ; Wed, 16 Apr 2014 13:06:30 -0400 (EDT) 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 LjLOZrl03PZ7 for ; Wed, 16 Apr 2014 13:06:26 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 75838CC08C for ; Wed, 16 Apr 2014 13:06:04 -0400 (EDT) Message-ID: <534EB87C.6030001@meetinghouse.net> Date: Wed, 16 Apr 2014 13:06:04 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> <53496866.8000807@meetinghouse.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/aNxZtTLs7bwlE8qt9wlVwZuC5LQ Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:06:38 -0000 Barry Leiba wrote: > Just clearing up one point here: > >> Well, let's see: > ... >> - DMARC.org defines the "DMARC Base Specification" with a link to >> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ - an IETF >> document > It is not "an IETF document". One of those would have a name that > starts with "draft-ietf-", followed by the name of the working group > it's part of. And even then, it's just a "work in progress." IETF > documents have RFC numbers. IETF work in progress has "draft-ietf-". > > draft-kucherawy-dmarc-base is an individually posted Internet draft. > Anyone can post one of those (go ahead: try it). They aren't IETF > documents. That distinction is important. > > In the "fine print" - but most folks don't read the fine print - which makes it really easy for folks to take liberties in marketing and management presentations. It's URL includes "ietf.org," it lives on an IETF server, it's header includes "Network Working Group." If it looks like an IETF document, and quacks like an IETF document - that's enough for an awful lot of people to claim that it IS an IETF document, and for an awful lot of folks to believe it. From the point of view of most of the world - at the level that sees IETF as "the Internet's standards body" - that distinction is so invisible as to be meaningless. From a legal point of view, it could be meaningless as well - in the same way that clauses buried in shrink wrapped licenses might or might not stand up in court. Example: "no liability for anything" clauses don't cancel out an implied warrant of merchantability. Even as a non-lawyer, I know that one. And again, Kleenex and Xerox and Coke spend a lot of money defending their trademarks - apparently, they believe that putting Kleenex(tm) on their boxes is not sufficient to prevent others from referring to their products as "kleenex." Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Wed Apr 16 10:13: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 DA7571A0235 for ; Wed, 16 Apr 2014 10:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKzrsNPu_upu for ; Wed, 16 Apr 2014 10:12:55 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DDF8E1A0165 for ; Wed, 16 Apr 2014 10:12:54 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 200so10350314ykr.3 for ; Wed, 16 Apr 2014 10:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=G2pjbypctJp4dGCIQ/C9Skb6rhiZUxB/hs1f/oU1x88=; b=DOSXpOby4cfxFilglIWbH9pg+xpCTYxAyciUkC8na5en9l84Fr/If5ImUwN/QMIcBf 7GNreu/E2pY5U8k7SkKX7MBhX2YoLXHjAahcJ+CyesS2xo9yzdoQHaVkCvBTGTnytKjT GHoZ+2/CFXMh8YojSWW02JiQLYbvidLcTktRWsAEo1r2IGSEchVRoBYLCWhmEyLHS3Zm 5bfxm/4JJ1o5WwRmwbh0/mEurgc86JmajfkhKfPkhuwrrBrpp5gTG7uiUoU0hwQsbPHF vsrsGoghb1iqw8ohW95WvJHEZ4o5RpE4dYGEVZTfoZqORzZVKjwl5OWzt7jO7XF4xIZu hh3g== X-Received: by 10.236.11.113 with SMTP id 77mr14554034yhw.70.1397668371568; Wed, 16 Apr 2014 10:12:51 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id p68sm43433986yho.10.2014.04.16.10.12.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 10:12:50 -0700 (PDT) Message-ID: <534EB996.8070102@gmail.com> Date: Wed, 16 Apr 2014 10:10:46 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <6.2.5.6.2.20140412072359.0bae2c30@resistor.net> <53496866.8000807@meetinghouse.net> <534EB87C.6030001@meetinghouse.net> In-Reply-To: <534EB87C.6030001@meetinghouse.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zhweps7im0K4E386v-CbItMaDwk Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:13:00 -0000 >> It is not "an IETF document". One of those would have a name that >> starts with "draft-ietf-", followed by the name of the working group >> it's part of. And even then, it's just a "work in progress." IETF >> documents have RFC numbers. IETF work in progress has "draft-ietf-". >> >> draft-kucherawy-dmarc-base is an individually posted Internet draft. >> Anyone can post one of those (go ahead: try it). They aren't IETF >> documents. That distinction is important. >> >> > In the "fine print" - but most folks don't read the fine print - which > makes it really easy for folks to take liberties in marketing and > management presentations. Of course, this has been explained multiple times in multiple venues. There is no way to prevent the actions of people who have no concern for speaking carefully and accurately, or who choose to dismiss details they find inconvenient. Such folk fundamentally are engaging in the political effort of persuasion, rather than the intellectual effort of understanding. For group interaction, the differences between the two are fundamentally different in terms of style, goals and outcome. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 16 10:13: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 B60EB1A0165 for ; Wed, 16 Apr 2014 10:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 RqiGWDu2MSJr for ; Wed, 16 Apr 2014 10:12:59 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 46D8D1A01E9 for ; Wed, 16 Apr 2014 10:12:59 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id n15so8421312lbi.13 for ; Wed, 16 Apr 2014 10:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1A36wARM6SOxEKvaErpG4BkTNNMf97TLX9Fs19QPQfg=; b=fxhVmpN3nDZdjvq9B4w8NnYZsB2a3QIOoHmjijaKPXn2xnssp7O2dM0Gw/Si7zZ2LB xZSevG+7xkGnr2EZnbgV68f5D9wnak58fRm/EQu8VmCGgPUdbIsEGvlU5JJharm3DLG8 r+76JdHmgp/F1CQklby5C/emu8NWcv1QtESo4n8glUrPx8bItj4dtnIjBPcUhWQ9R058 Y++Mc4Hk5wILQP8zQNudhhnxrowb5vH/qAlqwOROkJLuRBzQf3Gt83EXEktLrBi5uSkF BAwnbC/3tF8O0DhApkDWmmx6OKJMy3eavD4XwwEZ7dmSY7yjzFwLVP5EiXlESU1a9qFA J9NA== MIME-Version: 1.0 X-Received: by 10.152.246.43 with SMTP id xt11mr6136845lac.34.1397668375236; Wed, 16 Apr 2014 10:12:55 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.148.97 with HTTP; Wed, 16 Apr 2014 10:12:55 -0700 (PDT) In-Reply-To: <610289312.88482.1397667890896.JavaMail.zimbra@peachymango.org> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <610289312.88482.1397667890896.JavaMail.zimbra@peachymango.org> Date: Wed, 16 Apr 2014 13:12:55 -0400 X-Google-Sender-Auth: z9eeNQcZV1DrsVWXbnUsMYgIIJg Message-ID: From: Barry Leiba To: Franck Martin Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AjriAemoT3njTQkGZlBz_JlISZM Cc: Dave Crocker , "dmarc@ietf.org" , Murray Kucherawy Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:13:00 -0000 >> I'm not sure that any issue with mailing lists is documented in >> draft-kucherawy-dmarc-base at all, well or otherwise. A search for >> "mailing list" (or even "mailing") shows hits in three places, all in >> back matter, none of substance. >> >> There's nothing that I can see anywhere that warns of possible >> consequences (neither considerations for the domain publishing the >> policy nor discussion of collateral damage to mailing lists) of using >> "p=reject" -- not in the explanation of "p=reject", not in Section 6 >> ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting >> Messages"), not in the Security Considerations. >> >> Where is [it] well documented? > > In the upcoming BCP 1. I don't see it adequately covered there, on a quick scan. I haven't read it thoroughly, though. 2. There is no reference from dmarc-base to dmarc-bcp, not even an informative one. And this is an important enough consideration that I think it should be a normative reference. > Should we also document in this Murray's draft that MS-Exchange > breaks DKIM on forwarding, inventory all the operational cases? I > don't think so. The draft is to describe the protocol, the BCP is here > to document on how to operationally deploy and use it. I can't parse the first sentence, nor figure out what you're trying to refer to. But to answer the question that's behind what I think you're asking: Yes, we should document, either in the specification or in an Applicability Statement that the specification cites as a normative reference, considerations that are critical to getting the configuration right. It's fine to separate the protocol bits and the "other information" into different documents, but it *all* has to be there in order to fight against misconfiguration and the damage that can cause. Barry From nobody Wed Apr 16 10:30: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 053EF1A028C for ; Wed, 16 Apr 2014 10:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 kFX0WdMYGKEL for ; Wed, 16 Apr 2014 10:30:28 -0700 (PDT) Received: from nm9-vm7.bullet.mail.gq1.yahoo.com (nm9-vm7.bullet.mail.gq1.yahoo.com [98.136.218.246]) by ietfa.amsl.com (Postfix) with ESMTP id B61481A024F for ; Wed, 16 Apr 2014 10:30:27 -0700 (PDT) Received: from [98.137.12.190] by nm9.bullet.mail.gq1.yahoo.com with NNFMP; 16 Apr 2014 17:30:24 -0000 Received: from [98.137.12.253] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 16 Apr 2014 17:30:24 -0000 Received: from [127.0.0.1] by omp1061.mail.gq1.yahoo.com with NNFMP; 16 Apr 2014 17:30:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 543864.31844.bm@omp1061.mail.gq1.yahoo.com Received: (qmail 99093 invoked by uid 60001); 16 Apr 2014 17:30:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397669424; bh=zABHYi6j+PSqoGmNmR8M1y9alB06HNq+mM6Lc2WuOf0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=UCoo1/CSwLgk/fGbd8D3piQgCBbg3F0Mziw8PvA0xoXh+Yly1qJ9nTkrine/Vms8lJwRjopR7tqWPj1PRMLZj1aPLrZGW8tOFeXKb0LIiMSSYLeThPKmxNJ/9W7TorZScUB+fKWnwi5UnQFFPE1TAfkucwuzSpBpj+LY3JVjcIM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=KfI+Va1dHOYd65Dicrsrgot2AxmAT9g6EmCMZpjwPIAO7p6CyhNziCWi9aMJxRyFK9T39qx3Sq/IaY6zg+kpaJIHf5hJ8VkHGWV8ex7QQFNGWP2wIhpikOg6+bOlo5fqyDhxQb/P7XgvDcKCTEJktIMuOysomISODF/POdu5AA8=; X-YMail-OSG: 6a15ElMVM1kSee9a4E7KHvAcfjXdUYip3sijL3KgQ7qccaI ByL5ipQV7pr8aiNrD_tVt0I3Twymivg2WiV9RiBqA1dI_oi8rOw_3Kiv846k dsPLZkQx5yUldL.gAj31hyK96W231HV9SvOY8Ln0kuSL_09hQUJ3MwxCepL2 eifaMUFHvVM6MzolaTOcb1FgCFNQhKVfyNtyjYNm.3bg3iUqyd2sbcqLTUKJ 8KZEVVsPpyYe5Fw2hsZWQK_nrotgIsOH1OGqgyPb2F2xXQa6iE0i9fEOl3PG HkiM_CK42Ct31sUJsexYQJD9Y.ArAX6vx36ZJw2WhDDuBr95o2FAVODb8Q5I P8Ht3D06NMc__BGSpuQAz4sb.1KLY1B4NlBkGu41Js9fIXMJTUldyq9XOL8m 6SoEfa3bvN2k9N41WPNs13DpWscR8BLUgvc3Zp5Ji97XOWy8dqhRQbV6VEDF gyb8ULoQjmCAVyCqPmkOh1mjvQSnFSTXQuxEosbg.9Cl198XP2oorh7SU17O UOWjr9kemscvAUnSX87rkUSNupSIWOBVZgmKefSJI48FxsJP6ZiGtO0jE98. 7ZHUoXClV9tDDrwNIDSjfTQ8JzOiMOGzgOiRfnsiGCg7l_96AYxLf3V3J1_f E7li6bOb0dxf93w-- Received: from [109.121.36.90] by web164602.mail.gq1.yahoo.com via HTTP; Wed, 16 Apr 2014 10:30:24 PDT X-Rocket-MIMEInfo: 002.001, aSBqdXN0IGxvdmUgaG93IG5vYm9keSBkZWNpZGVkIGNvbW1lbnRpbmcgb24gbXkgcHJvcG9zYWxzLCBidXQgZXZlcnlib2R5CmdvIGluIGRlZXAgbGVuZ3RocyBhYm91dCB3aGF0LCBob3cgYW5kIHdoeSBpZXRmIGlzLgoKCgotLSAKClZsYXRrbyBTYWxhaiBha2EgZ29vZG9uZQpodHRwOi8vZ29vZG9uZS50awEwAQEBAQ-- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 Message-ID: <1397669424.61612.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Wed, 16 Apr 2014 10:30:24 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/SNQHQLt7aGatEkwv2Sl2nYo7qtY Subject: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:30:32 -0000 i just love how nobody decided commenting on my proposals, but everybody go in deep lengths about what, how and why ietf is. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Wed Apr 16 10:44: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 B717A1A0282 for ; Wed, 16 Apr 2014 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001] 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 HjQeBK0lP66o for ; Wed, 16 Apr 2014 10:44:51 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id AA4D41A01FD for ; Wed, 16 Apr 2014 10:44:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 578A329C3B8; Wed, 16 Apr 2014 12:44:48 -0500 (CDT) 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 QERYgZ2SsbhI; Wed, 16 Apr 2014 12:44:48 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 34BF429C42A; Wed, 16 Apr 2014 12:44:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 244A229C429; Wed, 16 Apr 2014 12:44:48 -0500 (CDT) 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 ymNjsaiPpdV5; Wed, 16 Apr 2014 12:44:48 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id E1F9E29C3B8; Wed, 16 Apr 2014 12:44:47 -0500 (CDT) Date: Wed, 16 Apr 2014 12:44:47 -0500 (CDT) From: Franck Martin To: Barry Leiba Message-ID: <897774698.90304.1397670287435.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <534699BA.9010602@melix.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <610289312.88482.1397667890896.JavaMail.zimbra@peachymango.org> 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 - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC's purpose Thread-Index: k0RKPnDdHGYGQtmVUxAlTcciQuVNSw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4OyK-xhw-smBZXwgLoo7S6XrdXo Cc: Dave Crocker , dmarc@ietf.org, Murray Kucherawy Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:44:55 -0000 ----- Original Message ----- > From: "Barry Leiba" > To: "Franck Martin" > Cc: "Dave Crocker" , dmarc@ietf.org, "Murray Kucherawy" > Sent: Wednesday, April 16, 2014 10:12:55 AM > Subject: Re: [dmarc-ietf] DMARC's purpose > > >> I'm not sure that any issue with mailing lists is documented in > >> draft-kucherawy-dmarc-base at all, well or otherwise. A search for > >> "mailing list" (or even "mailing") shows hits in three places, all in > >> back matter, none of substance. > >> > >> There's nothing that I can see anywhere that warns of possible > >> consequences (neither considerations for the domain publishing the > >> policy nor discussion of collateral damage to mailing lists) of using > >> "p=reject" -- not in the explanation of "p=reject", not in Section 6 > >> ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting > >> Messages"), not in the Security Considerations. > >> > >> Where is [it] well documented? > > > > In the upcoming BCP > > 1. I don't see it adequately covered there, on a quick scan. I > haven't read it thoroughly, though. Work in progress, feel free to submit some text to Dave. > > 2. There is no reference from dmarc-base to dmarc-bcp, not even an > informative one. And this is an important enough consideration that I > think it should be a normative reference. > > > Should we also document in this Murray's draft that MS-Exchange > > breaks DKIM on forwarding, inventory all the operational cases? I > > don't think so. The draft is to describe the protocol, the BCP is here > > to document on how to operationally deploy and use it. > > I can't parse the first sentence, nor figure out what you're trying to > refer to. But to answer the question that's behind what I think > you're asking: Yes, we should document, either in the specification or > in an Applicability Statement that the specification cites as a > normative reference, considerations that are critical to getting the > configuration right. It is well know that MS-Exchange breaks DKIM on forwarding by design, therefore breaks DMARC. It is not a trivial problem. Also Blackberries, break DMARC too. Should we cite all these cases in the draft? Make a laundry list? We always said do monitor mode and then decide if it makes sense to move to p=reject. Besides section 2.4 says it is out of scope: Handling of undesirable or malicious mail that is coming from the domain from which it claims to be sent. > > It's fine to separate the protocol bits and the "other information" > into different documents, but it *all* has to be there in order to > fight against misconfiguration and the damage that can cause. > As far as I can see (I just did another search on the RFCs) there is no misconfiguration as there is no normative RFC to define what a mailing list is, how it operates, how it handles bounces, subscriptions, etc..... I think this is what Ned was referring to in his post. Section 15.4 gives some advice to all sending systems: In the latter case, when doing an SMTP rejection, providing a clear hint can be useful in resolving issues. A receiver might indicate in plain text the reason for the rejection by using the word "DMARC" somewhere in the reply text. Many systems are able to scan the SMTP reply text to determine the nature of the rejection, thus providing a machine-detectable reason for rejection allows automated sorting of rejection causes so they can be properly addressed. I don't see the issue with mailing lists (and other systems) be different from doing appropriate bounce processing. So I propose the following to be added in 15.4: Some forwarding systems (including some mailing lists) are notably known to have a simple bounce processing system, in such cases, the forwarding system may consider after a few bounces that the recipient address is not valid anymore and unsubscribe such recipient. From nobody Wed Apr 16 10:57: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 7929D1A01B7 for ; Wed, 16 Apr 2014 10:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmXiLl3zZwE4 for ; Wed, 16 Apr 2014 10:56:58 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BDEC81A028E for ; Wed, 16 Apr 2014 10:56:50 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id 20so10353530yks.5 for ; Wed, 16 Apr 2014 10:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jJw1PsJmCQGeWRvmAYTj3ptULd9XQU9e8WoOuFpTsnE=; b=IgHB8vfQEXoAVMhdginDB8VOyL2/kcYlnw1Y5fuPX738feIhFP/VAHju7Naa2O7v2C kYegpJ8A6zdmzqCqkQdNmMyQ3QPtHBlwkMmELJ0OA4Tm91L4A45yE5Z1BKuCbx5epE2o U6f+WN+ms1fPwwD8ccsuaIQVyeaqGWmft9rwZZLV8I5oiZI7QErXBIHi20bMMJ63Eurc jOhSkv9i0id+beFjNpt8JVrE1WsKaMOR4nxgy6/dhdtzDJcOY+OuYVp1666gEwOMY9YP LP2+jngfyn0xx2ouXUrGcF5XFok8GlnbDYYSxt4kcZkK+K1QVR90qjrFbiMzN6ZO+zvo kW4g== X-Received: by 10.236.167.167 with SMTP id i27mr14882002yhl.95.1397671007428; Wed, 16 Apr 2014 10:56:47 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id h23sm43612004yhf.34.2014.04.16.10.56.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Apr 2014 10:56:46 -0700 (PDT) Message-ID: <534EC3E2.3040909@gmail.com> Date: Wed, 16 Apr 2014 10:54:42 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Barry Leiba References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <610289312.88482.1397667890896.JavaMail.zimbra@peachymango.org> 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/3O-uy7q_06zrYqwy1WLsY4uxhRs Cc: "dmarc@ietf.org" , Murray Kucherawy Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 17:57:03 -0000 On 4/16/2014 10:12 AM, Barry Leiba wrote: > 2. There is no reference from dmarc-base to dmarc-bcp, not even an > informative one. And this is an important enough consideration that I > think it should be a normative reference. The issue is important, certainly, but there are two reasons I think having base point to the draft bcp is the wrong approach: 1. The underlying issue here is essentially architectural rather than operations. DMARC is designed to work for some specialized end-to-end scenarios and known to fail for some others, When a spec defines something with those sorts of characteristics, I consider the explanation of its implications to be better placed in the specification. At the least, it facilitates understand the underlying architectural choices that were made. 2. BCPs usually come after the spec. A spec should not rely on a supporting BCP. It gets the document usage directionality all screwed up. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 16 12:11: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 018051A0304 for ; Wed, 16 Apr 2014 12:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, 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 U-GPgZq6Lm2T for ; Wed, 16 Apr 2014 12:11:50 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8301A0302 for ; Wed, 16 Apr 2014 12:11:49 -0700 (PDT) Received: from splunge.local (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s3GJBirZ022020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 16 Apr 2014 12:11:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1397675506; bh=8CgNYA7R9G1UdY/2VmHliKaR/xkafn1OxUeZc3Az5Ok=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=eT3Ci+YeEfTQ8hta8HSvq04BbXsTONZ4EkoFHYDBjJAwvsnpamuD3sVrWAH2peiao 7f9EEki+gaTgQcxoFzXv9WSjCRt4jUFSPR4sj+qyxo/69S66j4W8qk6afh3bk34ufm fUwZ+c8M68x+Jig8IvGps9bOaS359csqjjheWeI8= Message-ID: <534ED5F1.3010001@bluepopcorn.net> Date: Wed, 16 Apr 2014 12:11:45 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dmarc@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ojy7NT7CoOzU12SqQ-wuxQJb_Oo Subject: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 19:11:53 -0000 It seemed like a good time to run through the current DMARC draft. I'm pleased to see that quite a few of the comments I made in my 2 Oct 2013 review of the -01 draft have been addressed. Note that this review addresses the quality of the specification only; it intentionally doesn't address the question of whether deployment of DMARC might be harmful in some way. ===== 1. Introduction Top of page 6: "The receiver reports to the domain owner..." The receiver actually sends reports to a report receiver designated by the domain owner. 2.4 Out of Scope I still find the double negatives to be confusing, e.g., "DMARC will not make a distinction...". It's the making of a distinction that's out of scope, not the not making a distinction (forgive my own double negative, please!). Bullet 10: Again, DMARC doesn't do authentication, even for domains; it relies on other authentication mechanisms. 3. Terminology and Definitions Domain Owner: This definition refers to the domain owner as being the registrant of a DNS domain. But as used elsewhere in the spec, it can also be a delegate of that registrant that is given control over a subdomain. The document frequently refers to a domain owner publishing a DMARC record, so it's worth clarifying who has that capability. Report Receiver: "reports about the messages claiming to be from a third party" We're talking about the reports here, not the messages themselves, so I would suggest "reports from a third party about their messages". 3.1.2 General Concepts Paragraph 2: "provide feedback to the Domain Owner". Should this say a Report Receiver designated by the Domain Owner, or is that too much information at this point? Paragraph 3 doesn't quite capture the sense of alignment properly, especially for SPF. A message that is authorized by SPF might have an unaligned envelope-from address, so the validity of SPF for such messages is moot. 3.1.3 Flow Diagram Item 1: "Author constructs" and "Author also configures" -> "Domain Owner constructs" and "Domain Owner also configures" (I missed this last time) Item 7: 'e.g., a "pass" or "fail"' Are there other results? If not, remove the e.g. 3.1.4 Identifier Alignment Paragraph 5: Although this document makes it clear that "strict" and "relaxed" are different from their usage in DKIM, I'm still having trouble with those words. "strict" means that only this specific domain is affected; "relaxed" means that this domain and its subdomains are affected. So "relaxed" is really more strict in that it enforces more. I find the terms to be confusing, and would recommend something that more directly describes whether the policy applies to subdomains. 3.1.4.1 DKIM-authenticated identifiers Paragraph 4: Include section reference (3.2) to public suffix lists since the section describing it has moved after this text. 3.2 Organizational Domain I remain very concerned about this algorithm since I have been previously told very specifically not to do this by the DNS folks. I'm also concerned about the inconsistency (interoperability impact) that could result from different operators using different public suffix lists. 4. Policy Paragraph 4 basically says, if you don't want a particular authentication scheme to be considered by DMARC, don't use it at all. For a domain that is using SPF and DMARC (for example), this could be an impediment to their deployment of DKIM because they could not test with it without having it immediately affect recipients' message handling. One possibility would be to ignore DKIM if the testing (t=y) flag is set, although a campaign would be needed to get the many domains currently using t=y to turn it off. Another possibility would be to have a setting in DMARC to ignore a specific authentication method entirely. On a related note to the t=y flag for DKIM, are all types of SPF failure (-all, ~all, and ?all) treated equally, or can one of them (probably ?all) be used for testing? 5. DMARC policy record Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate characterization. If the query requirement matched perfectly with the DNS, DNS would have a way to determine the Administrative Domain without resorting to suffix lists and such. Just strike the sentence; this isn't relevant here anyway. 5.2 General Record Format fo: A colon-separated list of options is supported, but 0 and 1 conflict with each other so that either needs to be prohibited or it needs to define which wins. fo:d: "a signature": In the case of a message with multiple DKIM signatures, does that mean if any signature failed evaluation, a message is sent? Is a separate message sent for each failed signature? p:quarantine: What does "suspicious" mean? It sounds like it means something other than "place into spam folder" and "scrutinize with additional intensity" pct: "DMARC-generated reports...must be sent and received unhindered". How does one identity a DMARC-generated report to make sure it's unhindered, especially if a bad actor tries to make their messages look like reports? 5.3 Formal Definition dmarc-rfmt: Should allow a colon-separated list as described in 5.2. 7.1 Verifying External Destinations Paragraph 3: "verification steps SHOULD be taken" These steps are to protect another domain from attack. It needs to be a MUST. 7.2 Aggregate Reports The list of what SHOULD be in the reports seems like it belongs in the definitions of the report formats themselves. 7.3 Failure reports Paragraphs 1 and 2 conflict -- it looks like a change to include [IODEF] in the text was incompletely applied. 7.3.1 Reporting Format Update "Operators implementing this specification also implement": Is that a SHOULD or MUST before "also implement"? 7.4 Utility of Failure Reports Paragraph 1: "detects an authentication failure" -> "detects a DMARC failure" (since authentication can succeed but DMARC fail because of alignment) Paragraph 2 is not relevant to utility of failure reports and probably belongs in 7.3.1. 8. Policy Discovery Step 3: This implicitly says that policy directly applied to a subdomain takes precedence over that published by an Organizational Domain. That's fine, but it should be stated more clearly elsewhere. As I said before, it would be helpful to have something earlier in the specification that talks about the ability to publish a policy either directly on a subdomain or on an Organizational Domain. Also, note that subdomain policies are necessarily strict (don't apply to subdomains of the subdomain) because they won't be discovered using this algorithm. It should say that somewhere do operators don't try to apply DMARC to subtrees of their organizational domain. Second-to-last paragraph: "If the RFC5322.From domain does not exist in the DNS" is basically changing what RFC5321/5322 allow. This isn't the place to be making fundamental changes to the behavior of email. 9. Domain Owner Actions Last paragraph doesn't seem like it fits. Suggest it be removed. 10.1 Extract author domain "Such messages SHOULD be rejected": Agree where forbidden by RFC5322, but a single RFC5322.From containing multiple entities is explicitly valid. Again, this isn't the place to be making fundamental changes to the behavior of email. 11.1 Discovery Mail Receivers can also discover reporting requests from the Organizational Domain. That should be mentioned here. But I'm a little confused why we have another Discovery section at all. 11.2.1 Email The whole thing about filenames needs to go away. Since it's only a SHOULD requirement, the Report Receiver needs to be able to handle reports that don't follow this format as well as those that do. I also wonder if some operating systems have trouble with filenames containing the "!" character. Just let the filename be arbitrary. And since there's a MIME-type, the file extension shouldn't matter either. I have somewhat the same reaction to the Subject header field discussion. It's only a SHOULD, so report receivers can't depend on it. 11.2.3 Error Reports Last paragraph: If this is published as an independent submission RFC, there will be no opportunity to add something here. 14.1 Data Exposure Considerations Last paragraph: what's an "unexpected Mail Receiver"? The privacy consideration here, which isn't obvious from the wording, is that users may currently use forwarding in a way that prevents the sender from determining the ultimate delivery address. DMARC has the potential to break that. This might be important in the case of a user that is trying to distance themselves from a stalker. 14.2 Report Recipients Some potential exists for report recipients to perform traffic analysis: to obtain metadata about the receiver's traffic. In addition to verifying compliance with policies, receivers need to consider that before sending reports to a third party. 14.4 Secure Protocols This seems like it belongs more in Security Consideration than here. 15.5 Identifier Alignment Considerations "DKIM signing practices" -> "DKIM selector records" Note that actors that can gain control of SPF records or selectors can probably publish a DMARC record for the subdomain as well, which will take precedence over the record at the Organizational Domain. Last paragraph: What does "strict" have to do with this? 17.3 DNS Security Might want to make a distinction between DNSSEC publication and resolution. Publication is relevant to Domain Owners, and third-party Report Receivers. DNSSEC-aware resolution is relevant to Mail Receivers and Report Receivers. ===== I didn't particularly review the appendices this time around. -Jim From nobody Wed Apr 16 12:53: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 0A0241A0304 for ; Wed, 16 Apr 2014 12:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 CvzPJmy5hkrX for ; Wed, 16 Apr 2014 12:53:12 -0700 (PDT) Received: from nm9-vm1.bullet.mail.gq1.yahoo.com (nm9-vm1.bullet.mail.gq1.yahoo.com [98.136.218.240]) by ietfa.amsl.com (Postfix) with ESMTP id F26C51A0284 for ; Wed, 16 Apr 2014 12:53:08 -0700 (PDT) Received: from [98.137.12.56] by nm9.bullet.mail.gq1.yahoo.com with NNFMP; 16 Apr 2014 19:53:05 -0000 Received: from [98.137.12.195] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 16 Apr 2014 19:53:05 -0000 Received: from [127.0.0.1] by omp1003.mail.gq1.yahoo.com with NNFMP; 16 Apr 2014 19:53:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 875602.58773.bm@omp1003.mail.gq1.yahoo.com Received: (qmail 61152 invoked by uid 60001); 16 Apr 2014 19:53:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397677985; bh=TZ8VNpBODsyilnZo7yz+GqYRpnGD2ZEkGb6H4l76NFg=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=2bQQdJprHSi/fzOws6RQNcdZae1SiMow2KDAEwAkykkaJnoFYhXX+4JdGFqeW0G0/2a44ctbjQYr01cVDbOgJmDuTyCFwFyftkd1OFhL1QMsAZ/4w4Q5/3HzBCrAnIVFOx9dfdt3xAYBjDDL7PvyCTMI1Xh2qGoVqW5Q1WI3OyQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eaZn6a/Ze2lXu4Q3uLBmxC7RFX//dbsuFnmm2WLbTKA0ozjRB9d/bsoqn6w+8oeb9VLyc57olg+OBphhGQAtFfYmeU++UCa1cao3ukqpHL6n6lKGCGTJScmtp2WhTX9gKENUfOjXU9elmsOyyJ2rMcfmkKr9/EKfvttyrFFF5Sc=; X-YMail-OSG: c.N_0MAVM1noQPuHU3Fpxr6ECuwzETUtjdyHTtKjnbx4DFx S733LHYMtd9jzvPTedD1gmCe7oLCwgD_i_CoYwKe_SlI1PBc64ow4XDzpckU 03.h5hZzTETApy_d3ShLgXM_aAev9nDcfQqv9L.xTItRiZ3gO.fYmxyGYG1E fAlljMRgRXmnYmWsQ4rXBRacrfW3nDoubPK_bG5zQAnDAsphIV5SP7vOBs._ XuirgEXqi4n8FcfJn2R2NrvxYW7fEooZzRdsRjgS4CRpCyqkQTJfqSCWHbbQ 0oSkB0OC0ewGrnlHwE_aDlYhG2qlSr166EqFz45eDCCvbssDsuEJ9pLASXSS n36I8LD4l9kMX17_dIZ18KWgyEEvhaJZ8zlECxsplOeLEdXVu906qaTG3NSx D5kMwqCx5UemOoRHY4hMc4u.y3uJRhIb.EeLfcYQepPaAMGwhN6LtVdnQWVO WLkkrgoUdLPzveohyJB4r9cn4dIL6YE2LEV5pQrQIxv6SkpB.vh44ETwuAl9 e5TGZPOR2q25EmqSZopBSDwm8deQ4JiV3DBkmNSifwwxtn5t0eim.VB8Vdl4 J5KaO8AVsyVJEhqsHn4_OPfXRcB7BfbjlIf94J1LFwizS8iJY7kbhI9KpMAe jFXXj.qoTmua99xBrKw3HhkLtHK224Wlz6MG4NourwHCfNR6YN4JVPC4wxei xaq8qFkpkMyD8yg-- Received: from [109.121.36.90] by web164606.mail.gq1.yahoo.com via HTTP; Wed, 16 Apr 2014 12:53:05 PDT X-Rocket-MIMEInfo: 002.001, T24gV2VkbmVzZGF5LCBBcHJpbCAxNiwgMjAxNCA3OjQ0IFBNLCBNSCBNaWNoYWVsIEhhbW1lciAoNTMwNCkgd3JvdGU6Cj4gSSBoYXZlbid0IHNlZW4gYW55IG90aGVyIHBvc3QgZnJvbSB5b3Ugd2l0aCB0aGlzIHN1YmplY3QgbGluZS4KCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kbWFyYy9jdXJyZW50L21zZzAwNzQ5Lmh0bWwKCsKgCgotLSAKVmxhdGtvIFNhbGFqIGFrYSBnb29kb25lCmh0dHA6Ly9nb29kb25lLnRrATABAQEB X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397669424.61612.YahooMailNeo@web164602.mail.gq1.yahoo.com> Message-ID: <1397677985.57055.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Wed, 16 Apr 2014 12:53:05 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UGPlFR97mpMSY3elOZid2u2ifAQ Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 19:53:16 -0000 On Wednesday, April 16, 2014 7:44 PM, MH Michael Hammer (5304) wrote:=0A> I= haven't seen any other post from you with this subject line.=0A=0Ahttp://w= ww.ietf.org/mail-archive/web/dmarc/current/msg00749.html=0A=0A=A0=0A=0A-- = =0AVlatko Salaj aka goodone=0Ahttp://goodone.tk From nobody Wed Apr 16 14:39: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 8D3591A0359 for ; Wed, 16 Apr 2014 14:39:34 -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 L1SzXCZgu2J3 for ; Wed, 16 Apr 2014 14:39:28 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 64BB11A01DD for ; Wed, 16 Apr 2014 14:39:28 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id x13so11622629wgg.14 for ; Wed, 16 Apr 2014 14:39:24 -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=pEFjl67Gf0C/Lz77SEmQVBxz9biURrO+h0JgrZHmbF8=; b=jMdHFS/a7a5l6lRG6HuIduHgtPqAKfN138supKNQILzHdTL+SL0JbSI5Eu7jDEOA6i gJiOb7jYiAqspJX7BWKuGicKKEBeAtVN9gwAVWyx5so2nIIwVIN8Lw/7DS2yShMTBpNd vJ5jMrtCNQyxFnFDio9UnozOJOCDDr+j0NbUHKtbUmPo6HsJjVT9HHXZixBeRHzdw8FQ v/TsMmfRUQBBxSBPZD85YpWT1AjedHRvcdYUUvbnx3CbO6HqGmZ7cymD5wvRGFUvcoJH G67tESQ1YfLeuKECnDqdG6I4PBoYZuw+2WHANmohwtu4w4L77J/mo2t53lmxuniY6oQp RlwA== MIME-Version: 1.0 X-Received: by 10.194.24.74 with SMTP id s10mr8751603wjf.43.1397684364507; Wed, 16 Apr 2014 14:39:24 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Wed, 16 Apr 2014 14:39:24 -0700 (PDT) In-Reply-To: <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Wed, 16 Apr 2014 14:39:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=047d7b5d25420dff2004f72fc0bc Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vqCESSjzMz7RXeoFTp57APZ9wkM Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2014 21:39:34 -0000 --047d7b5d25420dff2004f72fc0bc Content-Type: text/plain; charset=UTF-8 I wouldn't take the lack of answers terribly personally. There certainly are a lot of threads to track right now. As for your specific ideas: On Mon, Apr 14, 2014 at 10:10 AM, Vlatko Salaj wrote: > i already mentioned including SRS in check logic. unfortunately, no dmarc > author rly added much to the topic, and i work alone only on my own > projects, > not on collaborative things as these. > I seem to remember there was in fact discussion of your SRS advocacy. > also, my 2nd suggestion, independent from 1st, if we mark SRS as 1st, > would be: > a. dmarc alignment is a big issue. read: huge issue. > b. since alignment is an issue, make it policy optional. > c. by "make it policy optional" i mean: include an option in dmarc dns > policy, > so that domain owners could turn dmarc alignment check on/off. > One way of viewing DMARC is that it seeks to allow a domain owner to have better control of how its domain is used, so I don't know what this would accomplish. If alignment is optional, what does DMARC do policy-wise that DKIM and SPF don't already do? this could be useful for: > domains using high volume ML participation, > domains that use 3rd party services for their email infrastructure, > domains that use forwarders, > bunch of other special cases u can find on internet today and in future. > > my 3rd suggestion, which would go nicely together with 2nd, is: > 1. current dmarc spec uses OR logic while processing SPF and DKIM; why? > They have complementary failure modes. Data shows that the vast majority of mail passes at least one if not both. OR is the best logic in that scenario, is it not? 2. make this policy processing logic selectable. > 3. by "make it selectable" i mean: include an option in dmarc dns policy, > so that domain owners could turn dmarc processing logic either to OR or > AND. > That might be useful, but isn't that more restrictive, and not less restrictive? How would it help your use case, for example? -MSK --047d7b5d25420dff2004f72fc0bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wouldn't take the lack of answers terribly personall= y.=C2=A0 There certainly are a lot of threads to track right now.
<= div class=3D"gmail_extra">
As for your specific ideas:

On Mon, Ap= r 14, 2014 at 10:10 AM, Vlatko Salaj <vlatko.salaj@goodone.tk>= ; wrote:
also, my 2nd suggestion, independent from 1st, if we mark SRS as 1st, would= be:
a. dmarc alignment is a big issue. read: huge issue.
b. since alignment is an issue, make it policy optional.
c. by "make it policy optional" i mean: include an option in dmar= c dns policy,
so that domain owners could turn dmarc alignment check on/off.

One way of viewing DMARC is that it seeks to allow a domain ow= ner to have better control of how its domain is used, so I don't know w= hat this would accomplish.=C2=A0 If alignment is optional, what does DMARC = do policy-wise that DKIM and SPF=20 don't already do?

this could be useful for:
domains using high volume ML participation,
domains that use 3rd party services for their email infrastructure,
domains that use forwarders,
bunch of other special cases u can find on internet today and in future.
my 3rd suggestion, which would go nicely together with 2nd, is:
1. current dmarc spec uses OR logic while processing SPF and DKIM; why?
=

They have complementary failure modes.=C2= =A0 Data shows that the vast majority of mail passes at least one if not bo= th.=C2=A0 OR is the best logic in that scenario, is it not?

2. make this policy processing logic selectable.
3. by "make it selectable" i mean: include an option in dmarc dns= policy,
so that domain owners could turn dmarc processing logic either to OR or AND= .

That might be useful, but isn't t= hat more restrictive, and not less restrictive?=C2=A0 How would it help you= r use case, for example?

-MSK
--047d7b5d25420dff2004f72fc0bc-- From nobody Wed Apr 16 22:50: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 6A13B1A045C for ; Wed, 16 Apr 2014 22:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 WLJRlMhiR7QJ for ; Wed, 16 Apr 2014 22:50:35 -0700 (PDT) Received: from nm6-vm2.bullet.mail.gq1.yahoo.com (nm6-vm2.bullet.mail.gq1.yahoo.com [98.136.218.193]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4EA1A0459 for ; Wed, 16 Apr 2014 22:50:35 -0700 (PDT) Received: from [98.137.12.58] by nm6.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 05:50:32 -0000 Received: from [98.137.12.200] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 05:50:32 -0000 Received: from [127.0.0.1] by omp1008.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 05:50:32 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 378819.53614.bm@omp1008.mail.gq1.yahoo.com Received: (qmail 83258 invoked by uid 60001); 17 Apr 2014 05:50:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397713832; bh=mzE7o9aW5I/yXu+pbQXDm4w5ODQXy+RtSmbaYsJtTMs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=km5sG+uhG/Gz+0VV1icbgJnyrLD8ptjjXCWydQ4oPT7HAMcJL0s6K2MiMQcNQW9cMJkB+EQRiZlSwX3Tyuj4op1eVFZgqywYfGJiD6or10L/vdQEqFA+u6YyZvhx4wAvaNWn4jxZefbo7LGBJRuAL6srBqCWB9dwRmjluiZMvRM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=s4DAF67G3x1vwc2URgK/5JscYbvLKg+DV2IaEE8VO8jbmOARj+i8ElEZUK2OFFZvCxx9R5oLeW8oAuRwbMDZzDJLyiRDKoCIt/6B1p8KCcZWzpEU6ocUj4ZQSAtBN2p0EYyQHKYRbR6WNO64mwBa16y1NN7Q0zlkPMi7VxtpIOY=; X-YMail-OSG: iT_.tZgVM1kkN91uMv8hMNKIaTo2eX1q3yWAM2nUeLstXRG depMmxhXkjzNlg.mlFTviRX6I9f8bG9Xj4TTQGNuVp.66JfWGKLzyV.2q2V5 DAtZczRqFkdlN64FssxNnfM3.MFGPfG9WWDgdXrJOI.NxJCBYEeRT1quF_N4 VJn_uc1LVL5GMWylPSAvzT_qtMcqvtO4XnBRU3GHbIj1T7al_BdN1KC.RlSb f1GmzXi3roxwiRZflI434RZIGBj4RwYI49PY2rdlc9AzkD_H9IRsvrajy2db kFOdqjBnzjKcnG0LUQSrujnPEq0ooGcjOB4tLdqLMuwosP3Nb6hGk65LdUZz 5zhuOTicUI1S.Du9bUwVnWDwbXwrLEGv70f2CaGMhyzCHlmCH9sh1hxNv4cB dAL2nocID4F.mYbPIl8rBQ4Uk6A7.8iBYWcqsf15_nSPpnn77DKaDbk6S2dh 3w7qgQ0O4B53tpv24sIjrDNCAU6.IIxhtsfW.ZV_Ho04eJDOBkQChO4vCV9p v807_wZG3VztQ7GnQNBUG3M9tv6.mrdzfzEQGuwObgtDpuQPEB5Rb7F49H6U LWqfHB5f.fjITniJqdUlskT1jKxBBSwzIWfKZ_3rp11T1DjyU Received: from [109.121.36.90] by web164601.mail.gq1.yahoo.com via HTTP; Wed, 16 Apr 2014 22:50:32 PDT X-Rocket-MIMEInfo: 002.001, T24gV2VkbmVzZGF5LCBBcHJpbCAxNiwgMjAxNCAxMTozOSBQTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSB3cm90ZToKCgo.IEkgd291bGRuJ3QgdGFrZSB0aGUgbGFjayBvZiBhbnN3ZXJzIHRlcnJpYmx5IHBlcnNvbmFsbHkuCgppIHJseSBkb24ndC4gaSBqdXN0IGZvdW5kIGl0IHJseSBsb2xhYmxlIGhvdyBldmVyeWJvZHkgaXMgd2hpbmluZyBhYm91dAppZXRmJ3MgcHVycG9zZSBoZXJlLCB3aGlsZSBsaXN0J3MgbWFpbiBhaW0gaXMgYWJvdXQgdGVjaG5pY2FsIGNvbnRyaWJ1dGlvbnMKdG8gdGhlIGRtYXJjIHMBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> Message-ID: <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Wed, 16 Apr 2014 22:50:32 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1I_F-kojRKVM2k5zOVWr8p-P7kA Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 05:50:39 -0000 On Wednesday, April 16, 2014 11:39 PM, Murray S. Kucherawy wrote: > I wouldn't take the lack of answers terribly personally. i rly don't. i just found it rly lolable how everybody is whining about ietf's purpose here, while list's main aim is about technical contributions to the dmarc standard, which of, i saw none. >> include an option in dmarc dns policy, so that domain owners could turn >> dmarc alignment check on/off. > One way of viewing DMARC is that it seeks to allow a domain owner to have > better control of how its domain is used, so I don't know what this would > accomplish. If alignment is optional, what does DMARC do policy-wise that > DKIM and SPF don't already do? let me ask u: how exactly r u allowing a domain owner to have better control of how its domain is used, when u do not allow it to say: i do not want alignment? i imagine, domain owners may actually prefer to send their email through 3rd party infrastructure. DMARC has no provisions for such practice. and it's a common practice, absolutely. whether it's formal or informal. >> include an option in dmarc dns policy, so that domain owners could turn >> dmarc processing logic either to OR or AND. > That might be useful, but isn't that more restrictive, and not less > restrictive? as i said: combined, alignment OFF and AND processing logic would work great in cases where alignment isn't possible, yet email is fully legitimate. and in such case, considering alignment requirement is gone, it's actually less restrictive, while still providing better authentication. and blah blah, u can see the benefit, i'm sure. also, it should be strict AND, meaning, all dmarc mechanism must exist and pass, for DMARC to pass, making such DMARC evaluation almost as reliable as alignment-based one, if not more, while still encompassing much wider range of email usage cases, in situation where it works better than alignment-based one. also, there may be other algorithms in the future which will become part of DMARC. allowing domain owners to have control of how these get evaluated is a right thing to do. my proposal is even stronger if u consider that some of these algorithms may get exploited in the future, which would completely annihilate OR-based DMARC, with no remedy. having AND-based option would fix that in advance. > How would it help your use case, for example? it would do wonders for me. my personal email stream would pass DMARC. DMARC policy "reject", alignment OFF, logic AND, reporting ON and "fo=d:s" would actually fix many of customer domains that i service, which use google or yahoo mail for their domain-based email. considering both google and yahoo use DKIM and SPF, those emails would pass such DMARC, even thought they are being sent through 3rd party services. and if DKIM and SPF get supported by other services, it would cover them too. also, making alignment and logic selectable, would not make additional pressure on big ESPs infrastructure, but it would cover much of failure cases current version has. it may even be worthwhile for big ESPs to use this type of DMARC policy: "reject", alignment OFF, logic AND, reporting ON. it would surely make reports they receive much more informative too, helping with data mining on other domain practices, which could be used in anti-spam etc. and any potential abuse would simply be dealt with by switching to alignment ON policy, when it's required for a particular domain. >> i already mentioned including SRS in check logic. unfortunately, no dmarc >> author rly added much to the topic > I seem to remember there was in fact discussion of your SRS advocacy. none rly taking the discussion to next lvl, but merely acknowledging i mentioned SRS, and dismissing it without much ado. also, i have another suggestion: include sender-id as another DMARC supported check algorithm. sender-id is different enough from SPF to cover many usage scenarios, and would just add to dmarc strengths. i don't rly understand why ppl take sender-id for 2nd generation SPF, since it isn't. yeah, i better not start this topic... we don't want another MARID. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Wed Apr 16 23:22:41 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 30FFC1A03DA for ; Wed, 16 Apr 2014 23:22:39 -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 0U4lcUOjihAl for ; Wed, 16 Apr 2014 23:22:34 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id D78491A03D6 for ; Wed, 16 Apr 2014 23:22:33 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so334195wib.4 for ; Wed, 16 Apr 2014 23:22:30 -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=A0isscivHPibzZJUbtZQQ+tSXoswEZzCxyN2g4snCm4=; b=td4WqJ59eNWS0+GSDAfRRfOZU+uARmSnhYll4j/waQH2ylsDM5AasGy6Y5kfi/Xnhm HX5fMUF4GueBAXDjDWvAhJ2TbkbcNvuMytFgn77477YRiw47A80vaHnPxPiwxn+6VOBu qOVXnfEyx54qvCKX7H1UbRKZ2ObgWNCO/PbE9rhHh5ttGh2F04Z0GOtJN4OMn6d5N9cT /exxkyqmFJyK7rybPIIbJAg4b/2oatbgZzkmbD/1f5rY3GiTtSi0CxOEU9zH6U6zqCBN Vphs2bPZmFhQbw3TH8/9rQ8i8tGiFoAYRqcq36Oa74rGu8rpy8kQw17p5YCAHwNIV68B OueQ== MIME-Version: 1.0 X-Received: by 10.180.106.132 with SMTP id gu4mr10080030wib.26.1397715749954; Wed, 16 Apr 2014 23:22:29 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Wed, 16 Apr 2014 23:22:29 -0700 (PDT) In-Reply-To: <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Wed, 16 Apr 2014 23:22:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=e89a8f3babd3c5eb0c04f7370e23 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QF9xVzYnM-ztuDpdC-VsUg6ezuI Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 06:22:39 -0000 --e89a8f3babd3c5eb0c04f7370e23 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 16, 2014 at 10:50 PM, Vlatko Salaj wrote: > > One way of viewing DMARC is that it seeks to allow a domain owner to have > > better control of how its domain is used, so I don't know what this would > > accomplish. If alignment is optional, what does DMARC do policy-wise that > > DKIM and SPF don't already do? > > let me ask u: how exactly r u allowing a domain owner to have better > control > of how its domain is used, when u do not allow it to say: i do not want > alignment? i imagine, domain owners may actually prefer to send their email > through 3rd party infrastructure. DMARC has no provisions for such > practice. > "I do not want alignment" is exactly the same as "I don't use DMARC" since DMARC is pretty much all about alignment. So, again, I don't understand why that's a useful thing to add. > and it's a common practice, absolutely. whether it's formal or informal. > What's an example? >> include an option in dmarc dns policy, so that domain owners could turn > >> dmarc processing logic either to OR or AND. > > That might be useful, but isn't that more restrictive, and not less > > restrictive? > > as i said: combined, alignment OFF and AND processing logic would work > great > in cases where alignment isn't possible, yet email is fully legitimate. > and in such case, considering alignment requirement is gone, it's actually > less restrictive, while still providing better authentication. and blah > blah, > u can see the benefit, i'm sure. > For the "off" case, isn't that just the same as "p=none"? For the "and" case, yes, that's possible to add if there's enough demand to add it. So far the people that have tried this are satisfied with the "or" logic. What do others think? > also, it should be strict AND, meaning, all dmarc mechanism must exist and > pass, for DMARC to pass, making such DMARC evaluation almost as reliable as > alignment-based one, if not more, while still encompassing much wider > range of > email usage cases, in situation where it works better than alignment-based > one. > Sure, if that's what the community wants to do. This is the first time I've heard anyone say this would be a useful thing to support. If anyone else agrees that it's needed, DMARC can easily be extended to include this capability. It's built that way. > also, there may be other algorithms in the future which will become part of > DMARC. allowing domain owners to have control of how these get evaluated is > a right thing to do. my proposal is even stronger if u consider that some > of > these algorithms may get exploited in the future, which would completely > annihilate OR-based DMARC, with no remedy. having AND-based option would > fix > that in advance. > Yes, that extensibility is already built into DMARC. > > How would it help your use case, for example? > > it would do wonders for me. my personal email stream would pass DMARC. > By turning off alignment, I bet it would. > DMARC policy "reject", alignment OFF, logic AND, reporting ON and "fo=d:s" > would actually fix many of customer domains that i service, which use > google > or yahoo mail for their domain-based email. considering both google and > yahoo > use DKIM and SPF, those emails would pass such DMARC, even thought they are > being sent through 3rd party services. and if DKIM and SPF get supported by > other services, it would cover them too. > What would that look like, exactly? From: your domain, a passing DKIM signature for a domain other than yours, a passing SPF test for a domain other than yours? If that's what you mean, then I can make any message I want that passes DMARC for your domain by sending it from my own box and signing it. Are you sure you want that? If that's not what you mean, then you'll have to build an example, because I don't get it. > also, making alignment and logic selectable, would not make additional > pressure on big ESPs infrastructure, but it would cover much of failure > cases current version has. > Actually I think if you advertise something that is substantially weaker than what DMARC has now, I suspect ESPs will be less likely to trust your stream because it's basically unprotected. none rly taking the discussion to next lvl, but merely acknowledging i > mentioned SRS, and dismissing it without much ado. > That probably means the benefit of adding SRS support wasn't obvious to the people responding. This may be obvious to you, but it's apparently not obvious to others. also, i have another suggestion: > include sender-id as another DMARC supported check algorithm. > > sender-id is different enough from SPF to cover many usage scenarios, > and would just add to dmarc strengths. i don't rly understand why ppl take > sender-id for 2nd generation SPF, since it isn't. > > yeah, i better not start this topic... we don't want another MARID. > I totally agree there, especially since Sender-ID got almost no adoption (see RFC 6686), and that seems unlikely to change now. -MSK --e89a8f3babd3c5eb0c04f7370e23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 16, 2014 at 10:50 PM, Vlatko Salaj <v= latko.salaj@goodone.tk> wrote:
=
> One way of viewing DMARC is that it see= ks to allow a domain owner to have
> better control of how its domain is used, so I don't know what thi= s would
> accomplish. If alignment is optional, what does DMARC do policy-wise t= hat
> DKIM and SPF don't already do?

let me ask u: how exactly r u allowing a domain owner to have better contro= l
of how its domain is used, when u do not allow it to say: i do not want
alignment? i imagine, domain owners may actually prefer to send their email=
through 3rd party infrastructure. DMARC has no provisions for such practice= .

"I do not want alignment" i= s exactly the same as "I don't use DMARC" since DMARC is pret= ty much all about alignment.=C2=A0 So, again, I don't understand why th= at's a useful thing to add.
=C2=A0
and it's a common practice, absolutely. whether it's formal or info= rmal.

What's an example?

>> include an option in dmarc dns policy, so that domain owners could= turn
>> dmarc processing logic either to OR or AND.
> That might be useful, but isn't that more restrictive, and not les= s
> restrictive?

as i said: combined, alignment OFF and AND processing logic would work grea= t
in cases where alignment isn't possible, yet email is fully legitimate.=
and in such case, considering alignment requirement is gone, it's actua= lly
less restrictive, while still providing better authentication. and blah bla= h,
u can see the benefit, i'm sure.

Fo= r the "off" case, isn't that just the same as "p=3Dnone&= quot;?

For the "and" case, yes, that's poss= ible to add if there's enough demand to add it.=C2=A0 So far the people= that have tried this are satisfied with the "or" logic.=C2=A0 Wh= at do others think?
=C2=A0
also, it should be strict AND, meaning, all dmarc mechanism must exist and<= br> pass, for DMARC to pass, making such DMARC evaluation almost as reliable as=
alignment-based one, if not more, while still encompassing much wider range= of
email usage cases, in situation where it works better than alignment-based = one.

Sure, if that's what the commu= nity wants to do.=C2=A0 This is the first time I've heard anyone say th= is would be a useful thing to support.=C2=A0 If anyone else agrees that it&= #39;s needed, DMARC can easily be extended to include this capability.=C2= =A0 It's built that way.
=C2=A0
also, there may be other algorithms in the future which will become part of=
DMARC. allowing domain owners to have control of how these get evaluated is=
a right thing to do. my proposal is even stronger if u consider that some o= f
these algorithms may get exploited in the future, which would completely annihilate OR-based DMARC, with no remedy. having AND-based option would fi= x
that in advance.

Yes, that extensibilit= y is already built into DMARC.
=C2=A0
> How would it help your use case, for example?

it would do wonders for me. my personal email stream would pass DMARC.
<= /blockquote>

By turning off alignment, I bet it would.=C2=A0
DMARC policy "reject", alignment OFF, logic AND, reporting ON and= "fo=3Dd:s"
would actually fix many of customer domains that i service, which use googl= e
or yahoo mail for their domain-based email. considering both google and yah= oo
use DKIM and SPF, those emails would pass such DMARC, even thought they are=
being sent through 3rd party services. and if DKIM and SPF get supported by=
other services, it would cover them too.

What would that look like, exactly?=C2=A0 From: your domain, a passing DK= IM signature for a domain other than yours, a passing SPF test for a domain= other than yours?=C2=A0 If that's what you mean, then I can make any m= essage I want that passes DMARC for your domain by sending it from my own b= ox and signing it.=C2=A0 Are you sure you want that?

If that's not what you mean, then you'll have to bui= ld an example, because I don't get it.
=C2=A0
also, making alignment and logic selectable, would not make additional
pressure on big ESPs infrastructure, but it would cover much of failure
cases current version has.

Actually I think = if you advertise something that is substantially weaker than what DMARC has= now, I suspect ESPs will be less likely to trust your stream because it= 9;s basically unprotected.

none rly taking the discussion to next lvl, but merely acknowledging i
mentioned SRS, and dismissing it without much ado.
That probably means the benefit of adding SRS support wasn'= t obvious to the people responding.=C2=A0 This may be obvious to you, but i= t's apparently not obvious to others.

also, i have another suggestion:
include sender-id as another DMARC supported check algorithm.

sender-id is different enough from SPF to cover many usage scenarios,
and would just add to dmarc strengths. i don't rly understand why ppl t= ake
sender-id for 2nd generation SPF, since it isn't.

yeah, i better not start this topic... we don't want another MARID.
=

I totally agree there, especially since Se= nder-ID got almost no adoption (see RFC 6686), and that seems unlikely to c= hange now.

-MSK
--e89a8f3babd3c5eb0c04f7370e23-- From nobody Thu Apr 17 04:42: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 E2FB71A0117 for ; Thu, 17 Apr 2014 04:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.791 X-Spam-Level: X-Spam-Status: No, score=-6.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBW77swFF48K for ; Thu, 17 Apr 2014 04:42:49 -0700 (PDT) Received: from msginmsm02vapp.fmr.com (ltm-fwus409m-410m.fidelity.com [155.199.16.10]) by ietfa.amsl.com (Postfix) with ESMTP id 330C31A010F for ; Thu, 17 Apr 2014 04:42:48 -0700 (PDT) Received: from msgrtphc05win.DMN1.FMR.COM (MSGRTPHC05WIN.dmn1.fmr.com [10.95.11.185]) by msginmsm02vapp.fmr.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.1) with ESMTP id s3HBgXjg018003 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 17 Apr 2014 11:42:34 GMT X-DKIM: OpenDKIM Filter v2.1.3 msginmsm02vapp.fmr.com s3HBgXjg018003 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; s=2012-05-26; t=1397734955; bh=DGFolVFQTad0xH9BQFx3852AC6pbULdmXs2bq+9UJok=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=oWCEfPL+ReHdjPU29LSiU4dlWLjDdgMc35jruS3NPR3vDpyTUh26WjzmDkqv+ibeh 8povolheJXdkB7mbbmmlhgu0jTr9kAVSTqMCZyVS6tTaxO6br8+ynA2G1orVAGQloc AsrrHSCZIJBBYNc8FZhUL8YfJ6afqJ+86UniUyD0= Received: from MSGRTPCCRF2WIN.DMN1.FMR.COM ([10.95.12.31]) by msgrtphc05win.DMN1.FMR.COM ([10.95.11.185]) with mapi; Thu, 17 Apr 2014 07:42:33 -0400 From: "Popowycz, Alex" To: "'Vlatko Salaj'" , "'dmarc@ietf.org'" Date: Thu, 17 Apr 2014 07:42:32 -0400 Thread-Topic: [dmarc-ietf] alignment and parsing logic as optionals Thread-Index: Ac9aAPd2KNPEC9gVRqeiDcRjQ5i4+gAMScUi Message-ID: <9495B91F5CA0E24C9161D71CD46E43DB011C89D75F38@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> In-Reply-To: <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9495B91F5CA0E24C9161D71CD46E43DB011C89D75F38MSGRTPCCRF2_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xFayiACdHn-I140eFZEXm1eYk48 Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 11:42:54 -0000 --_000_9495B91F5CA0E24C9161D71CD46E43DB011C89D75F38MSGRTPCCRF2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyaGFwcyBJJ20gbWlzc2luZyBzb21ldGhpbmcsIGJ1dCBlbGltaW5hdGluZyBhbGlnbm1lbnQg ZXNzZW50aWFsbHkgbnVsbGlmaWVzIHRoZSBhdXRoZW50aWNhdGlvbiB2YWx1ZSBmb3IgYSBnaXZl biBkb21haW4uIElmLCBmb3IgZXhhbXBsZSwgSSBkaXNhYmxlIGFsaWdubWVudCB0aGVuIEknbSBl c3NlbnRpYWxseSBzYXlpbmcgdGhhdCBhbnlvbmUgY2FuIGhpamFjay9zcG9vZi9taXNhcHByb3By aWF0ZSBteSBkb21haW4gYXMgbG9uZyBhcyB0aGV5IGhhdmUgYSB2YWxpZHNwZiByZWNvcmQgZm9y IHRoZSBzZW5kaW5nIG10YSBvciBES0lNIHNpZ24gdGhlaXIgbWVzc2FnZS4NCg0KRXhhbXBsZS4g TXkgZG9tYWluIGlzIGxlZ2l0aW1hdGVtYWlsLmNvbS4gSSBoYXZlIGEgRE1BUkMgcmVjb3JkIHRo YXQgaGFzIHNldCBhbGlnbm1lbnQgdG8gT0ZGLg0KU29tZW9uZSwgZWl0aGVyIGtub3duIHRvIG1l IG91dCBub3QsIG5vdyBzZW5kcyB1c2luZyB0aGUgRlJPTSBhZGRyZXNzIG9mIGxlZ2l0aW1hdGVt YWlsLmNvbSBidXQgc2lnbnMgd2l0aCBkPWJhZG1haWwuY29tLiBJdCBzZWVtcyB3aXRoIHRoZSBw cm9wb3NhbCBiZWxvdyB0aGF0IHdvdWxkICJwYXNzIiBETUFSQyBwcm9jZXNzaW5nIGFuZCBiZSBk ZWxpdmVyZWQgKG9yIGF0IGxlYXN0IG5vdCBnZXQgcmVqZWN0ZWQgZHVlIHRvIERNQVJDKS4gSSBn dWVzcyBJIGZhaWwgdG8gc2VlIGhvdyB0aGlzIHdvcmtzIHRvd2FyZHMgcmVkdWNpbmcvZWxpbWlu YXRpbmcgZnJhdWR1bGVudCBlbWFpbC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IFZsYXRrbyBTYWxhaiBbdmxhdGtvLnNhbGFqQGdvb2RvbmUudGs8bWFpbHRvOnZsYXRrby5z YWxhakBnb29kb25lLnRrPl0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNywgMjAxNCAwMTo1MCBB TSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOiBkbWFyY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtkbWFyYy1pZXRmXSBhbGlnbm1lbnQgYW5kIHBhcnNpbmcgbG9naWMgYXMgb3B0aW9uYWxzDQoN Cg0KT24gV2VkbmVzZGF5LCBBcHJpbCAxNiwgMjAxNCAxMTozOSBQTSwgTXVycmF5IFMuIEt1Y2hl cmF3eSB3cm90ZToNCg0KDQo+IEkgd291bGRuJ3QgdGFrZSB0aGUgbGFjayBvZiBhbnN3ZXJzIHRl cnJpYmx5IHBlcnNvbmFsbHkuDQoNCmkgcmx5IGRvbid0LiBpIGp1c3QgZm91bmQgaXQgcmx5IGxv bGFibGUgaG93IGV2ZXJ5Ym9keSBpcyB3aGluaW5nIGFib3V0DQppZXRmJ3MgcHVycG9zZSBoZXJl LCB3aGlsZSBsaXN0J3MgbWFpbiBhaW0gaXMgYWJvdXQgdGVjaG5pY2FsIGNvbnRyaWJ1dGlvbnMN CnRvIHRoZSBkbWFyYyBzdGFuZGFyZCwgd2hpY2ggb2YsIGkgc2F3IG5vbmUuDQoNCg0KPj4gaW5j bHVkZSBhbiBvcHRpb24gaW4gZG1hcmMgZG5zIHBvbGljeSwgc28gdGhhdCBkb21haW4gb3duZXJz IGNvdWxkIHR1cm4NCj4+IGRtYXJjIGFsaWdubWVudCBjaGVjayBvbi9vZmYuDQo+IE9uZSB3YXkg b2Ygdmlld2luZyBETUFSQyBpcyB0aGF0IGl0IHNlZWtzIHRvIGFsbG93IGEgZG9tYWluIG93bmVy IHRvIGhhdmUNCj4gYmV0dGVyIGNvbnRyb2wgb2YgaG93IGl0cyBkb21haW4gaXMgdXNlZCwgc28g SSBkb24ndCBrbm93IHdoYXQgdGhpcyB3b3VsZA0KPiBhY2NvbXBsaXNoLiBJZiBhbGlnbm1lbnQg aXMgb3B0aW9uYWwsIHdoYXQgZG9lcyBETUFSQyBkbyBwb2xpY3ktd2lzZSB0aGF0DQo+IERLSU0g YW5kIFNQRiBkb24ndCBhbHJlYWR5IGRvPw0KDQpsZXQgbWUgYXNrIHU6IGhvdyBleGFjdGx5IHIg dSBhbGxvd2luZyBhIGRvbWFpbiBvd25lciB0byBoYXZlIGJldHRlciBjb250cm9sDQpvZiBob3cg aXRzIGRvbWFpbiBpcyB1c2VkLCB3aGVuIHUgZG8gbm90IGFsbG93IGl0IHRvIHNheTogaSBkbyBu b3Qgd2FudA0KYWxpZ25tZW50PyBpIGltYWdpbmUsIGRvbWFpbiBvd25lcnMgbWF5IGFjdHVhbGx5 IHByZWZlciB0byBzZW5kIHRoZWlyIGVtYWlsDQp0aHJvdWdoIDNyZCBwYXJ0eSBpbmZyYXN0cnVj dHVyZS4gRE1BUkMgaGFzIG5vIHByb3Zpc2lvbnMgZm9yIHN1Y2ggcHJhY3RpY2UuDQoNCmFuZCBp dCdzIGEgY29tbW9uIHByYWN0aWNlLCBhYnNvbHV0ZWx5LiB3aGV0aGVyIGl0J3MgZm9ybWFsIG9y IGluZm9ybWFsLg0KDQoNCj4+IGluY2x1ZGUgYW4gb3B0aW9uIGluIGRtYXJjIGRucyBwb2xpY3ks IHNvIHRoYXQgZG9tYWluIG93bmVycyBjb3VsZCB0dXJuDQo+PiBkbWFyYyBwcm9jZXNzaW5nIGxv Z2ljIGVpdGhlciB0byBPUiBvciBBTkQuDQo+IFRoYXQgbWlnaHQgYmUgdXNlZnVsLCBidXQgaXNu J3QgdGhhdCBtb3JlIHJlc3RyaWN0aXZlLCBhbmQgbm90IGxlc3MNCj4gcmVzdHJpY3RpdmU/DQoN CmFzIGkgc2FpZDogY29tYmluZWQsIGFsaWdubWVudCBPRkYgYW5kIEFORCBwcm9jZXNzaW5nIGxv Z2ljIHdvdWxkIHdvcmsgZ3JlYXQNCmluIGNhc2VzIHdoZXJlIGFsaWdubWVudCBpc24ndCBwb3Nz aWJsZSwgeWV0IGVtYWlsIGlzIGZ1bGx5IGxlZ2l0aW1hdGUuDQphbmQgaW4gc3VjaCBjYXNlLCBj b25zaWRlcmluZyBhbGlnbm1lbnQgcmVxdWlyZW1lbnQgaXMgZ29uZSwgaXQncyBhY3R1YWxseQ0K bGVzcyByZXN0cmljdGl2ZSwgd2hpbGUgc3RpbGwgcHJvdmlkaW5nIGJldHRlciBhdXRoZW50aWNh dGlvbi4gYW5kIGJsYWggYmxhaCwNCnUgY2FuIHNlZSB0aGUgYmVuZWZpdCwgaSdtIHN1cmUuDQoN CmFsc28sIGl0IHNob3VsZCBiZSBzdHJpY3QgQU5ELCBtZWFuaW5nLCBhbGwgZG1hcmMgbWVjaGFu aXNtIG11c3QgZXhpc3QgYW5kDQpwYXNzLCBmb3IgRE1BUkMgdG8gcGFzcywgbWFraW5nIHN1Y2gg RE1BUkMgZXZhbHVhdGlvbiBhbG1vc3QgYXMgcmVsaWFibGUgYXMNCmFsaWdubWVudC1iYXNlZCBv bmUsIGlmIG5vdCBtb3JlLCB3aGlsZSBzdGlsbCBlbmNvbXBhc3NpbmcgbXVjaCB3aWRlciByYW5n ZSBvZg0KZW1haWwgdXNhZ2UgY2FzZXMsIGluIHNpdHVhdGlvbiB3aGVyZSBpdCB3b3JrcyBiZXR0 ZXIgdGhhbiBhbGlnbm1lbnQtYmFzZWQgb25lLg0KDQphbHNvLCB0aGVyZSBtYXkgYmUgb3RoZXIg YWxnb3JpdGhtcyBpbiB0aGUgZnV0dXJlIHdoaWNoIHdpbGwgYmVjb21lIHBhcnQgb2YNCkRNQVJD LiBhbGxvd2luZyBkb21haW4gb3duZXJzIHRvIGhhdmUgY29udHJvbCBvZiBob3cgdGhlc2UgZ2V0 IGV2YWx1YXRlZCBpcw0KYSByaWdodCB0aGluZyB0byBkby4gbXkgcHJvcG9zYWwgaXMgZXZlbiBz dHJvbmdlciBpZiB1IGNvbnNpZGVyIHRoYXQgc29tZSBvZg0KdGhlc2UgYWxnb3JpdGhtcyBtYXkg Z2V0IGV4cGxvaXRlZCBpbiB0aGUgZnV0dXJlLCB3aGljaCB3b3VsZCBjb21wbGV0ZWx5DQphbm5p aGlsYXRlIE9SLWJhc2VkIERNQVJDLCB3aXRoIG5vIHJlbWVkeS4gaGF2aW5nIEFORC1iYXNlZCBv cHRpb24gd291bGQgZml4DQp0aGF0IGluIGFkdmFuY2UuDQoNCg0KPiBIb3cgd291bGQgaXQgaGVs cCB5b3VyIHVzZSBjYXNlLCBmb3IgZXhhbXBsZT8NCg0KaXQgd291bGQgZG8gd29uZGVycyBmb3Ig bWUuIG15IHBlcnNvbmFsIGVtYWlsIHN0cmVhbSB3b3VsZCBwYXNzIERNQVJDLg0KDQpETUFSQyBw b2xpY3kgInJlamVjdCIsIGFsaWdubWVudCBPRkYsIGxvZ2ljIEFORCwgcmVwb3J0aW5nIE9OIGFu ZCAiZm89ZDpzIg0Kd291bGQgYWN0dWFsbHkgZml4IG1hbnkgb2YgY3VzdG9tZXIgZG9tYWlucyB0 aGF0IGkgc2VydmljZSwgd2hpY2ggdXNlIGdvb2dsZQ0Kb3IgeWFob28gbWFpbCBmb3IgdGhlaXIg ZG9tYWluLWJhc2VkIGVtYWlsLiBjb25zaWRlcmluZyBib3RoIGdvb2dsZSBhbmQgeWFob28NCnVz ZSBES0lNIGFuZCBTUEYsIHRob3NlIGVtYWlscyB3b3VsZCBwYXNzIHN1Y2ggRE1BUkMsIGV2ZW4g dGhvdWdodCB0aGV5IGFyZQ0KYmVpbmcgc2VudCB0aHJvdWdoIDNyZCBwYXJ0eSBzZXJ2aWNlcy4g YW5kIGlmIERLSU0gYW5kIFNQRiBnZXQgc3VwcG9ydGVkIGJ5DQpvdGhlciBzZXJ2aWNlcywgaXQg d291bGQgY292ZXIgdGhlbSB0b28uDQoNCmFsc28sIG1ha2luZyBhbGlnbm1lbnQgYW5kIGxvZ2lj IHNlbGVjdGFibGUsIHdvdWxkIG5vdCBtYWtlIGFkZGl0aW9uYWwNCnByZXNzdXJlIG9uIGJpZyBF U1BzIGluZnJhc3RydWN0dXJlLCBidXQgaXQgd291bGQgY292ZXIgbXVjaCBvZiBmYWlsdXJlDQpj YXNlcyBjdXJyZW50IHZlcnNpb24gaGFzLg0KDQppdCBtYXkgZXZlbiBiZSB3b3J0aHdoaWxlIGZv ciBiaWcgRVNQcyB0byB1c2UgdGhpcyB0eXBlIG9mIERNQVJDIHBvbGljeToNCiJyZWplY3QiLCBh bGlnbm1lbnQgT0ZGLCBsb2dpYyBBTkQsIHJlcG9ydGluZyBPTi4gaXQgd291bGQgc3VyZWx5IG1h a2UNCnJlcG9ydHMgdGhleSByZWNlaXZlIG11Y2ggbW9yZSBpbmZvcm1hdGl2ZSB0b28sIGhlbHBp bmcgd2l0aCBkYXRhIG1pbmluZw0Kb24gb3RoZXIgZG9tYWluIHByYWN0aWNlcywgd2hpY2ggY291 bGQgYmUgdXNlZCBpbiBhbnRpLXNwYW0gZXRjLg0KDQphbmQgYW55IHBvdGVudGlhbCBhYnVzZSB3 b3VsZCBzaW1wbHkgYmUgZGVhbHQgd2l0aCBieSBzd2l0Y2hpbmcgdG8gYWxpZ25tZW50DQpPTiBw b2xpY3ksIHdoZW4gaXQncyByZXF1aXJlZCBmb3IgYSBwYXJ0aWN1bGFyIGRvbWFpbi4NCg0KDQo+ PiBpIGFscmVhZHkgbWVudGlvbmVkIGluY2x1ZGluZyBTUlMgaW4gY2hlY2sgbG9naWMuIHVuZm9y dHVuYXRlbHksIG5vIGRtYXJjDQo+PiBhdXRob3Igcmx5IGFkZGVkIG11Y2ggdG8gdGhlIHRvcGlj DQo+IEkgc2VlbSB0byByZW1lbWJlciB0aGVyZSB3YXMgaW4gZmFjdCBkaXNjdXNzaW9uIG9mIHlv dXIgU1JTIGFkdm9jYWN5Lg0KDQpub25lIHJseSB0YWtpbmcgdGhlIGRpc2N1c3Npb24gdG8gbmV4 dCBsdmwsIGJ1dCBtZXJlbHkgYWNrbm93bGVkZ2luZyBpDQptZW50aW9uZWQgU1JTLCBhbmQgZGlz bWlzc2luZyBpdCB3aXRob3V0IG11Y2ggYWRvLg0KDQphbHNvLCBpIGhhdmUgYW5vdGhlciBzdWdn ZXN0aW9uOg0KaW5jbHVkZSBzZW5kZXItaWQgYXMgYW5vdGhlciBETUFSQyBzdXBwb3J0ZWQgY2hl Y2sgYWxnb3JpdGhtLg0KDQpzZW5kZXItaWQgaXMgZGlmZmVyZW50IGVub3VnaCBmcm9tIFNQRiB0 byBjb3ZlciBtYW55IHVzYWdlIHNjZW5hcmlvcywNCmFuZCB3b3VsZCBqdXN0IGFkZCB0byBkbWFy YyBzdHJlbmd0aHMuIGkgZG9uJ3Qgcmx5IHVuZGVyc3RhbmQgd2h5IHBwbCB0YWtlDQpzZW5kZXIt aWQgZm9yIDJuZCBnZW5lcmF0aW9uIFNQRiwgc2luY2UgaXQgaXNuJ3QuDQoNCnllYWgsIGkgYmV0 dGVyIG5vdCBzdGFydCB0aGlzIHRvcGljLi4uIHdlIGRvbid0IHdhbnQgYW5vdGhlciBNQVJJRC4N Cg0KDQotLQ0KVmxhdGtvIFNhbGFqIGFrYSBnb29kb25lDQpodHRwOi8vZ29vZG9uZS50aw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1hcmMgbWFp bGluZyBsaXN0DQpkbWFyY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kbWFyYw0K --_000_9495B91F5CA0E24C9161D71CD46E43DB011C89D75F38MSGRTPCCRF2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRNTCBUaWR5IGZvciBX aW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+DQo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDA4LjAzLjAzMzAuMDAwIj4NCjx0aXRsZT5SZTogW2RtYXJjLWlldGZdIGFsaWdubWVudCBh bmQgcGFyc2luZyBsb2dpYyBhcyBvcHRpb25hbHM8L3RpdGxlPg0KPC9oZWFkPg0KPGJvZHk+DQpQ ZXJoYXBzIEknbSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IGVsaW1pbmF0aW5nIGFsaWdubWVudCBl c3NlbnRpYWxseSBudWxsaWZpZXMgdGhlIGF1dGhlbnRpY2F0aW9uIHZhbHVlIGZvciBhIGdpdmVu IGRvbWFpbi4gSWYsIGZvciBleGFtcGxlLCBJIGRpc2FibGUgYWxpZ25tZW50IHRoZW4gSSdtIGVz c2VudGlhbGx5IHNheWluZyB0aGF0IGFueW9uZSBjYW4gaGlqYWNrL3Nwb29mL21pc2FwcHJvcHJp YXRlIG15IGRvbWFpbiBhcyBsb25nIGFzIHRoZXkgaGF2ZSBhIHZhbGlkc3BmIHJlY29yZCBmb3Ig dGhlIHNlbmRpbmcgbXRhIG9yIERLSU0gc2lnbiB0aGVpciBtZXNzYWdlLjxicj4NCjxicj4NCkV4 YW1wbGUuIE15IGRvbWFpbiBpcyBsZWdpdGltYXRlbWFpbC5jb20uIEkgaGF2ZSBhIERNQVJDIHJl Y29yZCB0aGF0IGhhcyBzZXQgYWxpZ25tZW50IHRvIE9GRi48YnI+DQpTb21lb25lLCBlaXRoZXIg a25vd24gdG8gbWUgb3V0IG5vdCwgbm93IHNlbmRzIHVzaW5nIHRoZSBGUk9NIGFkZHJlc3Mgb2Yg bGVnaXRpbWF0ZW1haWwuY29tIGJ1dCBzaWducyB3aXRoIGQ9YmFkbWFpbC5jb20uIEl0IHNlZW1z IHdpdGggdGhlIHByb3Bvc2FsIGJlbG93IHRoYXQgd291bGQgInBhc3MiIERNQVJDIHByb2Nlc3Np bmcgYW5kIGJlIGRlbGl2ZXJlZCAob3IgYXQgbGVhc3Qgbm90IGdldCByZWplY3RlZCBkdWUgdG8g RE1BUkMpLiBJIGd1ZXNzIEkgZmFpbCB0byBzZWUgaG93IHRoaXMgd29ya3MgdG93YXJkcyByZWR1 Y2luZy9lbGltaW5hdGluZyBmcmF1ZHVsZW50IGVtYWlsLjxicj4NCjxicj4NCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+RnJvbTombmJzcDs8L2I+VmxhdGtvIFNhbGFqIFs8YSBo cmVmPSJtYWlsdG86dmxhdGtvLnNhbGFqQGdvb2RvbmUudGsiPnZsYXRrby5zYWxhakBnb29kb25l LnRrPC9hPl08YnI+DQo8Yj5TZW50OiZuYnNwOzwvYj5UaHVyc2RheSwgQXByaWwgMTcsIDIwMTQg MDE6NTAgQU0gRWFzdGVybiBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG86Jm5ic3A7PC9iPmRtYXJj QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDombmJzcDs8L2I+UmU6IFtkbWFyYy1pZXRmXSBhbGln bm1lbnQgYW5kIHBhcnNpbmcgbG9naWMgYXMgb3B0aW9uYWxzPGJyPg0KPGJyPg0KPCEtLSBDb252 ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCjxwPjxmb250IHNpemU9IjIiPk9uIFdl ZG5lc2RheSwgQXByaWwgMTYsIDIwMTQgMTE6MzkgUE0sIE11cnJheSBTLiBLdWNoZXJhd3kgd3Jv dGU6PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBJIHdvdWxkbid0IHRha2UgdGhlIGxhY2sgb2YgYW5z d2VycyB0ZXJyaWJseSBwZXJzb25hbGx5Ljxicj4NCjxicj4NCmkgcmx5IGRvbid0LiBpIGp1c3Qg Zm91bmQgaXQgcmx5IGxvbGFibGUgaG93IGV2ZXJ5Ym9keSBpcyB3aGluaW5nIGFib3V0PGJyPg0K aWV0ZidzIHB1cnBvc2UgaGVyZSwgd2hpbGUgbGlzdCdzIG1haW4gYWltIGlzIGFib3V0IHRlY2hu aWNhbCBjb250cmlidXRpb25zPGJyPg0KdG8gdGhlIGRtYXJjIHN0YW5kYXJkLCB3aGljaCBvZiwg aSBzYXcgbm9uZS48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7Jmd0OyBpbmNsdWRlIGFuIG9wdGlvbiBp biBkbWFyYyBkbnMgcG9saWN5LCBzbyB0aGF0IGRvbWFpbiBvd25lcnMgY291bGQgdHVybjxicj4N CiZndDsmZ3Q7IGRtYXJjIGFsaWdubWVudCBjaGVjayBvbi9vZmYuPGJyPg0KJmd0OyBPbmUgd2F5 IG9mIHZpZXdpbmcgRE1BUkMgaXMgdGhhdCBpdCBzZWVrcyB0byBhbGxvdyBhIGRvbWFpbiBvd25l ciB0byBoYXZlPGJyPg0KJmd0OyBiZXR0ZXIgY29udHJvbCBvZiBob3cgaXRzIGRvbWFpbiBpcyB1 c2VkLCBzbyBJIGRvbid0IGtub3cgd2hhdCB0aGlzIHdvdWxkPGJyPg0KJmd0OyBhY2NvbXBsaXNo LiBJZiBhbGlnbm1lbnQgaXMgb3B0aW9uYWwsIHdoYXQgZG9lcyBETUFSQyBkbyBwb2xpY3ktd2lz ZSB0aGF0PGJyPg0KJmd0OyBES0lNIGFuZCBTUEYgZG9uJ3QgYWxyZWFkeSBkbz88YnI+DQo8YnI+ DQpsZXQgbWUgYXNrIHU6IGhvdyBleGFjdGx5IHIgdSBhbGxvd2luZyBhIGRvbWFpbiBvd25lciB0 byBoYXZlIGJldHRlciBjb250cm9sPGJyPg0Kb2YgaG93IGl0cyBkb21haW4gaXMgdXNlZCwgd2hl biB1IGRvIG5vdCBhbGxvdyBpdCB0byBzYXk6IGkgZG8gbm90IHdhbnQ8YnI+DQphbGlnbm1lbnQ/ IGkgaW1hZ2luZSwgZG9tYWluIG93bmVycyBtYXkgYWN0dWFsbHkgcHJlZmVyIHRvIHNlbmQgdGhl aXIgZW1haWw8YnI+DQp0aHJvdWdoIDNyZCBwYXJ0eSBpbmZyYXN0cnVjdHVyZS4gRE1BUkMgaGFz IG5vIHByb3Zpc2lvbnMgZm9yIHN1Y2ggcHJhY3RpY2UuPGJyPg0KPGJyPg0KYW5kIGl0J3MgYSBj b21tb24gcHJhY3RpY2UsIGFic29sdXRlbHkuIHdoZXRoZXIgaXQncyBmb3JtYWwgb3IgaW5mb3Jt YWwuPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyZndDsgaW5jbHVkZSBhbiBvcHRpb24gaW4gZG1hcmMg ZG5zIHBvbGljeSwgc28gdGhhdCBkb21haW4gb3duZXJzIGNvdWxkIHR1cm48YnI+DQomZ3Q7Jmd0 OyBkbWFyYyBwcm9jZXNzaW5nIGxvZ2ljIGVpdGhlciB0byBPUiBvciBBTkQuPGJyPg0KJmd0OyBU aGF0IG1pZ2h0IGJlIHVzZWZ1bCwgYnV0IGlzbid0IHRoYXQgbW9yZSByZXN0cmljdGl2ZSwgYW5k IG5vdCBsZXNzPGJyPg0KJmd0OyByZXN0cmljdGl2ZT88YnI+DQo8YnI+DQphcyBpIHNhaWQ6IGNv bWJpbmVkLCBhbGlnbm1lbnQgT0ZGIGFuZCBBTkQgcHJvY2Vzc2luZyBsb2dpYyB3b3VsZCB3b3Jr IGdyZWF0PGJyPg0KaW4gY2FzZXMgd2hlcmUgYWxpZ25tZW50IGlzbid0IHBvc3NpYmxlLCB5ZXQg ZW1haWwgaXMgZnVsbHkgbGVnaXRpbWF0ZS48YnI+DQphbmQgaW4gc3VjaCBjYXNlLCBjb25zaWRl cmluZyBhbGlnbm1lbnQgcmVxdWlyZW1lbnQgaXMgZ29uZSwgaXQncyBhY3R1YWxseTxicj4NCmxl c3MgcmVzdHJpY3RpdmUsIHdoaWxlIHN0aWxsIHByb3ZpZGluZyBiZXR0ZXIgYXV0aGVudGljYXRp b24uIGFuZCBibGFoIGJsYWgsPGJyPg0KdSBjYW4gc2VlIHRoZSBiZW5lZml0LCBpJ20gc3VyZS48 YnI+DQo8YnI+DQphbHNvLCBpdCBzaG91bGQgYmUgc3RyaWN0IEFORCwgbWVhbmluZywgYWxsIGRt YXJjIG1lY2hhbmlzbSBtdXN0IGV4aXN0IGFuZDxicj4NCnBhc3MsIGZvciBETUFSQyB0byBwYXNz LCBtYWtpbmcgc3VjaCBETUFSQyBldmFsdWF0aW9uIGFsbW9zdCBhcyByZWxpYWJsZSBhczxicj4N CmFsaWdubWVudC1iYXNlZCBvbmUsIGlmIG5vdCBtb3JlLCB3aGlsZSBzdGlsbCBlbmNvbXBhc3Np bmcgbXVjaCB3aWRlciByYW5nZSBvZjxicj4NCmVtYWlsIHVzYWdlIGNhc2VzLCBpbiBzaXR1YXRp b24gd2hlcmUgaXQgd29ya3MgYmV0dGVyIHRoYW4gYWxpZ25tZW50LWJhc2VkIG9uZS48YnI+DQo8 YnI+DQphbHNvLCB0aGVyZSBtYXkgYmUgb3RoZXIgYWxnb3JpdGhtcyBpbiB0aGUgZnV0dXJlIHdo aWNoIHdpbGwgYmVjb21lIHBhcnQgb2Y8YnI+DQpETUFSQy4gYWxsb3dpbmcgZG9tYWluIG93bmVy cyB0byBoYXZlIGNvbnRyb2wgb2YgaG93IHRoZXNlIGdldCBldmFsdWF0ZWQgaXM8YnI+DQphIHJp Z2h0IHRoaW5nIHRvIGRvLiBteSBwcm9wb3NhbCBpcyBldmVuIHN0cm9uZ2VyIGlmIHUgY29uc2lk ZXIgdGhhdCBzb21lIG9mPGJyPg0KdGhlc2UgYWxnb3JpdGhtcyBtYXkgZ2V0IGV4cGxvaXRlZCBp biB0aGUgZnV0dXJlLCB3aGljaCB3b3VsZCBjb21wbGV0ZWx5PGJyPg0KYW5uaWhpbGF0ZSBPUi1i YXNlZCBETUFSQywgd2l0aCBubyByZW1lZHkuIGhhdmluZyBBTkQtYmFzZWQgb3B0aW9uIHdvdWxk IGZpeDxicj4NCnRoYXQgaW4gYWR2YW5jZS48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IEhvdyB3b3Vs ZCBpdCBoZWxwIHlvdXIgdXNlIGNhc2UsIGZvciBleGFtcGxlPzxicj4NCjxicj4NCml0IHdvdWxk IGRvIHdvbmRlcnMgZm9yIG1lLiBteSBwZXJzb25hbCBlbWFpbCBzdHJlYW0gd291bGQgcGFzcyBE TUFSQy48YnI+DQo8YnI+DQpETUFSQyBwb2xpY3kgInJlamVjdCIsIGFsaWdubWVudCBPRkYsIGxv Z2ljIEFORCwgcmVwb3J0aW5nIE9OIGFuZCAiZm89ZDpzIjxicj4NCndvdWxkIGFjdHVhbGx5IGZp eCBtYW55IG9mIGN1c3RvbWVyIGRvbWFpbnMgdGhhdCBpIHNlcnZpY2UsIHdoaWNoIHVzZSBnb29n bGU8YnI+DQpvciB5YWhvbyBtYWlsIGZvciB0aGVpciBkb21haW4tYmFzZWQgZW1haWwuIGNvbnNp ZGVyaW5nIGJvdGggZ29vZ2xlIGFuZCB5YWhvbzxicj4NCnVzZSBES0lNIGFuZCBTUEYsIHRob3Nl IGVtYWlscyB3b3VsZCBwYXNzIHN1Y2ggRE1BUkMsIGV2ZW4gdGhvdWdodCB0aGV5IGFyZTxicj4N CmJlaW5nIHNlbnQgdGhyb3VnaCAzcmQgcGFydHkgc2VydmljZXMuIGFuZCBpZiBES0lNIGFuZCBT UEYgZ2V0IHN1cHBvcnRlZCBieTxicj4NCm90aGVyIHNlcnZpY2VzLCBpdCB3b3VsZCBjb3ZlciB0 aGVtIHRvby48YnI+DQo8YnI+DQphbHNvLCBtYWtpbmcgYWxpZ25tZW50IGFuZCBsb2dpYyBzZWxl Y3RhYmxlLCB3b3VsZCBub3QgbWFrZSBhZGRpdGlvbmFsPGJyPg0KcHJlc3N1cmUgb24gYmlnIEVT UHMgaW5mcmFzdHJ1Y3R1cmUsIGJ1dCBpdCB3b3VsZCBjb3ZlciBtdWNoIG9mIGZhaWx1cmU8YnI+ DQpjYXNlcyBjdXJyZW50IHZlcnNpb24gaGFzLjxicj4NCjxicj4NCml0IG1heSBldmVuIGJlIHdv cnRod2hpbGUgZm9yIGJpZyBFU1BzIHRvIHVzZSB0aGlzIHR5cGUgb2YgRE1BUkMgcG9saWN5Ojxi cj4NCiJyZWplY3QiLCBhbGlnbm1lbnQgT0ZGLCBsb2dpYyBBTkQsIHJlcG9ydGluZyBPTi4gaXQg d291bGQgc3VyZWx5IG1ha2U8YnI+DQpyZXBvcnRzIHRoZXkgcmVjZWl2ZSBtdWNoIG1vcmUgaW5m b3JtYXRpdmUgdG9vLCBoZWxwaW5nIHdpdGggZGF0YSBtaW5pbmc8YnI+DQpvbiBvdGhlciBkb21h aW4gcHJhY3RpY2VzLCB3aGljaCBjb3VsZCBiZSB1c2VkIGluIGFudGktc3BhbSBldGMuPGJyPg0K PGJyPg0KYW5kIGFueSBwb3RlbnRpYWwgYWJ1c2Ugd291bGQgc2ltcGx5IGJlIGRlYWx0IHdpdGgg Ynkgc3dpdGNoaW5nIHRvIGFsaWdubWVudDxicj4NCk9OIHBvbGljeSwgd2hlbiBpdCdzIHJlcXVp cmVkIGZvciBhIHBhcnRpY3VsYXIgZG9tYWluLjxicj4NCjxicj4NCjxicj4NCiZndDsmZ3Q7IGkg YWxyZWFkeSBtZW50aW9uZWQgaW5jbHVkaW5nIFNSUyBpbiBjaGVjayBsb2dpYy4gdW5mb3J0dW5h dGVseSwgbm8gZG1hcmM8YnI+DQomZ3Q7Jmd0OyBhdXRob3Igcmx5IGFkZGVkIG11Y2ggdG8gdGhl IHRvcGljPGJyPg0KJmd0OyBJIHNlZW0gdG8gcmVtZW1iZXIgdGhlcmUgd2FzIGluIGZhY3QgZGlz Y3Vzc2lvbiBvZiB5b3VyIFNSUyBhZHZvY2FjeS48YnI+DQo8YnI+DQpub25lIHJseSB0YWtpbmcg dGhlIGRpc2N1c3Npb24gdG8gbmV4dCBsdmwsIGJ1dCBtZXJlbHkgYWNrbm93bGVkZ2luZyBpPGJy Pg0KbWVudGlvbmVkIFNSUywgYW5kIGRpc21pc3NpbmcgaXQgd2l0aG91dCBtdWNoIGFkby48YnI+ DQo8YnI+DQphbHNvLCBpIGhhdmUgYW5vdGhlciBzdWdnZXN0aW9uOjxicj4NCmluY2x1ZGUgc2Vu ZGVyLWlkIGFzIGFub3RoZXIgRE1BUkMgc3VwcG9ydGVkIGNoZWNrIGFsZ29yaXRobS48YnI+DQo8 YnI+DQpzZW5kZXItaWQgaXMgZGlmZmVyZW50IGVub3VnaCBmcm9tIFNQRiB0byBjb3ZlciBtYW55 IHVzYWdlIHNjZW5hcmlvcyw8YnI+DQphbmQgd291bGQganVzdCBhZGQgdG8gZG1hcmMgc3RyZW5n dGhzLiBpIGRvbid0IHJseSB1bmRlcnN0YW5kIHdoeSBwcGwgdGFrZTxicj4NCnNlbmRlci1pZCBm b3IgMm5kIGdlbmVyYXRpb24gU1BGLCBzaW5jZSBpdCBpc24ndC48YnI+DQo8YnI+DQp5ZWFoLCBp IGJldHRlciBub3Qgc3RhcnQgdGhpcyB0b3BpYy4uLiB3ZSBkb24ndCB3YW50IGFub3RoZXIgTUFS SUQuPGJyPg0KPGJyPg0KPGJyPg0KLS08YnI+DQpWbGF0a28gU2FsYWogYWthIGdvb2RvbmU8YnI+ DQo8YSBocmVmPSJodHRwOi8vZ29vZG9uZS50ayI+aHR0cDovL2dvb2RvbmUudGs8L2E+PGJyPg0K PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpkbWFyYyBtYWlsaW5nIGxpc3Q8YnI+DQpkbWFyY0BpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmM8L2E+PGJyPjwvZm9udD48L3A+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_9495B91F5CA0E24C9161D71CD46E43DB011C89D75F38MSGRTPCCRF2_-- From nobody Thu Apr 17 06: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 067281A014E for ; Thu, 17 Apr 2014 06:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 pFPmcK__0RBp for ; Thu, 17 Apr 2014 06:58:00 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 93F971A013C for ; Thu, 17 Apr 2014 06:58:00 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id i11so478022oag.34 for ; Thu, 17 Apr 2014 06:57:56 -0700 (PDT) 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:content-type; bh=M7I4ALfNGuuCSlRibsUEnrKwl6qdFODP/CpajuoIb0Q=; b=fJimwjar12X2U2OMvc/xsvjb/YsIQvTqlzh3A59J1w+9ub5uGXgVy+NzQM0JRbOLc2 S+Ri9vFb9IQDv5t9LU2vCWpikS+GSL+WNFUWmsIzLO7obKjEtDahHVfwpCxok23RJIjq ybkU2RgLNc2sNFIGgsJW8XjMSwdfA4DVJzMB2mrT7MZHtS/o0ntffn1DFLQNMJZnVjFE xqybuwEC/Xspy/W2LLwbFbO0hqioB4/L4g9FN0dQPgsmMNHf6UK5OJMkoGp6GvDppnpt 0GvX2S15PnJjUw2xx1pKDyoFoAE6/BfQvi8CJiaglU3jGauIvdrrIyd/A8fMrCKBjENk NDew== X-Gm-Message-State: ALoCoQkhL0SQRPbzJ+gyySbWVSJ2+8SxiwpGPFwRCtQQZqhPHC55DABcSPPK1J13gMQE7aJQ/fUc MIME-Version: 1.0 X-Received: by 10.60.39.131 with SMTP id p3mr7503749oek.44.1397743076630; Thu, 17 Apr 2014 06:57:56 -0700 (PDT) Received: by 10.60.119.35 with HTTP; Thu, 17 Apr 2014 06:57:56 -0700 (PDT) In-Reply-To: <9495B91F5CA0E24C9161D71CD46E43DB011C89D75F38@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C89D75F38@MSGRTPCCRF2WIN.DMN1.FMR.COM> Date: Thu, 17 Apr 2014 09:57:56 -0400 Message-ID: From: Joseph Humphreys To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=089e0149cc3091f55e04f73d6bf0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LFgk4wOdK9ZNieOcIeopjm0hOKg Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 13:58:07 -0000 --089e0149cc3091f55e04f73d6bf0 Content-Type: text/plain; charset=UTF-8 At one time I suggested adding a feature to list domains that could be considered "in alignment" with yours. So if a domain owner wanted to authorize an email service provider, they could just add something to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or DKIM signing. I am still curious what's wrong with this proposal. It seems to me to cover Vlatko Salaj's use case, and would certainly be easier to implement than arranging to share a DKIM key. Regards, Joe Humphreys On Thu, Apr 17, 2014 at 7:42 AM, Popowycz, Alex wrote: > Perhaps I'm missing something, but eliminating alignment essentially > nullifies the authentication value for a given domain. If, for example, I > disable alignment then I'm essentially saying that anyone can > hijack/spoof/misappropriate my domain as long as they have a validspf > record for the sending mta or DKIM sign their message. > > Example. My domain is legitimatemail.com. I have a DMARC record that has > set alignment to OFF. > Someone, either known to me out not, now sends using the FROM address of > legitimatemail.com but signs with d=badmail.com. It seems with the > proposal below that would "pass" DMARC processing and be delivered (or at > least not get rejected due to DMARC). I guess I fail to see how this works > towards reducing/eliminating fraudulent email. > > -----Original Message----- > *From: *Vlatko Salaj [vlatko.salaj@goodone.tk] > *Sent: *Thursday, April 17, 2014 01:50 AM Eastern Standard Time > *To: *dmarc@ietf.org > *Subject: *Re: [dmarc-ietf] alignment and parsing logic as optionals > > On Wednesday, April 16, 2014 11:39 PM, Murray S. Kucherawy wrote: > > > > I wouldn't take the lack of answers terribly personally. > > i rly don't. i just found it rly lolable how everybody is whining about > ietf's purpose here, while list's main aim is about technical contributions > to the dmarc standard, which of, i saw none. > > > >> include an option in dmarc dns policy, so that domain owners could turn > >> dmarc alignment check on/off. > > One way of viewing DMARC is that it seeks to allow a domain owner to have > > better control of how its domain is used, so I don't know what this would > > accomplish. If alignment is optional, what does DMARC do policy-wise that > > DKIM and SPF don't already do? > > let me ask u: how exactly r u allowing a domain owner to have better > control > of how its domain is used, when u do not allow it to say: i do not want > alignment? i imagine, domain owners may actually prefer to send their email > through 3rd party infrastructure. DMARC has no provisions for such > practice. > > and it's a common practice, absolutely. whether it's formal or informal. > > > >> include an option in dmarc dns policy, so that domain owners could turn > >> dmarc processing logic either to OR or AND. > > That might be useful, but isn't that more restrictive, and not less > > restrictive? > > as i said: combined, alignment OFF and AND processing logic would work > great > in cases where alignment isn't possible, yet email is fully legitimate. > and in such case, considering alignment requirement is gone, it's actually > less restrictive, while still providing better authentication. and blah > blah, > u can see the benefit, i'm sure. > > also, it should be strict AND, meaning, all dmarc mechanism must exist and > pass, for DMARC to pass, making such DMARC evaluation almost as reliable as > alignment-based one, if not more, while still encompassing much wider > range of > email usage cases, in situation where it works better than alignment-based > one. > > also, there may be other algorithms in the future which will become part of > DMARC. allowing domain owners to have control of how these get evaluated is > a right thing to do. my proposal is even stronger if u consider that some > of > these algorithms may get exploited in the future, which would completely > annihilate OR-based DMARC, with no remedy. having AND-based option would > fix > that in advance. > > > > How would it help your use case, for example? > > it would do wonders for me. my personal email stream would pass DMARC. > > DMARC policy "reject", alignment OFF, logic AND, reporting ON and "fo=d:s" > would actually fix many of customer domains that i service, which use > google > or yahoo mail for their domain-based email. considering both google and > yahoo > use DKIM and SPF, those emails would pass such DMARC, even thought they are > being sent through 3rd party services. and if DKIM and SPF get supported by > other services, it would cover them too. > > also, making alignment and logic selectable, would not make additional > pressure on big ESPs infrastructure, but it would cover much of failure > cases current version has. > > it may even be worthwhile for big ESPs to use this type of DMARC policy: > "reject", alignment OFF, logic AND, reporting ON. it would surely make > reports they receive much more informative too, helping with data mining > on other domain practices, which could be used in anti-spam etc. > > and any potential abuse would simply be dealt with by switching to > alignment > ON policy, when it's required for a particular domain. > > > >> i already mentioned including SRS in check logic. unfortunately, no > dmarc > >> author rly added much to the topic > > I seem to remember there was in fact discussion of your SRS advocacy. > > none rly taking the discussion to next lvl, but merely acknowledging i > mentioned SRS, and dismissing it without much ado. > > also, i have another suggestion: > include sender-id as another DMARC supported check algorithm. > > sender-id is different enough from SPF to cover many usage scenarios, > and would just add to dmarc strengths. i don't rly understand why ppl take > sender-id for 2nd generation SPF, since it isn't. > > yeah, i better not start this topic... we don't want another MARID. > > > -- > Vlatko Salaj aka goodone > http://goodone.tk > > _______________________________________________ > 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 > > --089e0149cc3091f55e04f73d6bf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At one time I suggested adding a feature to list domains t= hat could be considered "in alignment" with yours. So if a domain= owner wanted to authorize an email service provider, they could just add s= omething to their DMARC policy to specify the domain the ESP uses for SPF/M= ailFrom and/or DKIM signing. I am still curious what's wrong with this = proposal. It seems to me to cover Vlatko Salaj's use case, and would ce= rtainly be easier to implement than arranging to share a DKIM key.

Regards,
Joe Humphreys


On Thu, Apr 17, 2014 at 7:42 = AM, Popowycz, Alex <Alex.Popowycz@fmr.com> wrote:
Perhaps I'm missing something, but eliminating alignment essentially nu= llifies the authentication value for a given domain. If, for example, I dis= able alignment then I'm essentially saying that anyone can hijack/spoof= /misappropriate my domain as long as they have a validspf record for the se= nding mta or DKIM sign their message.

Example. My domain is legitimatemail.com. I have a DMARC record that has set alignment to = OFF.
Someone, either known to me out not, now sends using the FROM address of legitimatemail.com but signs with d=3Dbadma= il.com. It seems with the proposal below that would "pass" DM= ARC processing and be delivered (or at least not get rejected due to DMARC)= . I guess I fail to see how this works towards reducing/eliminating fraudul= ent email.

-----Original Message-----
From:=C2=A0Vlatko Salaj [vlatko.salaj@goodone.tk]
Sent:=C2=A0Thursday, April 17, 2014 01:50 AM Eastern Standard Time To:=C2=A0dmarc@i= etf.org
Subject:=C2=A0Re: [dmarc-ietf] alignment and parsing logic as option= als

On Wednesday, April 16, 2014 11:39 PM, Murray S. Kucherawy wrote:<= br>

> I wouldn't take the lack of answers terribly personally.

i rly don't. i just found it rly lolable how everybody is whining about=
ietf's purpose here, while list's main aim is about technical contr= ibutions
to the dmarc standard, which of, i saw none.


>> include an option in dmarc dns policy, so that domain owners could= turn
>> dmarc alignment check on/off.
> One way of viewing DMARC is that it seeks to allow a domain owner to h= ave
> better control of how its domain is used, so I don't know what thi= s would
> accomplish. If alignment is optional, what does DMARC do policy-wise t= hat
> DKIM and SPF don't already do?

let me ask u: how exactly r u allowing a domain owner to have better contro= l
of how its domain is used, when u do not allow it to say: i do not want
alignment? i imagine, domain owners may actually prefer to send their email=
through 3rd party infrastructure. DMARC has no provisions for such practice= .

and it's a common practice, absolutely. whether it's formal or info= rmal.


>> include an option in dmarc dns policy, so that domain owners could= turn
>> dmarc processing logic either to OR or AND.
> That might be useful, but isn't that more restrictive, and not les= s
> restrictive?

as i said: combined, alignment OFF and AND processing logic would work grea= t
in cases where alignment isn't possible, yet email is fully legitimate.=
and in such case, considering alignment requirement is gone, it's actua= lly
less restrictive, while still providing better authentication. and blah bla= h,
u can see the benefit, i'm sure.

also, it should be strict AND, meaning, all dmarc mechanism must exist and<= br> pass, for DMARC to pass, making such DMARC evaluation almost as reliable as=
alignment-based one, if not more, while still encompassing much wider range= of
email usage cases, in situation where it works better than alignment-based = one.

also, there may be other algorithms in the future which will become part of=
DMARC. allowing domain owners to have control of how these get evaluated is=
a right thing to do. my proposal is even stronger if u consider that some o= f
these algorithms may get exploited in the future, which would completely annihilate OR-based DMARC, with no remedy. having AND-based option would fi= x
that in advance.


> How would it help your use case, for example?

it would do wonders for me. my personal email stream would pass DMARC.

DMARC policy "reject", alignment OFF, logic AND, reporting ON and= "fo=3Dd:s"
would actually fix many of customer domains that i service, which use googl= e
or yahoo mail for their domain-based email. considering both google and yah= oo
use DKIM and SPF, those emails would pass such DMARC, even thought they are=
being sent through 3rd party services. and if DKIM and SPF get supported by=
other services, it would cover them too.

also, making alignment and logic selectable, would not make additional
pressure on big ESPs infrastructure, but it would cover much of failure
cases current version has.

it may even be worthwhile for big ESPs to use this type of DMARC policy: "reject", alignment OFF, logic AND, reporting ON. it would surely= make
reports they receive much more informative too, helping with data mining on other domain practices, which could be used in anti-spam etc.

and any potential abuse would simply be dealt with by switching to alignmen= t
ON policy, when it's required for a particular domain.


>> i already mentioned including SRS in check logic. unfortunately, n= o dmarc
>> author rly added much to the topic
> I seem to remember there was in fact discussion of your SRS advocacy.<= br>
none rly taking the discussion to next lvl, but merely acknowledging i
mentioned SRS, and dismissing it without much ado.

also, i have another suggestion:
include sender-id as another DMARC supported check algorithm.

sender-id is different enough from SPF to cover many usage scenarios,
and would just add to dmarc strengths. i don't rly understand why ppl t= ake
sender-id for 2nd generation SPF, since it isn't.

yeah, i better not start this topic... we don't want another MARID.


--
Vlatko Salaj aka goodone
http://goodone.tk

_______________________________________________
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


--089e0149cc3091f55e04f73d6bf0-- From nobody Thu Apr 17 07:51: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 2B3481A0215 for ; Thu, 17 Apr 2014 07:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 sOE2X8bkBkXK for ; Thu, 17 Apr 2014 07:51:20 -0700 (PDT) Received: from nm1-vm10.bullet.mail.gq1.yahoo.com (nm1-vm10.bullet.mail.gq1.yahoo.com [98.136.218.89]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1FC1A020E for ; Thu, 17 Apr 2014 07:51:20 -0700 (PDT) Received: from [98.137.12.60] by nm1.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 14:51:16 -0000 Received: from [216.39.60.212] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 14:51:16 -0000 Received: from [127.0.0.1] by omp1099.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 14:51:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 510566.75290.bm@omp1099.mail.gq1.yahoo.com Received: (qmail 51465 invoked by uid 60001); 17 Apr 2014 14:51:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397746276; bh=6mna24hBMRkRnSoiPMVURE7jOWTeY7K81GqIMS0QLUE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=yCXGHkt2e0RjdaK3LykuET1fEqtAVNLd8D+TZtinWVbNUtv3YdhKlmEFebTKfrdS0Xtt5Y3ox8NtjBMgh+wwayUtvwKeb5K6rPM3R3hN+0Eqcj4R86tro8egq0LBx4OmMGT6PkGFXvh6I6BvAAQ6o3EYZ+PtIOaZPDN343oUJRs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KEuB4SujECLwrje3mjtFundTAbJjzYwpuIuq+qNvrvZlkbNjrxg/Y0kmOdtIn/ssibgLGr5vL52wmvA6Gy0QzxtqYQF1GB3rLW1yLcZ0V91kgt9DGd6myMds7a+YysqpAARCC6KnyyV1Crt3k7zctwaYohtzfzjVq0AfAo55y5c=; X-YMail-OSG: bruXy6wVM1m50uvgQwKmHwUNPwiIPJ_FibNTLJ8WMiZDP0x U7CBEKoOFF5uzzj5kyol8yFv011PdNv.GvT6Ong4CGw0x7vZ4g2v5Tdb1WcV 7BzhAgCGR.nz5FnIoB6lsbdD_YPjWGoXOE1yH6S.iXCpxsHKOCSVQiKcIolb M5pw.5hR39jyErc52hMjRfZXgHM_7rWZplQwVV1jEWca5WpTFlM0WY0dn3DI HpgjYNDh_MPsPtMCtsvwPVyazIyDMcxW8gHxSxG4d_P4bYTOfuZ4_eQdZpcy cK6hi5KpTgEtfyaVEGak5c6rgSS1A9B.Kx2he0miLkI_5vPU4LHHarL0lMTb 21oPe2P2VQ1Snrf.0MFE8Xy3HOiWRKPbStqug_8Qi_Icw.1FuAEhpH2gobmA lZJT21gmJhSdQ.K6GDj02M9YJoxmh.YZYPVDn_nQC08ffwh8De0LmBEjAWjJ JDMx9dS._NmtVvrN6UXdYp7JqoZ8aurjvdvWcNc_j66BT7YInm3UuYAOXJq8 C2ixUGKR09ZR8QNj62EnV2qRROeF8oZVs1ztFLqGaZMKVzIWdGIkeltdCKYS 4m7uGMT8SV22j1H9CSmQ7FjIRtVBxbHFgyBFGtrwq1WGO1FjG Received: from [109.121.36.90] by web164605.mail.gq1.yahoo.com via HTTP; Thu, 17 Apr 2014 07:51:16 PDT X-Rocket-MIMEInfo: 002.001, T24gVGh1cnNkYXksIEFwcmlsIDE3LCAyMDE0IDg6MjIgQU0sIE11cnJheSBTLiBLdWNoZXJhd3kgd3JvdGU6Cgo.IEZvciB0aGUgImFuZCIgY2FzZSwgeWVzLCB0aGF0J3MgcG9zc2libGUgdG8gYWRkIGlmIHRoZXJlJ3MgZW5vdWdoIGRlbWFuZAo.IHRvIGFkZCBpdC4gU28gZmFyIHRoZSBwZW9wbGUgdGhhdCBoYXZlIHRyaWVkIHRoaXMgYXJlIHNhdGlzZmllZCB3aXRoIHRoZQo.ICJvciIgbG9naWMuCgptYWtpbmcgRE1BUkMgc3RyaWN0bHkgYmFzZWQgb24gT1ItbG9naWMgd2lsbCBnZXQgaXQgb2Jzb2xldGUBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> Message-ID: <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Thu, 17 Apr 2014 07:51:16 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MYoIXXozURAb8CGTlZ0kKwJdXRo Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 14:51:22 -0000 On Thursday, April 17, 2014 8:22 AM, Murray S. Kucherawy wrote: > For the "and" case, yes, that's possible to add if there's enough demand > to add it. So far the people that have tried this are satisfied with the > "or" logic. making DMARC strictly based on OR-logic will get it obsolete as soon as someone finds a way to exploit any of the underlying mechanism, and that's already possible, either through DKIM replay attack, or through spoofed SPF authentication, whichever serves an attacker better. and if DMARC gets expanded by any additional mechanism, it will just make it weaker, with OR-dependency. > "I do not want alignment" is exactly the same as "I don't use DMARC" > since DMARC is pretty much all about alignment. So, again, I don't > understand why that's a useful thing to add. it's not the same. DMARC is not just authentication, it's also about reporting and conformance. i would be perfectly happy to get my email checked against SPF and DKIM and processed in a standard-defined way, and receive reports on which i can then act. otherwise, DMARC has no benefits for me at all. >> and it's a common practice, absolutely. whether it's formal or informal. > What's an example? i've already written about it. someone using yahoo or google email service to send their own domain email. i actually do that. and i imagine, a great deal of ppl. it also covers various 3rd party services, such as ones that deliver greeting cards, process petitions... >> as i said: combined, alignment OFF and AND processing logic would work great >> in cases where alignment isn't possible, yet email is fully legitimate. > For the "off" case, isn't that just the same as "p=none"? it isn't. if we accept the idea about making alignment optional, i would gladly expand the idea to more than just turning alignment on/off. actually, such alignment field would, in my proposal, include a three-state: 1. alignment ON, in which case from: header gets checked against. 2. alignment OFF, in which case domain owner specifies they have no benefit from DMARC alignment checks, but do want other checks performed, such as AND-logic mechanism evaluation, for example. 3. alignment domain-list value to include in alignment check: list of domains the domain owner wants to have included in DMARC alignment check, complementing from: header domain; this will cover almost all cases DMARC breaks now, such as 3rd party infrastructure, mailing lists that do not wish to make changes for DMARC-compatibility, forwarders that process their mail, but can't be controlled by domain owner, etc. it's somewhat similar to SPF domain definition, but different, since it affects DMARC-alignment process. > That probably means the benefit of adding SRS support wasn't obvious to > the people responding. This may be obvious to you, but it's apparently > not obvious to others. SRS has benefits. but not for big ESPs, mainly cause of infrastructure requirements. so, i'm done with advocating for that, cause it won't get supported by the most influential actors here, that's obvious. >> include sender-id as another DMARC supported check algorithm. >> yeah, i better not start this topic... we don't want another MARID. > I totally agree there, especially since Sender-ID got almost no adoption > (see RFC 6686), and that seems unlikely to change now. it would change quite fast if we would make it part of DMARC. actually, Sender-ID isn't all that bad at all. it was way ahead of its time. PRA could actually be a better way to determine owner's domain for alignment purposes than some undefined public-suffix list, especially in the light of newest moves by ICANN, introducing bunch of new top-lvl domains, which will probably host a bunch of sub-domains with registration capabilities by 3rd parties, etc. DMARC's dependance on a concept of "public-suffix list" is a can of worms i can't wait to see what will make of DMARC's usability at the end. it will be a mess for sure. i'm not rly sure how this isn't obvious to DMARC's authors, given all that experience in the domain. On Thursday, April 17, 2014 1:42 PM, "Popowycz, Alex" wrote: > Perhaps I'm missing something, but eliminating alignment essentially > nullifies the authentication value for a given domain. which, in some cases, has no value at all. as i mentioned up, alignment-OFF works well only with other options i'm proposing, and only in special cases. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Thu Apr 17 08:42: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 56CAD1A023F for ; Thu, 17 Apr 2014 08:42:16 -0700 (PDT) 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_00=-1.9, J_CHICKENPOX_14=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 qp4ft_rXOthG for ; Thu, 17 Apr 2014 08:42:12 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0E55C1A021A for ; Thu, 17 Apr 2014 08:42:04 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Thu, 17 Apr 2014 11:42:00 -0400 From: "MH Michael Hammer (5304)" To: Vlatko Salaj , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] alignment and parsing logic as optionals Thread-Index: AQHPWgD3My+VDjty10+auE80fMGkZZsVmd2AgACOJwD//8PvEA== Date: Thu, 17 Apr 2014 15:41:59 +0000 Message-ID: References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> In-Reply-To: <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.221] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean 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/C_PZtChEcfz5IX3vRDpWfPeKJyI Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:42:16 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Vlatko Salaj > Sent: Thursday, April 17, 2014 10:51 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals >=20 > On Thursday, April 17, 2014 8:22 AM, Murray S. Kucherawy wrote: >=20 > > For the "and" case, yes, that's possible to add if there's enough > > demand to add it. So far the people that have tried this are satisfied > > with the "or" logic. >=20 > making DMARC strictly based on OR-logic will get it obsolete as soon as > someone finds a way to exploit any of the underlying mechanism, and that'= s > already possible, either through DKIM replay attack, or through spoofed S= PF > authentication, whichever serves an attacker better. >=20 There isn't much that someone can do with a DKIM replay attack in a DMARC c= ontext because the entire body and key headers are signed. For spoofed SPF = authentication, the answer is DNSSEC. If DNSSEC is broken/exploited then th= e community will have larger issues than DMARC. > and if DMARC gets expanded by any additional mechanism, it will just make= it > weaker, with OR-dependency. This may or may not be true. It depends on the specific additional mechanis= m. >=20 >=20 > > "I do not want alignment" is exactly the same as "I don't use DMARC" > > since DMARC is pretty much all about alignment. So, again, I don't > > understand why that's a useful thing to add. >=20 > it's not the same. DMARC is not just authentication, it's also about repo= rting > and conformance. i would be perfectly happy to get my email checked > against SPF and DKIM and processed in a standard-defined way, and receive > reports on which i can then act. otherwise, DMARC has no benefits for me = at > all. >=20 Then just publish p=3Dnone. You get your email checked and you get your rep= orts. The discussion is about those domain owners that are seeking a higher= level of protection. >=20 > >> and it's a common practice, absolutely. whether it's formal or informa= l. > > What's an example? >=20 > i've already written about it. someone using yahoo or google email servic= e to > send their own domain email. i actually do that. and i imagine, a great d= eal of > ppl. >=20 > it also covers various 3rd party services, such as ones that deliver gree= ting > cards, process petitions... > Don't drag greeting cards into this fight. We've sent billions of greeting = card notifications on behalf of our customers in a DMARC conformant way (an= d as I've pointed out, even before DMARC was a gleam in anyone's eye) witho= ut any problems whatsoever. Other greeting card companies have followed our= lead in publishing SPF and DKIM signing but I'm not in a position to comme= nt on their specific implementations and configurations. Third party servic= es such as greeting cards are actually a much different use case than maili= ng lists.=20 >=20 > >> as i said: combined, alignment OFF and AND processing logic would > >> work great in cases where alignment isn't possible, yet email is fully > legitimate. > > For the "off" case, isn't that just the same as "p=3Dnone"? >=20 > it isn't. if we accept the idea about making alignment optional, i would = gladly > expand the idea to more than just turning alignment on/off. >=20 >=20 > actually, such alignment field would, in my proposal, include a three-sta= te: >=20 > 1. alignment ON, in which case from: header gets checked against. >=20 > 2. alignment OFF, in which case domain owner specifies they have no benef= it > from DMARC alignment checks, but do want other checks performed, such > as AND-logic mechanism evaluation, for example. >=20 If I were evil I could consistently defeat this every day of the weak witho= ut much effort. This was the same problem with PRA and the use of Sender. W= hen I first pointed this out to Microsoft (this is not intended to pick on = them) back in the 2006 timeframe, they told me it was my implementation tha= t was the problem. When I sent them crafted emails showing that I could con= sistently get a neutral under PRA checking for ANY From domain (abusing the= sender field) they agreed that this was a problem. > 3. alignment domain-list value to include in alignment check: list of dom= ains > the domain owner wants to have included in DMARC alignment check, > complementing > from: header domain; this will cover almost all cases DMARC breaks now, > such as 3rd party infrastructure, mailing lists that do not wish to make > changes for DMARC-compatibility, forwarders that process their mail, but > can't be controlled by domain owner, etc. it's somewhat similar to SPF > domain definition, but different, since it affects DMARC-alignment proces= s. >=20 This doesn't scale. How many domains would a large mailbox provider have to= include in the list to account for all domains subscribed to by their user= s? How short would the TTL have to be in order to work for newly subscribed= to domains? Where would this list live? The DNS folks would freak even if = the list weren't too long to be put in a DNS record. >=20 > > That probably means the benefit of adding SRS support wasn't obvious > > to the people responding. This may be obvious to you, but it's > > apparently not obvious to others. >=20 > SRS has benefits. but not for big ESPs, mainly cause of infrastructure > requirements. so, i'm done with advocating for that, cause it won't get > supported by the most influential actors here, that's obvious. >=20 >=20 > >> include sender-id as another DMARC supported check algorithm. > >> yeah, i better not start this topic... we don't want another MARID. > > I totally agree there, especially since Sender-ID got almost no > > adoption (see RFC 6686), and that seems unlikely to change now. >=20 > it would change quite fast if we would make it part of DMARC. >=20 > actually, Sender-ID isn't all that bad at all. it was way ahead of its ti= me. >=20 > PRA could actually be a better way to determine owner's domain for > alignment purposes than some undefined public-suffix list, especially in = the > light of newest moves by ICANN, introducing bunch of new top-lvl domains, > which will probably host a bunch of sub-domains with registration capabil= ities > by 3rd parties, etc. >=20 As I indicated above, PRA had a serious flaw that allowed it to be gamed. M= icrosoft dropped support for Sender-ID in favor of SPF. Is it worth spendin= g time on something which is basically deprecated/historic? > DMARC's dependance on a concept of "public-suffix list" is a can of worms= i > can't wait to see what will make of DMARC's usability at the end. it will= be a > mess for sure. i'm not rly sure how this isn't obvious to DMARC's authors= , > given all that experience in the domain. >=20 The public-suffix issue is a known one that impacts things other than DMARC= . There are proposals on how to address this issue but I have to admit to p= ersonally not following them or their progress - only so many cycles in the= day. Could you identify any specific instances where public-suffix has bee= n a significant (or non-significant) problem in the wild?=20 >=20 > On Thursday, April 17, 2014 1:42 PM, "Popowycz, Alex" wrote: >=20 > > Perhaps I'm missing something, but eliminating alignment essentially > > nullifies the authentication value for a given domain. >=20 > which, in some cases, has no value at all. as i mentioned up, alignment-O= FF > works well only with other options i'm proposing, and only in special cas= es. >=20 >=20 > -- > Vlatko Salaj aka goodone > http://goodone.tk >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Apr 17 08:51: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 84F6E1A021A for ; Thu, 17 Apr 2014 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 hW8uvevxj1_3 for ; Thu, 17 Apr 2014 08:51:06 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA0D1A013F for ; Thu, 17 Apr 2014 08:51:06 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wp4so642552obc.7 for ; Thu, 17 Apr 2014 08:51:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=w62GSyCEeFhcbGeKHDgKh2JrXJRx2fSRUsrRLVAPI7Y=; b=AKqMNC6g/PzrlOoQwhBd0rsRm5F1prb7osYxuYBA3phZdRox6QtNmiCdIuNA5oaLes a548q1uSzv1C1wSSafrJUMFnUQTY3IUud1iJwQEp9xYSFQVZTxTztMvXWnxA2T4A+BNp 3LAsjph83py3hSQHo6JtRyoV3L9nhfidQ7v1ufCeSR/TGDcUpVBW4kB+VigV7bHqFdX4 R1qTqUDa1DB+OhI1nBWcRdGVtmDCcOvD5WZrucDwJcueP4uqif5ieKtHp6EVY5VY/45r HgImHzKPYSseb1fuHEIsF85eJnsAxZ3oAJ0Byx8BE5THTo6tcocPWexl9B/B8xlIh/Nh 3Zcg== X-Gm-Message-State: ALoCoQnfESDq1W5ZmfRUFmrqOseoXZH12QY0utCo/902J+bLo19F7CQMDV6UI8b3RkbIJcn2WTjP MIME-Version: 1.0 X-Received: by 10.60.140.201 with SMTP id ri9mr1195450oeb.74.1397749862353; Thu, 17 Apr 2014 08:51:02 -0700 (PDT) Received: by 10.60.119.35 with HTTP; Thu, 17 Apr 2014 08:51:02 -0700 (PDT) Date: Thu, 17 Apr 2014 11:51:02 -0400 Message-ID: From: Joseph Humphreys To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7b4727dc07e43404f73f004e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lmTHNX_szpe2ayheyRq4eyGOVGk Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:51:10 -0000 --047d7b4727dc07e43404f73f004e Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 11:41 AM, MH Michael Hammer (5304) wrote: > > > 3. alignment domain-list value to include in alignment check: list of > domains > > the domain owner wants to have included in DMARC alignment check, > > complementing > > from: header domain; this will cover almost all cases DMARC breaks now, > > such as 3rd party infrastructure, mailing lists that do not wish to make > > changes for DMARC-compatibility, forwarders that process their mail, but > > can't be controlled by domain owner, etc. it's somewhat similar to SPF > > domain definition, but different, since it affects DMARC-alignment > process. > > > > This doesn't scale. How many domains would a large mailbox provider have > to include in the list to account for all domains subscribed to by their > users? How short would the TTL have to be in order to work for newly > subscribed to domains? Where would this list live? The DNS folks would > freak even if the list weren't too long to be put in a DNS record. > > It doesn't scale as a complete solution for mailing lists. I don't see any scaling problem for the case of a domain used by a single entity that wants to authorize a few service providers to send email on its behalf. --047d7b4727dc07e43404f73f004e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Apr 17, 2014 at 11:41 A= M, MH Michael Hammer (5304) <MHammer@ag.com> wrote:

> 3. alignment domain-list value to i= nclude in alignment check: list of domains
> the domain owner wants to have included in DMARC alignment check,
> complementing
> from: header domain; this will cover almost all cases DMARC breaks now= ,
> such as 3rd party infrastructure, mailing lists that do not wish to ma= ke
> changes for DMARC-compatibility, forwarders that process their mail, b= ut
> can't be controlled by domain owner, etc. it's somewhat simila= r to SPF
> domain definition, but different, since it affects DMARC-alignment pro= cess.
>

This doesn't scale. How many domains would a large mailbox provider hav= e to include in the list to account for all domains subscribed to by their = users? How short would the TTL have to be in order to work for newly subscr= ibed to domains? Where would this list live? The DNS folks would freak even= if the list weren't too long to be put in a DNS record.


It doesn't scale as a complete sol= ution for mailing lists. I don't see any scaling problem for the case o= f a domain used by a single entity that wants to authorize a few service pr= oviders to send email on its behalf. =C2=A0

--047d7b4727dc07e43404f73f004e-- From nobody Thu Apr 17 08:58: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 389C11A011C for ; Thu, 17 Apr 2014 08:57:54 -0700 (PDT) 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_21=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 RiPqWCyoh8C8 for ; Thu, 17 Apr 2014 08:57:50 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) by ietfa.amsl.com (Postfix) with ESMTP id 6518F1A012E for ; Thu, 17 Apr 2014 08:57:50 -0700 (PDT) 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.0.934.4; Thu, 17 Apr 2014 15:43:07 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.169]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.169]) with mapi id 15.00.0934.000; Thu, 17 Apr 2014 15:43:06 +0000 From: Terry Zink To: Franck Martin , Barry Leiba Thread-Topic: DMARC's purpose Thread-Index: AQHPWZYAisnH7aYbpUeoHtfnUTJjKZsV8+lw Date: Thu, 17 Apr 2014 15:43:06 +0000 Message-ID: <7b7364ba764c454790f3c12849727701@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <534699BA.9010602@melix.net> <5346BD0F.8030600@bluepopcorn.net> <6.2.5.6.2.20140412013413.0ba16da8@resistor.net> <534931B1.4010407@meetinghouse.net> <5349537A.8000604@gmail.com> <610289312.88482.1397667890896.JavaMail.zimbra@peachymango.org> In-Reply-To: <610289312.88482.1397667890896.JavaMail.zimbra@peachymango.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [174.31.185.248] x-exchange-organization-antispam-internal: BULK:None; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(13464003)(189002)(199002)(377454003)(33646001)(81342001)(76786001)(76796001)(81542001)(77096001)(69226001)(87936001)(50986002)(99396002)(85306002)(46102001)(93136001)(95416001)(98676001)(94946001)(94316002)(93886001)(93516002)(54316003)(54356002)(53806002)(47446003)(49866002)(63696004)(65816002)(59766002)(47736002)(51856002)(56816006)(56776002)(47976003)(95666003)(97336001)(97186001)(4396001)(15975445006)(83072002)(20776003)(81816001)(81686001)(19580395003)(80976001)(79102001)(92566001)(74706001)(87266001)(74876001)(76482001)(77982001)(74366001)(66066001)(19580405001)(90146001)(2656002)(80022001)(31966008)(83322001)(74502001)(85852003)(74662001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; 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/q-_EEoXXhF9N2kKxEah-t0inn6o Cc: Dave Crocker , "dmarc@ietf.org" , Murray Kucherawy Subject: Re: [dmarc-ietf] DMARC's purpose X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 15:57:55 -0000 > Should we also document in this Murray's draft that MS-Exchange breaks=20 > DKIM on forwarding, inventory all the operational cases? 1. If a message is sent via Exchange with a 3rd party DKIM signer, then DKI= M will not be broken if the next Exchange hop forwards. 2. Messages will be preserved with DKIM in a future release of Exchange, we= use it internally and it works. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Franck Martin Sent: Wednesday, April 16, 2014 10:05 AM To: Barry Leiba Cc: Dave Crocker; dmarc@ietf.org; Murray Kucherawy Subject: Re: [dmarc-ietf] DMARC's purpose ----- Original Message ----- > From: "Barry Leiba" > To: "Dave Crocker" , "Murray Kucherawy"=20 > > Cc: dmarc@ietf.org > Sent: Wednesday, April 16, 2014 9:53:15 AM > Subject: Re: [dmarc-ietf] DMARC's purpose >=20 > > 2. The spec is clear about how it works and what the implications are. > > The > > issue with mailing lists is well-documented. >=20 > aI'm not sure that any issue with mailing lists is documented in=20 > draft-kucherawy-dmarc-base at all, well or otherwise. A search for=20 > "mailing list" (or even "mailing") shows hits in three places, all in=20 > back matter, none of substance. >=20 > There's nothing that I can see anywhere that warns of possible=20 > consequences (neither considerations for the domain publishing the=20 > policy nor discussion of collateral damage to mailing lists) of using=20 > "p=3Dreject" -- not in the explanation of "p=3Dreject", not in Section 6= =20 > ("Policy Enforcement Considerations"), not in Section 15.4 ("Rejecting=20 > Messages"), not in the Security Considerations. >=20 > Where is is well documented? >=20 In the upcoming BCP Should we also document in this Murray's draft that MS-Exchange breaks DKIM= on forwarding, inventory all the operational cases? I don't think so. The = draft is to describe the protocol, the BCP is here to document on how to op= erationally deploy and use it. The reviews if I recall suggested to limit the draft to the protocol bits s= trictly. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Apr 17 09:36: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 BB0C31A019C for ; Thu, 17 Apr 2014 09:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 D-uIg0sRqaoW for ; Thu, 17 Apr 2014 09:36:03 -0700 (PDT) Received: from nm5.bullet.mail.gq1.yahoo.com (nm5.bullet.mail.gq1.yahoo.com [98.136.218.70]) by ietfa.amsl.com (Postfix) with ESMTP id 485561A0180 for ; Thu, 17 Apr 2014 09:36:03 -0700 (PDT) Received: from [216.39.60.184] by nm5.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 16:35:59 -0000 Received: from [216.39.60.214] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 16:35:59 -0000 Received: from [127.0.0.1] by omp1101.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 16:35:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 675977.31211.bm@omp1101.mail.gq1.yahoo.com Received: (qmail 34540 invoked by uid 60001); 17 Apr 2014 16:35:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397752559; bh=mKxqDvNsHq5HiL52cuUJ5VR+btoMbDgPU2+6WcZU9AA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=CmhV8kt2cziUMOoLoOPJpp9AmHmk9gQnylizm6mxhE2aZotsmbd5njygMl6y+pV0CUUwn8YK4v8A/tPuz0VUI3Z87yFdG8+PHKNTuLTAjTuiTl3oPn16TsYI7eHtdWNj8wRKMdzmZTJ67M+p5IHxA1+PRaQnRwzPilqJzH/jS48= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NYKCxm4LXs5i+4kHtqR1MKPdYXokYPjeE4zzxRic/srpluRTL9nI/qEMsrM9XLlPkhGE4lw7E5xn//KpT5gcp0z9P5HiAkJQG36rHDoJ5skguj64jECiV0Ha/fc37/BhMC+YGLzO2J2r1O90RW7Fp51anlbruxQNSQDlvdPypHk=; X-YMail-OSG: 7QonGacVM1mWElu9PDAnIAlfbsG3qeDRyWKMPpUhKzkpKu0 .dRTw8y6u_eCRWoYs4.u5wkq4OQsSSrBmg.t.bVefY1C7inaoK9uKH0OxbKe LlCUoNdG6RDIaVrTIpUNp4zpsqI.Ptwkl4eyUDPWI2dYKV0bklqL6kavkZ1w 5LVY1P84kneJMIpGmrY_.lvIPtp.F_3n.OurmxRYcE0gCxmdJ2oI.KKC0WY1 wQ60GnIII0Wik3qn8UuRrn5HUutvEklku9Ssv7RrAAz5crMmiXqCiYliQM8Q RiqCy7neFjrB2de2wbDtoGyMO8ix1G8u7MwcOXJl9ggVaHS7l3vADAUJG3mo eqKXhy2R5yn8uMSl9_Jnt8MJzkVjBEA58Iv8l4fTUJjOnJ45rpjmwTBptFR0 aXIuiqoXO7l_T4TgeZrjHwYoK42NVSkzeslNzl0RodbRYgIPK4mZbnigfrds xMOGfj6eB4jrbhZJex1K8RC_3PLtD8cK_BJ4jfFiqtIWNku.xodII_BX8djq VItahUymr.vvCSjIGDYPNPlofwnVcB.CbapDOQ6KhacDlTxRXlenM_iZP8Bf dU_.1H5_yK6Mia9fHSuug_8pJrDbR2xdB6iAYnPK2uoDv8nH3Dh25MK0NCzP j4WQk2284Lf8NJ2k- Received: from [109.121.36.90] by web164604.mail.gq1.yahoo.com via HTTP; Thu, 17 Apr 2014 09:35:59 PDT X-Rocket-MIMEInfo: 002.001, T24gVGh1cnNkYXksIEFwcmlsIDE3LCAyMDE0IDU6NDQgUE0sIEpvc2VwaCBIdW1waHJleXMgd3JvdGU6Cgo.IEF0IG9uZSB0aW1lIEkgc3VnZ2VzdGVkIGFkZGluZyBhIGZlYXR1cmUgdG8gbGlzdCBkb21haW5zIHRoYXQgY291bGQKPiBiZSBjb25zaWRlcmVkICJpbiBhbGlnbm1lbnQiIHdpdGggeW91cnMuIFNvIGlmIGEgZG9tYWluIG93bmVyIHdhbnRlZAo.IHRvIGF1dGhvcml6ZSBhbiBlbWFpbCBzZXJ2aWNlIHByb3ZpZGVyLCB0aGV5IGNvdWxkIGp1c3QgYWRkIHNvbWV0aGluZwo.IHRvIHRoZWlyIERNQVIBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> Message-ID: <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Thu, 17 Apr 2014 09:35:59 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MNCAlgyMzKA5ca9DBX75qrU6oig Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:36:04 -0000 On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrote: > At one time I suggested adding a feature to list domains that could > be considered "in alignment" with yours. So if a domain owner wanted > to authorize an email service provider, they could just add something > to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom > and/or DKIM signing. I am still curious what's wrong with this proposal. > It seems to me to cover Vlatko Salaj's use case, and would certainly be > easier to implement than arranging to share a DKIM key. finally, somebody that sees things from perspective other than a big sender. also, plz notice, working with DKIM 3rd party support is not only pretty messy, but usually not a supported option. so, DMARC badly needs its own solution for this alignment problem. On Thursday, April 17, 2014 5:42 PM, MH Michael Hammer (5304) wrote: > Third party services such as greeting cards are actually a much different > use case than mailing lists. if, and only if, it's built in DMARC-compatible way. and this isn't all that natural or intuitive. it seems DMARC wants to change everything to have it compatible with itself. i can understand how this benefits big players. it's just pity big players don't understand how this doesn't work for small players, aka 90% of the net. >> 2. alignment OFF, in which case domain owner specifies they have no benefit >> from DMARC alignment checks, but do want other checks performed, such >> as AND-logic mechanism evaluation, for example. > If I were evil I could consistently defeat this every day of the week > without much effort. domain owner publishing alignment-OFF policy wants such policy. who cares if anyone can beat it? it's their decision and they r ready to suffer consequences for whatever reason. at least they have an option. maybe they just want to process SPF and DKIM in a standard way, as defined by DMARC. without DMARC "reject" rule, they lose that. >> 3. alignment domain-list value to include in alignment check: list of domains >> the domain owner wants to have included in DMARC alignment check, >> complementing from: header domain > This doesn't scale. it scales the same way it scales for SPF. i see no problem there. also, scaling isn't rly an issue for big ESP. they will just use alignment-ON and force everyone to adapt. just like yahoo did recently. alignment domain-list is of great value to small domains. i'm quite sure this would be one of the most used tags in DMARC policy, if included in spec. >> actually, Sender-ID isn't all that bad at all. it was way ahead of its time. > Microsoft dropped support for Sender-ID in favor of SPF. merely cause it's not widely adopted. not because it's completely broken. > When I sent them crafted emails showing that I could consistently get > a neutral under PRA checking for ANY From domain (abusing the sender field) > they agreed that this was a problem. neutral result isn't a pass, under current DMARC evaluation rules. so, it's not the same situation as with plain Sender-ID check. > Could you identify any specific instances where public-suffix has been > a significant (or non-significant) problem in the wild? yes, i can. almost any new free domain service will have issues with this, until such public-suffix picks it up... which is yet another nightmare of infrastructure support. as i said, we r opening a can of worms here, especially where ICANN is moving with top-lvl domains. i saw it happening with Symantec's SafeWeb as well as all other URL checking services developed in recent years. it's a mess and needs high maintenance. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Thu Apr 17 09:49: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 BB1C71A0252 for ; Thu, 17 Apr 2014 09:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 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_NEUTRAL=0.779] 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 GZ22iwbwH7BG for ; Thu, 17 Apr 2014 09:49:50 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC74D1A0132 for ; Thu, 17 Apr 2014 09:49:49 -0700 (PDT) Received: (qmail 26665 invoked from network); 17 Apr 2014 16:49:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:mime-version:subject:references:in-reply-to:content-type:content-transfer-encoding:user-agent; s=6827.53500629.k1404; i=johnl-iecc.com@submit.iecc.com; bh=3nlyOaUf6GWHhAKLPQ+sUpfbOsNQeZHy0bhOy9J7Pm4=; b=aWgpx8J9M1Hk3aiNR9xgOA8Yc14M5ErAOvFJZDXybvrTV8utqn15EX6SUOxKIg0RjZpnt1tyB5yGw2mXV3rLnJWUIWPCA870i56d57melboM2qxjJXTN8CxZJ8Wr+srhZhu+6wZULBb4XXN+qGKPGGOrLme3okj4PnMhEaEsyAjCEO2221usSKXyVJp1HJUOYHwNkcDEtFYAi6vXdCUukG5fLCjmlFGU9cmwKRYyz6byyk/Wm47gVkTVwAB4IhOn DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:mime-version:subject:references:in-reply-to:content-type:content-transfer-encoding:user-agent; s=6827.53500629.k1404; olt=johnl-iecc.com@submit.iecc.com; bh=3nlyOaUf6GWHhAKLPQ+sUpfbOsNQeZHy0bhOy9J7Pm4=; b=zhx8Bl5Zn/HafebO9gtr9keFyfpyNuL7B1SVeS8DXbFCIiltjGTPyzLyTriguhFhTbpVuY/psRlFzCEiqvX/XZw5szqeMG7H8d6DPQQYsfDyJSJ6UupSNkpBr5dhDCAuZH3b+P38mRyiAAsRF+OT/xCLgFO4+SgmCSY6y/7dp7dEtOv2b7LAnwKOi3jCeaXybnmb4ACSqLMng5j9YaupDksLAcOWPhXvgMLX1YaiPhBr4OAmZtmf1sRthMDWKiNi Received: from jlevine.local ([216.146.45.247]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 17 Apr 2014 16:49:45 -0000 Date: 17 Apr 2014 12:49:39 -0400 Message-ID: <53500623.6090807@taugh.com> From: "John Levine" To: dmarc@ietf.org User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <534FFBDA.8040600@iecc.com> In-Reply-To: <534FFBDA.8040600@iecc.com> X-Forwarded-Message-Id: <534FFBDA.8040600@iecc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/s54KsVErhIlJUt034ewmU9dhniw Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:49:54 -0000 > > 3. alignment domain-list value to include in alignment check: > > > It doesn't scale as a complete solution for mailing lists. I don't see > any scaling problem for the case of a domain used by a single entity > that wants to authorize a few service providers to send email on its > behalf. Is that really a problem? I was under the impression that a sender either adds the providers' IPs to their SPF record, or gives them a DKIM signing key. This seems quite different from the mailing list problem, where it's unlikely that it is practical to track exactly which lists its users subscribe to. R's, John From nobody Thu Apr 17 09:53:03 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 498261A0194 for ; Thu, 17 Apr 2014 09:52:58 -0700 (PDT) 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 pjDZh7o80gWj for ; Thu, 17 Apr 2014 09:52:54 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1276C1A0180 for ; Thu, 17 Apr 2014 09:52:53 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ib6so809570vcb.27 for ; Thu, 17 Apr 2014 09:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=8ysDSM3KxFMwGrhd2um+VU5iwb2TiHaY8ioNTEkIlJs=; b=TlEwC/4XBZiTMcfatxuUFMrwuX0I/uMWTrcCVi9xjmtVHDxc1D/DJV4gcvU0F6Mvw0 1rHv6U+W5Y6LgLqXXjwXw/jvu8q25cjETo/39FJPHylrepOQ3TDcBc5jYLlmAfBBcac2 z8ndA0ulRvIQ2QuUebceXwPMal1xOhvBtVQSo= 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:content-type; bh=8ysDSM3KxFMwGrhd2um+VU5iwb2TiHaY8ioNTEkIlJs=; b=IjLd4idYVpc7LXsseaVi6lLKDbgjOz5j7IHZcRGyg+86pA0eRK3oIjaxwOP6x8glsr BWtv7aVVjqK6a0wTkciVA27+Ni2LdivWQ4c75HXq3VrsdxEfREjjeP2ahYIaKKWW4KIr 1WIQwP4PKlVS5TFlN9Eo78005eRn5eE42ArdEY5HdVEd0BovqI+VQ0rZMNNKAyd/UhhN 3mBzOgAgEt7xsju8gXaamZjeo+Pmutnj+Zwnv1dOzQTQNYC9i33LO1MLAGXvcM/SSJj0 kd9uSPtzcnQyBnq2dmGrzbnJA2fFl8vnVtf2JmVkQvm4NWxssUaTy7SbS6KhpqRjLC2A 6OSA== X-Gm-Message-State: ALoCoQn6oiRlcN8BESONmJTHvgC2enl77nVoA+b2qYaG9TvxWNeoPRix03Up0PztA4oT8GmBZJ3y X-Received: by 10.221.27.8 with SMTP id ro8mr2241834vcb.30.1397753570252; Thu, 17 Apr 2014 09:52:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.183.197 with HTTP; Thu, 17 Apr 2014 09:52:30 -0700 (PDT) X-Originating-IP: [50.1.80.118] In-Reply-To: <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> From: John Sweet Date: Thu, 17 Apr 2014 09:52:30 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11336baa0a213704f73fdd0f Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NcwXDoG-J2rXgN8WYnTEqJpHOu0 Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 16:52:58 -0000 --001a11336baa0a213704f73fdd0f Content-Type: text/plain; charset=ISO-8859-1 On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrote: > At one time I suggested adding a feature to list domains that could be > considered "in alignment" with yours. So if a domain owner wanted to > authorize an email service provider, they could just add something to their > DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or > DKIM signing. I am still curious what's wrong with this proposal. > How is this not covered by SPF "include:"? If your message has both MAILFROM and RFC822 From: aligned on your domain, and the connecting IP is in the range of the included domain, it's all good. J --001a11336baa0a213704f73fdd0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrot= e:
At one time I suggested adding a feature to list domains that could be cons= idered "in alignment" with yours. So if a domain owner wanted to = authorize an email service provider, they could just add something to their= DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or DK= IM signing. I am still curious what's wrong with this proposal.
=A0
How is this not covered by SPF "inclu= de:"?

If your message has both= MAILFROM and RFC822 From: aligned on your domain, and the connecting IP is= in the range of the included domain, it's all good.

J
=
--001a11336baa0a213704f73fdd0f-- From nobody Thu Apr 17 10:01:41 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 7A4C01A02F2 for ; Thu, 17 Apr 2014 10:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 CdeheskQR7tA for ; Thu, 17 Apr 2014 10:01:35 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id DE9C81A00DD for ; Thu, 17 Apr 2014 10:01:34 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so741461oag.14 for ; Thu, 17 Apr 2014 10:01:31 -0700 (PDT) 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:content-type; bh=dqhu+PPHbboAGUV2IrOg0IDCr7qJ+/vZgxzdSNQYYTM=; b=JvaZgSiIYipELyuXpItreHGMOZ8LMOVw8z4MdI0e/2Vf6BmCuiPZwYBoJCOJzBcNRQ ihFfRb8qaLIdv2XclhT8PkNpuDC4qRW8JmKhbCZLLyBGEFNHs47lH2kvKSjqLaKFZQ/c nJaRdJJg0tCe5bAPCcLca9Wnu26zWKXna/2RX4OKDAaQ0jxmLFgNqnD2URGnS27xgKwp kKoSIljgKHybA86pf16amJ9pytV9Bezj+IcU5R3OepLa8QP1oL+DDgl5gFDL1kCJzhiQ oFYXiE0AD9ObS1K39iHfxrHfWW8ZPEztMpEIwHfRrFpy9y1CQXvjlW2zj4Hs00ygxHoe jeFg== X-Gm-Message-State: ALoCoQnVgSNz6/ZyCiGlRmCVCWz0DNydBejO7SRaEorhY6T3atcFqTZ6aghu2EisyeH8OUBQX3LV MIME-Version: 1.0 X-Received: by 10.182.205.135 with SMTP id lg7mr8250277obc.32.1397754091202; Thu, 17 Apr 2014 10:01:31 -0700 (PDT) Received: by 10.60.119.35 with HTTP; Thu, 17 Apr 2014 10:01:31 -0700 (PDT) In-Reply-To: <53500623.6090807@taugh.com> References: <534FFBDA.8040600@iecc.com> <53500623.6090807@taugh.com> Date: Thu, 17 Apr 2014 13:01:31 -0400 Message-ID: From: Joseph Humphreys To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lTGOQ6lHVNLMHj9dCq6QUSR4apU Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 17:01:39 -0000 On Thu, Apr 17, 2014 at 12:49 PM, John Levine wrote: >> > 3. alignment domain-list value to include in alignment check: >> >> >> It doesn't scale as a complete solution for mailing lists. I don't see >> any scaling problem for the case of a domain used by a single entity >> that wants to authorize a few service providers to send email on its >> behalf. > > > Is that really a problem? I was under the impression that a sender > either adds the providers' IPs to their SPF record, or gives them a DKIM > signing key. > > This seems quite different from the mailing list problem, where it's > unlikely that it is practical to track exactly which lists its users > subscribe to. It's a problem if the service provider wants to offer bounce processing by using their own domain for the return path, which I think is not uncommon. That puts SPF out of alignment. Sharing a DKIM key is a solution, but is not trivial. The alignment domain-list solution seems trivial to me, and it works without active support from the sender, which is nice. Regards, Joe Humphreys From nobody Thu Apr 17 10:18: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 9540F1A014B for ; Thu, 17 Apr 2014 10:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 3oe7hhkI3m7V for ; Thu, 17 Apr 2014 10:18:42 -0700 (PDT) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4C38C1A00FE for ; Thu, 17 Apr 2014 10:18:42 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id wn1so759532obc.23 for ; Thu, 17 Apr 2014 10:18:38 -0700 (PDT) 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:content-type; bh=KbzMy9KsbTyRwg7/6q/XvqQnU3DVoq4kEOr7w0Jwzvw=; b=Yx7v2bj6IuoUQ8bmgG+2RPlb2laJCtD1Ge1Jx5cJTGLHM1E/g4ALUh9+P8igknqTi9 JjFvG8GTBvSfdk7HKbag+hKSpe3qmZfLtawp7WaFlQC/M+fyivyef0FAvKaFpVjFwwSX vVL4BTghCG4m8Hfo1jotI6c9LZcwWG4s+aM84usTXdZKTc6FpS5IpPBacL8fbDNS/MPa jIw7t/CSYEW1d90R69jxZIiWIo5/wOOYZxHZg+MFKNKGRcZVULbpblCgzGSpGxZQKvyz WQxBbDdWU2JZmEd9eBubIhjwf1HeYEKcAoUEVdQxogUtognuss5X5tTuGHbydiOlYP2j p4Bg== X-Gm-Message-State: ALoCoQklLF3SOwgtFzl+If6SzqhMxAE7Q3mdXpu0TBKAJAVquf1aSdEYeBdlMZhdrKiUOjme3nsJ MIME-Version: 1.0 X-Received: by 10.60.74.195 with SMTP id w3mr12894410oev.28.1397755118511; Thu, 17 Apr 2014 10:18:38 -0700 (PDT) Received: by 10.60.119.35 with HTTP; Thu, 17 Apr 2014 10:18:38 -0700 (PDT) In-Reply-To: References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Thu, 17 Apr 2014 13:18:38 -0400 Message-ID: From: Joseph Humphreys To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mYxvWF0NqBE2OVojsp2HVlFOr_8 Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 17:18:46 -0000 On Thu, Apr 17, 2014 at 12:52 PM, John Sweet wrote: > On Thursday, April 17, 2014 5:44 PM, Joseph Humphreys wrote: >> >> At one time I suggested adding a feature to list domains that could be >> considered "in alignment" with yours. So if a domain owner wanted to >> authorize an email service provider, they could just add something to their >> DMARC policy to specify the domain the ESP uses for SPF/MailFrom and/or DKIM >> signing. I am still curious what's wrong with this proposal. > > > How is this not covered by SPF "include:"? > > If your message has both MAILFROM and RFC822 From: aligned on your domain, > and the connecting IP is in the range of the included domain, it's all good. > I just replied to a similar question from John Levine, that I'm trying to support a use case where SPF will not be in alignment: a third-party sender that wants to handle bounces on behalf of the author. Vlatko Salaj also brought up the case of using gmail to send mail with a From header in your own domain. (Gmail seems to use your gmail address as the MAILFROM address.) Just to generalize the point: requiring alignment for the purpose of using SPF to authenticate the From header has the unintended (I think) consequence of restricting the Return-Path to the same domain. An aligned-domain list would not have this consequence. Regards, Joe Humphreys From nobody Thu Apr 17 10:24: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 24F121A0242 for ; Thu, 17 Apr 2014 10:24:37 -0700 (PDT) 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 zuSdEvVSmNCy for ; Thu, 17 Apr 2014 10:24:32 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B33011A01B3 for ; Thu, 17 Apr 2014 10:24:32 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hu19so838871vcb.29 for ; Thu, 17 Apr 2014 10:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=zxumniZaNK7MDD4+EprHBTE1+7imF/sg8v1KAWmRw70=; b=loys7V0BrUYp7Z1+XCsYS4kAobjDby5T0/bTKOQPRrz4U/1Cm3Bstg11K21R3s3ng2 OoKmWERnWaKt05bze7SzSt1lflrXy9tP4tjc+YMY6buoQwNzLHrTa9VUBAhqXolfHZqK e940cXKHb7VUnnW9EcWTwC92enabxRQuKQ+ec= 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:content-type; bh=zxumniZaNK7MDD4+EprHBTE1+7imF/sg8v1KAWmRw70=; b=H9FINePmZFbsPSuzCQixW8skiCxKCVc6w7uczXrb+3dJwtJ477Jrq6iiRFSnMjEdcr belb9nQ4lTuLkC8a3kuV+EENmtjamnRPVjCf7zWFxj/WbUemuq43nEKmkK+isySObN6C KqRZ7dQgpAducYWWcCTIYjEsp6rCM6dlbFSrydtQ84iIziGEvLD3+PGFCJH8y9JM7LNM gs/YPky9exaX7g42ge/oWXkcZG6i/bhcJZ+MJhBaCR31VoDNBerWACFis/yoK71KGlD/ oLnZ8ooQO9HH0iy5ZFsvox4Jj+78GM21YePjP22sdRevrs3BreAB0iu5Qaor+4xyVx3O qHCA== X-Gm-Message-State: ALoCoQn0cojDn8x/rMmTtwPz3K1TXQMPwVvhbpdE85gRoAfqS4onRxPXDAkxk0ZvIcOw75NG3LU2 X-Received: by 10.52.37.196 with SMTP id a4mr2452887vdk.33.1397755468805; Thu, 17 Apr 2014 10:24:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.183.197 with HTTP; Thu, 17 Apr 2014 10:24:08 -0700 (PDT) X-Originating-IP: [50.1.80.118] In-Reply-To: References: <534FFBDA.8040600@iecc.com> <53500623.6090807@taugh.com> From: John Sweet Date: Thu, 17 Apr 2014 10:24:08 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=bcaec51a8b8633926b04f7404ef9 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Zj1_tmE0lnogUPBf-LM66T_3W58 Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 17:24:37 -0000 --bcaec51a8b8633926b04f7404ef9 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 17, 2014 at 10:01 AM, Joseph Humphreys < jhumphreys@salesforce.com> wrote: > It's a problem if the service provider wants to offer bounce processing by > using their own domain for the return path, which I think is not uncommon. > That puts SPF out of alignment. > I think the difference is that the sender's domain can include the ISP's ranges in their own SPF record. You can't reasonably do that for every domain of every mailing list your users may post to. The ISP rewrites the MAIL FROM to deflect bounces. This passes SPF (IP matches MAIL FROM), and also passes DMARC's aligned SPF (RFC822 From has the original sender domain, which includes the ISP's IP range). Please tell me what I'm missing. J --bcaec51a8b8633926b04f7404ef9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 17, 2014 at 10:01 AM, Joseph Humphreys <jhumphreys@salesforce.com> wrote:
It's a problem if the se= rvice provider wants to offer bounce processing by using their own domain f= or the return path, which I think is not uncommon. That puts SPF out of ali= gnment.

I think the difference is that the s= ender's domain can include the ISP's ranges in their own SPF record= . You can't reasonably do that for every domain of every mailing list y= our users may post to.

The ISP rewrites the MAIL FROM to deflect bounces.=A0 This p= asses SPF (IP matches MAIL FROM), and also passes DMARC's aligned SPF (= RFC822 From has the original sender domain, which includes the ISP's IP= range).

Please tell me what I'm missing.

J
=

--bcaec51a8b8633926b04f7404ef9-- From nobody Thu Apr 17 10:32: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 35CC31A0066 for ; Thu, 17 Apr 2014 10:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.571 X-Spam-Level: X-Spam-Status: No, score=-1.571 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 CvR6ruLHgxQW for ; Thu, 17 Apr 2014 10:32:45 -0700 (PDT) Received: from nm30-vm6.bullet.mail.gq1.yahoo.com (nm30-vm6.bullet.mail.gq1.yahoo.com [98.136.216.197]) by ietfa.amsl.com (Postfix) with ESMTP id E14811A0056 for ; Thu, 17 Apr 2014 10:32:44 -0700 (PDT) Received: from [98.137.12.191] by nm30.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 17:32:41 -0000 Received: from [98.137.12.245] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 17:32:41 -0000 Received: from [127.0.0.1] by omp1053.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 17:32:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 393649.29139.bm@omp1053.mail.gq1.yahoo.com Received: (qmail 99715 invoked by uid 60001); 17 Apr 2014 17:32:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397755961; bh=vDJ3Mr9ogbXfgUvpkRP2p+Gj99deouVnylCpA2uroZA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=4HNoIN6+EvWZcbHl+urEg5slAb+S3r7R0wUEcI4AhpUqfCYyRTvOlK3eDgACqe3EHga3kTO4pYlJnRlr4RnuO2bQpxuplC70AG9Zik3lRPjKiRTOxg9m4cM9i2TQXqs+nHmGRRyrR/jj8nzOufcV5pB/Qbt2AKfNjOGf1AS5D+Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=lUeGOmIkxCCWx/43t+ejCa/pPGA8sELEaQeYXbwm7aCx+bYmqTx6Oav+8Xt7Nk8VaYHSKw60mHEzjr0HKguNeiZLfFGmpI6dkaHxHtyG4FIKrxKD0AVVnwqKgswuk0Y8J2N84wNDKgbfP19LIvs4vMgnwLnrV3OKC1tYGR6ikJQ=; X-YMail-OSG: S430rOsVM1lAsXZ4_vrue0cqF7qmZxtAqeQrGrg_rAgt2aV LHNf25pJ5A_Uwsjcf5AAmQNvrbD42.JLrdTfZGFX0ruxE.AI9Y86l8ERsnZY MZWSXSSd7a8uW7UqdejR1oZvFGpAXxWlUdL_P871ZfFjsCCqzoT76lHoehK8 97DzPUxq_KjK.6sUHPDDSM6gzu5A4Oo.dJhHMFnfTEApOPEe.joNMz9k3ME. Za7jEiWoC6BkAnsFpoNlqPgF0_Ch8ceZTiNhcLWoA.BLj61PLlawdkql24RE D5_5iN73BObFtRO_pnM3cWEhIQsEp2HKWF2dkMmq9z1pE6f41QouFLQVH45d L2EV78ZDPkUhLG4SH1TMT4yuW8Bjh360q5JZWk0s5qgqHTxPWr10h3ACzccJ RHPv0DwOkRAW8y4OI4BjwXfC3BoGZRf3lQwK9V94S7YwM3IP5Mv0j1_N9IDE EbpPO6VsNUTWuvZWkTbBD_Rs.H0B21kCUtZ8lIdOJOcsfw6KSA.9QWv8q9VN nMmoVWCYVRCsN_krq2t849XNk2EzSX3MlLSqkSPg9twVQzRM8tb_J0pa0R.0 HeI.k6vSSuLV0_3IiAnix71TLvHVQe5sGfBHPtnIR9bFt6qdRRIGEJIgQCoQ dIf5m2ZTR.YSVOsjW5rG73G0- Received: from [109.121.36.90] by web164605.mail.gq1.yahoo.com via HTTP; Thu, 17 Apr 2014 10:32:41 PDT X-Rocket-MIMEInfo: 002.001, T24gVGh1cnNkYXksIEFwcmlsIDE3LCAyMDE0IDY6NTMgUE0sIEpvaG4gTGV2aW5lIHdyb3RlOgoKPj4gSSBkb24ndCBzZWUgYW55IHNjYWxpbmcgcHJvYmxlbSBmb3IgdGhlIGNhc2Ugb2YgYSBkb21haW4gdXNlZCBieSBhIHNpbmdsZQo.PiBlbnRpdHkgdGhhdCB3YW50cyB0byBhdXRob3JpemUgYSBmZXcgc2VydmljZSBwcm92aWRlcnMgdG8gc2VuZCBlbWFpbCBvbgo.PiBpdHMgYmVoYWxmLgo.IElzIHRoYXQgcmVhbGx5IGEgcHJvYmxlbT8gSSB3YXMgdW5kZXIgdGhlIGltcHJlc3Npb24gdGhhdCBhIHNlbmQBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> Message-ID: <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Thu, 17 Apr 2014 10:32:41 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/stBc8qURfERB3bALPixtD5prEcM Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 17:32:49 -0000 On Thursday, April 17, 2014 6:53 PM, John Levine wrote: >> I don't see any scaling problem for the case of a domain used by a single >> entity that wants to authorize a few service providers to send email on >> its behalf. > Is that really a problem? I was under the impression that a sender either > adds the providers' IPs to their SPF record, or gives them a DKIM signing key. wrong: 1. DKIM key sharing requires such a support, which is usually not there. 2. SPF policy check doesn't evaluate ur SPF policy at all, but ur ESP's. On Thursday, April 17, 2014 6:53 PM, John Sweet wrote: >> I am still curious what's wrong with this proposal. > How is this not covered by SPF "include:"? If your message has both MAILFROM > and RFC822 From: aligned on your domain, and the connecting IP is in the > range of the included domain, it's all good. it isn't covered by SPF's "include:". seems not many understand this problem, let me make an example: if i use yahoo email for my goodone.tk domain, yahoo will send my email with yahoo.com DKIM key and with yahoo.com SPF MailFrom [my yahoo account address]. and i can't do anything about it. yahoo doesn't support key-sharing, nor it will. so, my domain-email sent from yahoo mail isn't aligned. however, it is legitimate, it is DKIM-signed and it has proper SPF. out of my 15 small-business customers, 12 use exactly this usage scenario. usually google. and when i said it would be a problem, that was not the best way, trying to force them to send mail through their own server, they didn't want to hear it. and i imagine, it is a pretty common practice in the wild for small players. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Thu Apr 17 11:03: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 B15251A0220 for ; Thu, 17 Apr 2014 11:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 144hoSyT6c7p for ; Thu, 17 Apr 2014 11:03:04 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 459E01A0149 for ; Thu, 17 Apr 2014 11:03:04 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rd18so712227iec.15 for ; Thu, 17 Apr 2014 11:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/2VYGGRM8x4t13TLp1P4mM6hWHITRLwDRt692yMtNaY=; b=OttRDRYe9FXHsTTEc+lB/PU+efXOooy15f3N7kjmztDCAi4Kasa2dxUU5YbOVlHrFl lCu3BIBfkrdtzco1jIPwX6B39iYu5WuI2L+q/bp3k6MxnDMk9/a68fMoikozrmCsXZd5 eh/a+XhPGBhWyTI85N74GyTwfZF5SMuPV8fgb4j6dkrpPzliwiCVBuj+pbP1YfIc/m0g jdATtfa60Mn2i68b8lyaFV/cO2By/msTtGi39hOlvbzZXV/aauXRsFVli+AxXprKQQVR Ilo92rsvCUaVBVjtWDcoKmp+2FgUS0ym5+ifO+DSrJ+bsoa5uoBiYiPbEEHO/gMJ2up8 MHYA== X-Received: by 10.50.61.146 with SMTP id p18mr12470563igr.38.1397757780488; Thu, 17 Apr 2014 11:03:00 -0700 (PDT) Received: from jtrentadams-isoc.local (c-67-166-0-110.hsd1.co.comcast.net. [67.166.0.110]) by mx.google.com with ESMTPSA id on9sm8026059igb.11.2014.04.17.11.02.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 11:02:59 -0700 (PDT) Message-ID: <53501751.5000706@gmail.com> Date: Thu, 17 Apr 2014 12:02:57 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Vlatko Salaj , "dmarc@ietf.org" References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> In-Reply-To: <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6UawWgDt-6khPlQJIFE3WvERkro Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 18:03:09 -0000 Vlatko - On 4/17/14 11:32 AM, Vlatko Salaj wrote: [ snip ] > so, my domain-email sent from yahoo mail isn't aligned. however, it is > legitimate, it is DKIM-signed and it has proper SPF. > > out of my 15 small-business customers, 12 use exactly this usage scenario. > usually google. and when i said it would be a problem, that was not the best > way, trying to force them to send mail through their own server, they didn't > want to hear it. > > and i imagine, it is a pretty common practice in the wild for small players. > I see your use case, and why the alignment issue is problematic. And you've prompted me to wonder if we need to layer in the concept of "authorized use" in addition to how we've been talking about technical email authentication. In this flow, your email is authenticating with SPF and DKIM, but you're running into an issue where Yahoo no longer authorizes their domain to be used in that flow. To start, we need to agree that a domain owner is permitted to authorize how it's domain can be used. Then, when a domain owner publishes a DMARC record, they're announcing to the world that their domain can only be used to send email in a specific way (i.e. "aligned"). It's this concept of authorized use that we may be missing in the conversation. Heavily abused domain owners have empirical evidence to prove that alignment is a key factor to blocking spoofed domain abuse. And they are now in a position to authorize those methods they determined to be less susceptible to abuse. That's not to say that other uses are invalid, just that they fall outside what the domain owner is authorizing. And, in the use cases you're suggesting, it sounds like mailbox providers such as Yahoo are telling the world, "Due to being heavily abused, we are no longer authorizing the practice of using our domains in that way." I'm not sure that gets us closer to a workable solution, but perhaps the shift in perception helps shake loose some ideas. HTH, Trent -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From nobody Thu Apr 17 11:05: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 022781A02E7 for ; Thu, 17 Apr 2014 11:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 d5icaib_8YUs for ; Thu, 17 Apr 2014 11:05:37 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id E298F1A0319 for ; Thu, 17 Apr 2014 11:04:32 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id 0BCD5CC0A1 for ; Thu, 17 Apr 2014 14:04:29 -0400 (EDT) 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 BOeTN0NmJqpn for ; Thu, 17 Apr 2014 14:04:20 -0400 (EDT) Received: from new-host.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 56918CC099 for ; Thu, 17 Apr 2014 14:04:20 -0400 (EDT) Message-ID: <535017A4.4020109@meetinghouse.net> Date: Thu, 17 Apr 2014 14:04:20 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> In-Reply-To: <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/O-UwM21CSsnc-xNKUYd12EePth0 Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 18:05:43 -0000 Not sure who wrote this anymore: >> At one time I suggested adding a feature to list domains that could >> be considered "in alignment" with yours. So if a domain owner wanted >> to authorize an email service provider, they could just add something >> to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom >> and/or DKIM signing. I am still curious what's wrong with this proposal. >> It seems to me to cover Vlatko Salaj's use case, and would certainly be >> easier to implement than arranging to share a DKIM key. That seems like it would only work if one is designating only one, or a small number of ESPs. It doesn't seem to address the mailing list case - Yahoo's subscribers, en masse, belong to a huge number of lists, hosted all over the place. Which scales about as poorly as SPF (if you do mailing lists, you end up back at v= +all. So we're back to managing whitelists. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Thu Apr 17 11:38: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 649B21A02A3 for ; Thu, 17 Apr 2014 11:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 k7kLmWIxNeUr for ; Thu, 17 Apr 2014 11:38:28 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id EB1F91A018F for ; Thu, 17 Apr 2014 11:38:27 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n16so856738oag.41 for ; Thu, 17 Apr 2014 11:38:24 -0700 (PDT) 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:content-type; bh=RmzVLOtu/PGLMAKuPL1j9M/IRJVgWb1v34lgJ3/Dudg=; b=AVX4FUcYNtyU4g74+CzEhz3VAy4UCgr3LOqWfOYIk2Yly/aAsxuvb36DHyoGSEuTaR 7KjxLYSBuZZNKprxJp85wPWqPEnfQCr+xLKVrR9FcGiusbFI1DBya2DJvSYoIRlkiz3P Ua86WNSCNnQ44tP0pqqns1xB0nhaN7zscUAt9YaYE1ARkivmmrw/y6yeAlEa5pPigTSk rH4zzj/t5QEHixAgE6EylKouqAJgVHZ3BSH5aHWH2YI4z1xRDL/7hQq0Gm1p39pUqBB4 q5jsPguaQ2k0vlUfKxXWHfdOq5Vm2T3ly/3XOmJU5ydM0BrOpMz3Ykyx4k+n5Zw8z6RO SHxQ== X-Gm-Message-State: ALoCoQl2bmhcV+ZOnwfpXDO7CrwgIRi3MtGhT5Qt6hNenBsIL8DQDTG6NREn8BKJxXwpGEoWXMd6 MIME-Version: 1.0 X-Received: by 10.182.42.228 with SMTP id r4mr13376145obl.20.1397759904239; Thu, 17 Apr 2014 11:38:24 -0700 (PDT) Received: by 10.60.119.35 with HTTP; Thu, 17 Apr 2014 11:38:24 -0700 (PDT) In-Reply-To: <535017A4.4020109@meetinghouse.net> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <535017A4.4020109@meetinghouse.net> Date: Thu, 17 Apr 2014 14:38:24 -0400 Message-ID: From: Joseph Humphreys To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/W5nnXGrXzmG7SR66GYkQYqATlUw Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 18:38:29 -0000 On Thu, Apr 17, 2014 at 2:04 PM, Miles Fidelman wrote: > Not sure who wrote this anymore: >>> >>> At one time I suggested adding a feature to list domains that could >>> be considered "in alignment" with yours. So if a domain owner wanted >>> to authorize an email service provider, they could just add something >>> to their DMARC policy to specify the domain the ESP uses for SPF/MailFrom >>> and/or DKIM signing. I am still curious what's wrong with this proposal. >>> It seems to me to cover Vlatko Salaj's use case, and would certainly be >>> easier to implement than arranging to share a DKIM key. > > > That seems like it would only work if one is designating only one, or a > small number of ESPs. It doesn't seem to address the mailing list case - > Yahoo's subscribers, en masse, belong to a huge number of lists, hosted all > over the place. Which scales about as poorly as SPF (if you do mailing > lists, you end up back at v= +all. > > So we're back to managing whitelists. > I agree that it does not solve the mailing list case. It solves at least two other cases. If someone has a solution that solves all cases, I will gladly forget about this solution. Regards, Joe H From nobody Thu Apr 17 12:05: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 D4D321A0137 for ; Thu, 17 Apr 2014 12:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 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_NEUTRAL=0.779] 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 cyYTnOR5dDoz for ; Thu, 17 Apr 2014 12:04:55 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 83E831A0182 for ; Thu, 17 Apr 2014 12:04:55 -0700 (PDT) Received: (qmail 51918 invoked from network); 17 Apr 2014 19:04:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:mime-version:subject:references:in-reply-to:content-type:content-transfer-encoding:user-agent; s=cacd.535025d1.k1404; i=johnl-iecc.com@submit.iecc.com; bh=Q6JCMXqkCmhDa86NLUODgJWmMxdk7Zg6wE2Yu6Xynl8=; b=XaOHUh9AzRnp5FWn8zUU8zDTzWVczVRXa+dT8i0sVd1gSHHtxI4A/bLUs2ysivI8mV5xLqozViBDNX7jnlQlP5NLx/T64l7aiBnQJvojtCV5Dk4wlDw4e3k/+vvDBM/C6g9nytxA+emDeqkwB20672SoU9RFfMu75P3/U9JmGlEgXLfcjH0Sg1vYpYzb0oxDhuzcPXy0uGE8l+r93nMZT0T6KyRFFCdfjIxE3Dr5gAbJnLxE0szDSOanmIzsEYBt DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:mime-version:subject:references:in-reply-to:content-type:content-transfer-encoding:user-agent; s=cacd.535025d1.k1404; olt=johnl-iecc.com@submit.iecc.com; bh=Q6JCMXqkCmhDa86NLUODgJWmMxdk7Zg6wE2Yu6Xynl8=; b=woyhXpUlkhq031soy77rHNMgUTu1HRmqpjCNwZ4AlJmq2BgchuLPDYp0hBOGu8D/umINlW9ri8otjn95OeefYdW+KLcs9As+nlZWLZUBYUrf5taSS974zf69tQr55OgLKuLGKLvvGPEgHDLpT/Ym45wD5mH7FNeCyv4Bkz1UP5jXynenQm4PR2nn3Nusfs6mz0QcWqjSVnfG5trde6qcofkE5H2jBdcPpYaRNxMUN7OQlMbHcOsrz7YTxJVDxZg6 Received: from jlevine.local ([216.146.45.247]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 17 Apr 2014 19:04:49 -0000 Date: 17 Apr 2014 15:04:45 -0400 Message-ID: <535025CD.5090207@taugh.com> From: "John Levine" To: "Joseph Humphreys" , "dmarc@ietf.org" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <534FFBDA.8040600@iecc.com> <53500623.6090807@taugh.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/Pi2CO58aBt_vVdQqPqOTNEfLQmg Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:05:01 -0000 On 4/17/14, 1:03 PM, Joseph Humphreys wrote: > > The alignment domain-list solution seems trivial to me, and it works > without active support from the sender, which is nice. As I understand it, it requires a domain to enumerate every mailing list domain in which any of its users participate in its DMARC record. That's probably doable for a tiny domain like mine, but not for someone like Yahoo. R's, John From nobody Thu Apr 17 12:08: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 AEAC81A0137 for ; Thu, 17 Apr 2014 12:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 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_NEUTRAL=0.779] 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 C2kZv4Le9xvY for ; Thu, 17 Apr 2014 12:08:40 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4D41A01F2 for ; Thu, 17 Apr 2014 12:08:40 -0700 (PDT) Received: (qmail 53432 invoked from network); 17 Apr 2014 19:08:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:mime-version:subject:references:in-reply-to:content-type:content-transfer-encoding:user-agent; s=d0b7.535026b4.k1404; i=johnl-iecc.com@submit.iecc.com; bh=1m6c3b1244KNYSvTRGxqP/7UmFQDk/m0rJxwGw5rhEY=; b=I2DmXd09gIJrSK9Xs1HSQJ4mi/FuZbaaCJEPu2sueOXicfK6vK+VkXwDLM+qewAHxhtaAN9LnwVmvl/XKUG8kbwjPsMZSUU8GL8v4rd/YCyoFInuriCNEhNzqgrq7kBbffH7iRbmM+TBS2OeNlwLLDvVW1d6KdR7s/bWOqMjpWny6t/1yu/LJAVTBLAS+64+ARn1Xm4zLayAE22porUCYFjm/0amXqDFV2mEXp62BbsQB7khv3XvDLgYgW4FmVvT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:mime-version:subject:references:in-reply-to:content-type:content-transfer-encoding:user-agent; s=d0b7.535026b4.k1404; olt=johnl-iecc.com@submit.iecc.com; bh=1m6c3b1244KNYSvTRGxqP/7UmFQDk/m0rJxwGw5rhEY=; b=rFI/dTylVZKkBZXMnMjfu0Ml97t7HR9vxyHfEkl3/OEm6fSA0XT7KJPgF6InsCKVCtRQSCcnvOvCZRjK70bKpq9zLUfZOxUbLdqdCiP8LMcNpcR/8QkLmVWYcjShPz3Zh1JJg41V9f/Hnm3cboVGXRkBLx+6VijGmxg7XtbZvpZSTj+sHYPW/THrQcXmWWtRzOXLihqbo73UPTLlo8HZ9fY/JE6R89Rnj1jv6aaU63VIxqVmyT47Kll1dZ4wySGV Received: from jlevine.local ([216.146.45.247]) by imap.iecc.com ([64.57.183.75]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 17 Apr 2014 19:08:36 -0000 Date: 17 Apr 2014 15:08:33 -0400 Message-ID: <535026B1.8050002@taugh.com> From: "John Levine" To: "John Sweet" , "dmarc@ietf.org" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 References: <534FFBDA.8040600@iecc.com> <53500623.6090807@taugh.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/7qUhCOvNHGze2wZXoVDzeAy3QVk Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:08:45 -0000 > The ISP rewrites the MAIL FROM to deflect bounces. This passes SPF (IP > matches MAIL FROM), and also passes DMARC's aligned SPF (RFC822 From has > the original sender domain, which includes the ISP's IP range). > > Please tell me what I'm missing. A DMARC SPF pass requires that the MAIL FROM domain be the same as the From: header domain, or in less strict mode a subdomain. The subdomain is probably doable, after considerable coordination between the sender and its ESP. The sender publishes MX records for the subdomain that point at the ESP's bounce handler. From nobody Thu Apr 17 12:38: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 91D761A0110 for ; Thu, 17 Apr 2014 12:38:11 -0700 (PDT) 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, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, MIME_QP_LONG_LINE=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 Qysstd_jTPYb for ; Thu, 17 Apr 2014 12:38:06 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id DE14B1A0109 for ; Thu, 17 Apr 2014 12:38:06 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md12so702787pbc.21 for ; Thu, 17 Apr 2014 12:38:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=ktW+Hivn0fMLQtjDF63E09weolKlZzAXTasrtrURTGY=; b=d1/pQIqqtiKHyXGjIgeI8PNZuoNVXpBSSG9jjJPmMZp119YhfdrfovXQkfzIUMlHmD hTcKlAm4/xMW4yPsVDO13fN5qt0westgFtMAhShB6nqW6NnEvyMzIfy82RSAIsWMQ843 GgcN9WcsxaUdKaHYWTcXlGqVrPxXiRwPaTDEI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=ktW+Hivn0fMLQtjDF63E09weolKlZzAXTasrtrURTGY=; b=aui+uO2iu1PfLFZGPo8uXu3o0v2CADdE+DGFmvn8mQ3QGsQ7un+ejTJxBPKoJGJJmk b7Pd1VuUi3xDHjR1sJX6Ytizh2wNi/oe624McrqYFefJXKWUBpHk5dQdfrUorDAs/cYv 4Hi4lvu8v6SQjjrB3Q/G3UISgigywB6bXPiSYncYhJ9iPEk/PBiv/FdJ+zx6Xb4PtpS9 ++zI9ZHHk7EwhjccrgwT9nsWk+hiqvN3A9xwpSkxif7njnYyVUjbcRnSl+amlpoID3d9 pP0VMOc6ubcVF6UTAcAuG1ERptnq+vDFgiAYExNqk9tGtZDDPdyePbFC4c4xPgZryZKF e3oA== X-Gm-Message-State: ALoCoQkK+qXUUdFPFztHT6THNL5p7E9SGI/nIFYfYRQFNp2Ow8848BL03BbSrU6uGxng1gP3GiVN X-Received: by 10.66.216.137 with SMTP id oq9mr17334141pac.97.1397763483305; Thu, 17 Apr 2014 12:38:03 -0700 (PDT) Received: from [10.0.1.205] (50-197-151-169-static.hfc.comcastbusiness.net. [50.197.151.169]) by mx.google.com with ESMTPSA id xo9sm129389877pab.18.2014.04.17.12.38.00 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 17 Apr 2014 12:38:02 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.4.1.140326 Date: Thu, 17 Apr 2014 12:37:57 -0700 From: Tomki Camp To: "J. Trent Adams" , Vlatko Salaj , "dmarc@ietf.org" Message-ID: Thread-Topic: [dmarc-ietf] alignment and parsing logic as optionals References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> <53501751.5000706@gmail.com> In-Reply-To: <53501751.5000706@gmail.com> 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/mMYyt1RwiKVF3rnNmxewtNmcT1M Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:38:11 -0000 While I do not think that Yahoo! would have opted for this level of enforcement, I do think the variation in alignment requirement could be interesting, and useful in some cases. What about a scenario where a user would like to - receive DMARC reporting - request DMARC-aware receivers reject email which does not pass base authentication measures (SPF or DKIM), but not apply the next step of alignment enforcement This could still be beneficial in cutting off illegitimate email which does not pass SPF or DKIM at all, but provides the allowance which some domain owners could find a useful middle or even final step in their DMARC deployment. Could it be set up as allowing aspf=3Dn for =E2=80=9Calign SPF =3D none=E2=80=9D and adkim=3D= n? Could the application be considered when the request is given as =E2=80=9Cadkim=3Dn;aspf=3Dr=E2=80=9D, meaning =E2=80=9CDKIM alignment not required; if the DKIM signature passes at all, this is a pass. SPF alignment required in relaxed mode; to pass DMARC-SPF, SPF must pass and be in alignment=E2=80=9D -- Tomki -----Original Message----- From: "J. Trent Adams" Date: Thursday, April 17, 2014 at 11:02 To: Vlatko Salaj , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals > >Vlatko - > >On 4/17/14 11:32 AM, Vlatko Salaj wrote: > >[ snip ] >> so, my domain-email sent from yahoo mail isn't aligned. however, it is >> legitimate, it is DKIM-signed and it has proper SPF. >> >> out of my 15 small-business customers, 12 use exactly this usage >>scenario. >> usually google. and when i said it would be a problem, that was not the >>best >> way, trying to force them to send mail through their own server, they >>didn't >> want to hear it. >> >> and i imagine, it is a pretty common practice in the wild for small >>players. >> > >I see your use case, and why the alignment issue is problematic. > >And you've prompted me to wonder if we need to layer in the concept of >"authorized use" in addition to how we've been talking about technical >email authentication. In this flow, your email is authenticating with >SPF and DKIM, but you're running into an issue where Yahoo no longer >authorizes their domain to be used in that flow. > >To start, we need to agree that a domain owner is permitted to authorize >how it's domain can be used. Then, when a domain owner publishes a DMARC >record, they're announcing to the world that their domain can only be >used to send email in a specific way (i.e. "aligned"). > >It's this concept of authorized use that we may be missing in the >conversation. Heavily abused domain owners have empirical evidence to >prove that alignment is a key factor to blocking spoofed domain abuse. >And they are now in a position to authorize those methods they >determined to be less susceptible to abuse. > >That's not to say that other uses are invalid, just that they fall >outside what the domain owner is authorizing. And, in the use cases >you're suggesting, it sounds like mailbox providers such as Yahoo are >telling the world, "Due to being heavily abused, we are no longer >authorizing the practice of using our domains in that way." > >I'm not sure that gets us closer to a workable solution, but perhaps the >shift in perception helps shake loose some ideas. > >HTH, >Trent > >--=20 >J. Trent Adams > >Profile: http://www.mediaslate.org/jtrentadams/ >LinkedIN: http://www.linkedin.com/in/jtrentadams >Twitter: http://twitter.com/jtrentadams > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Apr 17 12:55: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 E4F441A0011 for ; Thu, 17 Apr 2014 12:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 uXiL1iioyIrv for ; Thu, 17 Apr 2014 12:55:11 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id 67C0F1A007B for ; Thu, 17 Apr 2014 12:55:11 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id va2so978971obc.0 for ; Thu, 17 Apr 2014 12:55:07 -0700 (PDT) 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:content-type; bh=z8uFaPSLIzud6JvWedUEdczgroj/g/N3cmy15ggMK14=; b=nG1OVOwHR2H+PbObgPQbLwWO7JaaB/olOIQswms9GuXSujZ6N+UhZyUzrnzetv13/v SfSoyd1zAcAVsn/x/BYNsE8MAe9UYWzMYTVLNq6863s0q4uIoco3qZz5QmazcJo1qvJ6 wwjwXXv+Xv8IyHcnLwvbVTEIeG2np6seHFgEwJkge6b9pJGUD9qtwHyfS47IgWGszKhf 9d4eeGlC225aB9tJOKwHWnJPV2oynp9VXB33DLmXokPV13EkBwQcetPDRFS0bXWfd6Mo bPxh0HaJKp76xXGC8SXZJZJOQFO87CQUnwy7G/TDNz5CKeY6eqfDNYK6F+fAdfi05p4E 9D0w== X-Gm-Message-State: ALoCoQnWg72FAzYkfEWGyKcyClTKhljqs/sCkVprTLEsWQe9DiKmHp2toAZLzhYKvrOWfMiK/EXf MIME-Version: 1.0 X-Received: by 10.60.159.5 with SMTP id wy5mr3327581oeb.58.1397764507537; Thu, 17 Apr 2014 12:55:07 -0700 (PDT) Received: by 10.60.119.35 with HTTP; Thu, 17 Apr 2014 12:55:07 -0700 (PDT) In-Reply-To: <535025CD.5090207@taugh.com> References: <534FFBDA.8040600@iecc.com> <53500623.6090807@taugh.com> <535025CD.5090207@taugh.com> Date: Thu, 17 Apr 2014 15:55:07 -0400 Message-ID: From: Joseph Humphreys To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/YPPAhbeC-rpAQ0uu7YkK8g7rXpw Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 19:55:16 -0000 On Thu, Apr 17, 2014 at 3:04 PM, John Levine wrote: > On 4/17/14, 1:03 PM, Joseph Humphreys wrote: > >> >> The alignment domain-list solution seems trivial to me, and it works >> without active support from the sender, which is nice. > > > As I understand it, it requires a domain to enumerate every mailing list > domain in which any of its users participate in its DMARC record. That's > probably doable for a tiny domain like mine, but not for someone like Yahoo. > Agreed -- I am absolutely not suggesting that this solves the mailing list problem. I believe it does solve the bounce-processing ESP problem, and the piggybacking on gmail problem. I also believe it's easier to implement than delegated subdomains or 3d-party DKIM. Regards, Joe Humphreys From nobody Thu Apr 17 13:14: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 396271A0054 for ; Thu, 17 Apr 2014 13:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 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_72=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 idb4mGQ1eexp for ; Thu, 17 Apr 2014 13:14:18 -0700 (PDT) Received: from msginmsm09vapp.fmr.com (ltm-fwus209m-210m.fidelity.com [155.199.204.10]) by ietfa.amsl.com (Postfix) with ESMTP id E64CF1A0045 for ; Thu, 17 Apr 2014 13:14:03 -0700 (PDT) Received: from msgrtphc05win.DMN1.FMR.COM (MSGRTPHC05WIN.dmn1.fmr.com [10.95.11.185]) by msginmsm09vapp.fmr.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.1) with ESMTP id s3HKDdvx022259 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 17 Apr 2014 20:13:39 GMT X-DKIM: OpenDKIM Filter v2.1.3 msginmsm09vapp.fmr.com s3HKDdvx022259 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; s=2012-05-26; t=1397765620; bh=yLHz/xzXW6X19KMShmL+hZmPy3VIO8KrHl2j3pZw7AE=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rHcXz4rwbStHXKTSGY4E0qADDq3nSPTzPWVAszqPZJ2Ju8aHc6i+ZsrJFcbnou9Th w4mPDjLHVK2wMq/qQWmizf/roKDyhwc1qo1mQlAR4i+j2tmC/PjVrYISSExIC/FGn7 P8CvAtxnbIcoiOEtPkmQxSILldwpOuW8E6BQvRmw= Received: from MSGRTPCCRF2WIN.DMN1.FMR.COM ([10.95.12.31]) by msgrtphc05win.DMN1.FMR.COM ([10.95.11.185]) with mapi; Thu, 17 Apr 2014 16:13:39 -0400 From: "Popowycz, Alex" To: Vlatko Salaj , "dmarc@ietf.org" Date: Thu, 17 Apr 2014 16:13:38 -0400 Thread-Topic: [dmarc-ietf] alignment and parsing logic as optionals Thread-Index: Ac9aYxz2XVVReCt/SK2OPOqKvEGTuQAFElnw Message-ID: <9495B91F5CA0E24C9161D71CD46E43DB011C8A155CA1@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> In-Reply-To: <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US 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/SqmrN-nFdGFhRqux0AxLK6zFVrc Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:14:24 -0000 But if your ESP is where your email originates, then citing them in your SP= F is appropriate. =20 If you're worried about the impact of DMARC then: a) Don't publish a DMARC record=20 b) Publish a DMARC record with p=3Dnone or=20 c) Publish any DMARC policy but use an SPF record like "v=3Dspf1 ip4:0.0.0.= 0/0 ~all As for small domains being able to send DMARC compliant mail, (not trying = to market Google's capability... but) that's easily accomplished with Gmail= using your own DKIM key that's published on your own DNS entry for your pe= rsonal/small business domain.=20 -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Vlatko Salaj Sent: Thursday, April 17, 2014 1:33 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals On Thursday, April 17, 2014 6:53 PM, John Levine wrote: >> I don't see any scaling problem for the case of a domain used by a singl= e >> entity that wants to authorize a few service providers to send email on >> its behalf. > Is that really a problem? I was under the impression that a sender either > adds the providers' IPs to their SPF record, or gives them a DKIM signing= key. wrong: 1. DKIM key sharing requires such a support, which is usually not there. 2. SPF policy check doesn't evaluate ur SPF policy at all, but ur ESP's. On Thursday, April 17, 2014 6:53 PM, John Sweet wrote: >> I am still curious what's wrong with this proposal. > How is this not covered by SPF "include:"? If your message has both MAILF= ROM > and RFC822 From: aligned on your domain, and the connecting IP is in the > range of the included domain, it's all good. it isn't covered by SPF's "include:". seems not many understand this problem, let me make an example: if i use yahoo email for my goodone.tk domain, yahoo will send my email with yahoo.com DKIM key and with yahoo.com SPF MailFrom [my yahoo account address]. and i can't do anything about it. yahoo doesn't support key-sharing, nor it will. so, my domain-email sent from yahoo mail isn't aligned. however, it is legitimate, it is DKIM-signed and it has proper SPF. out of my 15 small-business customers, 12 use exactly this usage scenario. usually google. and when i said it would be a problem, that was not the bes= t way, trying to force them to send mail through their own server, they didn'= t want to hear it. and i imagine, it is a pretty common practice in the wild for small players= . --=20 Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Apr 17 13:42: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 43B2F1A0045 for ; Thu, 17 Apr 2014 13:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 kq_e3vcwLSNy for ; Thu, 17 Apr 2014 13:42:51 -0700 (PDT) Received: from nm23-vm6.bullet.mail.gq1.yahoo.com (nm23-vm6.bullet.mail.gq1.yahoo.com [98.136.217.85]) by ietfa.amsl.com (Postfix) with ESMTP id 63A261A01A5 for ; Thu, 17 Apr 2014 13:42:51 -0700 (PDT) Received: from [98.137.12.56] by nm23.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 20:42:47 -0000 Received: from [98.137.12.204] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 20:42:47 -0000 Received: from [127.0.0.1] by omp1012.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 20:42:47 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 812600.35570.bm@omp1012.mail.gq1.yahoo.com Received: (qmail 32041 invoked by uid 60001); 17 Apr 2014 20:42:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397767367; bh=JO2M1lsalxiHa8zCDXx+BxBgXJ7NHpvLvaMi9iW72uk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2wrrCbF43krXK3eq6L9sz1lemjInxcKYWq77jL7aEgoivPxCk7iVriEcCjm1dkbrEbGEkCz63xiu6x8Ho9vphXcX5xtAq6ACXRfdd3wjuwijMlofCTLWVTVG3+3CTeemBcmhyR+e1I/nXraoeGi9vSMIYSrjAcAs/GUYM0/8pBQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=C+03C41wKJS17q2PkN9m93xtkqMgC/XVCiFXg7aaxOtjFiDSYBV+DK5NrbkP+0MKKrRdfd8WqWyanXoqUIjywn2nVHtoLQIOqq+HBT4lp1W1vj/lOW2KnqvsXsXmUOWkt9eT2KGmvB/ZOI2HLfuzC7fYKLbnXmEEQrwTrdDKdFE=; X-YMail-OSG: e_TNsaIVM1klFP0V0rJAJ8eYRLUEjseLaXbkF5vun30lfTx 6vhPIYWEyACSayIMf3ca5Tu4cULeo4QCqDQhEybHt3HE0CT0FVVXUNj0hs83 hdtStsNRqcVBOqq8TRW7Lydk6yfkbeSHiC9YrUfTDHXRttSt5GKSEeWbyzMw iS34ldqDNTXBSJq7Jdgb0pnfVkccGtY5eVmqjkupG0.G34xsz5m9GWqledjJ NsdkjSaYRqHp71NwJOpO4C1CkRbpV2tHAe8Mv7vuH89BGHX8iKgwG3BphwkR .LT9kJ9Cj_wvyvthgwjmqc0x_1j24KTvunElb3JeB3hmj0Y3JVoCDKyKQvi3 leZ7xrC0QrBwZh0eI5OYkdpIYgjhUcRxBfJum9IntEEiVxStPrZompPDYyU0 lprV0onif_NPlajo4Lg0bZeDB5PPk4P8uT1HTDTCcoFFh_W0dOnTY6TauZkK 8XwIfQritwx_V5KiOyR1UT0cUBeRoLqunwFPf5qaeCWFHqMeITaa63cKPAiR zVfFYAPx.HBtiE2WPDtPeDpy3oPLyWPext27RaGtOgIvAw44U_txOkOpibhh XoOtJp2SkIEgi.60P0KOamufBVCSpYQPReV0KWgaH6I8Mxa8z Received: from [109.121.36.90] by web164603.mail.gq1.yahoo.com via HTTP; Thu, 17 Apr 2014 13:42:47 PDT X-Rocket-MIMEInfo: 002.001, T24gVGh1cnNkYXksIEFwcmlsIDE3LCAyMDE0IDEwOjE0IFBNLCAiUG9wb3d5Y3osIEFsZXgiIHdyb3RlOgoKPiBCdXQgaWYgeW91ciBFU1AgaXMgd2hlcmUgeW91ciBlbWFpbCBvcmlnaW5hdGVzLCB0aGVuIGNpdGluZyB0aGVtIGluIHlvdXIKPiBTUEYgaXMgYXBwcm9wcmlhdGUuCgoKd3JvbmcgY29uY2x1c2lvbiwgYnV0IGknbSBub3QgZ29ubmEgcmVwZWF0IG15c2VsZi4Kb25lIGV4YW1wbGUgc2hvdWxkIGJlIGVub3VnaCB0byBldmVyeWJvZHkuCgoKCj4gQXMgZm9yIHNtYWxsIGRvbWFpbnMgYmVpbmcgYWIBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8A155CA1@MSGRTPCCRF2WIN.DMN1.FMR.COM> Message-ID: <1397767367.11500.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Thu, 17 Apr 2014 13:42:47 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <9495B91F5CA0E24C9161D71CD46E43DB011C8A155CA1@MSGRTPCCRF2WIN.DMN1.FMR.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/L0-rbDVto5mmQwuBAW2sN9HN0hA Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:42:55 -0000 On Thursday, April 17, 2014 10:14 PM, "Popowycz, Alex" wrote: > But if your ESP is where your email originates, then citing them in your > SPF is appropriate. wrong conclusion, but i'm not gonna repeat myself. one example should be enough to everybody. > As for small domains being able to send DMARC compliant mail, > (not trying to market Google's capability... but) that's easily > accomplished with Gmail using your own DKIM key that's published > on your own DNS entry for your personal/small business domain. which isn't free. thus, u r trying to market google's capabilities, while missing the point. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Thu Apr 17 13:51: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 055621A01D7 for ; Thu, 17 Apr 2014 13:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.928 X-Spam-Level: X-Spam-Status: No, score=0.928 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 QmaiSchlgJps for ; Thu, 17 Apr 2014 13:51:03 -0700 (PDT) Received: from nm7-vm3.bullet.mail.gq1.yahoo.com (nm7-vm3.bullet.mail.gq1.yahoo.com [98.136.218.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2311A01D5 for ; Thu, 17 Apr 2014 13:51:03 -0700 (PDT) Received: from [98.137.12.59] by nm7.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 20:50:59 -0000 Received: from [98.137.12.212] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 20:50:59 -0000 Received: from [127.0.0.1] by omp1020.mail.gq1.yahoo.com with NNFMP; 17 Apr 2014 20:50:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 880464.14438.bm@omp1020.mail.gq1.yahoo.com Received: (qmail 82568 invoked by uid 60001); 17 Apr 2014 20:50:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397767859; bh=741aX/S4ve0wlLHSHOyIOOi5AymOtUdlN1suvVvSko8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MURjhz1evaPe4EU+0y8YzCT8JVpfxyMAeVoPgol49DrM9B+kZoyZ3ME28NpZmNPzYqcNVNINK4mk+lPAKQn4ZaymfQ2MOefVN9/2FTt/48od1WnzyWOYbiv3HXOhGGs0rYSG5qyIPjnSgrT7dvydETCW3RvAV/KT+L16yiaZTNk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=21oi5knnPZ3EdZ4MgsDA6ph/oKjk5sV0v+0unkE3nELN0H5jQ498GCk3j9kUROF3mCs9uXCJLj7xuM4kTjA6K+2MnotZxogd5TObR95OD7b4lRodrA+7sPhSs2R5k4HrUyoptUltRX4TusrbzVBp5kzSuMjLBY6lngLfj/uOzk4=; X-YMail-OSG: J2DrFicVM1nljMfp9gLoaqbN1HMsJs1EIGhuxQM8YgnKTb1 TvyfHPmaGfxeU.FeAKa0pZwlhMQ4xmLIa8QkDCUs0tC7A2HcdawYxDnGxsOv wwCFarPs8_z5977Vui0IPMLK6DrEmdgEyPDprn6A6p2iRGbSvJz8uO1ogurh 1.6YYn_2ITFwr8U4I7Hr8UlpDLl6Uyzzwj7m2DUzSYU0flFywvIOM7J2HhQl uIXPMkM0XcNdpxkE0uUOt40Frb8VBfVr_rCCzjKeD_HYZpaLxKt.8dmBSqX_ W8DUk_BxBXtDmWozcmjoyN6ghZN.4.hBzsI4BSXDEKDa6wUJhDkOY7UcBdd_ Z5NYmQ2Sc22pOIZayqiBn1GL61Tsjh1JM8rC0IW.zVuotP.smIe4u3afNEI6 .EA5_gm8DqiLjtRnoYPcwLsKZj6kipJZ6Vm1US4zhEPCaK73EVKRBi0BcEdV 10IcFML3Jwu9cVm_xPTgxnQP_vcQ300AXwA9XzyMl5JH7m5es1y.409hS9ED XiWOB4hhjNp6qjXTaM5E647rnWqv1fXtYX04TVU8GC26XW31pH3l3gkH3TrZ Hz.D1wf4kMAww.yi67Yei8M7Q1LUeln4Xc_uCrK0lgtRA46FduKHMq5Orq_o RNbIE9a9DtxuiXg6t3wdVDimwWupNBvKXexLTCF0fgO36NcRNl_cEASlfuoS h3EM- Received: from [109.121.36.90] by web164605.mail.gq1.yahoo.com via HTTP; Thu, 17 Apr 2014 13:50:59 PDT X-Rocket-MIMEInfo: 002.001, T24gVGh1cnNkYXksIEFwcmlsIDE3LCAyMDE0IDk6MzggUE0sIFRvbWtpIENhbXAgd3JvdGU6Cgo.IENvdWxkIGl0IGJlIHNldCB1cCBhcyBhbGxvd2luZyBhc3BmPW4gZm9yIOKAnGFsaWduIFNQRiA9IG5vbmXigJ0gYW5kIGFka2ltPW4_CgppIGZpbmQgdGhpcyBhIGNvbnZlbmllbnQgd2F5IG9mIGludHJvZHVjaW5nIGFsaWdubWVudC1PRkYgbG9naWMsIHllcy4KCmFsc28sIGFzcGYgYW5kIGFka2ltIHRhZ3Mgd291bGQgYmUgYSBiZXN0IHBsYWNlIGZvciBhbGlnbm1lbnQgZG9tYWluLWxpc3QsIGltby4KCmYBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> <53501751.5000706@gmail.com> Message-ID: <1397767859.2407.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Thu, 17 Apr 2014 13:50:59 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: 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/qb5sbwabyDeP1PQ7SQT0cAbW4QA Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 20:51:05 -0000 On Thursday, April 17, 2014 9:38 PM, Tomki Camp wrote:=0A=0A> Could it be s= et up as allowing aspf=3Dn for =E2=80=9Calign SPF =3D none=E2=80=9D and adk= im=3Dn?=0A=0Ai find this a convenient way of introducing alignment-OFF logi= c, yes.=0A=0Aalso, aspf and adkim tags would be a best place for alignment = domain-list, imo.=0A=0Afor example "aspf=3Dn,r:yahoo.com,s:google.com" woul= d mean none alignment for=0Afrom: header domain, relaxed alignment for yaho= o.com and strict alignment=0Afor google.com. the domain in this question us= es yahoo and google mail services=0Ato send mail, and doesn't use its own s= ervers at all.=0A=0A-- =0AVlatko Salaj aka goodone=0Ahttp://goodone.tk From nobody Thu Apr 17 23: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 7A2B61A00D4 for ; Thu, 17 Apr 2014 23:04:33 -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 K3qA6hqx8LQq for ; Thu, 17 Apr 2014 23:04:28 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 991361A001C for ; Thu, 17 Apr 2014 23:04:28 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so1235362wes.38 for ; Thu, 17 Apr 2014 23:04:24 -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=LeC9nXWyO2f/brfUPMWsWlRuXOpL8BvUq9+aCLnIdU0=; b=Zzoq4Tx1howoSfoFW7bX2FzhF6Jh/OcfIofL2Et5mhsv+e/rzt2flWhm8wRj6nOOaF QtqNE/J3JNB5SxWl/XDVUOyzys1S3rJxAR4lf8coTxsBzofei06M8pb1iJqnLvA4sBOP lB3aH6r+EHbS/ybxr2xxJCG/r6QnOApgwZsfZIIIzk5uc7NU2fkNdpqNi3khxi3Yyqya +FMnoH1R7HlYbgda9ZPA4KONy9OeBxVnawweaIZfl8+ok/dUX7Cb0WqPeN3pWnOo8AnD JFTn3HTVyzjbUYCZQrr2ysp/R2jaxUK6ZmfcrI2KSJnTdJZAComxp+zzO8RjDSKT3aaa JFxA== MIME-Version: 1.0 X-Received: by 10.180.78.41 with SMTP id y9mr1132853wiw.26.1397801064223; Thu, 17 Apr 2014 23:04:24 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Thu, 17 Apr 2014 23:04:24 -0700 (PDT) In-Reply-To: <1397767367.11500.YahooMailNeo@web164603.mail.gq1.yahoo.com> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8A155CA1@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1397767367.11500.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Thu, 17 Apr 2014 23:04:24 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=f46d04389477e65c8f04f74aeb09 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LuGg15DyzP5yL1RxsyuWtXuJQ24 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Apr 2014 06:04:33 -0000 --f46d04389477e65c8f04f74aeb09 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 1:42 PM, Vlatko Salaj wrote: > > wrong conclusion, but i'm not gonna repeat myself. > one example should be enough to everybody. > > I think if you want to get your ideas understood and thus adopted, you're going to have to set your patience and politeness thresholds a lot higher than they are now. -MSK --f46d04389477e65c8f04f74aeb09 Content-Type: text/html; charset=UTF-8
On Thu, Apr 17, 2014 at 1:42 PM, Vlatko Salaj <vlatko.salaj@goodone.tk> wrote:

wrong conclusion, but i'm not gonna repeat myself.
one example should be enough to everybody.


I think if you want to get your ideas understood and thus adopted, you're going to have to set your patience and politeness thresholds a lot higher than they are now.

-MSK
--f46d04389477e65c8f04f74aeb09-- From nobody Thu Apr 17 23:20: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 C5AB31A017D for ; Thu, 17 Apr 2014 23:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 N8jWddbBdh0A for ; Thu, 17 Apr 2014 23:20:26 -0700 (PDT) Received: from nm20-vm5.bullet.mail.gq1.yahoo.com (nm20-vm5.bullet.mail.gq1.yahoo.com [98.136.217.36]) by ietfa.amsl.com (Postfix) with ESMTP id 4901B1A019F for ; Thu, 17 Apr 2014 23:20:25 -0700 (PDT) Received: from [216.39.60.181] by nm20.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 06:20:21 -0000 Received: from [98.137.12.222] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 06:20:21 -0000 Received: from [127.0.0.1] by omp1030.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 06:20:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 571846.88123.bm@omp1030.mail.gq1.yahoo.com Received: (qmail 82107 invoked by uid 60001); 18 Apr 2014 06:20:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397802021; bh=hK6xymot1Inos2/sSdOvTrSCo0XKapwarxSM0arEZK8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ovFA+aTFVwL/dC1ovyFbEcOSFHxfNjaO0ur/tdz20NUVE4O4/YOBx9ghhW221YzDuWi6e0lxev14bIKUr5le5wCHlSe5GyxFM3qqTZyT3Nfhilkg9y2dlJvZ3qSyWTLIn3F2DMc62XFlfqXOaB8nC7Utjd5rNKBOZF76vKUH8CA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MZmXfCmU9ph5qRVH8vcff/xYlT5z5XyKMeQ/osKsVZTGIiT0wlQI431dpH3aM4yjX6nvVSXeVAiCOy30mqE7e+gBLXT6JkBAjhClq8MnUcOi24Uwd6Xp8itT538wxbAtLwzaVpRqV4ezOjyYgDqh1T87FslfCAvoFV3JH0QjCL0=; X-YMail-OSG: coRpagkVM1mBDELEJLL6VzD2pnxTXTV.TU_9rxiERPy5TOi d4jAMlhoXO8oI7RXkzrmZg8.9yYyBgdGORlsQxuOIe.IOEdGga41FwQUjqgD AiztBP0amxGGoqJSIUwNuodK4Xh96Ylvpg4Sagw6RwLCm8DiwP9OBjakeHHO z3Pov2EYXZo_AMemPwGos2N6E7_.D2pD0Q1cwAEgcA6F4j8s_QAfjr5TbJau lnvd.wAYToVnfh3RDCK1NSMMwHNZbKb7VdXiSD15UbgCEQOcJGrvzYN80Vht T1_PBJZdWRsiib1N.yM4VnugLLYdOvkmkeDcoOoilLPSTridB7aGxPd3vdmS RsfB8DYIdvi8Q_tOpaKJI_Wn0a._vCRdTLNlxkKX2uQUQ41_hVfkDw6UCODr zVQUBeA9RF7l1PyOoL5cTlS4WLPcWtuChv4Zwcu_nvCkfDqz6uiJFknApw5t I7KWgJ0XNHrNCiPWhcvmuamPb02rc6bXWb1A7kWEZTKsYhC12aCRY6A4mC3n 9eQjVbkvvEPpb5B4rG6ev8c1h.dclS215frQ108ESEU__8_jKdEAoI5eqcAg CbekYpxHEQhFIQSKXneoTZxFHuAITUjvp9eTgLuMwnr2aueqw3o76kuiAttz Q2yRYHX3s4J5lBzo- Received: from [109.121.36.90] by web164604.mail.gq1.yahoo.com via HTTP; Thu, 17 Apr 2014 23:20:21 PDT X-Rocket-MIMEInfo: 002.001, PiBJIHRoaW5rIGlmIHlvdSB3YW50IHRvIGdldCB5b3VyIGlkZWFzIHVuZGVyc3Rvb2QgYW5kIHRodXMgYWRvcHRlZCwKPiB5b3UncmUgZ29pbmcgdG8gaGF2ZSB0byBzZXQgeW91ciBwYXRpZW5jZSBhbmQgcG9saXRlbmVzcyB0aHJlc2hvbGRzCj4gYSBsb3QgaGlnaGVyIHRoYW4gdGhleSBhcmUgbm93LgoKCmkgZG8gbm90IGhhdmUgbXVjaCBwYXRpZW5jZSBmb3IgcHBsIHRoYXQgaGF2ZSBubyB0aW1lIHRvIHJlYWQgc3RlcCBieSBzdGVwCmV4YW1wbGUsIGJ1dCBkbyBoYXZlIHRpbWUgdG8gd3JpdGUgYSBsZW4BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8A155CA1@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1397767367.11500.YahooMailNeo@web164603.mail.gq1.yahoo.com> Message-ID: <1397802021.17514.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Thu, 17 Apr 2014 23:20:21 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xlpW51aBciQ3tL8mEwWe5DVStCM Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 18 Apr 2014 06:20:31 -0000 > I think if you want to get your ideas understood and thus adopted, > you're going to have to set your patience and politeness thresholds > a lot higher than they are now. i do not have much patience for ppl that have no time to read step by step example, but do have time to write a lengthy response, while missing the point and promoting commercial services. i was tired and i apologize for the tone, but not for the point i was making. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Apr 18 01: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 CD12C1A0101 for ; Fri, 18 Apr 2014 01:44:25 -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 zrQHaztJ_u0L for ; Fri, 18 Apr 2014 01:44:21 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 928411A004B for ; Fri, 18 Apr 2014 01:44:20 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u57so1372480wes.36 for ; Fri, 18 Apr 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=zk1VfuLp9NY52upK7DThBkFTGTFY6WhkHw9ScxBwmow=; b=X6Tpc7udOGrmPYVfwCULvpFAtYQKN1EhOmfUXCLUZ2oh4DgclsIWRF/v/vZzIyoFvq BDxECNHA1Nv4bK5WTimxM+27BzHBBu1LmA/z3gw98BXIZqavRZAgbLn/5r+SSps6eo9S zX1QY4GQFYlzwu/WPTJGwOOzHHeaz3PcxQVyvDyB0Hs6hUqi1+oaWZZqhx85d89w18cW 2YpG1Oy38UjEpRVp+IcG5Mfa3X9T1jVT4bP6G3cipb7zi4/yYD39NZSXy68t8aFpHchd EgO2QOER5APANNrkdEzDEz5x1SAiniy9Qc3tdGQRDX69TpFP2BqeQd9W5StGRiMw6y4n a0+Q== MIME-Version: 1.0 X-Received: by 10.194.174.42 with SMTP id bp10mr552289wjc.57.1397810656237; Fri, 18 Apr 2014 01:44:16 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Fri, 18 Apr 2014 01:44:16 -0700 (PDT) In-Reply-To: <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Fri, 18 Apr 2014 01:44:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=089e01493cb4a0df7a04f74d2781 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Up52pHTM1hNdN7EJQyF7rQ-szlg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Apr 2014 08:44:26 -0000 --089e01493cb4a0df7a04f74d2781 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 7:51 AM, Vlatko Salaj wrote: > making DMARC strictly based on OR-logic will get it obsolete as soon as > someone finds a way to exploit any of the underlying mechanism, and that's > already possible, either through DKIM replay attack, or through spoofed SPF > authentication, whichever serves an attacker better. > The DKIM replay attack assumes that either (a) the entire content is signed, in which case the only replay is the re-sending of a complete original (which is presumably valid), or (b) there's partial content signing going on, which is strongly discouraged practice anyway. What's an example of spoofed SPF authentication? > "I do not want alignment" is exactly the same as "I don't use DMARC" > > since DMARC is pretty much all about alignment. So, again, I don't > > understand why that's a useful thing to add. > > it's not the same. DMARC is not just authentication, it's also about > reporting > and conformance. i would be perfectly happy to get my email checked against > SPF and DKIM and processed in a standard-defined way, and receive reports > on > which i can then act. otherwise, DMARC has no benefits for me at all. > So you don't want the authentication enforcement, only the reports? Isn't that what "p=none" does? You would get reports of unaligned mail and SPF/DKIM results in that case already. > >> and it's a common practice, absolutely. whether it's formal or informal. > > What's an example? > > i've already written about it. someone using yahoo or google email service > to send their own domain email. i actually do that. and i imagine, a great > deal of ppl. > > it also covers various 3rd party services, such as ones that deliver > greeting > cards, process petitions... > It seems to me more like you're talking about a way to extend specific other domains to be allowed to send mail as your domain and still pass. SPF and DKIM already have mechanisms to do that, not to mention experimental extensions like ATPS. The problem is that you need to know ahead of time which senders will do so, which has the obvious scaling problem. Of course, since DMARC is about keeping control over that, maybe it's an expected scaling problem, but it's still something that needs to be handled. >> as i said: combined, alignment OFF and AND processing logic would work > great > >> in cases where alignment isn't possible, yet email is fully legitimate. > > For the "off" case, isn't that just the same as "p=none"? > > it isn't. if we accept the idea about making alignment optional, i would > gladly expand the idea to more than just turning alignment on/off. > I still don't understand this. What's the difference between "p=none" and what you're calling "alignment off"? > actually, such alignment field would, in my proposal, include a > three-state: > > 1. alignment ON, in which case from: header gets checked against. > > 2. alignment OFF, in which case domain owner specifies they have no benefit > from DMARC alignment checks, but do want other checks performed, such as > AND-logic mechanism evaluation, for example. > But the AND-logic is "SPF and DKIM have to pass, and be aligned". So you're saying both need to pass (in the AND case), but it doesn't matter which domains they validated? Again, that means I can send any mail I want as your domain and that would pass DMARC, and I'm not clear about why you want that. 3. alignment domain-list value to include in alignment check: list of > domains > the domain owner wants to have included in DMARC alignment check, > complementing > from: header domain; this will cover almost all cases DMARC breaks now, > such > as 3rd party infrastructure, mailing lists that do not wish to make changes > for DMARC-compatibility, forwarders that process their mail, but can't be > controlled by domain owner, etc. it's somewhat similar to SPF domain > definition, > but different, since it affects DMARC-alignment process. > Right, that's the third-party case discussed above. There are a bunch of limitations, assuming this is something that's actually in enough demand to add. For starters: (1) sticking the list in a DNS TXT field will not scale (suppose you want to authorize a thousand third parties), and (2) you have to keep the list current, which will need automation and security around it as users seek to add entries (by subscribing to lists, for example). > I totally agree there, especially since Sender-ID got almost no adoption > > (see RFC 6686), and that seems unlikely to change now. > > it would change quite fast if we would make it part of DMARC. > What would be the value in doing so? > PRA could actually be a better way to determine owner's domain for > alignment > purposes than some undefined public-suffix list, especially in the light of > newest moves by ICANN, introducing bunch of new top-lvl domains, which will > probably host a bunch of sub-domains with registration capabilities by 3rd > parties, etc. > I don't think we really want to re-have the MARID arguments. The fact that in several years nobody adopted Sender-ID speaks pretty loudly to me. > DMARC's dependance on a concept of "public-suffix list" is a can of worms > i can't wait to see what will make of DMARC's usability at the end. it > will be > a mess for sure. i'm not rly sure how this isn't obvious to DMARC's > authors, > given all that experience in the domain. > It is obvious. Appendix A.6 even acknowledges that the public suffix method is "far from perfect", and that if and when any better mechanism appears, DMARC should change to use it. There has been work appearing in the IETF's Applications Area to create such a system, but there's nothing formal or deployed yet. -MSK --089e01493cb4a0df7a04f74d2781 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 17, 2014 at 7:51 AM, Vlatko Salaj <vlat= ko.salaj@goodone.tk> wrote:
making DMARC strictly based on OR-logic will= get it obsolete as soon as
someone finds a way to exploit any of the underlying mechanism, and that= 9;s
already possible, either through DKIM replay attack, or through spoofed SPF=
authentication, whichever serves an attacker better.
<= br>
The DKIM replay attack assumes that either (a) the entire con= tent is signed, in which case the only replay is the re-sending of a comple= te original (which is presumably valid), or (b) there's partial content= signing going on, which is strongly discouraged practice anyway.

What's an example of spoofed SPF authentication?

=
> "I do not want alignment" is exactly the sam= e as "I don't use DMARC"
> since DMARC is pretty much all about alignment. So, again, I don't=
> understand why that's a useful thing to add.

it's not the same. DMARC is not just authentication, it's als= o about reporting
and conformance. i would be perfectly happy to get my email checked against=
SPF and DKIM and processed in a standard-defined way, and receive reports o= n
which i can then act. otherwise, DMARC has no benefits for me at all.

So you don't want the authentication enf= orcement, only the reports?=C2=A0 Isn't that what "p=3Dnone" = does?=C2=A0 You would get reports of unaligned mail and SPF/DKIM results in= that case already.
=C2=A0
>> and it's a common practice, absolutely. whethe= r it's formal or informal.
> What's an example?

i've already written about it. someone using yahoo or google emai= l service
to send their own domain email. i actually do that. and i imagine, a great<= br> deal of ppl.

it also covers various 3rd party services, such as ones that deliver greeti= ng
cards, process petitions...

It seems to= me more like you're talking about a way to extend specific other domai= ns to be allowed to send mail as your domain and still pass.=C2=A0 SPF and = DKIM already have mechanisms to do that, not to mention experimental extens= ions like ATPS.=C2=A0 The problem is that you need to know ahead of time wh= ich senders will do so, which has the obvious scaling problem.=C2=A0 Of cou= rse, since DMARC is about keeping control over that, maybe it's an expe= cted scaling problem, but it's still something that needs to be handled= .

>> as i said: combined, alignment OFF and AND process= ing logic would work great
>> in cases where alignment isn't possible, yet email is fully le= gitimate.
> For the "off" case, isn't that jus= t the same as "p=3Dnone"?

it isn't. if we accept the idea about making alignment optional, = i would
gladly expand the idea to more than just turning alignment on/off.

I still don't understand this.=C2=A0 What&#= 39;s the difference between "p=3Dnone" and what you're callin= g "alignment off"?
=C2=A0
actually, such alignment field would, in my proposal, include a three-state= :

1. alignment ON, in which case from: header gets checked against.

2. alignment OFF, in which case domain owner specifies they have no benefit=
from DMARC alignment checks, but do want other checks performed, such as AND-logic mechanism evaluation, for example.

But the AND-logic is "SPF and DKIM have to pass, and be aligned&= quot;.=C2=A0 So you're saying both need to pass (in the AND case), but = it doesn't matter which domains they validated?=C2=A0 Again, that means= I can send any mail I want as your domain and that would pass DMARC, and I= 'm not clear about why you want that.

3. alignment domain-list value to include in alignment check: list of domai= ns
the domain owner wants to have included in DMARC alignment check, complemen= ting
from: header domain; this will cover almost all cases DMARC breaks now, suc= h
as 3rd party infrastructure, mailing lists that do not wish to make changes=
for DMARC-compatibility, forwarders that process their mail, but can't = be
controlled by domain owner, etc. it's somewhat similar to SPF domain de= finition,
but different, since it affects DMARC-alignment process.

Right, that's the third-party case discussed above.= =C2=A0 There are a bunch of limitations, assuming this is something that= 9;s actually in enough demand to add.=C2=A0 For starters: (1) sticking the = list in a DNS TXT field will not scale (suppose you want to authorize a tho= usand third parties), and (2) you have to keep the list current, which will= need automation and security around it as users seek to add entries (by su= bscribing to lists, for example).

> I totally agree there, especially since Sender-ID got = almost no adoption
> (see RFC 6686), and that seems unlikely to change now.

it would change quite fast if we would make it part of DMARC.

What would be the value in doing so?
=C2=A0=
PRA could actually be a better way to determine owner's domain for alig= nment
purposes than some undefined public-suffix list, especially in the light of=
newest moves by ICANN, introducing bunch of new top-lvl domains, which will=
probably host a bunch of sub-domains with registration capabilities by 3rd<= br> parties, etc.

I don't think we real= ly want to re-have the MARID arguments.=C2=A0 The fact that in several year= s nobody adopted Sender-ID speaks pretty loudly to me.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> DMARC's dependance on a concept of "public-suffix list" is a = can of worms
i can't wait to see what will make of DMARC's usability at the end.= it will be
a mess for sure. i'm not rly sure how this isn't obvious to DMARC&#= 39;s authors,
given all that experience in the domain.

It is obvious.=C2=A0 Appendix A.6 even acknowledges that the public suffi= x method is "far from perfect", and that if and when any better m= echanism appears, DMARC should change to use it.=C2=A0 There has been work = appearing in the IETF's Applications Area to create such a system, but = there's nothing formal or deployed yet.

-MSK

--089e01493cb4a0df7a04f74d2781-- From nobody Fri Apr 18 01:44:53 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 4B6FA1A01AD for ; Fri, 18 Apr 2014 01:44:51 -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 GGeKEeJF6_7V for ; Fri, 18 Apr 2014 01:44:46 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8921A017F for ; Fri, 18 Apr 2014 01:44:45 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so302435wgg.30 for ; Fri, 18 Apr 2014 01:44:41 -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=iYXt9RtBjI0KenKqunF0XZkH6pmhoOlqazL2Sh34nKY=; b=lvd8eRrsTV9L+f9s5REPMSiXHaQ5my3tZMcCmWgt9BiBLv4hhaMvQMl4oGWlyu7QG4 pE/zXmG9fsXwvi8c6/bJYqeW+GjVyd6DRk4agn3LaQynyyNKRCEjhgXZWbJcILuQeLWr AakYFxYuBxbD8/mOFpgtlLlsJIq5y140lTkQYwFtdtdRrhw7xEQpRJy5mNw+JDzRuQgx g+1DGNZ6+UnoTkCxMTAtDkQGuqL14AUr2zCybLh6tJhNfaIxnD071Mz+HZbnrP2rW9C1 U27aMsNLpZWRKB8TABhKA0DX5HKW2J+b+/INF9nWhhifQ4wJyXYqRaHjab2f/j0fXoN6 boFg== MIME-Version: 1.0 X-Received: by 10.194.5.5 with SMTP id o5mr15474408wjo.16.1397810681874; Fri, 18 Apr 2014 01:44:41 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Fri, 18 Apr 2014 01:44:41 -0700 (PDT) In-Reply-To: <1397802021.17514.YahooMailNeo@web164604.mail.gq1.yahoo.com> References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8A155CA1@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1397767367.11500.YahooMailNeo@web164603.mail.gq1.yahoo.com> <1397802021.17514.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Fri, 18 Apr 2014 01:44:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=047d7b5d43fe280e6104f74d298d Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mNRhUYS8DesOEgbokllt2AUUDIM Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Apr 2014 08:44:51 -0000 --047d7b5d43fe280e6104f74d298d Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 11:20 PM, Vlatko Salaj wrote: > > I think if you want to get your ideas understood and thus adopted, > > you're going to have to set your patience and politeness thresholds > > a lot higher than they are now. > > i do not have much patience for ppl that have no time to read step by step > example, but do have time to write a lengthy response, while missing the > point > and promoting commercial services. > Reaching consensus requires dialog and patience, and sometimes needs more than just one example. There's a lot of smart people here who have been working on this for a long time, probably with very different perspectives and experience than you have. Assuming they're all dumb or lazy because they're "missing the point" seems like a pretty bad place from which to start. If all people get is snark when they probe your ideas, I'm pretty sure they'll just stop answering. -MSK --047d7b5d43fe280e6104f74d298d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 17, 2014 at 11:20 PM, Vlatko Salaj <v= latko.salaj@goodone.tk> wrote:
=
> I think if you want to = get your ideas understood and thus adopted,
> you're going to have to set your patience and politeness threshold= s
> a lot higher than they are now.

i do not have much patience for ppl that have no time to read step by= step
example, but do have time to write a lengthy response, while missing the po= int
and promoting commercial services.

Reac= hing consensus requires dialog and patience, and sometimes needs more than = just one example.=C2=A0 There's a lot of smart people here who have bee= n working on this for a long time, probably with very different perspective= s and experience than you have.=C2=A0 Assuming they're all dumb or lazy= because they're "missing the point" seems like a pretty bad = place from which to start.

If all people get is snark when they probe your ideas,= I'm pretty sure they'll just stop answering.

-MSK
=
--047d7b5d43fe280e6104f74d298d-- From nobody Fri Apr 18 01:50:23 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 4764D1A021D for ; Fri, 18 Apr 2014 01:50:22 -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 O3zI1pgaRwNw for ; Fri, 18 Apr 2014 01:50:17 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 852231A0101 for ; Fri, 18 Apr 2014 01:50:17 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id x48so1327933wes.7 for ; Fri, 18 Apr 2014 01:50:13 -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=w/P6Cvv1pLzoO0ERv8VTA/6eF+H81LGSUIHnCACbbd0=; b=yPpmkkTM1ZKylWsk4VLHYOFgzNzo0BffVbMXHSriz8Exd+dLTzUJzDk/JE1XMkxOQa DBdgRy568ZmSIudjBZORTYZq1/7kS6O9ynpApIUeOV/3fa+K/iIsl3on5nIi/HR5gDkA zDng7csxx0MPk4HavWkTJviB3ziswjYLz6o2fQfObmuhWSJKtUNWYAEZbIyjH/Tjd2k9 MgGKrYn1qRWXd76A8Atud0qarMjH202dsJveZuHhbXsp4RpQMdijXEWADSW0Be/JTlOm KPCxVrnaXHEFfkOCQUxEtPCSih/XULk1AdIPYLw3rYxpwDfz72tigqOQaAigZ3FIJCsp MpTA== MIME-Version: 1.0 X-Received: by 10.180.76.146 with SMTP id k18mr1625865wiw.5.1397811013246; Fri, 18 Apr 2014 01:50:13 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Fri, 18 Apr 2014 01:50:13 -0700 (PDT) In-Reply-To: References: <534FFBDA.8040600@iecc.com> <53500623.6090807@taugh.com> Date: Fri, 18 Apr 2014 01:50:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Joseph Humphreys Content-Type: multipart/alternative; boundary=f46d04374995e866b104f74d3c0e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zha5IoZpo1Q7HsXjgNVnBh11RPk Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Apr 2014 08:50:22 -0000 --f46d04374995e866b104f74d3c0e Content-Type: text/plain; charset=UTF-8 On Thu, Apr 17, 2014 at 10:01 AM, Joseph Humphreys < jhumphreys@salesforce.com> wrote: > The alignment domain-list solution seems trivial to me, and it works > without active support from the sender, which is nice. > How does it work without active support from the sender? Doesn't the sender first have to ensure it's in that list? That's kind of an important step for a list operator with a new subscriber from a "p=reject" domain. -MSK --f46d04374995e866b104f74d3c0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 17, 2014 at 10:01 AM, Joseph Humphreys <jhumphreys@salesforce.com> wrote:
The alignment domain-list solution seems tri= vial to me, and it works
without active support from the sender, which is nice.

How does it work without active support from the sender?=C2= =A0 Doesn't the sender first have to ensure it's in that list?=C2= =A0 That's kind of an important step for a list operator with a new sub= scriber from a "p=3Dreject" domain.

-MSK
--f46d04374995e866b104f74d3c0e-- From nobody Fri Apr 18 01:58:41 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 7FB081A0107 for ; Fri, 18 Apr 2014 01:58:36 -0700 (PDT) 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_41=0.6, J_CHICKENPOX_51=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 F4bzDpsks3s5 for ; Fri, 18 Apr 2014 01:58:32 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 342291A0299 for ; Fri, 18 Apr 2014 01:58:31 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id q58so1352677wes.20 for ; Fri, 18 Apr 2014 01:58:26 -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=0vy1mE9HmcA9SrgkYJFzdVYiAtQilAwWf1nB/xpxzvc=; b=q52um1fmg9xej8w38IxFaEoJAA/vJAc9QRe+hV4N/FhV3wHkw40k5h2OIRmGBtX7eo MNcz1yUlTrhyfTQQBQyDIsnxxBMiE5RY1g2zsDFuqMzYzzJL17Y99dOLmgPS5LEI6kys o1MA9MRdcKDWULdeB4A/SLPHTVQxLJzhN2hvHBfagwkdt13d5lkyoaSCln8ZmbTESw/T OM1l2SmDVNRndhmHSU8WnNHKhUHQsa3N4Fj3vU1LaoHULfqYQX2/AIpEHi7kgpzMf88G k/QzaLa3TuLnNNpdH2+H5T1GwjuAOXrAh8x1qzsiZdjWpwvekDFv8OKXeAevo5PWvKM9 igLQ== MIME-Version: 1.0 X-Received: by 10.194.175.70 with SMTP id by6mr15514624wjc.3.1397811506716; Fri, 18 Apr 2014 01:58:26 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Fri, 18 Apr 2014 01:58:26 -0700 (PDT) In-Reply-To: References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> <53501751.5000706@gmail.com> Date: Fri, 18 Apr 2014 01:58:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tomki Camp Content-Type: multipart/alternative; boundary=089e013d175a5227d704f74d5a4b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DFtoWWTi4Vse2a9DmejPNNKBqnY Cc: Vlatko Salaj , "dmarc@ietf.org" , "J. Trent Adams" Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Apr 2014 08:58:37 -0000 --089e013d175a5227d704f74d5a4b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 17, 2014 at 12:37 PM, Tomki Camp wrote: > What about a scenario where a user would like to > - receive DMARC reporting > - request DMARC-aware receivers reject email which does not pass base > authentication measures (SPF or DKIM), but not apply the next step of > alignment enforcement > What's the next step part? If you've rejected the message because it passes neither SPF or DKIM, it seems like you're done with that message irrespective of alignment. > This could still be beneficial in cutting off illegitimate email which > does not pass SPF or DKIM at all, but provides the allowance which some > domain owners could find a useful middle or even final step in their DMAR= C > deployment. > Shooting from the hip, I'm inclined to say this is out of scope for DMARC. DMARC has as one of its core tenets the notion of From: field alignment, because what the user sees comes from the From: field for most (almost all?) MUAs. If you take that out of the equation, it seems like we're talking about stuff a layer below DMARC, not DMARC itself. > Could it be set up as allowing aspf=3Dn for =E2=80=9Calign SPF =3D none= =E2=80=9D and adkim=3Dn? > If you're going to say "either has to pass but I don't care about alignment", then I can use my own domain in the MAIL FROM or sign with my own domain and send mail with your domain in the From:, and it'll pass the DMARC test. Is that really an attractive alternative? -MSK --089e013d175a5227d704f74d5a4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 17, 2014 at 12:37 PM, Tomki Camp <tcamp@agari.c= om> wrote:
What about a scenario where a user would like to
- receive DMARC reporting
- request DMARC-aware receivers reject email which does not pass base
authentication measures (SPF or DKIM), but not apply the next step of
alignment enforcement

What's the ne= xt step part?=C2=A0 If you've rejected the message because it passes ne= ither SPF or DKIM, it seems like you're done with that message irrespec= tive of alignment.
=C2=A0
This could still be beneficial in cutting off illegitimate email which
does not pass SPF or DKIM at all, but provides the allowance which some
domain owners could find a useful middle or even final step in their DMARC<= br> deployment.

Shooting from the hip, I= 9;m inclined to say this is out of scope for DMARC.=C2=A0 DMARC has as one = of its core tenets the notion of From: field alignment, because what the us= er sees comes from the From: field for most (almost all?) MUAs.=C2=A0 If yo= u take that out of the equation, it seems like we're talking about stuf= f a layer below DMARC, not DMARC itself.
=C2=A0
Could it be set up as allowing aspf=3Dn for =E2=80=9Calign SPF =3D none=E2= =80=9D and adkim=3Dn?

If you're goi= ng to say "either has to pass but I don't care about alignment&quo= t;, then I can use my own domain in the MAIL FROM or sign with my own domai= n and send mail with your domain in the From:, and it'll pass the DMARC= test.=C2=A0 Is that really an attractive alternative?

-MSK
--089e013d175a5227d704f74d5a4b-- From nobody Fri Apr 18 04:01: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 022341A0144 for ; Fri, 18 Apr 2014 04:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crD3NLNP32Zv for ; Fri, 18 Apr 2014 04:01:19 -0700 (PDT) Received: from nm2-vm2.bullet.mail.gq1.yahoo.com (nm2-vm2.bullet.mail.gq1.yahoo.com [98.136.218.129]) by ietfa.amsl.com (Postfix) with ESMTP id DFD1D1A00D4 for ; Fri, 18 Apr 2014 04:01:18 -0700 (PDT) Received: from [98.137.12.189] by nm2.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 11:01:15 -0000 Received: from [98.137.12.226] by tm10.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 11:01:15 -0000 Received: from [127.0.0.1] by omp1034.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 11:01:15 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 158619.58054.bm@omp1034.mail.gq1.yahoo.com Received: (qmail 15489 invoked by uid 60001); 18 Apr 2014 11:01:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397818875; bh=9YoLUB1WziXiudSNFd1RC6fFRnGiZuqs92DfiDaGMHs=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=l/dG0mlMid+MwQv7xQVWZepZbWt+6gKodNkUng5KKIEJVqFdG7gJV3hnN2owXyYNU8DzVySw6hXwJjUAJO2KKCC5+LGeu35qhgsHNV3xHHSgaEtjw+GT1or5nu8z7jxCWhsOVoFjMzXsr9pmAeiO82hsZyHWgxXBPi/R7i3ZEA4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=5Ve0gP+fVeERNNyE+eWWjyb+1+6sP88JFT5Esh6Jq9BwYy0D1G4yIhNLKYlOQyelRI8nqIAjxRajWzO6YYqYXgh3CvB6j/63xawInd6DMzcRy3DMsGAr3Rd22koJt7s8isi2BPSkWs7R3Wj/7CwY58zdzhT/+xBWZjJzKy8yIWI=; X-YMail-OSG: hf1pD24VM1nHH.wCKA95SVtyH9_UDoXQjHyT2rnykQYjEN3 0wNnyvf2aAsbQ_r656U4WwXlyulwiTCSdd5itg1aVVHIDkF9rV5ECRrgedgJ YE3OsgMpTbMtHu.ovV3lHVmBpZJ4bZGbIDrzxaeuWEc.vQHOI36eu1OqNSZI jbWEVh2swh2J34LEpi_WCUgZ0M1uzrqo7Khl2YPaJsWPdlLes3bJ5im1YNlU AkHJp8r4GeCdJZjHW00Ka46dWBHxPzqOeJMWrsGPHI3ITLmQeyCy13qL6jxo Nc_SW8ZxEAvVf3Nwyz1ved6M2YqK4rdgVg1zysoXGFG4IbCYahhuWLotnkpD 3IV7FTrZik4zWWuxsufUKREfiq7_VOAXcCA4ml2stEoxhKGGJZE4mL3CudBI Ey86BOCYEediulFg1dtRqrmBm1UO8TrByHSg9EUJRK812v84v0R6G5tu0YE7 2Kpa0Kfn12KYffTVIgj2LtqMBuBOc2j3fGi8p9HzaWnmTDl1l4I5j48sGfNq pvX0GjMykeg4TOFCJJj0p86LSS7bZbsBpaWPVSrr9w3Ra8dEUs3rNdcqbsti 9KF4wwtc2WlofJjcsmBmRVSh8YyTMEk.NDN9SJQ-- Received: from [109.121.36.90] by web164602.mail.gq1.yahoo.com via HTTP; Fri, 18 Apr 2014 04:01:15 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBBcHJpbCAxOCwgMjAxNCAxMDo0NCBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4gd3JvdGU6CgoKPiBBc3N1bWluZyB0aGV5J3JlIGFsbCBkdW1iIG9yIGxhenkgYmVjYXVzZSB0aGV5J3JlICJtaXNzaW5nIHRoZSBwb2ludCIKPiBzZWVtcyBsaWtlIGEgcHJldHR5IGJhZCBwbGFjZSBmcm9tIHdoaWNoIHRvIHN0YXJ0LgoKCmRpZG4ndCBoYXBwZW4uCgoKCj4gSWYgYWxsIHBlb3BsZSBnZXQgaXMgc25hcmsgd2hlbiB0aGV5IHByb2JlIHlvdXIgaWRlYXMsIEkBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397752559.76418.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1397755961.28237.YahooMailNeo@web164605.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8A155CA1@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1397767367.11500.YahooMailNeo@web164603.mail.gq1.yahoo.com> <1397802021.17514.YahooMailNeo@web164604.mail.gq1.yahoo.com> Message-ID: <1397818875.52846.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 18 Apr 2014 04:01:15 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/EbLGsgFezgttLe78PuT4j_ltv0E Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 18 Apr 2014 11:01:23 -0000 On Friday, April 18, 2014 10:44 AM, Murray S. Kucherawy wrote: > Assuming they're all dumb or lazy because they're "missing the point" > seems like a pretty bad place from which to start. didn't happen. > If all people get is snark when they probe your ideas, I'm pretty sure > they'll just stop answering. also didn't happen. why do u exactly defend someone who promoted google's commercial services? -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Apr 18 05:32: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 82FD21A01D4 for ; Fri, 18 Apr 2014 05:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 ihp6SyRQfnWo for ; Fri, 18 Apr 2014 05:32:39 -0700 (PDT) Received: from nm20-vm6.bullet.mail.gq1.yahoo.com (nm20-vm6.bullet.mail.gq1.yahoo.com [98.136.217.37]) by ietfa.amsl.com (Postfix) with ESMTP id AE85E1A01CF for ; Fri, 18 Apr 2014 05:32:39 -0700 (PDT) Received: from [98.137.12.188] by nm20.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 12:32:36 -0000 Received: from [98.137.12.224] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 12:32:35 -0000 Received: from [127.0.0.1] by omp1032.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 12:32:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 969202.95917.bm@omp1032.mail.gq1.yahoo.com Received: (qmail 87988 invoked by uid 60001); 18 Apr 2014 12:32:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397824355; bh=PLUqc5vP51/TnyIsCLPecaucqCgtmUo6iHB3LN8GWKE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dHSYjHP4ZorhAJSg39vTuZObQAZs6G8QCwwXKmVIk2eqV9p6tPx9MQpIp15WEgFwZSk6YaGcclB07au9dKm3X0y9QYj7wi/OQYEyQS7IRrbXXPXHfuUVSjRQXDs7jVPGsxKJufDIt0UDCvnOH0JI+aX57/qrLJ2tqU46YG5r92o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Z+8+S2ASF5U0mBSFgaNDRoSQfV168tGM0psy4pJmdR/7bxc2Yq29u9Bc1EnnSQzkYBLziejiBXV/1D8KJ4i7XSi3gR++hw/6uLw2g74Nivz3PJoYWYdFgJPrBvoKX9/i74KKQJhDmv/7ogpcP2ygYQ3kc8QG9EIs5wO6WLvP5hY=; X-YMail-OSG: fA4SqPkVM1nzKvBQ1k0k6CQ03NIFkJkjv0EXH.1aR7VQrkK 8RONrH.7ksEwIPtCQkxKEbV4adzZAu_zddnknhvZkp12MvazPM14MM1GHkl2 Vz5pJCGLugmEd0Egka8OIzudkvr14_Q3TkNe705XYg2WXm.TQRpoRX48quFV 9P_lmww3OeVa0wxL8g9XPFNCHiSmtnC2fcph_ZNIw0ZfplRlT4FbOnScddFB 2CT7jBsDZMgJhrgieebE5w3gpFpqlBEDPfJJdO5KxQbmVjpdY28jRC7VX6bh oxriRm7K32p..ccQDHz1T5rsCsCFfwGZr6VWArQ2D6KSJCtWqAwE0TCJD32r ZaXCYQ4YFayh5Q1kG7APab_LyO8M24XjAwgs.wGzzmnhm4OB6ZF5vcBdsarW vzzSRCfPTyDHbrxl7kcTeNfjvvqndumDieNkOnaNCmK547Att3od06EzVbR. htISXFiHnMD2RcsvOVEGC5RqUfdQ47fJLEorKRW7raxhmJ3XoLMy4VHboh6E VjtYXptCKEBQLwnQrq5WgXaLpvckm_5OygHyMYuca0o7m4Ta.6tnbljNFHkj EeqTOLsHeMiwdexpGvmbY5k4_Fw7fjcRJaXDwOWia3UAHXYKCVcYli5TwTge m1eO1 Received: from [109.121.36.90] by web164601.mail.gq1.yahoo.com via HTTP; Fri, 18 Apr 2014 05:32:35 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBBcHJpbCAxOCwgMjAxNCAxMDo0NCBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4gd3JvdGU6CgoKPiBTbyB5b3UgZG9uJ3Qgd2FudCB0aGUgYXV0aGVudGljYXRpb24gZW5mb3JjZW1lbnQsIG9ubHkgdGhlIHJlcG9ydHM_CgpubywgaSBkbyB3YW50IGF1dGhlbnRpY2F0aW9uIGVuZm9yY2VtZW50LiBpIGRvIG5vdCB3YW50IGFsaWdubWVudCBlbmZvcmNlbWVudC4KaSB3YW50IHBhcnNpbmcgb2YgYm90aCBTUEYgYW5kIERLSU0gaW4gQU5ELWJhc2VkIGxvZ2kBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1397339657.73886.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397495438.17678.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1397713832.37403.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1397746276.4551.YahooMailNeo@web164605.mail.gq1.yahoo.com> Message-ID: <1397824355.30469.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Fri, 18 Apr 2014 05:32:35 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/T3rCJvh7N_ucvq4KmgV7YOQTxNk Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 18 Apr 2014 12:32:43 -0000 On Friday, April 18, 2014 10:44 AM, Murray S. Kucherawy wrote: > So you don't want the authentication enforcement, only the reports? no, i do want authentication enforcement. i do not want alignment enforcement. i want parsing of both SPF and DKIM in AND-based logic and i want it standardized, and standardized rejection based on failure of such parsing, and standardized reporting, and standardized introduction in anti-spam filters. hint: "standardized" is the point here. if that, somehow, isn't obvious. > Isn't that what "p=none" does? nope. "p=none" simply excludes my email from DMARC completely. i do get reporting, but i don't get standardized parsing, or standardized rejection on failure, or standardized anti-spam filtering introduction, or whatever else builds on DMARC in the future. > So you're saying both need to pass (in the AND case), but it doesn't > matter which domains they validated? > Again, that means I can send any mail I want as your domain and that > would pass DMARC, and I'm not clear about why you want that. cause u r not fixing alignment problems u introduced in DMARC, and i have no other choice but to disregard alignment completely, yet i also don't care about possible phishing that much, cause either my domain doesn't get phished much or SPF/DKIM/anti-spam filtering on receivers' side works well in such cases, which brings me back to alignment again and how i don't care about alignment or how u don't want to fix it, so i decide i'll just turn it off, instead of bickering on DMARC mailing list about fixing the alignment problem, which u don't want to fix, cause u keep saying it's a feature. and came the time when google started defending problems as features. however, as i said, DMARC is way more than just alignment, and i do care about those other things, especially if there's AND-logic in the standard. 10 goto _top > Right, that's the third-party case discussed above. > There are a bunch of limitations, assuming this is something that's > actually in enough demand to add. and what does "enough demand to add" mean? who decides about what's enough, in this, adhoc something which isn't even an ietf approved wg? > For starters: (1) sticking the list in a DNS TXT field will not scale > (suppose you want to authorize a thousand third parties), and i just love how u r gonna authorize a 1000 3rd parties with DKIM-key sharing, instead. nice discussion we have here. maybe next time i can make ridiculous contra argument like this on some of ur new ideas, just to be fair. > (2) you have to keep the list current, which will need automation and > security around it as users seek to add entries (by subscribing to lists, > for example). i guess u r intentionally missing the point here. i have no other idea why it is so hard to read when i write "small players", few domains, or whatever else i wrote while trying to paint this "small" picture for everybody here. so, it's not 1000 domains, 4000 IPs, 50000 servers. it would be, on average, imo, 2 domains [for those who actually use the setting, which is already a special case, not a common practice]. > Of course, since DMARC is about keeping control over that, > maybe it's an expected scaling problem, but it's still something that > needs to be handled. which isn't enough of a reason against. >>> I totally agree there, especially since Sender-ID got almost no adoption >>> (see RFC 6686), and that seems unlikely to change now. >> it would change quite fast if we would make it part of DMARC. > What would be the value in doing so? alignment-pass in various special cases i'm trying to cover here with my proposals, which currently have alignment-fail status. if Sender-ID was part of DMARC, my "goodone.tk email stream coming from yahoo mail use case" would be solved instantly. it would also cover mailing lists, and whatnot, just because of benefits Sender-ID has over SPF. so, if Sender-ID was a part of DMARC-underlying mechanisms, i would drop all my proposals, cause my troubling case scenarios would be solved, as well as many others. > The fact that in several years nobody adopted Sender-ID > speaks pretty loudly to me. this is like saying that there r no business politics in protocol world. right. it's pretty obvious Sender-ID was a collateral victim of general displeasure with Microsoft's business model. who knows, we may soon see the same happening to Google too... if it haven't started already. > It seems to me more like you're talking about a way to extend specific > other domains to be allowed to send mail as your domain and still pass. > SPF and DKIM already have mechanisms to do that, not to mention > experimental extensions like ATPS. DMARC's alignment problem isn't SPF's or DKIM's problem. and if u r suggesting i should use DKIM extensions, which r rarely supported, or other tools, to fix problems DMARC introduces, then i'll just quit this mailing list, and ignore the entire protocol, cause it's broken and u r telling me u don't want to fix it. ps. i hope nobody felt threatened by my somewhat ironical tone in this message. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Apr 18 10:04: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 4A9311A01FE for ; Fri, 18 Apr 2014 10:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 wLJNOFt6anUS for ; Fri, 18 Apr 2014 10:04:13 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id B1EE51A01DE for ; Fri, 18 Apr 2014 10:04:12 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id i11so1999312oag.34 for ; Fri, 18 Apr 2014 10:04:08 -0700 (PDT) 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:content-type; bh=RXm3+cqpKVBvTk+I1xWVXg4JumO2WDkVynMluchQbIc=; b=C405KjYk032RUImuBQiodeDA0l0XolKNgcnkO/q8UVHA/efI7PbTm3Gg+ZD5xb3Zax MVmctMNONAJSkhnZTGGA+BJuUbxGUlGXZBR4CPfsahmFpZxSIOXTUxFqLkeQqMOx1WA6 DjOdkEsVF2Kf6YeSSmt42aRvAVwXnsUEWJzCTA6Cx17TDoG5783qzgDrDwE2RQXZw+Jz Dd4I81u81f4V8O1OJtp4yJefv9Ljd+IwRpb1ALBVarVK15bi9QYQI3qqoWEBT6VwKmAH Ll7yiRRJKTmYGZxePZ86EwW7KQ6g1penDV/SZVY1bzLGFBTt5IQV5LnPdjbOAI4dUVB9 Wepg== X-Gm-Message-State: ALoCoQkdL9GykFwOEyvy5bSMcRU9WjW/v9Gqz+NPRt4kyknE0WcWHj7/wRgEOrTmh5rdPCwQqf28 MIME-Version: 1.0 X-Received: by 10.182.28.195 with SMTP id d3mr18082468obh.19.1397840648434; Fri, 18 Apr 2014 10:04:08 -0700 (PDT) Received: by 10.60.119.35 with HTTP; Fri, 18 Apr 2014 10:04:08 -0700 (PDT) In-Reply-To: References: <534FFBDA.8040600@iecc.com> <53500623.6090807@taugh.com> Date: Fri, 18 Apr 2014 13:04:08 -0400 Message-ID: From: Joseph Humphreys To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Tubo2D_cdHxs81vnz8eYBjBcGf0 Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Apr 2014 17:04:16 -0000 On Fri, Apr 18, 2014 at 4:50 AM, Murray S. Kucherawy wrote: >> >> The alignment domain-list solution seems trivial to me, and it works >> without active support from the sender, which is nice. > > > How does it work without active support from the sender? Doesn't the sender > first have to ensure it's in that list? That's kind of an important step > for a list operator with a new subscriber from a "p=reject" domain. > Again, I have not been proposing this as a solution for mailing lists. It solves at least two other problems: third-party bounce handlers, and using your own domain with some large mail providers like gmail. In either case, the domain owner can use DMARC without requiring any support from the sender. This is not theoretical -- we have customers who are currently stalled on DMARC implementations and who could move forward if this were included in the spec. If you are willing to accept additional DNS lookups, you actually could use this to alleviate the mailing list problem, just by adding an include syntax for aligned domain lists. That would create a mechanism for people to make public, curated MLM whitelists. I hesitate to bring that up because I imagine some people won't like the idea of more DNS lookups, and I don't want the entire idea to get shot down by association. From nobody Fri Apr 18 11:00: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 5888A1A04A1 for ; Fri, 18 Apr 2014 11:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 bYzXDQaepbP3 for ; Fri, 18 Apr 2014 11:00:49 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 121861A0495 for ; Fri, 18 Apr 2014 11:00:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E8DE929C767; Fri, 18 Apr 2014 13:00:42 -0500 (CDT) 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 8_001r-vOZYd; Fri, 18 Apr 2014 13:00:42 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C75E929C773; Fri, 18 Apr 2014 13:00:42 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B21F829C76C; Fri, 18 Apr 2014 13:00:42 -0500 (CDT) 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 8CwoiRjK8X79; Fri, 18 Apr 2014 13:00:42 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 969E629C767; Fri, 18 Apr 2014 13:00:42 -0500 (CDT) Date: Fri, 18 Apr 2014 13:00:41 -0500 (CDT) From: Franck Martin To: Joseph Humphreys Message-ID: <1256700617.145686.1397844041664.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <534FFBDA.8040600@iecc.com> <53500623.6090807@taugh.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 - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: alignment and parsing logic as optionals Thread-Index: g2qe96q3s+JhQW9aSXVWA+GmtLaSAQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/L2aIj8bnTyvW00GdhGmZxkPUuXA Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Apr 2014 18:00:55 -0000 ----- Original Message ----- > From: "Joseph Humphreys" > To: dmarc@ietf.org > Sent: Friday, April 18, 2014 10:04:08 AM > Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals > > On Fri, Apr 18, 2014 at 4:50 AM, Murray S. Kucherawy > wrote: > >> > >> The alignment domain-list solution seems trivial to me, and it works > >> without active support from the sender, which is nice. > > > > > > How does it work without active support from the sender? Doesn't the > > sender > > first have to ensure it's in that list? That's kind of an important step > > for a list operator with a new subscriber from a "p=reject" domain. > > > > Again, I have not been proposing this as a solution for mailing lists. > It solves at least two other problems: third-party bounce handlers, > and using your own domain with some large mail providers like gmail. > In either case, the domain owner can use DMARC without requiring any > support from the sender. This is not theoretical -- we have customers > who are currently stalled on DMARC implementations and who could move > forward if this were included in the spec. > > If you are willing to accept additional DNS lookups, you actually > could use this to alleviate the mailing list problem, just by adding > an include syntax for aligned domain lists. That would create a > mechanism for people to make public, curated MLM whitelists. I > hesitate to bring that up because I imagine some people won't like the > idea of more DNS lookups, and I don't want the entire idea to get shot > down by association. > Not delving in the details, but I may be off base... It seems this solution is akin to have to add to your SPF record the whole of Google cloud or Salesforce cloud, with a "trust us" we don't allow any of our other members to send email on your behalf on any of our applications... https://dmarcian.com/spf-survey/google.com 212,996 authorized individual IPv4 addresses https://dmarcian.com/spf-survey/salesforce.com 228,934 authorized individual IPv4 addresses I prefer that 3rd parties relay our mail mail through our servers. From nobody Fri Apr 18 11:02: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 55F611A03C9 for ; Fri, 18 Apr 2014 11:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 RcYa8RuGyBoM for ; Fri, 18 Apr 2014 11:02:52 -0700 (PDT) Received: from nm4-vm7.bullet.mail.gq1.yahoo.com (nm4-vm7.bullet.mail.gq1.yahoo.com [98.136.218.166]) by ietfa.amsl.com (Postfix) with ESMTP id D3F1B1A041A for ; Fri, 18 Apr 2014 11:02:50 -0700 (PDT) Received: from [216.39.60.182] by nm4.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 18:02:47 -0000 Received: from [98.137.12.49] by tm18.bullet.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 18:02:46 -0000 Received: from [127.0.0.1] by omp1064.mail.gq1.yahoo.com with NNFMP; 18 Apr 2014 18:02:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 901197.39430.bm@omp1064.mail.gq1.yahoo.com Received: (qmail 18904 invoked by uid 60001); 18 Apr 2014 18:02:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1397844166; bh=Xoc4HbL7mYevKbNIvygIoWXa/o4yhxrjgGowTlllws4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=HM/3CWUaEne4Ct6XuvuKEfJeX+PCg492jSWnYmZSxGK76VGDrpOCIaTMvSbF3KI1v8yo2CtpAysPrecSo2OgAqrbp4+g1Kh36Y87M7AsNrJzEFojGFuW/nCulvEJq3S11ds/WtQTIALhJivTsoy/kvuBvD7UuyEyOZjNZQxHUPo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=wH1z0dUO+F8pMOySvMCG62s6IP+0aycn4vQv2P4tqsEZt/Q+v2uEr18X1Sh1Sv319V4A3hpOFWSe5DJm2S9OMXAS3VWvlnPCZ8fMjW1JYSamiGxEFdKLZjpOVlD78MPsDpMFZvEj/xv2XqJu4huvuiIVpa7V/CnWmsIXqPZOy2U=; X-YMail-OSG: rMF4EXcVM1n6RxtN58BjGXiAv7R_ZtfXq2PxzxoY43zmvQR 5RoXndJfD5TNfTMeZVPwl8lMxwUjByoevxQEspJNqXBrIlw.n6QfvhV2uGeC ubMD3tRBz7gy5TXlTo7e98Lm1pYD_kdDTKFegdP7gBWlrOw.nG0Q_nTY9WSK ySAh5J_1nArIRL_sIX8_DZ36YEqt78lBYOgDLlYfpPHeODJRwaFBiPJ2Cqzp DriM8yTzAdlUCqXLZp_EUC0opFM_FaKXRoYiLZGPrRFQbQdYWYx_.7DTn_sh jXFh9EAJ5HY__vgi0EHo2rCRgQyRaEDeBjvD1IkSQ0.zmA4B05n77ZKpStTh JKqvAC5.nDwvkudpsTBMQWzbaPHrzp1YBlauf23YGbWLNzj.lDCfql_6dMqx ehgu7VaZiGO.WKNYtjFAaHQgMA4jT2GqVnDExehpNPY4Yn2Wl3k_H4pOi4F1 dF7S5z_vGdOjEwjrylLrkLfU3PWpTdPr5Rqsu2umNBt1_xSWpxrNKKtlIKad TLcK57ufRCAOYprwHgwZBZdkv0Vm_7TBRmtdJxckG.abc01tHpOUjpSzBfqY bBeC17Gp.mmP1nH0woXFeoAhPFIr2hhyKVb6bbtveGbwv9DfpF5B8uTVKOXI E8SJfoixgZGfs3CdEvwA- Received: from [109.121.36.90] by web164606.mail.gq1.yahoo.com via HTTP; Fri, 18 Apr 2014 11:02:46 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpLCAxOCBBcHIgMjAxNCAxMzowNDowOCAtMDQwMCwgSm9zZXBoIEh1bXBocmV5cyA8amh1bXBocmV5cyBhdCBzYWxlc2ZvcmNlLmNvbT4gd3JvdGU6CgoKPiBBZ2FpbiwgSSBoYXZlIG5vdCBiZWVuIHByb3Bvc2luZyB0aGlzIGFzIGEgc29sdXRpb24gZm9yIG1haWxpbmcgbGlzdHMuCj4gSXQgc29sdmVzIGF0IGxlYXN0IHR3byBvdGhlciBwcm9ibGVtczogdGhpcmQtcGFydHkgYm91bmNlIGhhbmRsZXJzLAo.IGFuZCB1c2luZyB5b3VyIG93biBkb21haW4gd2l0aCBzb21lIGxhcmdlIG1haWwgcHJvdmkBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 Message-ID: <1397844166.17668.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Fri, 18 Apr 2014 11:02:46 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zOU7XOLcEflUzNPG2oI-KDJUAno Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 18 Apr 2014 18:02:57 -0000 On Fri, 18 Apr 2014 13:04:08 -0400, Joseph Humphreys wrote: > Again, I have not been proposing this as a solution for mailing lists. > It solves at least two other problems: third-party bounce handlers, > and using your own domain with some large mail providers like gmail. > In either case, the domain owner can use DMARC without requiring any > support from the sender. This is not theoretical -- we have customers > who are currently stalled on DMARC implementations and who could move > forward if this were included in the spec. u can easily guess my standing on this, from my previous messages. +1 > If you are willing to accept additional DNS lookups, you actually > could use this to alleviate the mailing list problem, just by adding > an include syntax for aligned domain lists. That would create a > mechanism for people to make public, curated MLM whitelists. I > hesitate to bring that up because I imagine some people won't like the > idea of more DNS lookups, and I don't want the entire idea to get shot > down by association. this seems promising, but i doubt it will have big support here. however, this could solve issues with mailing lists that do not want to adopt a DMARC-compatible way of doing things, which i absolutely support. DMARC should be adapted to account for our world, not the other way around. that said, and having examined Sender-ID spec better, all these issues could be solved just by having Sender-ID in DMARC. Sender-ID passes alignment where SPF fails, no matter what's DKIM status. so, we have two working solutions. do we have any will to actually solve the problem? or is status quo and finding excuses of higher priority? -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Apr 18 12:05: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 C02C81A043F for ; Fri, 18 Apr 2014 11:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, 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 XyCqFF3SRVlC for ; Fri, 18 Apr 2014 11:43:57 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF6B1A0461 for ; Fri, 18 Apr 2014 11:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1397846633; x=1429382633; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=U9zO0sYXY1U1rjHK/mfZ4MiyoIgqrYQ/RIg2+ggPY8c=; b=x4wwP5ZsedvzaLF3eODbVpiGRMT7UAVdM6cwfKhEPH4mO+uylbXXxSXn 1rzY1iAbi5jJg34RaFMgQUIXcvwKvOQ38hFeZ6YbL7XfT977gt3s36T1I LqrcDvUXGHdK1GT7qfehJorx/jNaJJmzuzsDQhpNgKcnCPNbrWCT00Arp Y=; X-IronPort-AV: E=McAfee;i="5400,1158,7412"; a="62180672" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 18 Apr 2014 11:43:52 -0700 X-IronPort-AV: E=Sophos;i="4.97,885,1389772800"; d="scan'208";a="664282486" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Apr 2014 11:43:53 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 18 Apr 2014 11:43:52 -0700 Message-ID: <53517267.7050905@qti.qualcomm.com> Date: Fri, 18 Apr 2014 13:43:51 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gXrVxoo31uT8kkzLXzROmvsCs1g X-Mailman-Approved-At: Fri, 18 Apr 2014 12:05:43 -0700 Subject: [dmarc-ietf] Mailing lists - assumptions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 18 Apr 2014 18:43:58 -0000 [Bcc'ing dmarc, but directed to ietf-822, since that's where we appear to be having the discussion for the moment.] These ideas about mailing lists have been rattling around in my head these past couple of days, and they're based on a bunch of design assumptions. So I figured I'd post my list of assumptions and see if anybody thought any of them were off in space. 1. The mailing list itself is going to have to participate in this in some way. There's no point in trying to design something for mailing lists that simply will not make any modifications. 2. In the end, we want mailing lists to be able to send messages that say "From: user@originatingdomain.example.com" and not have to say "From: list@listdomain.example.net". 3. If an originator sends mail to a mailing list, the originator is implicitly giving permission for the list to re-distribute the message "From:" the originator. 4. If an originating site allows its users sending mail to mailing lists at all, the site is OK with *any* mailing list re-distributing mail from its users. so long as the mailing list received the mail directly from the originating user through the originating site. That is, originating sites don't care about pre-vetting mailing lists; they just care that the mail sent by mailing lists came directly from their users. 5. For a recipient of mailing list mail, their site cares about whether the message they got came directly from the mailing list site, cares that the mailing list got the mail directly from the originating user's site, and cares that the mailing list got the mail relatively recently. For the most part, the recipient's site doesn't care how much has changed about the content of the message. The eventual recipient might care if the changes are in the extreme, but from a "is this spoofed spam" perspective, that really doesn't matter. 6. The mailing list cares about whether it got the message directly from the originating user's site. 7. An originating site would be willing to query (through a DNS lookup or otherwise) the first hop recipient for any message and stick something in the message that indicates, "This message came from originating user's site and was sent to recipient at such-and-so time", in order to facilitate #4 and #5. 8. The mechanism we use might need to chain: If I send to a mailing list A, which itself sends to another mailing list B, the eventual recipient will be able to see that the message it got came directly from B, which it got from A, which it got from me. Anything I screwed up there? Any assumption I'm missing? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sat Apr 19 22:25: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 53DDA1A0138 for ; Sat, 19 Apr 2014 22:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.602 X-Spam-Level: X-Spam-Status: No, score=-99.602 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_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_51=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8PRTR_2csnD for ; Sat, 19 Apr 2014 22:25:08 -0700 (PDT) Received: from winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 43D441A0137 for ; Sat, 19 Apr 2014 22:25:08 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1569; t=1397971496; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=yACXrtbInoEex9hlkpJhQ+rBoPQ=; b=YtyKrwLMWan+x4Yip51E rfaAqJws/tPCn+qDNlbpWnxIbN2lmhW/Q1F8+c3on7roKHCc6qOzBV6/BB3k8v1j 1P+/mCpYQA5aT+203vMyYb4uvCCY6iNsD1MNGL8y4WIG7QL2290bQ/GTGBAAUSxv qiPqBuekyuRgcf7RiSRMlSE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 20 Apr 2014 01:24:56 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1080068351.7140.3440; Sun, 20 Apr 2014 01:24:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1569; t=1397971421; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=XOHSsHh leAOwIxryU/gr7SJjb0eEGT5g/+bqx7dC6rw=; b=mWoIx/qqzRU46Opf03PK6Xp BBUA3DiQw0wDRSfO7A0f9LBfYJ7WXpQCnONcUoI8jFjj7yYDJxknXRNFiSLdkQd8 UPyV154VOXD2fLuBg8HjHRpgpN+/rDSrKKymYFX973G/LJBZrSuuIZB4008Fo0xn uSS89rwblyotwjGTGRoE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 20 Apr 2014 01:23:41 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1099596859.9.11676; Sun, 20 Apr 2014 01:23:40 -0400 Message-ID: <53535A22.7060306@isdg.net> Date: Sun, 20 Apr 2014 01:24:50 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/r5_m2tcTV6LCy5qfj44phEa0yy8 Subject: [dmarc-ietf] DMARC Extension for 3rd party Signers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 20 Apr 2014 05:25:12 -0000 I hope this would be a consideration as a fix or method to address the problem with DMARC's p=reject restrictive policy for 3rd party signers, including mailing list. Please correct any misunderstanding with the DMARC draft I may have. DMARC by definition requires alignment for matching domains. An adkim=s (strict) is an exact match and adkim=r (relaxed) means sub-domains are allowed. From what I see, there is no 3rd party allowance and the only things that saves you is p=none or p=quarantine. If the DMARC draft is locked down, I would like to propose an extension. Section 3.1.4.3 talks about authentication extensions: 3.1.4.3. Alignment and Extension Technologies If DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified. This would be a simple first step consideration -- A new ATPS tag atps=0 default, extension disabled allowed backward compatibility. atps=1 Valid alignment allows a valid 3rd party signature (no checks). atps=2 Valid alignment allows a valid 3rd party signature with ATPS (Authorized 3rd Party Signer) checking, RFC6541. atps=1 basically declares a relaxed MUST SIGN policy. atps=2 means the 3rd party signer must be authorized using RFC6541. Pete Resnick is exploring a May-Resign protocol idea, so we add an option for it. atps=3 Valid alignment allows a valid 3rd party signature using the May-Resign header method. -- HLS From nobody Mon Apr 21 09:01: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 D97501A0225 for ; Mon, 21 Apr 2014 09:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 Wo-vZQhpkiP6 for ; Mon, 21 Apr 2014 09:01:27 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id B36831A0223 for ; Mon, 21 Apr 2014 09:01:21 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id o6so4374983oag.36 for ; Mon, 21 Apr 2014 09:01:16 -0700 (PDT) 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:content-type; bh=CwRlmvenrui7QTk3bAlUYtHnjbixCWgya6qI90+AlG0=; b=eCwS7VXZk7rbsnVVoctV9lFWQcR/3HDfSoHB4QKAty2itRLnPEUcbGZd2h5eVd7B/w yJpgvGg9xztZJYKERPkJm2U/60nyNbtS5Tzvj+c99rzM/xTwd4NWWVCyFnu532it01+c /Gs9eoorxr6COntrBblTevyLA6I93hVbSOYNvvfMCmVe3dynKQDMNpHD8R2N4FnuN9zB ZCs3tQty21XHuewbRRaE1fYbNkkVRAk5KYp2XK2yWIYI5KMyOKmQhujVz4ci6esNLsYr /oBxw40n1Yxo57QrSbEz+wLdflJv/8zEgXryywQZSUVb2edDtfO12aOsouDWb09OQbR5 L4TA== X-Gm-Message-State: ALoCoQkJrY/o4spqkSxk/+LQ6OJ64S9Ynmw6MGNsuRI0HY79nDmlj3JXBSCQgRfMUZ8YxnOfReM1 MIME-Version: 1.0 X-Received: by 10.182.142.37 with SMTP id rt5mr888696obb.76.1398096076464; Mon, 21 Apr 2014 09:01:16 -0700 (PDT) Received: by 10.60.119.35 with HTTP; Mon, 21 Apr 2014 09:01:16 -0700 (PDT) In-Reply-To: <1256700617.145686.1397844041664.JavaMail.zimbra@peachymango.org> References: <534FFBDA.8040600@iecc.com> <53500623.6090807@taugh.com> <1256700617.145686.1397844041664.JavaMail.zimbra@peachymango.org> Date: Mon, 21 Apr 2014 12:01:16 -0400 Message-ID: From: Joseph Humphreys To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BjQLc6TsLMlLCuHqbBrkkyL7jLc Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 16:01:45 -0000 On Fri, Apr 18, 2014 at 2:00 PM, Franck Martin wrote: > >> If you are willing to accept additional DNS lookups, you actually >> could use this to alleviate the mailing list problem, just by adding >> an include syntax for aligned domain lists. That would create a >> mechanism for people to make public, curated MLM whitelists. I >> hesitate to bring that up because I imagine some people won't like the >> idea of more DNS lookups, and I don't want the entire idea to get shot >> down by association. >> > > Not delving in the details, but I may be off base... > > It seems this solution is akin to have to add to your SPF record the whole of Google cloud or Salesforce cloud, with a "trust us" we don't allow any of our other members to send email on your behalf on any of our applications... Yes, it is, unless the sender sets aside a more SPF-restricted domain to use for sending customers' mail. In fact it is very similar to including another organization's SPF record in your own, which does not seem uncommon. That doesn't seem to me like a shocking level of trust. > > https://dmarcian.com/spf-survey/google.com 212,996 authorized individual IPv4 addresses > https://dmarcian.com/spf-survey/salesforce.com 228,934 authorized individual IPv4 addresses > > I prefer that 3rd parties relay our mail mail through our servers. That is eminently reasonable, considering that your organization sends email as part of its core business, and is well prepared to take on that responsibility. Obviously, there are a lot of organizations out there who are not in that position. So I think the question is, does adding an "aligned domains list" feature encourage policies that are inherently unsafe? I would argue that authorizing a service provider to send for you on all of their IPs is not substantially different from authorizing them on one IP. Once you've authorized someone to send mail on your behalf at all, you are essentially trusting them to do it safely. Regards, Joe H From nobody Mon Apr 21 09: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 D961B1A023B for ; Mon, 21 Apr 2014 09:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 xfAzJv2beC4k for ; Mon, 21 Apr 2014 09:20:37 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 676261A0225 for ; Mon, 21 Apr 2014 09:20:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 394F62AC01D for ; Mon, 21 Apr 2014 11:20:21 -0500 (CDT) 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 q4fjVr7mTOQo for ; Mon, 21 Apr 2014 11:20:21 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 160AE2AC01B for ; Mon, 21 Apr 2014 11:20:21 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 072392AC01D for ; Mon, 21 Apr 2014 11:20:21 -0500 (CDT) 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 HtCedQHbTtva for ; Mon, 21 Apr 2014 11:20:20 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id DE0392AC01B for ; Mon, 21 Apr 2014 11:20:20 -0500 (CDT) Date: Mon, 21 Apr 2014 11:20:18 -0500 (CDT) From: Franck Martin To: dmarc@ietf.org Message-ID: <558993074.13410.1398097218749.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <534FFBDA.8040600@iecc.com> <1256700617.145686.1397844041664.JavaMail.zimbra@peachymango.org> 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 - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: alignment and parsing logic as optionals Thread-Index: zdvPS/afJOWohjEAiTFRuadCtkUuqA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/e5tuxXrN_EP7fcNAbd4RXotg-eQ Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 16:20:42 -0000 ----- Original Message ----- > From: "Joseph Humphreys" > To: dmarc@ietf.org > Sent: Monday, April 21, 2014 9:01:16 AM > Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals > > On Fri, Apr 18, 2014 at 2:00 PM, Franck Martin > wrote: > > > >> If you are willing to accept additional DNS lookups, you actually > >> could use this to alleviate the mailing list problem, just by adding > >> an include syntax for aligned domain lists. That would create a > >> mechanism for people to make public, curated MLM whitelists. I > >> hesitate to bring that up because I imagine some people won't like the > >> idea of more DNS lookups, and I don't want the entire idea to get shot > >> down by association. > >> > > > > Not delving in the details, but I may be off base... > > > > It seems this solution is akin to have to add to your SPF record the whole > > of Google cloud or Salesforce cloud, with a "trust us" we don't allow any > > of our other members to send email on your behalf on any of our > > applications... > > Yes, it is, unless the sender sets aside a more SPF-restricted domain > to use for sending customers' mail. In fact it is very similar to > including another organization's SPF record in your own, which does > not seem uncommon. That doesn't seem to me like a shocking level of > trust. Yes indeed, but then, the recent breaches shows too much trust has been sprinkled all around. Many ESP will provide you with dedicated IPs for your sends, this allows you to control your deliverability, the email security, etc... They come at a price, but you have what you pay for. > > > > > https://dmarcian.com/spf-survey/google.com 212,996 authorized individual > > IPv4 addresses > > https://dmarcian.com/spf-survey/salesforce.com 228,934 authorized > > individual IPv4 addresses > > > > I prefer that 3rd parties relay our mail mail through our servers. > > That is eminently reasonable, considering that your organization sends > email as part of its core business, and is well prepared to take on > that responsibility. Obviously, there are a lot of organizations out > there who are not in that position. > > So I think the question is, does adding an "aligned domains list" > feature encourage policies that are inherently unsafe? I would argue > that authorizing a service provider to send for you on all of their > IPs is not substantially different from authorizing them on one IP. > Once you've authorized someone to send mail on your behalf at all, you > are essentially trusting them to do it safely. > I wish this would be that simple, more often than not, you are pushed into an agreement and can only negotiate mitigating factors as to lower the risk. From nobody Mon Apr 21 11:54: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 473C51A0261 for ; Mon, 21 Apr 2014 11:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.129 X-Spam-Level: * X-Spam-Status: No, score=1.129 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 Kk3rr5QIF8g2 for ; Mon, 21 Apr 2014 11:54:22 -0700 (PDT) Received: from nm25-vm8.bullet.mail.gq1.yahoo.com (nm25-vm8.bullet.mail.gq1.yahoo.com [98.136.217.119]) by ietfa.amsl.com (Postfix) with ESMTP id 275201A025B for ; Mon, 21 Apr 2014 11:54:22 -0700 (PDT) Received: from [98.137.12.191] by nm25.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 18:54:17 -0000 Received: from [98.137.12.231] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 18:54:17 -0000 Received: from [127.0.0.1] by omp1039.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 18:54:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 180653.2048.bm@omp1039.mail.gq1.yahoo.com Received: (qmail 82289 invoked by uid 60001); 21 Apr 2014 18:54:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398106456; bh=v+gDwMJ68zPTVgc6dd+tjfPgeLrNZESU+b58dDGaErQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dkD2cPfW6uIH267XZFiuCo2DsVjoRHLu6dww4OmwSEsPqKYYVXwiXBZgPhhAXmJKLJAVh2dfbFaO3DGpcwiOGbCWND03VCx0WNI7TInNcnRGlnLNhAlwEbbVD+E7XqIitSOAwJiy4qiHaCNPpeXwZVQBBOBc2X2ODXk3KYYcii0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=TYGAzbkNX+5G+pI3kUCKPVvGV5TdwvtjIWPwr8FnFIpE+AzJRQem7DhvHcaksXNix/4OJLcdWr8AK92y5STWH+xaNEjFDLowyJeXZFAtm1bTxl/Qgr4dtZSwyGUAjftf6FyE6pugBsCZ9+khwB3Q/5eBMekz0yQEXOXlWxfqyLU=; X-YMail-OSG: s0RTVk4VM1kArlh4qsHq8hHU3cbcka3qFW5aBWmKZtoiemG T.CTt1ns0aPy7wh7JbpRvTbm7JjqlSuOj99zszv4pNaD5oTN.UY77ld9Cnhg kwmUFyhKyzq6PIZY7mYb7Ay9dr_pH6TjdaWbtceEx9vOTFb5uvGFYjkzqgmU _XJnxnNgH5nMuL46O6PAYHCFPU8GUKrUv0kS5n5U5g3WRid53b5Gjfwnerqw 2OHgmqHsPlRfPbh.5i3wOQmCnqkSvheYQ9MwmgHi.cZfJxNPqMit0mgg6ny7 are9CO09r96BdofbMXV83oiV0M14zrQQy2BdlyuUyPKFqG0CB1.0zBzu9AUQ JqcQADKBq83mXjwIiUxMcAlpjhW_tkhupQsRNrMqVH_qRXaTWlXCdrVrVsmc PaP1GWYQqHA0lloqrMFSfdqAH1SS6duvHyMwGnaMtSY3i2OxruRfi0z5sYxm rbleNYDGlEO3VdxjTVqOmt_o65I2TjX.6cyf.wVtKwjuGuguL5YLuU0zt3Kc vB7ksfNjA6PLkY9YBL4eMC.ptdaAbLBoA95DZlvc2mJedJRzkFGzS1L02Ddr hPOH8bcYHHD05kciN1kUi14q9yJRSmTIaPCJrQukQ0dNsdny1HFohu1Fi11V f0QGZ..LrAtXtz7_RHY9IMUE- Received: from [109.121.36.90] by web164602.mail.gq1.yahoo.com via HTTP; Mon, 21 Apr 2014 11:54:16 PDT X-Rocket-MIMEInfo: 002.001, T24gU3VuZGF5LCBBcHJpbCAyMCwgMjAxNCA5OjAwIFBNLCBIZWN0b3IgU2FudG9zIHdyb3RlOgoKCj4gVGhpcyB3b3VsZCBiZSBhIHNpbXBsZSBmaXJzdCBzdGVwIGNvbnNpZGVyYXRpb24gLS0gQSBuZXcgQVRQUyB0YWcKCnRoaXMgbWF5IGZpeCBES0lNIDNyZCBwYXJ0eSBzdXBwb3J0LCBidXQgZG9lcyBsaXR0bGUgdG8gc3VwcG9ydAozcmQgcGFydHkgU1BGLiBpIHRoaW5rIGl0J3MgaW1wb3J0YW50IHRvIGhhdmUgYSBmaXggZm9yIGFsbAp1bmRlcmx5aW5nIG1lY2hhbmlzbXMsIG5vdCBqdXN0IHNvbWUgb2YBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 Message-ID: <1398106456.78279.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Mon, 21 Apr 2014 11:54:16 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cVQKsdRWAoAX7R4yt3rt7z9kh0g Subject: Re: [dmarc-ietf] DMARC Extension for 3rd party Signers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 18:54:24 -0000 On Sunday, April 20, 2014 9:00 PM, Hector Santos wrote:=0A=0A=0A> This woul= d be a simple first step consideration -- A new ATPS tag=0A=0Athis may fix = DKIM 3rd party support, but does little to support=0A3rd party SPF. i think= it's important to have a fix for all=0Aunderlying mechanisms, not just som= e of them.=0A=0Aconsidering DMARC may include additional underlying mechani= sm in=0Athe future, a fix for 3rd party needs to be DMARC-based, not=0Abase= d on whatever underlying mechanisms are included in DMARC=0Ainstead, imo. i= f we start fixing underlying mechanisms just to=0Ahave them DMARC-imposed a= lignment requirement compatible,=0Awe are introducing new griefs to be deal= t with in the future,=0Aand adding bunch of incompatibilities with legacy s= upport for=0Athose protocols. so, whoever supports DMARC will have to add= =0Asupport for all those new extensions and additional protocols=0Awhich ma= y be more than what they are willing to do, opting for=0Ajust ignoring DMAR= C completely.=0A=0Aalso, such path simply creates more resource usage, espe= cially on=0ADNS, cause all those extensions have their DNS checks, and=0Aso= metimes more than one. also, more protocols, more libraries=0Arunning on se= rver, fighting for resources...=0A=0Awhy should we go that line, when it's = easier to build a DMARC-based=0Asupport for 3rd party and fix the problem a= t the source?=0A=0A=0A> atps=3D0=A0 default, extension disabled allowed bac= kward compatibility.=0A> atps=3D1=A0 Valid alignment allows a valid 3rd par= ty signature (no checks).=0A=0Athis is similar to specifying adkim=3Dn, the= way Tomki Camp already=0Asuggested, which i like better instead, since it'= s DMARC-based.=0A=0A=0A> atps=3D2=A0 Valid alignment allows a valid 3rd par= ty signature with ATPS=0A> (Authorized 3rd Party Signer) checking, RFC6541.= =0A=0Aa receiver wishing to support ATPS can account for it during processi= ng=0ADMARC, without any change in DMARC itself.=0A=0Ahowever, i'm quite sur= e everybody would be much more happy with a=0Asingle working protocol, inst= ead of bunch of extensions.=0A=0A=0A> atps=3D3=A0 Valid alignment allows a = valid 3rd party signature using=0A> the May-Resign header method.=0A=0Awhic= h is what exactly? i guess something similar to adkim=3Ds:yahoo.com,=0Awhic= h i proposed already, but if u would like to continue lobbying for=0Athis i= dea, please elaborate and provide examples.=0A=0A=0Ain any case, i would li= ke to see what benefits these solutions have=0Aover other suggested proposa= ls, like those suggested by=0AJoseph Humphreys, Tomski Camp and me, all of = which tend to fix=0ADMARC, and not introduce requirements for additional ex= tensions to=0Aunderlying protocols.=0A=0Ai can see many cons with ATPS-path= while comparing the two principally=0Adifferent ideas.=0A=0ADMARC was crea= ted as a solution for a problem a bunch of other=0Aextensions tried coverin= g before already. all about failing.=0A=0Awe could skip that broken-path wi= th DMARC today, since it's still in=0Adevelopment, and simply add 3rd party= support to its base. i see=0Ano issue with the idea of authorised alignmen= t. it's natural to the=0Away email works. with some thinking, i'm sure we c= an make it work=0Afor mailing lists too.=0A=0Athis is how i read J. Trent A= dams' last post.=0A=0A=0A-- =0AVlatko Salaj aka goodone=0Ahttp://goodone.tk From nobody Mon Apr 21 12:38: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 99BFC1A0270 for ; Mon, 21 Apr 2014 12:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 acM4IQcMI-Ym for ; Mon, 21 Apr 2014 12:38:02 -0700 (PDT) Received: from nm2-vm1.bullet.mail.gq1.yahoo.com (nm2-vm1.bullet.mail.gq1.yahoo.com [98.136.218.128]) by ietfa.amsl.com (Postfix) with ESMTP id E39AD1A0263 for ; Mon, 21 Apr 2014 12:38:01 -0700 (PDT) Received: from [216.39.60.184] by nm2.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 19:37:56 -0000 Received: from [98.137.12.195] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 19:37:56 -0000 Received: from [127.0.0.1] by omp1003.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 19:37:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 951777.33627.bm@omp1003.mail.gq1.yahoo.com Received: (qmail 13792 invoked by uid 60001); 21 Apr 2014 19:37:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398109076; bh=pd9nwlzh5qp0tnS5eHN/E8Gy7+1Y3djbLEQEwmcdxhU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=IKMOOFLKFkG0ZBO1zFDi/KHsyHCH4ukBQS3w0s6wGFLAd6zrQ+IZg3O8YohkTfF/J9mMefS+oatRo5hVTN09qp+jMQC7Pg9vsgt5+M+eDceBVc+jCZmcun8O+x2Bs2stFbhxoBT7lwxuLvndSsZP2lRAEqw8tDHwQFsZs/YAUWs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=5XvSVCsgRlTkko1m70HYkbm769s3a7p1yLc4dqxVpkmLyl8qu2une/Xw5ieJW6TgBhhZg2DyzmVDi/jp3JaApAhRWKPvyzVRmBrfpH9Xfs6orMNjFYVdPdfwcYz0bSnwrx02jdJI2cttrW1L5GpB8KT2PHtOFacZ2uNgReeRQS4=; X-YMail-OSG: 9g7zV6cVM1kF3gUjO2zAl2oRkiI61iheuT.L20WCNqjXmHc zZY1gUgEa3GeMIm0hbWkZQhHhBtJHZQ1YuqyFpewplvT87gOuCdjvz5GrsBi LdGW.ES.ZqAuy08YS55NwatZ96EcK0slusPbNGi1VNZ3N5fscR6qzqs3uf_c X7gthNyYq8ybIfE5N6zrJv8hRh9ZdLmxGvbEZgoPNdoa8ddMjwHsY3g1deA0 JfYht8YYyS1kyOYeSLmlXvF6TVQzT8frD4jhsPOKEeKq8Dcbpe6BLK9pFPQX 1hyd8FqGH3eNJ1dmTqcwudmXSGIsnp5SmvnRS_FzBtHMfc9VTDhL3DeX3guV .oaGiJF.mKVm4rNenNNfYIioX_yKhYnOBvVAiZwQnOFr0F0Z3NVCOkWZoCKZ XOynChXdbn3Xv7XBiDj.y3BoW_0k68yJGnmXf8xEbLD0BzBAIVF2XEtGkiAS iUd4rkCFKvMVVDHZZCHqVLqk2SqYYRwHKwFPxb1dMdjd3FaBXGfZ_Xx1GIfF J6tWdBYA.4UNkx6h_cv_2HnC6nqGqIzdRxTqtZPxjbsDT1b9559QorAA4U6x xnBUoxVhMsOv.ibtRQ8vzyiC3RhJUpoOgtY8- Received: from [109.121.36.90] by web164605.mail.gq1.yahoo.com via HTTP; Mon, 21 Apr 2014 12:37:56 PDT X-Rocket-MIMEInfo: 002.001, T24gTW9uZGF5LCBBcHJpbCAyMSwgMjAxNCA5OjAxIFBNLCAiZG1hcmMtcmVxdWVzdEBpZXRmLm9yZyIgPGRtYXJjLXJlcXVlc3RAaWV0Zi5vcmc.IHdyb3RlOgoKCj4.IFRoYXQgZG9lc24ndCBzZWVtIHRvIG1lIGxpa2UgYSBzaG9ja2luZyBsZXZlbCBvZiB0cnVzdC4KPiBZZXMgaW5kZWVkLCBidXQgdGhlbiwgdGhlIHJlY2VudCBicmVhY2hlcyBzaG93cyB0b28gbXVjaCB0cnVzdAo.IGhhcyBiZWVuIHNwcmlua2xlZCBhbGwgYXJvdW5kLiBNYW55IEVTUCB3aWxsIHByb3ZpZGUgeW91IHdpdGgKPiBkZWRpY2EBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: Message-ID: <1398109076.63587.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Mon, 21 Apr 2014 12:37:56 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gegJdaB53b-w5Hc0AZSwkZZUB38 Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 19:38:05 -0000 On Monday, April 21, 2014 9:01 PM, "dmarc-request@ietf.org" wrote: >> That doesn't seem to me like a shocking level of trust. > Yes indeed, but then, the recent breaches shows too much trust > has been sprinkled all around. Many ESP will provide you with > dedicated IPs for your sends, this allows you to control your > deliverability, the email security, etc... They come at a price, > but you have what you pay for. should i read this as: if u want DMARC 3rd party support, please pay? maybe we should then just forget about making DMARC an open standard, instead just paying for proprietary solutions in the same area. that's about much better security overall. faulty thinking, if u ask me. i have no problem with making a standard as flexible as possible and let the domain owners' decide what and how much security they like. introducing authorised alignment doesn't essentially break DMARC. it just makes it more natural to email today and also adds support for things we, obviously, need and use. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Mon Apr 21 14:19: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 66A011A0292 for ; Mon, 21 Apr 2014 14:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 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.272, 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 aMPgLdrmSIAq for ; Mon, 21 Apr 2014 14:19:20 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) by ietfa.amsl.com (Postfix) with ESMTP id B19F51A02C1 for ; Mon, 21 Apr 2014 14:19:20 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s3LLJ6j2039809 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 21 Apr 2014 14:19:12 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s3LLJ6j2039809 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1398115152; bh=YcG2xCMuMkkkUjU5FHsYrQE0mriokWcsFjlp+OUS1lk=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aYYD0ELEU6sqiWPqld8JdbIcPWdH1DdBBG+RQKtsqongVaVM0BOrE/ZKCj+F8Cu5E PX43eFZzHSYRkQkUmwZdV/07a0+cC7A1JXlXeIIdWRxzLhwWakgBXErbhEr9mwwWzZ eKlCnizTMuDnfZAuoLYjlxowfd3emeNJbDcT73Ms= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <53558B4C.2070800@crash.com> Date: Mon, 21 Apr 2014 14:19:08 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <1398109076.63587.YahooMailNeo@web164605.mail.gq1.yahoo.com> In-Reply-To: <1398109076.63587.YahooMailNeo@web164605.mail.gq1.yahoo.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.2.7 (segv.crash.com [72.52.75.15]); Mon, 21 Apr 2014 14:19:12 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tjRRlLkcz0j5M8CW_lK7YBu8Ukg Subject: Re: [dmarc-ietf] alignment and parsing logic as optionals X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 21:19:26 -0000 On 04/21/2014 12:37 PM, Vlatko Salaj wrote: > I think Franck wrote: >>> That doesn't seem to me like a shocking level of trust. >> Yes indeed, but then, the recent breaches shows too much trust >> has been sprinkled all around. Many ESP will provide you with >> dedicated IPs for your sends, this allows you to control your >> deliverability, the email security, etc... They come at a price, >> but you have what you pay for. > should i read this as: if u want DMARC 3rd party support, please > pay? No, this was a concern and for many a best practice well before DMARC arrived. Using a large pool of vendor/ESP IP addresses leaves the sending organization (ABC) exposed to: - IP reputation impacted by all other customers - Another ESP customer's account being used to send email as ABC (depends on ESP controls) - Security of entire ESP infrastructure versus a small subset (dev systems, disaster recovery, etc) In other cases it's part of a more general policy that the vendor/ESP not use shared infrastructure when handling any of the contracting company's (customers') data. --S. From nobody Mon Apr 21 14:32: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 27D4F1A02D0 for ; Mon, 21 Apr 2014 14:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.702 X-Spam-Level: X-Spam-Status: No, score=-98.702 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_51=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOlEtPor7V0c for ; Mon, 21 Apr 2014 14:32:06 -0700 (PDT) Received: from ntbbs.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 060601A02CD for ; Mon, 21 Apr 2014 14:32:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8478; t=1398115911; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=fB5fNqUu78Mo3A8WiKLolI+PdOM=; b=oxYdaw2YLEK5IBFK48PO rMX2k6/GcaQbVUgAM1hKLTDs0dUXvxohSSOhT6a7qRI6H1Xq9SH1rkLsHRHlTXG+ dQhYbTXzXHYjlG13uUz+mgMK6rOKsRciuuxZIgrogwzHcfdEIxehDwl4dPqDhpuJ cbCiRF9YPUjzLfB3YMUqvuU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 21 Apr 2014 17:31:51 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1224481955.10825.2376; Mon, 21 Apr 2014 17:31:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=8478; t=1398115831; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fkpiM9A v7cdCOFMhtMN1l7zHvEajdcYByrHZQ7B9DSE=; b=cHuwpzEfC/eC2/6heV1BDbl oHWdjeImrxIk368iBZVFf6PrvNXO2KgQZ3KrrNFxiGuRq/tCvjdUnunB1s6/vVHs EUWrjb2PPYNQLe4qA+rJsw10TGpP0mrEznCUvDPvb5u+1viJWP8PDdxtHhIEfQT+ AoDdDoMMf10/k0tqq8bY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 21 Apr 2014 17:30:31 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1244007625.9.10572; Mon, 21 Apr 2014 17:30:30 -0400 Message-ID: <53558E41.5030704@isdg.net> Date: Mon, 21 Apr 2014 17:31:45 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Vlatko Salaj , "dmarc@ietf.org" References: <1398106456.78279.YahooMailNeo@web164602.mail.gq1.yahoo.com> In-Reply-To: <1398106456.78279.YahooMailNeo@web164602.mail.gq1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-U4DYAAGM8CVNqQ0D2FxULfZ7PU Subject: Re: [dmarc-ietf] DMARC Extension for 3rd party Signers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 21:32:10 -0000 On 4/21/2014 2:54 PM, Vlatko Salaj wrote: > On Sunday, April 20, 2014 9:00 PM, Hector Santos wrote: > > >> This would be a simple first step consideration -- A new ATPS tag > > this may fix DKIM 3rd party support, but does little to support > 3rd party SPF. i think it's important to have a fix for all > underlying mechanisms, not just some of them. How do you define a 3rd party SPF condition that isn't already defined and authorized by the 1st party? IOW, by virtue of the 1st party adding the 3rd party information into a SPF record, it is inherently ready for 3rd party operations. No? This would be different that the DKIM + Author Domain Policy security model. The problem with all the author domain policy protocols is that anyone can SIGN. The original SSP (Sender Signer Practices) had 3rd party semantic and controls. ADSP pruned and reduced SSP to 1st party semantics. The pruning left holes and ADSP was left unsolved. DMARC followed up with its own more explicit 1st party only semantics. The main difference SSP, ADSP and DMARC is that finally someone has taken the rejection handling semantics seriously and began to apply it. That also means that any domain with ADSP dkim=discardable can expect to see rejection/discard to be finally enabled. See PAYPAL.COM ADSP and DMARC records. Also, consider that DMARC "may" have violated RFC5016 "Requirements for DKIM Signing Practices Protocol" section 5.3, provision #10: 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. Refs: Deployment Consideration, Section 4.3. If DMARC is about conforming to DKIM operations, then it SHOULD of provided the option for 3rd party signers to exist. DKIM is about 3rd party TRUST support. Even the policy advocated accepted that model, but we also felt POLICY was a fundamental part too. > considering DMARC may include additional underlying mechanism in > the future, a fix for 3rd party needs to be DMARC-based, not > based on whatever underlying mechanisms are included in DMARC > instead, imo. if we start fixing underlying mechanisms just to > have them DMARC-imposed alignment requirement compatible, > we are introducing new griefs to be dealt with in the future, > and adding bunch of incompatibilities with legacy support for > those protocols. so, whoever supports DMARC will have to add > support for all those new extensions and additional protocols > which may be more than what they are willing to do, opting for > just ignoring DMARC completely. I am not sure what that all means, but DMARC is notT conforming to the DKIM specification that by design allows for 3rd party operations. So whatever the above means, DMARC does need to be fixed or not endorsed by the IETF. DKIM is a STD level specification now. DMARC must FIT with DKIM, not the other way around. > also, such path simply creates more resource usage, especially on > DNS, cause all those extensions have their DNS checks, and > sometimes more than one. also, more protocols, more libraries > running on server, fighting for resources... Yes, ATPS does add more DNS records, but that seems to be an more acceptable in application design today, i.e. just like XML. High overhead processing which today machines and communication speeds can handle making it feasible to consider. > why should we go that line, when it's easier to build a DMARC-based > support for 3rd party and fix the problem at the source? Agree, but if there is going to be resistance by the "gate keepers" of the specification and they won't do the "right thing" then the IETF needs to make the corrections, and the best current way to do this is with extensions which DMARC section 3.1.4.3 allows. I agree, it should be part of the base spec. >> atps=0� default, extension disabled allowed backward compatibility. >> atps=1� Valid alignment allows a valid 3rd party signature (no checks). > > this is similar to specifying adkim=n, the way Tomki Camp already > suggested, which i like better instead, since it's DMARC-based. If adkim=n(one) was proposed then that would do the trick to satisfy this particular "MUST BE SIGNED, BY ANYONE" practice, it would match: SSP o=- signature required, 3rd party allowed policy ADSP dkim=all signature required, 3rd party allowed policy? The problem was ADSP proposed standard was that it was unclear whether dkim=all also allowed 3rd party signatures. You should review the 9+ years of R&D done with DKIM + POLICY layer, starting with SSP and ADSP to see how DMARC evolved and what fell thru the cracks with it. My thinking was that DMARC was never really meant to be a policy handling protocol but a reporting protocol. >> atps=2� Valid alignment allows a valid 3rd party signature with ATPS >> (Authorized 3rd Party Signer) checking, RFC6541. > > a receiver wishing to support ATPS can account for it during processing > DMARC, without any change in DMARC itself. > > however, i'm quite sure everybody would be much more happy with a > single working protocol, instead of bunch of extensions. Sure, but you also have to be prepared for extensions too. >> atps=3� Valid alignment allows a valid 3rd party signature using >> the May-Resign header method. > > which is what exactly? i guess something similar to adkim=s:yahoo.com, > which i proposed already, but if u would like to continue lobbying for > this idea, please elaborate and provide examples. Mr. Resnick can provide more details, but in general, the point was to show flexibility with a new tag that allows for additional alignment processing. > in any case, i would like to see what benefits these solutions have > over other suggested proposals, like those suggested by > Joseph Humphreys, Tomski Camp and me, all of which tend to fix > DMARC, and not introduce requirements for additional extensions to > underlying protocols. Again, there is 9+ years of R&D. Overall, the #1 issue was not that it wasn't a good idea, but how to SCALE it and how do manage it. It adds complexity. But the #1 resistance was the mailing list folks who didn't want to have any restrictions on (re)signing mail. See above about section 5.3, item 10 in RFC5016. But there was proof of concepts and operations did already yse ADSP plus ATPS. There is an even a ADSP + ATPS wizard zone creator and simulator at: http://www.winserver.com/public/wcadsp > DMARC was created as a solution for a problem a bunch of other > extensions tried covering before already. all about failing. There is only one difference -- rejection was finally switched on. ADSP did have support too by many of the high value domains. But I don't think we were quite ready to do the rejection/discarding enforcement. We were just processing and logging the results to hopefully gather data with the AUTH-RES header. Reporting was always suggested but it was also viewed as something to limit potential abuse and it was never formalized. That is what DMARC did and what YAHOO did was finally turned on the rejection switch. Thats really the main and only true event shocker here, IMO. Not DMARC as a "language" itself because we did have SSP and ADSP but we had too many IETF opponents against POLICY regarding middle ware issues -- hence this issue with YAHOO now. DMARC was produced outside the IETF as it was envisioned to be the only way to get something moving. Unfortunately, they really didn't do a good job in satisfying all the possible boundary conditions of the DKIM+POLICY+TRUST model. In other words, they didn't really learn, did they? DMARC is very limited and that is what the IETF has to address. > we could skip that broken-path with DMARC today, since it's still in > development, and simply add 3rd party support to its base. i see > no issue with the idea of authorised alignment. it's natural to the > way email works. with some thinking, i'm sure we can make it work > for mailing lists too. Agree. -- HLS From nobody Mon Apr 21 15:09: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 AD55E1A02D1 for ; Mon, 21 Apr 2014 15:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 FKDkXY-DXiuN for ; Mon, 21 Apr 2014 15:09:00 -0700 (PDT) Received: from nm19-vm4.bullet.mail.gq1.yahoo.com (nm19-vm4.bullet.mail.gq1.yahoo.com [98.136.217.27]) by ietfa.amsl.com (Postfix) with ESMTP id 777201A0039 for ; Mon, 21 Apr 2014 15:09:00 -0700 (PDT) Received: from [98.137.12.188] by nm19.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 22:08:55 -0000 Received: from [98.137.12.244] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 22:08:55 -0000 Received: from [127.0.0.1] by omp1052.mail.gq1.yahoo.com with NNFMP; 21 Apr 2014 22:08:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 407948.42317.bm@omp1052.mail.gq1.yahoo.com Received: (qmail 61883 invoked by uid 60001); 21 Apr 2014 22:08:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398118135; bh=mh/Uhq+whoabtgaNkx5htxM9hpWYOo7MpGlMs3h/YUY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=M7nhytxBKVwFD1xK+65ZbsYOqVYHz33KZnmvdlyFGfIIm/bXPFNc2IUYOQqQXSdNLAaC9fv2yoch9xstKh7kiMcWj7s4P9N2EPz8vITAVXEsyLOT6DyvY1US+xF8Zjqagy5rEOlFrBxAyBwWH86kI3RF/Bpiga40TLmiAbjI/4o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gbFwUTTTkgwIdQRGUAEz84ST0mJo+VnbICFp0+xgv4oDJa09X4NvPUeXhXYhovJlTaC2yNzIZzsj4k0SNg6yn1gYcG/Y1ZaAAx8ED4EgGO5KE1lk5HcqbkTKpU7Ufpd6y/rQaHDbaPZevFOymaOfVebPwW6sOWVjxw6nW8YMc8Y=; X-YMail-OSG: 7EgESpgVM1kCSMA0Cmwnf0e0X8si94yXv9YPVb9oW97RTf9 CO.Ejn5FR8scrNn_bXVdbxC4542k_SjuiCsS0n7WDCsJ7xmRFCUmOmi48eB0 5ZIy7p3xWP1x_x6X9hJdb0ejEHGu5y8dWu9Qai9Zbyd3JSjvLUKF9wJ23qGC gZdxFch3c41mrQc90O4x1vbQVM8tVPqJ3EibDVzviSH6H9Cq9nEUzBPilfJT 1Pk93epVltHwRqIpNvtNHm2ptZ4x6VrCUndlL.JVEo6twtlOvoww.lbvylJQ hD9ZlKsqXaJQiA44svqqQycqvKVnc.Ll.3l0HYx3uM4orrFiKvnx3A757aow wd44K0iKsI4RBIz8Pk0hu1s9EYWTYxjcaOtyjMT9T5WL_kInxuEo9Gd2eVnA tJhpKRimh4.6x66sNQt_4VLtgrJA3KSuKqSv2b13adqpW8giYc03hKQ_psfK Hm1oGsg2ZcgNU8nFoS1saGWqNAPZjzvC9N1vDMaRv60BUJwWfQ2FnYcqy62J TxgJ27XGkO1TvGpfu9OlTEFeNlN8YhyRT14Its9sV07cHGLBs3ls1vHhJpGg gNDPPS53NbENzl_AsMni8MDYtz4fIsf7lBHlBKgRSLYEMwoI7DEjUXKFLGle 28a0.smJ8TSfnwq4- Received: from [109.121.36.90] by web164605.mail.gq1.yahoo.com via HTTP; Mon, 21 Apr 2014 15:08:55 PDT X-Rocket-MIMEInfo: 002.001, T24gTW9uZGF5LCBBcHJpbCAyMSwgMjAxNCAxMTozMiBQTSwgSGVjdG9yIFNhbnRvcyA8aHNhbnRvc0Bpc2RnLm5ldD4gd3JvdGU6CgoKPj4.IFRoaXMgd291bGQgYmUgYSBzaW1wbGUgZmlyc3Qgc3RlcCBjb25zaWRlcmF0aW9uIC0tIEEgbmV3IEFUUFMgdGFnCj4.IHRoaXMgbWF5IGZpeCBES0lNIDNyZCBwYXJ0eSBzdXBwb3J0LCBidXQgZG9lcyBsaXR0bGUgdG8gc3VwcG9ydAo.PiAzcmQgcGFydHkgU1BGLiBpIHRoaW5rIGl0J3MgaW1wb3J0YW50IHRvIGhhdmUgYSBmaXggZm9yIGFsbAo.PiB1bmRlcmx5aW4BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1398106456.78279.YahooMailNeo@web164602.mail.gq1.yahoo.com> <53558E41.5030704@isdg.net> Message-ID: <1398118135.56070.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Mon, 21 Apr 2014 15:08:55 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <53558E41.5030704@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZjNex8KkfPfpFD_ff40NqObTo3s Subject: Re: [dmarc-ietf] DMARC Extension for 3rd party Signers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:09:05 -0000 On Monday, April 21, 2014 11:32 PM, Hector Santos wrote:= =0A=0A=0A>>> This would be a simple first step consideration -- A new ATPS = tag=0A>> this may fix DKIM 3rd party support, but does little to support=0A= >> 3rd party SPF. i think it's important to have a fix for all=0A>> underly= ing mechanisms, not just some of them.=0A> How do you define a 3rd party SP= F condition that isn't already defined=0A> and authorized by the 1st party?= =A0 IOW, by virtue of the 1st party=0A> adding the 3rd party information in= to a SPF record, it is inherently=0A> ready for 3rd party operations. No?= =0A=0Ano. 3rd party SPF support in DMARC's alignment context means support= =0Afor 3rd party SMTP MAIL FROM, or 3rd party HELO/EHLO. by SPF specs,=0Ath= ere are no provisions for 3rd party SPF support in this sense.=0A=0Awhat SP= F specs do allow is adding 3rd party servers to the IP pool of=0Asenders, b= ut that's not full 3rd party support actually, in DMARC=0Aalignment terms.= =0A=0A=0A> If DMARC is about conforming to DKIM operations, then it SHOULD = of=0A> provided the option for 3rd party signers to exist.=0A=0Ai agree on = this fully. it's only the question of how... and i would=0Arather see it in= side DMARC, instead of outside of it.=0A=0A=0A> My thinking was that DMARC = was never really meant to be a policy=0A> handling protocol but a reporting= protocol.=0A=0Athis does make sense, especially how badly alignment requir= ement=0Awas imagined. however, since it's more than a reporting protocol no= w,=0Aand it's a promising one, we should fix it to include 3rd party=0Aprop= erly, as it should have been done in the 1st place.=0A=0A=0A> Unfortunately= , they really didn't do a good job in satisfying=0A> all the possible bound= ary conditions of the DKIM+POLICY+TRUST model.=0A> In other words, they did= n't really learn, did they? DMARC is very=0A> limited and that is what the = IETF has to address.=0A=0A+1!=0A=0A=0A-- =0AVlatko Salaj aka goodone=0Ahttp= ://goodone.tk From nobody Mon Apr 21 16:18: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 9510B1A0303 for ; Mon, 21 Apr 2014 16:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6Ag7VZsGuuk for ; Mon, 21 Apr 2014 16:18:36 -0700 (PDT) Received: from groups.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 070251A030B for ; Mon, 21 Apr 2014 16:18:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1353; t=1398122301; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=mnzCa/dJTlJqQXFv4o8cs9PHpb4=; b=ltWPqK5XuaulIedcXOPP mXGLLDjV+rOh8enACB2xkwM9closgWd7dqhHvxrhAikQ0ziXPq6jZYLVkUVRjeY7 DtNZcDFECSZhp8zQsGOpEcuUPW6UqZnr4e0Rzd5aQFItoQ/n4NChV//1ZhrVhRKS dUL5fqiD45eXd6XfrtBKi+E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 21 Apr 2014 19:18:21 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1230872146.10825.2024; Mon, 21 Apr 2014 19:18:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1353; t=1398122222; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=katOPs7 m4dMpYHjcaVYQhzAKBRCWE2172cbmYUtalYI=; b=FWnxPhNKo5oT6Wj3jzxf293 W/nU7XzJKkZMsRm44LbnwbspHrUYIav8LkvHYsC0zgW/pj2L570utvcMvpeNjJgC aWB6Gu/HgKt0d5mmADDNk9kSf47XhcqkrVWcRpM0lStrUosAZ+LLbDww4d8rez9K Lz5pLoun28dp3eH31cdk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 21 Apr 2014 19:17:02 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1250398328.9.10600; Mon, 21 Apr 2014 19:17:01 -0400 Message-ID: <5355A739.1000409@isdg.net> Date: Mon, 21 Apr 2014 19:18:17 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Vlatko Salaj , "dmarc@ietf.org" References: <1398106456.78279.YahooMailNeo@web164602.mail.gq1.yahoo.com> <53558E41.5030704@isdg.net> <1398118135.56070.YahooMailNeo@web164605.mail.gq1.yahoo.com> In-Reply-To: <1398118135.56070.YahooMailNeo@web164605.mail.gq1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3IX2jWBy1sngSkFd_ltiWpZT1Ho Subject: Re: [dmarc-ietf] DMARC Extension for 3rd party Signers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 23:18:40 -0000 On 4/21/2014 6:08 PM, Vlatko Salaj wrote: > On Monday, April 21, 2014 11:32 PM, Hector Santos wrote: >> How do you define a 3rd party SPF condition that isn't already defined >> and authorized by the 1st party?� IOW, by virtue of the 1st party >> adding the 3rd party information into a SPF record, it is inherently >> ready for 3rd party operations. No? > > no. 3rd party SPF support in DMARC's alignment context means support > for 3rd party SMTP MAIL FROM, or 3rd party HELO/EHLO. by SPF specs, > there are no provisions for 3rd party SPF support in this sense. You mean Multi-hop, relays where there is a nodal IP transition point which fails the LMAP IP::DOMAIN assertion. (SPF is an LMAP protocol). The Association of the Sender IP and SMTP Envelope Domains: LMAP Validation and Trust Analysis http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm > what SPF specs do allow is adding 3rd party servers to the IP pool of > senders, but that's not full 3rd party support actually, in DMARC > alignment terms. Right. I think the DKIM 3rd party resigner issue is the more important issue at this point. If this is not resolved, mail system developers like myself will be forced to provide undesirable "mail tampering" kludges and considerations to customers. :( -- HLS From nobody Tue Apr 22 00:21: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 2F7961A00D3 for ; Tue, 22 Apr 2014 00:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.129 X-Spam-Level: * X-Spam-Status: No, score=1.129 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 YLccVLdQeEqO for ; Tue, 22 Apr 2014 00:21:00 -0700 (PDT) Received: from nm16-vm9.bullet.mail.gq1.yahoo.com (nm16-vm9.bullet.mail.gq1.yahoo.com [98.137.177.242]) by ietfa.amsl.com (Postfix) with ESMTP id ED4BC1A007A for ; Tue, 22 Apr 2014 00:20:59 -0700 (PDT) Received: from [98.137.12.59] by nm16.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2014 07:20:54 -0000 Received: from [216.39.60.198] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 22 Apr 2014 07:20:54 -0000 Received: from [127.0.0.1] by omp1085.mail.gq1.yahoo.com with NNFMP; 22 Apr 2014 07:20:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 652193.51353.bm@omp1085.mail.gq1.yahoo.com Received: (qmail 12006 invoked by uid 60001); 22 Apr 2014 07:20:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398151254; bh=6DHbZn18O9p/6wYGan2o0jg7EGAc+cQ85BCtQytfrkY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=K/WRYZCVKr3Cxe5UNneRJJ4xpHfsKRsS3ZXNOejO8LMZzRokh9cFOKxx0+kkBY936stAtcwUkdrM3EEHT01JZjmWeF/DSGYFr1bV2428sjIPFdCNmz6nQ9nSjM/3RUGbva1nzErbeH1bOJ+e9o0/Tle0/2jEugf4M4GzEYGMFuo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=eTaieDEXsHoilQT0Unxyo94fvA/ymx2AEZB6GleM38RDBRAWH8cofuSoCZiwPqfc+OoUDi1G7bO7NJBtYdTiBVA21S/nL2C3hARUH+ja/w7Lftaec7V+USpjYj3LpnEktq0bhWkjP68JMw4/AQ1xt8kesen79bMsjjwm7al5WFc=; X-YMail-OSG: Qm0c64QVM1njysd3CuvCJeeRtWjVF6A5ZpGG88w_BCZkrpJ xs9OwC4yIkoSDlE2llyezy_GqspYgKBK_i6v.YNtp3UFNmDMQARBdA3V.ZkO 4_l9l0OC057sIgQtq3rJJXyaraqs1OJI12krjAq1Rb4LbFuSQtRGTbd3uDD. uGvFSkl0PrVqnGdH5MCYliyttplcAu6DOCt.5pT5wJXvYh3n1K_QqRxuf9I9 tyLzGFUHbhi_BvKVrv8nO6VgtzVVDtgYC63RNDqi6ci2JbdCHcyeDx7lyLcj 2TZtA7e.pEUKIdMNjLJmtuNJBcv4dPA3VxNtfbr_1tuhwGjeGYnzt6uOShs0 WitfbJrJj3SGT8XBYlKyeALfwDUJvTpzyjHr4aNl7pNHTTGoyCV2lE0vyHab ImfbPXonNLT.ecZxQTH624tkJJk.4OmWNeHw5hZpSDQaN4t00U8gzlHSPxS4 0fT05b2IzzNZAtZKgWYM_6qB90Q1kSP0hABJzi.8KurzszTr_zNKCTw3Y.LY 3RA_WllcyUmpaZrS9yFONa19UWBZd3Q2HkkQWSKY_SEKOWLWEslMnCHR8Th8 WihO_ySM8B3zLsHJ7qIk8bj9BXIRBDl_lRUIdump.V_X4.aUx.wWU8M8_5Ih JEayZSI3glFpLBYwDDb35Mi1ObMsoICDVdXzq_X_OqSRDCQ1MWhjPRCM4WDm t_WQ5 Received: from [79.175.89.237] by web164605.mail.gq1.yahoo.com via HTTP; Tue, 22 Apr 2014 00:20:54 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgQXByaWwgMjIsIDIwMTQgMToxOCBBTSwgSGVjdG9yIFNhbnRvcyA8aHNhbnRvc0Bpc2RnLm5ldD4gd3JvdGU6CgoKPiBJIHRoaW5rIHRoZSBES0lNIDNyZCBwYXJ0eSByZXNpZ25lciBpc3N1ZSBpcyB0aGUgbW9yZSBpbXBvcnRhbnQgaXNzdWUKPiBhdCB0aGlzIHBvaW50LgoKaSBob2xkIGJvdGggYXJlIGltcG9ydGFudC4KClNQRidzIDNyZCBwYXJ0eSBzdXBwb3J0IHdhcyBiYXNpY2FsbHkgZml4ZWQgd2l0aCBTZW5kZXItSUQuIGJ1dCBNaWNyb3NvZnQKbmV2ZXIgcGxheWVkIHdlbGwgdGgBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1398106456.78279.YahooMailNeo@web164602.mail.gq1.yahoo.com> <53558E41.5030704@isdg.net> <1398118135.56070.YahooMailNeo@web164605.mail.gq1.yahoo.com> <5355A739.1000409@isdg.net> Message-ID: <1398151254.8652.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Tue, 22 Apr 2014 00:20:54 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <5355A739.1000409@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Tuc9Nt9SO2WIiWv97fTVtSEmOb4 Subject: Re: [dmarc-ietf] DMARC Extension for 3rd party Signers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 22 Apr 2014 07:21:04 -0000 On Tuesday, April 22, 2014 1:18 AM, Hector Santos wrote: > I think the DKIM 3rd party resigner issue is the more important issue > at this point. i hold both are important. SPF's 3rd party support was basically fixed with Sender-ID. but Microsoft never played well that open standards game... if it did, i'm sure we would be having Sender-ID in DMARC now, in place of SPF, and this problem would have been solved instantly. however, since both SPF and DKIM 3rd party alignment support is similar in nature, i'm sure DMARC can be flexibly expanded enough to fix both issues, and any future mechanism it introduces, in the same way. let's face it: all these scenarios are somewhat special in nature, and while quite used and needed, they are not the default setting. so, even if it places scaling problems on DMARC, it's not like everybody will be using them on large scale. "p=reject; rua=mailto:abuse@example.com; ruf=mailto:abuse@example.com; adkim=n,s:yahoo.com; aspf=yahoo.com" DMARC entry for example.com domain solution is fool-proof, flexible, trivial and easily maintained. it reads as: 1. request none alignment for example.com domain [DKIM will never align with owner's domain, cause their domain doesn't sign when it uses its own infrastructure, and 3rd party DKIM signatures will never align with it either, cause they are 3rd party] 2. request strict alignment for yahoo.com domain [1st party email fails here, but 3rd party signed email will align] 3. request relaxed alignment for example.com domain [default relaxed setting for owner's domain doesn't need to be specified, and it will align when any email is sent through domain's infrastructure, and fail when it's sent through 3rd party] 4. request relaxed alignment for yahoo.com domain [default relaxed setting doesn't need to be specified, and it will align when any email is sent through 3rd party, fail on 1st] 5. reject anything that doesn't pass these scenarios, and report accordingly 6. 1st party example: sends DKIM-unsigned email - DMARC passes, based on SPF alignment policy 7. 3rd party example: sends DKIM-signed email - DMARC passes, with both DKIM and SPF alignment passing. consideration for abuse: 1. most ESPs verify email address ownership before it can be used in their system, so nobody but ppl owning such addresses would be able to post messages on behalf of a domain publishing some ESPs as 3rd party for their mail subsystem. this is recommended and historical practice already. 2. ESPs need to handle malicious accounts quite well already. so, 3rd party DMARC would not introduce anything that's already not there, or put additional pressure on ESPs. i can't see any exploit holes in this suggestion, at least not one already covered by existing practices. i repeat: all this 3rd party solution usage case is special in its very nature. it would be applied where needed, and not a default DMARC deployment. i really see no reason why DMARC can't be flexible enough to include it. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Wed Apr 23 05: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 8A38A1A0377 for ; Wed, 23 Apr 2014 05:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 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, RP_MATCHES_RCVD=-0.272] 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 vrb5wZQaD3O5 for ; Wed, 23 Apr 2014 05:59:34 -0700 (PDT) Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff89]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5A71A038D for ; Wed, 23 Apr 2014 05:59:34 -0700 (PDT) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 3gDMDH64y9zySH; Wed, 23 Apr 2014 14:59:27 +0200 (CEST) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=lrz.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lrz.de; h= user-agent:message-id:subject:subject:from:from:date:date :content-transfer-encoding:content-type:content-type :mime-version:received:received:received; s=postout; t= 1398257967; bh=AnboP3Y6cAXveYTIC2l8qMAU9ZhHJD+o7gpY5KIbpJg=; b=M iHsvWFinNQ1fK12LKfBPXW+78g99fONXQy/ivUhrYRM52G2xsF7Bk64mQV5hwZ9i 7lG3EYD7XhP/+H3Kdxt0VrNxms/cMKmKrLsqdyq7jBQ20t/or5spimwTsycKh0xj yBTICTVcSNBfUwf9HJfhoY/v9laTduKUEB8keXoIpaF6+ls77nrcmEQ+xAaMHJVk YkCzT5C3Ysf6uLWBMxtkBnMxNPjTu4BFRJIIxmrDgWk6FXVnrERLpC3tVqqTrz++ OY+yyaN534XbVw/yNmVXVuVg/SvONIgNTeo+izigf1vK8liugoB7JfXHB36uK7iv SSrv04rC8N7uJdp8GRRvg== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id D2ITupAwxp4i; Wed, 23 Apr 2014 14:59:27 +0200 (CEST) Received: from roundcube.lrz.de (lxmhs47.srv.lrz.de [10.156.6.47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by postout1.mail.lrz.de (Postfix) with ESMTPSA id 3gDMDH1kfJzyRp; Wed, 23 Apr 2014 14:59:27 +0200 (CEST) Received: from badwlrz-clmst01.ws.lrz.de ([129.187.12.172]) by roundcube.lrz.de with HTTP (HTTP/1.1 POST); Wed, 23 Apr 2014 14:59:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Apr 2014 14:59:27 +0200 From: Michael Storz To: , Message-ID: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> X-Sender: Michael.Storz@lrz.de User-Agent: Roundcube Webmail/0.8.4 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XGWRQ0zdgpbD95BvwofQuE5cNv4 Subject: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 23 Apr 2014 12:59:43 -0000 Just saw it in my logs. You find the announcement at http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ -- Michael From nobody Wed Apr 23 13: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 7BB801A03D8 for ; Wed, 23 Apr 2014 08:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 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.272] 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 ztosifqK8XWe for ; Wed, 23 Apr 2014 08:05:37 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A851A03CF for ; Wed, 23 Apr 2014 08:05:21 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.149.29]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3NF52F3009696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Apr 2014 08:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1398265514; bh=p+1eiimRlnjWzLRvrurzUlQMHYssJ6LvwM239GxuK38=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=nXB9/Tc4OD7etqo7MbUW1iYjXUGS/uEsFMlloKwEaDu3vUkwKG1UhQ9w4I264Mcqu gWkEQtRYpEUNVwDsSIz/kqduSGGoIgOczvJjtvMQ3G0AJMIH5BsV7MIwEX9w+1V3se H+dvPFGeHBLDVR2gGblPVME6YCeZZ49IfRgmxAQc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1398265514; i=@elandsys.com; bh=p+1eiimRlnjWzLRvrurzUlQMHYssJ6LvwM239GxuK38=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qHRqGwaoou/vK7sii9Y8oe8znKCCIjzPL8ty5Gd6ZECydKtqmcTdjSjLtTHm9Hepl +cTu7GDz3kUVW61qveaM3neE4pBl+1BmMnQiR7HiIW5PHAgvug65yqKpgLt4KrKl6P 0WW5oZCbLiaKGnOvRn302DkTOophE94MEaVobH34= Message-Id: <6.2.5.6.2.20140423071924.0d340bb0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 23 Apr 2014 07:23:56 -0700 To: mrex@sap.com From: S Moonesamy In-Reply-To: <20140423003045.EBE6F1ACDC@ld9781.wdf.sap.corp> References: <6.2.5.6.2.20140422074852.0d368728@elandnews.com> <20140423003045.EBE6F1ACDC@ld9781.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/aiZOO9f_7dC-YNQYuUXtcKa3jxQ X-Mailman-Approved-At: Wed, 23 Apr 2014 13:44:27 -0700 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 15:05:39 -0000 Hi Martin, At 17:30 22-04-2014, Martin Rex wrote: >Some MTAs (sendmail?) seem to recreate an RFC5322.From from the Envelope, >in case that it is missing in the message. Yes, sendmail does that. Regards, S. Moonesamy From nobody Wed Apr 23 16:43: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 4E7951A073C; Wed, 23 Apr 2014 16:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 fLvvWIpeeCRz; Wed, 23 Apr 2014 16:43:05 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD821A0734; Wed, 23 Apr 2014 16:43:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D131039AAA9; Wed, 23 Apr 2014 18:42:58 -0500 (CDT) 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 cZA9yLGz4RSS; Wed, 23 Apr 2014 18:42:58 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AE5B939AAB8; Wed, 23 Apr 2014 18:42:58 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 977BD39AAB3; Wed, 23 Apr 2014 18:42:58 -0500 (CDT) 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 U8UI9MCVw0Vj; Wed, 23 Apr 2014 18:42:58 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 7556239AAA9; Wed, 23 Apr 2014 18:42:58 -0500 (CDT) Date: Wed, 23 Apr 2014 18:42:57 -0500 (CDT) From: Franck Martin To: dmarc@ietf.org Message-ID: <1302891628.92012.1398296577196.JavaMail.zimbra@peachymango.org> In-Reply-To: <1825854784.91854.1398296066545.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_92011_1247733592.1398296577195" X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: empty from, was Review of draft-kucherawy-dmarc-base-04 Thread-Index: 16PKek0xlYm3XB4aNjMz0DMQhd9OoQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fz3e7POvMakGPjC7VDUT5SXaCA4 Cc: ietf@ietf.org Subject: Re: [dmarc-ietf] empty from, was Review of draft-kucherawy-dmarc-base-04 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 23:43:07 -0000 ------=_Part_92011_1247733592.1398296577195 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If you read carefully http://tools.ietf.org/html/rfc6854#section-3=20 Mailbox syntax is the normal syntax to use in the "From:" and "Sender:" header fields; the address syntax defined in Section 2.1 , which allows the specification of a group, is only for Limited Use (see RFC 2026 [RFC2026], Section=C2=A03.3 , item (d)) for the reasons described below.=20 You will see that an empty from is not encouraged and to be used only when = you have a specific EAI need.=20 Basically if your MTA does EAI, it can reject emails (more or less safely) = from another, EAI aware or not, MTA.=20 More over if you do DMARC, I think it is perfectly fine to ignore this RFC,= like people ignore SMTP over IPv6...=20 If I recall, I pushed this change during the last call of the document, bec= ause the From: header with no domain in fact weakens anti-spam measures, an= d I don't think the IETF vision is "less security".=20 ------=_Part_92011_1247733592.1398296577195 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
Mailbox syntax is the normal syntax to use in the "From:" and
   "Sender:" header fields; the address syntax defined in Section 2.1,
   which allows the specification of a group, is only for Limited Use
   (see RFC 2026 [RFC2026], Section 3.3, item (d)) for the reasons
   described below.
You will see that an empty from is not encouraged and to be used only when you have a specific EAI need.

Basically if your MTA does EAI, it can reject emails (more or less safely) from another, EAI aware or not, MTA.

More over if you do DMARC, I think it is perfectly fine to ignore this RFC, like people ignore SMTP over IPv6...

If I recall, I pushed this change during the last call of the document, because the From: header with no domain in fact weakens anti-spam measures, and I don't think the IETF vision is "less security".


------=_Part_92011_1247733592.1398296577195-- From nobody Wed Apr 23 21:37: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 53AF61A02D0 for ; Wed, 23 Apr 2014 21:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.272] 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 CFC0aKK2nj_6 for ; Wed, 23 Apr 2014 21:37:52 -0700 (PDT) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 9A84C1A02A3 for ; Wed, 23 Apr 2014 21:37:52 -0700 (PDT) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5/8.14.5) with ESMTP id s3O4bhKL030297 for ; Wed, 23 Apr 2014 21:37:46 -0700 Received: from vpn-135-70-99-10.vpn.swst.att.com ([135.70.99.10]) by maillennium.att.com (mailgw1) with ESMTP id <20140424043742gw100j0clje>; Thu, 24 Apr 2014 04:37:42 +0000 X-Originating-IP: [135.70.99.10] Message-ID: <53589515.4070909@att.com> Date: Thu, 24 Apr 2014 00:37:41 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dmarc@ietf.org, dmarc-discuss@dmarc.org References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> In-Reply-To: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ycDwB_Ta2UO63dejYXc__Xai310 Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 04:37:54 -0000 On 4/23/14, 8:59 AM, Michael Storz wrote: > Just saw it in my logs. You find the announcement at > > http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ > And I saw a dmarc rejection this morning from a comcast address. Tony Hansen From nobody Thu Apr 24 02:46: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 6B3B11A014B for ; Thu, 24 Apr 2014 02:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fRqZ7i2maU4 for ; Thu, 24 Apr 2014 02:46:53 -0700 (PDT) Received: from listserv.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9EB1A013C for ; Thu, 24 Apr 2014 02:46:53 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1825; t=1398332796; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ZUemhXErthhuP6zMs2hgQX7/AGM=; b=KxX3sWoXRdDPcYAf/7NP gL+B9RISE1FCLOfZHau3NLwC9vmYQ39363aJIgy9lSuTMzEmnLANidSuz2yDl0rW ZCMArBYw9/pDCSqy1ZNOR9piL7MRDwV6uWwNcTBrx8aWFG30Gw8W7V2D+2T9YgZu dZS1Cm9YSGwhiUqA6pyoWKY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 24 Apr 2014 05:46:36 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1441364716.666.3820; Thu, 24 Apr 2014 05:46:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1825; t=1398332714; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=xBlz62z x/mk57oinjf2EXbNZA7voIn1xkgGeE73j4zc=; b=MtFnHrHKFuSDIlkUjBrOgyV YYHXDfe+PmzQZfIsN4jVzLCKA43ZQJekeUzPLzCBTWR6DeSJT67s0cF8rrxViwWl qmdfT5NtsDwcPvfAzy40obrdPvzE6EfHTeetXpmxhYqxKDi67CdiHmL6OEXclceB ons179IS+5FA4lzA5uRc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 24 Apr 2014 05:45:14 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1460890171.9.7032; Thu, 24 Apr 2014 05:45:13 -0400 Message-ID: <5358DD7C.40107@isdg.net> Date: Thu, 24 Apr 2014 05:46:36 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Michael Storz , dmarc@ietf.org, dmarc-discuss@dmarc.org References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> In-Reply-To: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/SkKpXwI4SkNyql-uwW_LVI8HX_4 Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 09:46:56 -0000 On 4/23/2014 8:59 AM, Michael Storz wrote: > Just saw it in my logs. You find the announcement at > > http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ So much for the theory that DKIM ADSP-like strong policies would never be used by big operations! And the irony, the IETF had just made ADSP historic for this theory of "special case no one will use," and for same interop mailing list problem. Maybe its time to make DMARC historic too before it even gets a RFC! All that needs to be done is change ADSP to DMARC below at the IETF RFC Status change link. Technically, it is still almost no deployment, just a few BIG guys!! ------------------ https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ RFC Status Change : Change the status of ADSP (RFC 5617) to Historic ADSP has garnered almost no deployment and use in the 4 years since its advancement to IETF Proposed Standard. While there are implementations in code, there is very little deployment and no evidence of the benefits that were expected when the standard was written. There is, however, evidence of harm caused by incorrect configuration and by inappropriate use. There have, for example, been real cases where a high-value domain published an ADSP record of "discardable", but allowed users on their domain to subscribe to mailing lists. When posts from those users were sent to other domains that checked ADSP, those subscriber domains rejected the messages, resulting in forced unsubscribes from mailman (due to bounces) for the unsuspecting subscribers. Assurances that are provided by ADSP are generally obtained out of band in the real Internet, and not through ADSP. Current deployment of ADSP is not recommended. ------------------ -- HLS From nobody Thu Apr 24 04:29:29 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 CF70F1A004E for ; Thu, 24 Apr 2014 04:29:27 -0700 (PDT) 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 6IqPt8mQKHZy for ; Thu, 24 Apr 2014 04:29:25 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A14471A0188 for ; Thu, 24 Apr 2014 04:29:25 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id t10so1729631eei.33 for ; Thu, 24 Apr 2014 04:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PhD0V+qLKn6yDSpwqR5R9d8aOPk0o/DA02kdYgrkQ/M=; b=LCwCsDvYp6mil7i5o/JJgIKoYbGh5dkodClJmnMr8vGbU0qsH2qpOQ5clKbPb/JXU8 3Yc1JN4tKdE0QgRL+GAr9tfQE5x6ixsEmOMNbE1NYy0t1NPul2HW1K+D8AHJhtp/Em1R nB7LbD4qwtUzS2t8/asRTGoFowsF5D+yO60cU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=PhD0V+qLKn6yDSpwqR5R9d8aOPk0o/DA02kdYgrkQ/M=; b=IXHoPohP1BPf1UGaYn7pnkdntDB733H2EqnLzD9ampvNkmBpOY4KWcDDPHmkWJUy2R XtoiH7J9IFVuQSPVxX7aHDThGYYPL2JvQzjnx0wOeUk9YXffg7LrJheorCmqknBgDKLW DmSN2JI224HbyTZSiYiZ0kym5+upd2CiEGFyU3c/fL36xbJuLUeP7O5Jowkkr9xokVRP W1trGrnhmaiY5maxWf0tcWnYRQV3LWHt9fsjS9YwGV7vYeKg09O59y5n1AphIM+0mfCU sdpSeA955aSYQ8CQQxZ/8QImwp0nrU7kmNDHCy9+oS8ZJHomFbkZ3MCaLpB5HwJ5d/fi CC5A== X-Gm-Message-State: ALoCoQn+bFeLd9GmTGxCakLny9GIz1mKfV7ew8OWDa/eZBzlruuD+abLTyFAbnCpzUgz44f/hWYW X-Received: by 10.15.102.74 with SMTP id bq50mr1722310eeb.21.1398338959029; Thu, 24 Apr 2014 04:29:19 -0700 (PDT) Received: from [10.199.32.160] (host90-152-0-109.ipv4.regusnet.com. [90.152.0.109]) by mx.google.com with ESMTPSA id w1sm14955317eel.16.2014.04.24.04.29.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 04:29:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Chris Meidinger In-Reply-To: <6.2.5.6.2.20140423071924.0d340bb0@elandnews.com> Date: Thu, 24 Apr 2014 12:29:16 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <6.2.5.6.2.20140422074852.0d368728@elandnews.com> <20140423003045.EBE6F1ACDC@ld9781.wdf.sap.corp> <6.2.5.6.2.20140423071924.0d340bb0@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vICcbDVWUV_8vr9VnMK3FOMwItQ Cc: dmarc@ietf.org, mrex@sap.com Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-04 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 11:29:28 -0000 On Apr 23, 2014, at 15:23, S Moonesamy wrote: > Hi Martin, > At 17:30 22-04-2014, Martin Rex wrote: >> Some MTAs (sendmail?) seem to recreate an RFC5322.From from the Envelope, >> in case that it is missing in the message. > > Yes, sendmail does that. Unless you prevent it by removing the F=F equate from your mailer flags. Chris From nobody Thu Apr 24 09:40: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 735B41A0375 for ; Thu, 24 Apr 2014 09:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.273 X-Spam-Level: X-Spam-Status: No, score=-7.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_CERTIFIED=-3, RCVD_IN_RP_SAFE=-2, RP_MATCHES_RCVD=-0.272, 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 rTXhwpfEA-2L for ; Thu, 24 Apr 2014 09:40:16 -0700 (PDT) Received: from o1.corpout.returnpath.com (o1.corpout.returnpath.com [50.31.61.183]) by ietfa.amsl.com (Postfix) with SMTP id 568491A01E1 for ; Thu, 24 Apr 2014 09:40:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=returnpath.com; h=from:to:cc:subject:references:in-reply-to:content-type:mime-version; s=smtpapi; bh=uUxcB8dvF04GnLkz9eIQAhdzc5M=; b=qVwzxLI21Z+e823i8c yF4vZfzAO6TBxsSuFIMioKxdCo5fyLUnQ1JK2L7Pj4dBZ1nyRAPk/OJDqjjo7248 YyE91ItjrM67aqfv0Q3pSxsZo3RwtJI3lmxKBZvDdmn4qTh4NOL2Sc2OHzgc+Ank uBdtymbdQE25eEIy9vk7gl9YQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=returnpath.com; h=from:to:cc:subject:references:in-reply-to:content-type:mime-version; q=dns; s=smtpapi; b=iMtnS61RW+ZhZNv/x2eIJywyPaBBgByc+OOiR4xLLhBe dpybGThBTtn4ERbahxxfnpbcDfsUlCLQjgCLNgF5JZB08gy0InsockJCZFykhSgm 3uYIs8jouCvHO05gWEu6AUiapKMnSfhoSDOhDPOOFa2C54Qpuyzm3Maq5fTHONM= Received: by filter-144.sjc1.sendgrid.net with SMTP id 1398357606-3844809772840568476 2014-04-24 16:40:06.523779624 +0000 UTC Received: from smtp.corp.returnpath.net (smtp.corp.returnpath.net [50.201.69.7]) by ismtpd-016 (SG) with ESMTP id 145949b36bd.638d.2dbfe6 Thu, 24 Apr 2014 16:39:31 +0000 (GMT) Received: from rpcoex01.rpcorp.local ([10.0.1.142]) by rpcoex01.rpcorp.local ([10.0.1.142]) with mapi; Thu, 24 Apr 2014 10:39:30 -0600 From: Greg Colburn To: Hector Santos Date: Thu, 24 Apr 2014 10:39:29 -0600 Thread-Topic: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' Thread-Index: Ac9f28PUaI5t8N0KTsW7bg7dqA50pg== Message-ID: <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> In-Reply-To: <5358DD7C.40107@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_775462A4-2C94-478A-A4D7-70784BCB0CAE"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-SG-EID: ttWHLwNw6rhAFWw30n9Iv9H9bTFVLrGYwa7KMAiUt5JvqxM/HOhxrOyE7CDWT6WyOI8HTNO9LfGeghNmOAFHmhyxWgdg3wfO6PCLMp1Ov38DnVnv0cid3LWgQHfQSqw5n2Ztr/SWUr1qAd6qewCqafY7/r0cxGM4S4QRaq1D7w4= Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DVZgdQp-Axixw5MjHNXTUiQT7ZY Cc: Michael Storz , "dmarc@ietf.org" , DMARC Discuss Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:40:19 -0000 --Apple-Mail=_775462A4-2C94-478A-A4D7-70784BCB0CAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Apr 24, 2014, at 3:46 AM, Hector Santos wrote: >=20 > change ADSP to DMARC below at the IETF RFC Status change link.=20 > Technically, it is still almost no deployment, just a few BIG guys!! >=20 Hector I challenge your assertion that there is =93almost no deployment=94. In th= e past 3 days at Return Path we=92re received reports from 147 unique ISPs,= companies, etc. Greg Colburn --Apple-Mail=_775462A4-2C94-478A-A4D7-70784BCB0CAE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTWT5BAAoJEI63vcv0urJiQokIAKSxzlTOuIS8SdonE1R1nDoJ 2+a3HaGalbcCr91noacR7Kc0z6fYUqxMjs7R0qrcxrmheSuc6KxSrfxBFdF7BJ2c KsA0E+uF1pDNlDprLqvjfr8xl2/tySdijgvteoumBqBYdWSTbSjIRY35Q1bhJCUM 6XxtSwd2BoWgQdIStPqiWJotkP0AAeYjLRr8rQWw+NJnjFpT+imHOEFKdQ/SkJBY Zg5UbvmgPxkxn/JSl5XycrPcwa7f5lb4lHFIWM6+stNOGH0ero+6nwdOiJPiaKlw WlXi5OQadat8DnQsXT4AOEH/oomTfsCB3VG1hxLbwTAB4fjTQC6Q4XlUMATgUW8= =f7/m -----END PGP SIGNATURE----- --Apple-Mail=_775462A4-2C94-478A-A4D7-70784BCB0CAE-- From nobody Thu Apr 24 09:44: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 5F1171A03BD for ; Thu, 24 Apr 2014 09:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RUBPkiSnudL9 for ; Thu, 24 Apr 2014 09:44:48 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9565D1A037A for ; Thu, 24 Apr 2014 09:44:48 -0700 (PDT) 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.0.939.4; Thu, 24 Apr 2014 16:44:41 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.125]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.16]) with mapi id 15.00.0939.000; Thu, 24 Apr 2014 16:44:41 +0000 From: Terry Zink To: Greg Colburn , Hector Santos Thread-Topic: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' Thread-Index: AQHPXvPmzuPPWAPwKEihicdkHT1tXJsghkIAgABzXICAAADAkA== Date: Thu, 24 Apr 2014 16:44:40 +0000 Message-ID: <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> In-Reply-To: <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.159.134] x-exchange-antispam-report-test: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(24454002)(189002)(199002)(51704005)(97336001)(79102001)(46102001)(94946001)(33646001)(95416001)(87266001)(65816002)(90146001)(97186001)(47976003)(31966008)(74662001)(77096001)(74502001)(54316003)(19580395003)(83322001)(19580405001)(56816006)(63696004)(49866002)(47736002)(47446003)(80976001)(59766002)(53806002)(87936001)(54356002)(2656002)(77982001)(56776002)(50986002)(51856002)(93136001)(95666003)(98676001)(74366001)(81542001)(99396002)(92566001)(81686001)(81816001)(81342001)(74876001)(83072002)(69226001)(76796001)(66066001)(76786001)(85306002)(76482001)(20776003)(85852003)(93516002)(74706001)(94316002)(4396001)(80022001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; 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/0OcBAMRKyomj5YPYhiqO8c1NY5Q Cc: Michael Storz , "dmarc@ietf.org" , DMARC Discuss Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:44:50 -0000 >> On Apr 24, 2014, at 3:46 AM, Hector Santos wrote: >>=20 >> change ADSP to DMARC below at the IETF RFC Status change link.=20 >> Technically, it is still almost no deployment, just a few BIG guys!! >>=20 >> >> Hector > I challenge your assertion that there is "almost no deployment". In the = past=20 > 3 days at Return Path we're received reports from 147 unique ISPs,=20 > companies, etc. >=20 > Greg Colburn I agree with Greg. Large ISPs like DMARC. I suspect that the smaller player= s like mailing-list-operators (and other non-compliant-yet-valid-email-scen= arios) will be forced to work with, or around, DMARC before DMARC is abando= ned by large operators. --Terry From Dianne.Solomon@firstdata.com Thu Apr 24 05:32:32 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 DC5691A01D1 for ; Thu, 24 Apr 2014 05:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.272, 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 SYDSKPKOVKUk for ; Thu, 24 Apr 2014 05:32:30 -0700 (PDT) Received: from x1ppir015.firstdata.com (x1ppir015.firstdata.com [216.66.222.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0221A01B0 for ; Thu, 24 Apr 2014 05:32:27 -0700 (PDT) Received: from pps.filterd (x1ppir015.firstdata.com [127.0.0.1]) by x1ppir015.firstdata.com (8.14.5/8.14.5) with SMTP id s3OCRVRZ004367 for ; Thu, 24 Apr 2014 08:32:20 -0400 Received: from x1ppir036.1dc.com (X1PPIR036.1dc.com [10.180.7.184]) by x1ppir015.firstdata.com with ESMTP id 1kektkm0tg-9 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 24 Apr 2014 08:32:20 -0400 Received: from firstdata.com (W1PVHT004.1dc.com [10.178.226.75]) by X1PPIR036.1dc.com (RSA Interceptor) for ; Thu, 24 Apr 2014 07:32:04 -0500 Received: from W1PVMB002.1DC.com ([169.254.2.220]) by W1PVHT004.1DC.com ([10.178.226.105]) with mapi id 14.03.0158.001; Thu, 24 Apr 2014 08:32:04 -0400 From: "Solomon, Dianne B" To: "dmarc@ietf.org" Thread-Topic: Forensic Reporting Thread-Index: Ac9fuS4FmLLFjRfrTHWj94wQa0BaUg== Date: Thu, 24 Apr 2014 12:32:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.227.21.63] Content-Type: multipart/alternative; boundary="_000_B644DEED2E6A3A49B0CC0BF8BDACDE785752DBECW1PVMB0021DCcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.96, 1.0.14, 0.0.0000 definitions=2014-04-24_04:2014-04-24,2014-04-24,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0SOjMr1sZlBev3vaZ5x9Km5E1fM X-Mailman-Approved-At: Thu, 24 Apr 2014 09:45:11 -0700 Subject: [dmarc-ietf] Forensic Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 12:34:04 -0000 --_000_B644DEED2E6A3A49B0CC0BF8BDACDE785752DBECW1PVMB0021DCcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi.. I am new to DMARC. From what I am learning, few companies are impl= ementing forensic reporting because of potential privacy issues. Has ther= e been discussion on changing the format or delivery of the forensic report= s that would make it a more acceptable option? Dianne Blitstein Solomon, CIPP, CIPP/IT | Architect, ISCD.IS.Messaging Secu= rity | First Data Corporation | www.firstdata.com 4000 Coral Ridge Drive, Coral Springs, FL 33065 | (O) +1.954.851.7290 | (M)= 954.695.8094 | GMT -5 Suspect an information security incident? Please call 888-427-4468. --_000_B644DEED2E6A3A49B0CC0BF8BDACDE785752DBECW1PVMB0021DCcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi..   I am new to DMARC.  From what I am learning,= few companies  are implementing forensic reporting because of potenti= al privacy issues.   Has there been discussion on changing the format or delivery of the forensic reports that would make it a more a= cceptable option? 

 

 

Dianne Blitstein Solomon, CIPP, CIPP/IT | Architect, IS= CD.IS.Messaging Security | First Data Corporation | www.firstdata.com

| (O) = +1.954.851.7290 | (M) = 954.695.8094 | GMT -5

Suspect an information security incident?  Pl= ease call 888-427-4468.

&= nbsp;

 

 

 

--_000_B644DEED2E6A3A49B0CC0BF8BDACDE785752DBECW1PVMB0021DCcom_-- From nobody Thu Apr 24 09:56: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 A4AED1A0318 for ; Thu, 24 Apr 2014 09:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_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 nFtfCm0W5n1U for ; Thu, 24 Apr 2014 09:56:54 -0700 (PDT) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id 85DF21A0229 for ; Thu, 24 Apr 2014 09:56:54 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id D5CA01C2153; Thu, 24 Apr 2014 18:56:46 +0200 (CEST) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id BC5521FE025E; Thu, 24 Apr 2014 18:56:46 +0200 (CEST) Date: Thu, 24 Apr 2014 18:56:46 +0200 From: Kurt Roeckx To: Greg Colburn Message-ID: <20140424165646.GA13886@roeckx.be> References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/q_ayviNiLG0dlMsHIE6wEZW1DZ0 Cc: Michael Storz , "dmarc@ietf.org" , Hector Santos , DMARC Discuss Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 16:56:56 -0000 On Thu, Apr 24, 2014 at 10:39:29AM -0600, Greg Colburn wrote: > > On Apr 24, 2014, at 3:46 AM, Hector Santos wrote: > > > > change ADSP to DMARC below at the IETF RFC Status change link. > > Technically, it is still almost no deployment, just a few BIG guys!! > > > > Hector > > I challenge your assertion that there is "almost no deployment". In the past 3 days at Return Path we're received reports from 147 unique ISPs, companies, etc. And of course there are only about 150 ISPs. 147 really is "a few". Kurt From nobody Thu Apr 24 10:34: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 2D18A1A01DB for ; Thu, 24 Apr 2014 10:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] 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 ijkrKrleVHz8 for ; Thu, 24 Apr 2014 10:34:13 -0700 (PDT) Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4B71A0222 for ; Thu, 24 Apr 2014 10:34:13 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( EGS R6 8.14.5/8.14.5) with ESMTP id s3OHY61b023025 for ; Thu, 24 Apr 2014 10:34:07 -0700 Received: from ds135-91-110-232.dhcps.ugn.att.com ([135.91.110.232]) by maillennium.att.com (mailgw1) with ESMTP id <20140424173406gw100j0cm5e>; Thu, 24 Apr 2014 17:34:06 +0000 X-Originating-IP: [135.91.110.232] Message-ID: <53594B0F.8030501@att.com> Date: Thu, 24 Apr 2014 13:34:07 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dmarc@ietf.org, dmarc-discuss@dmarc.org References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <53589515.4070909@att.com> In-Reply-To: <53589515.4070909@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nwOOE8xr5yS0JmAhWfKpRua9oQU Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:34:17 -0000 On 4/24/14, 12:37 AM, Tony Hansen wrote: > On 4/23/14, 8:59 AM, Michael Storz wrote: >> Just saw it in my logs. You find the announcement at >> >> http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ >> > > And I saw a dmarc rejection this morning from a comcast address. Sigh After re-reading the bounce message, it's a message going to comcast from a yahoo sender via a mailing list I manage. So it's comcast applying the dmarc reject to yahoo addresses. Sorry for the noise. Tony Hansen From nobody Thu Apr 24 10:44: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 908171A02B5 for ; Thu, 24 Apr 2014 10:24:12 -0700 (PDT) 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 rfIjN87jy-oL for ; Thu, 24 Apr 2014 10:24:11 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AE9461A01DB for ; Thu, 24 Apr 2014 10:24:11 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kp14so2134936pab.5 for ; Thu, 24 Apr 2014 10:24:05 -0700 (PDT) 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=UrD/mKU6+1MEJ7L6R+cEe9Eh5002meV0X78vcduko2U=; b=XOkoI2xoSVIK9aTfaclKfok4AcltK3yDl1UbM5sakGHTpfdKHNB1U85idNbYEdTxQq xzzhDpvZ0jqxEcWv2g9KZnblNlt0hTjpR5OY4OkNjIOuFGFzDWZV/K4nI7HVWwo6bHyY rOVMS/g8ZJU9undsgm2N1F/7IBL/ltmuh8Wwz1Y5JX/hOuvPOK34am2TaOwo9Nt8hxKl Mw11FhH61YUXD7uokEXxXTuqsbfIuh5soiUAJ/OoMYmDHIrW7FKQDhq7f5Ed8Nv3p2t6 qB6gnCsbDSTMLe9XZQT9FUwwlbvL+aHbisXMdrzp+YdO8zglOVic8wlpW6fCK6a4QL4Y h5zA== X-Received: by 10.66.149.37 with SMTP id tx5mr1540053pab.81.1398360245651; Thu, 24 Apr 2014 10:24:05 -0700 (PDT) Received: from dhcp150.priv.bungi.com (c-24-4-159-60.hsd1.ca.comcast.net. [24.4.159.60]) by mx.google.com with ESMTPSA id yw3sm10262965pbc.69.2014.04.24.10.24.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 10:24:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Douglas Otis In-Reply-To: <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Thu, 24 Apr 2014 10:24:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <77A20043-6821-402E-ACBD-EEF2B9477557@gmail.com> References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> To: Terry Zink X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KNJEYmrakkFICUDWUK3z5BTvFH4 X-Mailman-Approved-At: Thu, 24 Apr 2014 10:44:08 -0700 Cc: "dmarc@ietf.org" , Hector Santos , Greg Colburn , DMARC Discuss Subject: Re: [dmarc-ietf] [dmarc-discuss] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:24:12 -0000 On Apr 24, 2014, at 9:44 AM, Terry Zink = wrote: >>> On Apr 24, 2014, at 3:46 AM, Hector Santos wrote: >>>=20 >>> change ADSP to DMARC below at the IETF RFC Status change link.=20 >>> Technically, it is still almost no deployment, just a few BIG guys!! >>>=20 >>>=20 >>> Hector >=20 >> I challenge your assertion that there is "almost no deployment". In = the past=20 >> 3 days at Return Path we're received reports from 147 unique ISPs,=20 >> companies, etc. >>=20 >> Greg Colburn >=20 > I agree with Greg. Large ISPs like DMARC. I suspect that the smaller = players like mailing-list-operators (and other = non-compliant-yet-valid-email-scenarios) will be forced to work with, or = around, DMARC before DMARC is abandoned by large operators. Dear Terry, Now that some Large ISPs (mis)apply DMARC p=3Dreject on user accounts, = perhaps it is time to update ATP to conform with DMARC rather than ADSP. = ATP can enable third-party authorizations at higher rates more = effectively and efficiently than by other protocols or technologies. = Once put into practice, other DMARC domains could share the = authorizations necessary to avoid disrupting legitimate mailing-lists. = Doing so would lessen the burden of such policy now affecting tens of = thousands of church and neighborhood organizations who depend on = mailing-lists. Regards, Douglas Otis From nobody Thu Apr 24 10:44: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 F3CEB1A026A for ; Thu, 24 Apr 2014 10:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.802 X-Spam-Level: X-Spam-Status: No, score=-98.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF6tMxWE929K for ; Thu, 24 Apr 2014 10:44:13 -0700 (PDT) Received: from winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3D41A037A for ; Thu, 24 Apr 2014 10:44:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3986; t=1398361443; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=8iMP+yKjDQNgY0WPiASWXJ4B5Qs=; b=VuruLRi37Qdejx0kCOgS KtxSHeCbXA9tHfWTTVAmL++gZZkeDzzjX4bgEuunDpm97unAttamlVetnHw0oAgA gO5lAyyu8W9mXa9fsx2zuPtIeXXW0+loUMJF2rv5H2f7Pp+KGgOx452GwPQDJl8P o8YobUEVGlvN+SohFH/w7sQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 24 Apr 2014 13:44:03 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1470010540.666.2304; Thu, 24 Apr 2014 13:44:02 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3986; t=1398361359; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=eXLNONk nlWYQEyXzxrrCcGkQ5DFzAgRFydfUthVdNLE=; b=2podgsLSpi9G/5xYTrBDtCG mNJvgv2IiHlRRYSi95ooWZbcb9q+Mrhhh9/+0i71Z394mh2diko39H9JsUmzkNBK Rz4I6VJLpOr5lFPEQwE5UnZ4qvZhOS9oAtEa/j8Pj53M7i/rh260H3ANG+OBvReJ 12odDTJfIpboK/PPvFU8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 24 Apr 2014 13:42:39 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1489535453.9.11920; Thu, 24 Apr 2014 13:42:38 -0400 Message-ID: <53594D62.4070609@isdg.net> Date: Thu, 24 Apr 2014 13:44:02 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Terry Zink , Greg Colburn References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/sYe-gAWGYB2euOW6cn1CiolMhNk Cc: Michael Storz , "dmarc@ietf.org" , DMARC Discuss Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 17:44:16 -0000 On 4/24/2014 12:44 PM, Terry Zink wrote: >>> On Apr 24, 2014, at 3:46 AM, Hector Santos wrote: >>> >>> change ADSP to DMARC below at the IETF RFC Status change link. >>> Technically, it is still almost no deployment, just a few BIG guys!! >>> >>> >>> Hector > >> I challenge your assertion that there is "almost no deployment". In the past >> 3 days at Return Path we're received reports from 147 unique ISPs, >> companies, etc. >> >> Greg Colburn > > I agree with Greg. Large ISPs like DMARC. I suspect that the smaller players like mailing-list-operators (and other non-compliant-yet-valid-email-scenarios) will be forced to work with, or around, DMARC before DMARC is abandoned by large operators. > > --Terry It was mostly tongue in cheek. I understand DMARC has caught on. I was never against DMARC, but the fact that it was repeating nearly 9+ years of work in what ADSP was already doing (except reporting), and ADSP was indeed the IETF proposed standard track item, made this all issue really surreal. It didn't need to happen. It was coming and all the policy advocates were believers of it. But before DMARC, there was SSP and ADSP and ADSP had to be pushed aside (made HISTORIC this year) in order to clear the path for DMARC. I accept that. We went through the many of IETF-MAN-YEARS engineering the issues DKIM + POLICY layer had, namely, that middleware would need to (software) adapt to new AUTHOR DOMAIN POLICY controls However, the opponents of these new policy protocols did not support it for the most part and held it back from moving forward. It was abandoned in the DKIM-WG, left unfinished. In short, DMARC did not learn from what happen with DKIM+ADSP and as a result we had these "new surprises" for the IETF. It was a total lost of control of the IETF getting in front of this technical mail integration issue known since 2006 with my DSAP I-D, and Murray's 2011 RFC6377 with similar guidelines when I had reminded people again of the potential problems!! DKIM Signature Authorization Protocol (DSAP) http://tools.ietf.org/html/draft-santos-dkim-dsap-00 DomainKeys Identified Mail (DKIM) and Mailing Lists https://tools.ietf.org/html/rfc6377 And I was all ready to go a 2006 IETF meeting to push POLICY with this presentation: http://www.winserver.com/public/ssp/DSAP-00.pdf So if there was ever strong believers in a DKIM POLICY layer and framework, I was among them. ADSP was brushed off because the same folks who believed ADSP's strong reject/discard policy concept will ever get used, also believed DMARC's strong p=reject will never be used as well, and certainly not by the likes of a AOL.COM and YAHOO.COM, two aged and polluted domains like millions of others who would major interesting in improving the security quality and brand of their domains. As one of the strongest advocates of DKIM POLICY in the IETF, I am in full support of DMARC's growing adoption. Years were spent on ADSP, but if we can finally get a DKIM PAYOFF with DMARC, then I'm all for it. Its the "language of choice." That said, as a total mail system developer, I must also make sure that we support the Mailing Listing software can properly fit into the DKIM+POLICY model. We already did it with DKIM+ADSP+ATPS support -- a list will not allow subscriptions from restrictive ADSP policies. We will now add DMARC to the framework. The only thing we need to do is add 3rd party semantics to DMARC to allow the mailing list system to better co-exist and its done for the most part. You will not get an argument from me that DKIM is the finally a winner with a growing market of DMARC p=reject. I hope the Crockers, Levines et al, all finally realize that Author Domain Policies are real and can co-exist with 3rd party Trust layers, and all the 3rd party trust vendors should be pushing hard for policy and use it as a carrot to get customers. -- HLS From nobody Thu Apr 24 11:20: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 2FBA21A032B for ; Thu, 24 Apr 2014 11:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.138 X-Spam-Level: X-Spam-Status: No, score=-101.138 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_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBs0vgMCv6Te for ; Thu, 24 Apr 2014 11:20:37 -0700 (PDT) Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2261A02BA for ; Thu, 24 Apr 2014 11:20:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1122; t=1398363628; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1hGGS6YLBR02QeDD8zQ/yjASv9I=; b=UxkWyPaJ2XuRc2M5xMbI YjMCDNGwPqMdsx6fZ7T6i7hSqUsLH7MWGU5ReXDT7x8X7+0pmytDLapJ2Hs2dq4z AnC6bC+oGASg6uBn3frdv42g1KPOROU4Hx0EAtUlTxs2RBkyUs8xY7zIizvBSIkM WDISri+7E2hmu0NxRP0Zu8E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 24 Apr 2014 14:20:28 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1472195880.666.3548; Thu, 24 Apr 2014 14:20:27 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1122; t=1398363542; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=mjXZERU jKl1+P6qbYx+hu4RyH6jTmY1gMdC7PrKjfho=; b=X7JHaqsyOQD0xQArZrPqOts Xdw07cVTmNYijhIBa+sXI3WahMnbsb6A1uldjz7+roEcNfu10haFeZx6KEZL8Vg4 QAEwKkZ9XnS7JLV7vNjtR05snJwleWgVUPIh0I5Iuif26SMx8mWSPAvEbwxuZicp 0wTV9dCmebyk/7/8kgWA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 24 Apr 2014 14:19:02 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1491719015.9.11948; Thu, 24 Apr 2014 14:19:02 -0400 Message-ID: <535955EA.8030006@isdg.net> Date: Thu, 24 Apr 2014 14:20:26 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Vlatko Salaj , "dmarc@ietf.org" References: <1398106456.78279.YahooMailNeo@web164602.mail.gq1.yahoo.com> <53558E41.5030704@isdg.net> <1398118135.56070.YahooMailNeo@web164605.mail.gq1.yahoo.com> <5355A739.1000409@isdg.net> <1398151254.8652.YahooMailNeo@web164605.mail.gq1.yahoo.com> In-Reply-To: <1398151254.8652.YahooMailNeo@web164605.mail.gq1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4XxGIf9VsAjuEVlUdYY79SzAruM Subject: Re: [dmarc-ietf] DMARC Extension for 3rd party Signers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:20:38 -0000 On 4/22/2014 3:20 AM, Vlatko Salaj wrote: > On Tuesday, April 22, 2014 1:18 AM, Hector Santos wrote: > > >> I think the DKIM 3rd party resigner issue is the more important issue >> at this point. > > i hold both are important. > > ... > > i really see no reason why DMARC can't be flexible enough to include it. > Hi Vlatko, Take a look at the 2006 DSAP I-D proposed author domain policy protocol which provided tags to covered the complete 1st vs 3rd party boundary conditions for DKIM signing practices: „ Original Party Signature (OP tag): „ Not Expected (op-) „ Expected (op+) Optional (op~) „ 3rd Party Signature (3P tag): „ No Expected (3p-) „Expected (3p+) „ Optional (3p~) See page 15/16 in http://www.winserver.com/public/ssp/DSAP-00.pdf So the strongest would be the signing policy (sp=): sp=op+,3p- You can also make it so that a domain only signs with a 3rd party trust vendor, with sp=op-,3p+ DMARC needs to offer similar semantical and tag flexibility to cover all possible 1st and 3rd signature conditions. -- HLS From nobody Thu Apr 24 11:27: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 6FE4A1A0318 for ; Thu, 24 Apr 2014 11:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=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 RIyxvllR0Cfg for ; Thu, 24 Apr 2014 11:27:19 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.90]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB901A02BA for ; Thu, 24 Apr 2014 11:27:17 -0700 (PDT) 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.0.939.4; Thu, 24 Apr 2014 18:27:10 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.125]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.16]) with mapi id 15.00.0939.000; Thu, 24 Apr 2014 18:27:10 +0000 From: Terry Zink To: Hector Santos , Greg Colburn Thread-Topic: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' Thread-Index: AQHPXvPmzuPPWAPwKEihicdkHT1tXJsghkIAgABzXICAAADAkIAAEUkAgAAKj0A= Date: Thu, 24 Apr 2014 18:27:09 +0000 Message-ID: <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <53594D62.4070609@isdg.net> In-Reply-To: <53594D62.4070609@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.159.134] x-exchange-antispam-report-test: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(69234005)(24454002)(479174003)(377454003)(13464003)(243025004)(51444003)(199002)(189002)(74876001)(81342001)(92566001)(81686001)(81542001)(99396002)(81816001)(76786001)(66066001)(93886001)(76796001)(85306002)(15975445006)(83072002)(69226001)(93136001)(95666003)(74366001)(98676001)(15202345003)(4396001)(80022001)(85852003)(20776003)(76482001)(93516002)(74706001)(94316002)(33646001)(95416001)(87266001)(94946001)(65816002)(47976003)(90146001)(97186001)(97336001)(46102001)(79102001)(53806002)(80976001)(59766002)(49866002)(63696004)(47446003)(47736002)(87936001)(51856002)(50986002)(56776002)(54356002)(77982001)(2656002)(74662001)(31966008)(54316003)(56816006)(19580405001)(19580395003)(83322001)(77096001)(74502001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/eg7-t8EJ_lfCwfsDL4NbFPvzK7I Cc: Michael Storz , "dmarc@ietf.org" , DMARC Discuss Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:27:21 -0000 PiBBRFNQIHdhcyBicnVzaGVkIG9mZiBiZWNhdXNlIHRoZSBzYW1lIGZvbGtzIHdobyBiZWxpZXZl ZCBBRFNQJ3Mgc3Ryb25nIA0KPiByZWplY3QvZGlzY2FyZCBwb2xpY3kgY29uY2VwdCB3aWxsIGV2 ZXIgZ2V0IHVzZWQsIGFsc28gYmVsaWV2ZWQgRE1BUkMncyBzdHJvbmcgDQo+IHA9cmVqZWN0IHdp bGwgbmV2ZXIgYmUgdXNlZCBhcyB3ZWxsLCBhbmQgY2VydGFpbmx5IG5vdCBieSB0aGUgbGlrZXMg b2YgYSBBT0wuQ09NIA0KPiBhbmQgWUFIT08uQ09NLCB0d28gYWdlZCBhbmQgcG9sbHV0ZWQgZG9t YWlucyBsaWtlIG1pbGxpb25zIG9mIG90aGVycyB3aG8NCj4gIHdvdWxkIG1ham9yIGludGVyZXN0 aW5nIGluIGltcHJvdmluZyB0aGUgc2VjdXJpdHkgcXVhbGl0eSBhbmQgYnJhbmQgb2YgdGhlaXIg ZG9tYWlucy4NCg0KQ29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLCBidXQgSSB0aGluayB0aGF0IHRo ZXJlIGFyZSBzaWduaWZpY2FudCBkaWZmZXJlbmNlcyBiZXR3ZWVuIG5vdyBhbmQgd2hlbiBBRFNQ IHdhcyBiZWluZyBpbnZlc3RpZ2F0ZWQ6DQoNCjEuIERLSU0gaGFzIG11Y2ggbW9yZSBwcmV2YWxl bmNlIGluIDIwMTQgdGhhbiBpdCBkaWQgaW4gMjAwNiwgc28gcmVxdWlyaW5nIGl0IHRvZGF5IGlz bid0IGFzIGJpZyBhbiBvYnN0YWNsZS4NCg0KMi4gREtJTSBkb2Vzbid0IHRpZSB0aGUgZD0gc2ln bmF0dXJlIGZpZWxkIHRvIHRoZSA1MzIyLkZyb206IGFkZHJlc3MuIFNvLCB5b3UgY2FuIERLSU0t c2lnbiBhbGwgeW91IHdhbnQgYW5kIGFkZCBhdXRob3JpemVkIHRoaXJkIHBhcnR5IHNpZ25hdHVy ZXMgYWxsIHlvdSB3YW50LiBCdXQgaWYgdGhlIEZyb206IGFkZHJlc3MgaXMgZGlmZmVyZW50IHRo YW4gd2hhdCB3YXMgYXV0aGVudGljYXRlZCwgdGhlbiB0aGUgZW5kIHVzZXIgd29uJ3QgdW5kZXJz dGFuZCB0aGUgZGlmZmVyZW5jZS4NCg0KMy4gRE1BUkMgaXMgYmFzaWNhbGx5IGFuIGFudGktcGhp c2hpbmcgdGVjaG5vbG9neSwgd2hlcmVhcyB3aGlsZSBES0lNICsgQURTUCBjYW4gZG8gdGhhdCwg aXQgZG9lc24ndCBkbyBpdCBhcyB3ZWxsLiBJdCdzIGxlc3MgaW50dWl0aXZlIHRvIGVuZCB1c2Vy cy4gQW5kIGJlY2F1c2UgRE1BUkMgaXMgYmV0dGVyIGZvciBhbnRpLXBoaXNoaW5nLCBJIHdvdWxk IGd1ZXNzIHRoYXQncyB3aHkgaXQgaGFzIG11Y2ggYmV0dGVyIHRyYWN0aW9uIHRoYXQgQURTUCBl dmVyIGNvdWxkLiBTcGVha2luZyBmb3IgYSBsYXJnZShpc2gpIGVtYWlsIHByb3ZpZGVyLCBES0lN IGlzIGdvb2QgYnV0IHN0b3BwaW5nIHBoaXNoaW5nIGlzIGJldHRlci4NCg0KLS0gVGVycnkNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhlY3RvciBTYW50b3MgW21haWx0bzpo c2FudG9zQGlzZGcubmV0XSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyNCwgMjAxNCAxMDo0NCBB TQ0KVG86IFRlcnJ5IFppbms7IEdyZWcgQ29sYnVybg0KQ2M6IE1pY2hhZWwgU3Rvcno7IGRtYXJj QGlldGYub3JnOyBETUFSQyBEaXNjdXNzDQpTdWJqZWN0OiBSZTogW2RtYXJjLWlldGZdIEZZSTog QU9MIE1haWwgdXBkYXRlcyBETUFSQyBwb2xpY3kgdG8gJ3JlamVjdCcNCg0KT24gNC8yNC8yMDE0 IDEyOjQ0IFBNLCBUZXJyeSBaaW5rIHdyb3RlOg0KPj4+IE9uIEFwciAyNCwgMjAxNCwgYXQgMzo0 NiBBTSwgSGVjdG9yIFNhbnRvcyA8aHNhbnRvc0Bpc2RnLm5ldD4gd3JvdGU6DQo+Pj4NCj4+PiBj aGFuZ2UgQURTUCB0byBETUFSQyBiZWxvdyBhdCB0aGUgSUVURiBSRkMgU3RhdHVzIGNoYW5nZSBs aW5rLg0KPj4+IFRlY2huaWNhbGx5LCBpdCBpcyBzdGlsbCBhbG1vc3Qgbm8gZGVwbG95bWVudCwg anVzdCBhIGZldyBCSUcgZ3V5cyEhDQo+Pj4NCj4+Pg0KPj4+IEhlY3Rvcg0KPg0KPj4gSSBjaGFs bGVuZ2UgeW91ciBhc3NlcnRpb24gdGhhdCB0aGVyZSBpcyAiYWxtb3N0IG5vIGRlcGxveW1lbnQi LiAgSW4gDQo+PiB0aGUgcGFzdA0KPj4gMyBkYXlzIGF0IFJldHVybiBQYXRoIHdlJ3JlIHJlY2Vp dmVkIHJlcG9ydHMgZnJvbSAxNDcgdW5pcXVlIElTUHMsIA0KPj4gY29tcGFuaWVzLCBldGMuDQo+ Pg0KPj4gR3JlZyBDb2xidXJuDQo+DQo+IEkgYWdyZWUgd2l0aCBHcmVnLiBMYXJnZSBJU1BzIGxp a2UgRE1BUkMuIEkgc3VzcGVjdCB0aGF0IHRoZSBzbWFsbGVyIHBsYXllcnMgbGlrZSBtYWlsaW5n LWxpc3Qtb3BlcmF0b3JzIChhbmQgb3RoZXIgbm9uLWNvbXBsaWFudC15ZXQtdmFsaWQtZW1haWwt c2NlbmFyaW9zKSB3aWxsIGJlIGZvcmNlZCB0byB3b3JrIHdpdGgsIG9yIGFyb3VuZCwgRE1BUkMg YmVmb3JlIERNQVJDIGlzIGFiYW5kb25lZCBieSBsYXJnZSBvcGVyYXRvcnMuDQo+DQo+IC0tVGVy cnkNCg0KSXQgd2FzIG1vc3RseSB0b25ndWUgaW4gY2hlZWsuDQoNCkkgdW5kZXJzdGFuZCBETUFS QyBoYXMgY2F1Z2h0IG9uLiBJIHdhcyBuZXZlciBhZ2FpbnN0IERNQVJDLCBidXQgdGhlIGZhY3Qg dGhhdCBpdCB3YXMgcmVwZWF0aW5nIG5lYXJseSA5KyB5ZWFycyBvZiB3b3JrIGluIHdoYXQgQURT UCB3YXMgYWxyZWFkeSBkb2luZyAoZXhjZXB0IHJlcG9ydGluZyksIGFuZCBBRFNQIHdhcyBpbmRl ZWQgdGhlIElFVEYgcHJvcG9zZWQgc3RhbmRhcmQgdHJhY2sgaXRlbSwgbWFkZSB0aGlzIGFsbCBp c3N1ZSByZWFsbHkgc3VycmVhbC4gIEl0IGRpZG4ndCBuZWVkIHRvIGhhcHBlbi4gIEl0IHdhcyBj b21pbmcgYW5kIGFsbCB0aGUgcG9saWN5IGFkdm9jYXRlcyB3ZXJlIGJlbGlldmVycyBvZiBpdC4g IEJ1dCBiZWZvcmUgRE1BUkMsIHRoZXJlIHdhcyBTU1AgYW5kIEFEU1AgYW5kIEFEU1AgaGFkIHRv IGJlIHB1c2hlZCBhc2lkZSAobWFkZSBISVNUT1JJQyB0aGlzIHllYXIpIGluIG9yZGVyIHRvIGNs ZWFyIHRoZSBwYXRoIGZvciBETUFSQy4gIEkgYWNjZXB0IHRoYXQuDQoNCldlIHdlbnQgdGhyb3Vn aCB0aGUgbWFueSBvZiBJRVRGLU1BTi1ZRUFSUyBlbmdpbmVlcmluZyB0aGUgaXNzdWVzIERLSU0g DQorIFBPTElDWSBsYXllciBoYWQsIG5hbWVseSwgdGhhdCBtaWRkbGV3YXJlIHdvdWxkIG5lZWQg dG8gKHNvZnR3YXJlKQ0KYWRhcHQgdG8gbmV3IEFVVEhPUiBET01BSU4gUE9MSUNZIGNvbnRyb2xz ICAgSG93ZXZlciwgdGhlIG9wcG9uZW50cyBvZiANCnRoZXNlIG5ldyBwb2xpY3kgcHJvdG9jb2xz IGRpZCBub3Qgc3VwcG9ydCBpdCBmb3IgdGhlIG1vc3QgcGFydCBhbmQgaGVsZCBpdCBiYWNrIGZy b20gbW92aW5nIGZvcndhcmQuICBJdCB3YXMgYWJhbmRvbmVkIGluIHRoZSBES0lNLVdHLCBsZWZ0 IHVuZmluaXNoZWQuDQoNCkluIHNob3J0LCBETUFSQyBkaWQgbm90IGxlYXJuIGZyb20gd2hhdCBo YXBwZW4gd2l0aCBES0lNK0FEU1AgYW5kIGFzIGEgcmVzdWx0IHdlIGhhZCB0aGVzZSAibmV3IHN1 cnByaXNlcyIgZm9yIHRoZSBJRVRGLiBJdCB3YXMgYSB0b3RhbCBsb3N0IG9mIGNvbnRyb2wgb2Yg dGhlIElFVEYgZ2V0dGluZyBpbiBmcm9udCBvZiB0aGlzIHRlY2huaWNhbCBtYWlsIGludGVncmF0 aW9uIGlzc3VlIGtub3duIHNpbmNlIDIwMDYgd2l0aCBteSBEU0FQIEktRCwgYW5kIE11cnJheSdz IDIwMTENClJGQzYzNzcgd2l0aCBzaW1pbGFyIGd1aWRlbGluZXMgd2hlbiBJIGhhZCByZW1pbmRl ZCBwZW9wbGUgYWdhaW4gb2YgdGhlIHBvdGVudGlhbCBwcm9ibGVtcyEhDQoNCiAgIERLSU0gU2ln bmF0dXJlIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgKERTQVApDQogICBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1zYW50b3MtZGtpbS1kc2FwLTAwDQoNCiAgIERvbWFpbktleXMgSWRl bnRpZmllZCBNYWlsIChES0lNKSBhbmQgTWFpbGluZyBMaXN0cw0KICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzYzNzcNCg0KQW5kIEkgd2FzIGFsbCByZWFkeSB0byBnbyBhIDIwMDYg SUVURiBtZWV0aW5nIHRvIHB1c2ggUE9MSUNZIHdpdGggdGhpcw0KcHJlc2VudGF0aW9uOg0KDQog ICBodHRwOi8vd3d3LndpbnNlcnZlci5jb20vcHVibGljL3NzcC9EU0FQLTAwLnBkZg0KDQpTbyBp ZiB0aGVyZSB3YXMgZXZlciBzdHJvbmcgYmVsaWV2ZXJzIGluIGEgREtJTSBQT0xJQ1kgbGF5ZXIg YW5kIGZyYW1ld29yaywgSSB3YXMgYW1vbmcgdGhlbS4NCg0KQURTUCB3YXMgYnJ1c2hlZCBvZmYg YmVjYXVzZSB0aGUgc2FtZSBmb2xrcyB3aG8gYmVsaWV2ZWQgQURTUCdzIHN0cm9uZyByZWplY3Qv ZGlzY2FyZCBwb2xpY3kgY29uY2VwdCB3aWxsIGV2ZXIgZ2V0IHVzZWQsIGFsc28gYmVsaWV2ZWQg RE1BUkMncyBzdHJvbmcgcD1yZWplY3Qgd2lsbCBuZXZlciBiZSB1c2VkIGFzIHdlbGwsIGFuZCBj ZXJ0YWlubHkgbm90IGJ5IHRoZSBsaWtlcyBvZiBhIEFPTC5DT00gYW5kIFlBSE9PLkNPTSwgdHdv IGFnZWQgYW5kIHBvbGx1dGVkIGRvbWFpbnMgbGlrZSBtaWxsaW9ucyBvZiBvdGhlcnMgd2hvIHdv dWxkIG1ham9yIGludGVyZXN0aW5nIGluIGltcHJvdmluZyB0aGUgc2VjdXJpdHkgcXVhbGl0eSBh bmQgYnJhbmQgb2YgdGhlaXIgZG9tYWlucy4NCg0KQXMgb25lIG9mIHRoZSBzdHJvbmdlc3QgYWR2 b2NhdGVzIG9mIERLSU0gUE9MSUNZIGluIHRoZSBJRVRGLCBJIGFtIGluIGZ1bGwgc3VwcG9ydCBv ZiBETUFSQydzIGdyb3dpbmcgYWRvcHRpb24uICBZZWFycyB3ZXJlIHNwZW50IG9uIEFEU1AsIGJ1 dCBpZiB3ZSBjYW4gZmluYWxseSBnZXQgYSBES0lNIFBBWU9GRiB3aXRoIERNQVJDLCB0aGVuIEkn bSBhbGwgZm9yIGl0LiAgSXRzIHRoZSAibGFuZ3VhZ2Ugb2YgY2hvaWNlLiINCg0KVGhhdCBzYWlk LCBhcyBhIHRvdGFsIG1haWwgc3lzdGVtIGRldmVsb3BlciwgSSBtdXN0IGFsc28gbWFrZSBzdXJl IHRoYXQgd2Ugc3VwcG9ydCB0aGUgTWFpbGluZyBMaXN0aW5nIHNvZnR3YXJlIGNhbiBwcm9wZXJs eSBmaXQgaW50byB0aGUgDQpES0lNK1BPTElDWSBtb2RlbC4gIFdlIGFscmVhZHkgZGlkIGl0IHdp dGggREtJTStBRFNQK0FUUFMgc3VwcG9ydCAtLSBhDQpsaXN0IHdpbGwgbm90IGFsbG93IHN1YnNj cmlwdGlvbnMgZnJvbSByZXN0cmljdGl2ZSBBRFNQIHBvbGljaWVzLiAgV2Ugd2lsbCBub3cgYWRk IERNQVJDIHRvIHRoZSBmcmFtZXdvcmsuDQoNClRoZSBvbmx5IHRoaW5nIHdlIG5lZWQgdG8gZG8g aXMgYWRkIDNyZCBwYXJ0eSBzZW1hbnRpY3MgdG8gRE1BUkMgdG8gYWxsb3cgdGhlIG1haWxpbmcg bGlzdCBzeXN0ZW0gdG8gYmV0dGVyIGNvLWV4aXN0IGFuZCBpdHMgZG9uZSBmb3IgdGhlIG1vc3Qg cGFydC4NCg0KWW91IHdpbGwgbm90IGdldCBhbiBhcmd1bWVudCBmcm9tIG1lIHRoYXQgREtJTSBp cyB0aGUgZmluYWxseSBhIHdpbm5lciANCndpdGggYSBncm93aW5nIG1hcmtldCBvZiBETUFSQyBw PXJlamVjdC4gICBJIGhvcGUgdGhlIENyb2NrZXJzLCANCkxldmluZXMgZXQgYWwsIGFsbCBmaW5h bGx5IHJlYWxpemUgdGhhdCBBdXRob3IgRG9tYWluIFBvbGljaWVzIGFyZSByZWFsIGFuZCBjYW4g Y28tZXhpc3Qgd2l0aCAzcmQgcGFydHkgVHJ1c3QgbGF5ZXJzLCBhbmQgYWxsIHRoZSAzcmQgcGFy dHkgdHJ1c3QgdmVuZG9ycyBzaG91bGQgYmUgcHVzaGluZyBoYXJkIGZvciBwb2xpY3kgYW5kIHVz ZSBpdCBhcyBhIGNhcnJvdCB0byBnZXQgY3VzdG9tZXJzLg0KDQotLQ0KSExTDQoNCg0K From nobody Thu Apr 24 11:56: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 2CC0E1A036B for ; Thu, 24 Apr 2014 11:56:16 -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 5l-2tvzhBaAQ for ; Thu, 24 Apr 2014 11:56:12 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id BDF071A03C2 for ; Thu, 24 Apr 2014 11:56:10 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so2686667wes.3 for ; Thu, 24 Apr 2014 11:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZysDrB9IdELe22lOEmYjlgR6z3e/yq0Do+NOTbrqQxk=; b=Oidv7vqiH2QwdDLFNfxE1n31Qgxs0jPruaWcLC6JHQm0ZXBfCsJTu1hc+iK8iMY+az wE0LdUDtF2lLMaxxCW0xlADgIKkIxC62sYlKqzNoIMzBI9SbhmoK6NowWNtlGXRcFhGL rokK+KqJDz4iPxMzMpZ9Wv6FMTTwqCX8aUnUBgyuyPxPaC4beojHytusVkqcNehEetR0 IIIq0nv/yZGNSi/xRMakNaw/WhTWX7Fa7TE9M58EU2k1uvzd7N27Xn428k8TD4/kmtzQ BQDbSsnWBp1l0jzmxIXYoyEIw7OPgD8HX6F1uBcR/EIggEgG+4yJK9XJXyhLQiKLh8AS lFhw== MIME-Version: 1.0 X-Received: by 10.194.109.227 with SMTP id hv3mr3223340wjb.10.1398365763536; Thu, 24 Apr 2014 11:56:03 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Thu, 24 Apr 2014 11:56:03 -0700 (PDT) In-Reply-To: <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <53594D62.4070609@isdg.net> <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Thu, 24 Apr 2014 11:56:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=089e0102ee289a0ef004f7ce660e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/RjCEl1lFKP4mkSywKKs06n07TxU Cc: Michael Storz , "dmarc@ietf.org" , Hector Santos , Greg Colburn , DMARC Discuss Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 18:56:16 -0000 --089e0102ee289a0ef004f7ce660e Content-Type: text/plain; charset=UTF-8 On Thu, Apr 24, 2014 at 11:27 AM, Terry Zink wrote: > Correct me if I am wrong, but I think that there are significant > differences between now and when ADSP was being investigated: > > 1. DKIM has much more prevalence in 2014 than it did in 2006, so requiring > it today isn't as big an obstacle. > > 2. DKIM doesn't tie the d= signature field to the 5322.From: address. So, > you can DKIM-sign all you want and add authorized third party signatures > all you want. But if the From: address is different than what was > authenticated, then the end user won't understand the difference. > > 3. DMARC is basically an anti-phishing technology, whereas while DKIM + > ADSP can do that, it doesn't do it as well. It's less intuitive to end > users. And because DMARC is better for anti-phishing, I would guess that's > why it has much better traction that ADSP ever could. Speaking for a > large(ish) email provider, DKIM is good but stopping phishing is better. > When we did ADSP (RFC 5617), the mailing list damage it could do was considered a showstopper for the vast majority of everyone participating, and advocates for "strong policy" were in the rough. I note from ADSP's author list that this included Yahoo!. The recommended practice was to split streams, so ADSP-protected mail was in one domain and user mail was in another. This is why domains like yahoo-inc.com, googlers.com, paypal-inc.com, etc. began to appear. It was still true when we revised DKIM a couple of years later, because the concerns were unchanged yet yielded no relevant changes to DKIM itself, and the working group produced RFC 6377 to document the problem in more detail rather than take another run at trying to solve it. What's changed since then appears to be that some operators now believe the collateral damage is acceptable. -MSK --089e0102ee289a0ef004f7ce660e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 24, 2014 at 11:27 AM, Terry Zink <= tzink@exchange.microsoft.com> wrote:
Correct me if I am wrong, but I think that t= here are significant differences between now and when ADSP was being invest= igated:

1. DKIM has much more prevalence in 2014 than it did in 2006, so requiring = it today isn't as big an obstacle.

2. DKIM doesn't tie the d=3D signature field to the 5322.From: address.= So, you can DKIM-sign all you want and add authorized third party signatur= es all you want. But if the From: address is different than what was authen= ticated, then the end user won't understand the difference.

3. DMARC is basically an anti-phishing technology, whereas while DKIM + ADS= P can do that, it doesn't do it as well. It's less intuitive to end= users. And because DMARC is better for anti-phishing, I would guess that&#= 39;s why it has much better traction that ADSP ever could. Speaking for a l= arge(ish) email provider, DKIM is good but stopping phishing is better.

When we did = ADSP (RFC 5617), the mailing list damage it could do was considered a shows= topper for the vast majority of everyone participating, and advocates for &= quot;strong policy" were in the rough.=C2=A0 I note from ADSP's au= thor list that this included Yahoo!.=C2=A0 The recommended practice was to = split streams, so ADSP-protected mail was in one domain and user mail was i= n another.=C2=A0 This is why domains like = yahoo-inc.com, googlers.com, paypal-inc.com, etc. began to appear.

It was still true when we revised DKIM a couple of years lat= er, because the concerns were unchanged yet yielded no relevant changes to = DKIM itself, and the working group produced RFC 6377 to document the proble= m in more detail rather than take another run at trying to solve it.

What's changed since then appears to be that some operat= ors now believe the collateral damage is acceptable.

-MSK
--089e0102ee289a0ef004f7ce660e-- From nobody Thu Apr 24 12:06:11 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 702D41A03C2 for ; Thu, 24 Apr 2014 12:06:10 -0700 (PDT) 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 sbysGBvdRkxq for ; Thu, 24 Apr 2014 12:06:08 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B75CE1A0389 for ; Thu, 24 Apr 2014 12:06:08 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p10so1897503pdj.32 for ; Thu, 24 Apr 2014 12:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=aQzk8efw59BwZL31tP1BzZMLtM7ybhzF5Dkl8Hm8O7E=; b=K+IdVgZEWk1rYhwitwN03R34yBj/PNFOFYfV1MHrBUubGH43S5v+9MLWgds8msFkIU kvnl6aHVunxWv5PrIszaGXHvPRTO4rfBjlnEGje6YBvl52QG1fxrJV9xXmc1JwlkBUlj QeJiij6rzANDGNqNjz84uFqWCSJIgLkAruzJ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=aQzk8efw59BwZL31tP1BzZMLtM7ybhzF5Dkl8Hm8O7E=; b=Qjx3AOb8gxbDmKLVQPISMHFIusJ9Xvk4L4I8F4HtrmNEsJ/+076ZUodKdNbmWxlQ/Y oZcBoth1j7JSH2/X288YehOqpIJNZeM8mH9JqatFyziF/W8D6YKOFB5wbrVshW9kIw/z 3Kr0tQCEsDdmd0Z3OEPogALKfjL8RMDdUrwMoj22T2bOYudvb+Ucrc1vk2M6zPpWqVt8 bcT58UIOmFUWnN05cC1WC0AFKLqi73gy815MoDHlv12BkJ94NuPVfa3mo3owRuPTiPnq uOkzI0vxu2MgDoAVHdly1j+wtGDCzXga0ObGPacr/jCS/EP/7v6/AMC2SWJwCf5/nC6J 9yIQ== X-Gm-Message-State: ALoCoQmWbuNfdS5sXrRY6jpetEFRxkTOSumQY5XZ3NkQu8W+SVMbo38yvNXlV4aCkxSeyart3QEW X-Received: by 10.68.135.42 with SMTP id pp10mr5724313pbb.58.1398366362710; Thu, 24 Apr 2014 12:06:02 -0700 (PDT) Received: from [10.0.1.209] (50-197-151-169-static.hfc.comcastbusiness.net. [50.197.151.169]) by mx.google.com with ESMTPSA id sh5sm10736155pbc.21.2014.04.24.12.05.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Apr 2014 12:06:01 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2D3CC5FA-4013-4116-A425-24232700808A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Patrick Peterson In-Reply-To: Date: Thu, 24 Apr 2014 12:05:52 -0700 Message-Id: References: To: "Solomon, Dianne B" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KLNs_tuqHxbMepgmYFP3mQKqiJo Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Forensic Reporting X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 19:06:10 -0000 --Apple-Mail=_2D3CC5FA-4013-4116-A425-24232700808A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dianne I am not aware of any active efforts. Here are a few options that may = have some viability for you and others. They may not have any viability = either. :) NOTE: This is not a statement that there is an acceptable solution to = the privacy issues nor that additional work shouldn=92t be done. Merely = a summary of some known issues to mitigate. It is up to each domain = owner to determine if there is an issue and if these mitigation options = have value. No need to respond with the inadequacy of the options below = - if they aren=92t good enough then just don=92t request forensic data = and propose ways to change the specification to address privacy issues. 1. Don=92t provide a ruf address and receive no forensic data for = certain domains Eliminates privacy issue, eliminates all message-level data 2. Request forensic data on domains which have acceptable privacy = concerns Forensic data is requested on a per-domain basis. This may help some = organizations and not others. For example, if there is an = notices@alerts.bank.com mail stream that is all automated messages = without PII, forensic data could be received with minimal risk and = domains such as broker@privatewealthmanagement.bank.com could not have = forensic data collected. 3. Publish record with ruf parameter Po=3D0 This ensures message-level failures will only be received if both SPF = and DKIM fail authentication (vs either one). This does not eliminate = the issue, but when used in conjuction with delaying receipt of forensic = data until most mail streams have some level of authentication, it = reduces the risk significantly - only your lawyer can determine how = much. For details on this argument, see Section 5.2 of = https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=3D= 1 4. Redact forensic data upon receipt Either via a vendor or your own system, you can redact, upon ingestion = of the forensic message, certain data fields and ensure the ingestion = system never records or stores them. The data is transmitted over the = internet (like the original message) but there will never be a human or = machine readable record of fields which generate PII concerns. Some = DMARC service providers support this.=20 pat On Apr 24, 2014, at 5:32 AM, Solomon, Dianne B = wrote: > Hi.. I am new to DMARC. =46rom what I am learning, few companies = are implementing forensic reporting because of potential privacy issues. = Has there been discussion on changing the format or delivery of the = forensic reports that would make it a more acceptable option?=20 > =20 > =20 > Dianne Blitstein Solomon, CIPP, CIPP/IT | Architect, ISCD.IS.Messaging = Security | First Data Corporation | www.firstdata.com > 4000 Coral Ridge Drive, Coral Springs, FL 33065 | (O) +1.954.851.7290 = | (M) 954.695.8094 | GMT -5 > Suspect an information security incident? Please call 888-427-4468. > =20 > =20 > =20 > =20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail=_2D3CC5FA-4013-4116-A425-24232700808A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJTWWCQAAoJEK1XNLV61MH0euIH/2M3D2dxI7A1Qdl/msjc7EdX SD84rnmRF6knVeNUxIUVt3lipAXtvbT2+XN1mpAL5nL2Z20XZdb2/uhvP2Kni2g3 B2S2nOB3mKzS2W6/mSazrWevZmyu4rS4ReHRLIAOhFPk9UBfZzFDpD3zRXlX7FZ3 6xec7NodDIZBAGDeSUsjleewIRK63j1mZNRDTVm06F5ApBAXA420a4ZFHkJamMmo Qie3EmhDiS39BT6819FMmKNfW8spu5NYznaYb1HVoq5tT5JM2E23WMt/EtSWg2wB Z4MK45XhVJ5025K6pffHePQjMqZVTSeSoSg+f4Lh1Sb1X8CTZ1z4fXaIPFUm2tM= =NTkb -----END PGP SIGNATURE----- --Apple-Mail=_2D3CC5FA-4013-4116-A425-24232700808A-- From nobody Thu Apr 24 14: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 C29F71A019E for ; Thu, 24 Apr 2014 14:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 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.272, 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 pe5UYfXTcoSt for ; Thu, 24 Apr 2014 14:27:42 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id 697801A0165 for ; Thu, 24 Apr 2014 14:27:42 -0700 (PDT) Received: from splunge.local ([12.199.7.82]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s3OLRYJk010986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 24 Apr 2014 14:27:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1398374856; bh=PvCid9tGc9Q9clTvsOaeAWT7rEXEOFYquEMiFO3MNnQ=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Y9cqj0kpyXTZBw6ku/pGXeWe3cltgYyI/LNWKn+TzqSBQ+N9XCGlNQISzWMzvh1zE cd/SOAYjj/u1Plhz2VofVi8TlHhpjbiktZGJOOpLdwJMYD3CpCBtmi45XAeiYFy+Qf 0cZiOIm8TIv+TASKgn88R2LCtH+Kr9VxVHtbO/40= Message-ID: <535981C5.7000003@bluepopcorn.net> Date: Thu, 24 Apr 2014 14:27:33 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <53594D62.4070609@isdg.net> <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FTuFilmGktFIY-C_99982Zz2CQQ Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 21:27:43 -0000 On 4/24/14 11:27 AM, Terry Zink wrote: > Correct me if I am wrong, but I think that there are significant differences between now and when ADSP was being investigated: > > 1. DKIM has much more prevalence in 2014 than it did in 2006, so requiring it today isn't as big an obstacle. ADSP is published by the same domains that are deploying DKIM, so the overall prevalence of DKIM isn't a factor. > 2. DKIM doesn't tie the d= signature field to the 5322.From: address. So, you can DKIM-sign all you want and add authorized third party signatures all you want. But if the From: address is different than what was authenticated, then the end user won't understand the difference. But ADSP does tie the d= signature to the 5322.From domain, by virtue of the fact that only signatures where d= matches the 5322.From domain match are considered "author domain" signatures. > > 3. DMARC is basically an anti-phishing technology, whereas while DKIM + ADSP can do that, it doesn't do it as well. It's less intuitive to end users. And because DMARC is better for anti-phishing, I would guess that's why it has much better traction that ADSP ever could. Speaking for a large(ish) email provider, DKIM is good but stopping phishing is better. I'd like to understand why DMARC is "better for anti-phishing". But let's not turn this into a DMARC-vs-ADSP argument. And in either case, it shouldn't be intuitive to end users; it shouldn't even be visible to them. -Jim From nobody Thu Apr 24 14:40: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 9C8641A03F2 for ; Thu, 24 Apr 2014 14:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM7PD4UCHtUm for ; Thu, 24 Apr 2014 14:40:06 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 30E181A03EF for ; Thu, 24 Apr 2014 14:40:06 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 24 Apr 2014 23:39:58 +0200 Message-ID: From: "J. Gomez" To: , DMARC Discuss References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Thu, 24 Apr 2014 23:39:44 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lNcrx7F7r9pGtcQ2_MJ7Ab6W3-4 Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 21:40:09 -0000 On Thursday, April 24, 2014 6:44 PM [GMT+1=3DCET], Terry Zink wrote: > > > On Apr 24, 2014, at 3:46 AM, Hector Santos > > > wrote:=20 > > >=20 > > > change ADSP to DMARC below at the IETF RFC Status change link. > > > Technically, it is still almost no deployment, just a few BIG > > > guys!!=20 >=20 > > I challenge your assertion that there is "almost no deployment".=20 > > In the past 3 days at Return Path we're received reports from 147 > > unique ISPs, companies, etc. > >=20 > > Greg Colburn >=20 > I agree with Greg. Large ISPs like DMARC. I suspect that the smaller > players like mailing-list-operators (and other > non-compliant-yet-valid-email-scenarios) will be forced to work with, > or around, DMARC before DMARC is abandoned by large operators. Large ISPs/ESPs like DMARC because they, by definition, are = too-big-to-block so they can afford to offload the support costs of = DMARC failure cases on the small email operators. There where they happen not to be too-big-to-block, those ISPs/ESPs = don't dare to indulge in such practices (confront yahoo.com vs = yahoo.fr/yahoo.es DMARC policies). They way for small email operators to "work with/around" that, is to not = check DMARC for incoming email, to publish at most a DMARC policy of = "none", and to stick to good old plain-SPF. Regards, J.Gomez From nobody Thu Apr 24 14:49: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 6DE661A03F7 for ; Thu, 24 Apr 2014 14:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 CmMPG6D4YO9e for ; Thu, 24 Apr 2014 14:49:01 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id A75841A03F5 for ; Thu, 24 Apr 2014 14:49:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5B1FF39ADCF; Thu, 24 Apr 2014 16:48:55 -0500 (CDT) 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 Nf_hfHQKzbfq; Thu, 24 Apr 2014 16:48:55 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3C70939AD49; Thu, 24 Apr 2014 16:48:55 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 261A3399A15; Thu, 24 Apr 2014 16:48:55 -0500 (CDT) 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 424rXhi6gqUE; Thu, 24 Apr 2014 16:48:55 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 0988539AC60; Thu, 24 Apr 2014 16:48:55 -0500 (CDT) Date: Thu, 24 Apr 2014 16:48:52 -0500 (CDT) From: Franck Martin To: Jim Fenton Message-ID: <308873318.118810.1398376132860.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <53594D62.4070609@isdg.net> <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <535981C5.7000003@bluepopcorn.net> 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 - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: AOL Mail updates DMARC policy to 'reject' Thread-Index: ofjLchhVqLvXR6LUK50cpJR/nSo0Cw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nWMBkonPwoOdAkhXFi-Q2yMtAcw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 21:49:03 -0000 ----- Original Message ----- > From: "Jim Fenton" > To: dmarc@ietf.org > Sent: Thursday, April 24, 2014 2:27:33 PM > Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' > > > 3. DMARC is basically an anti-phishing technology, whereas while DKIM + > > ADSP can do that, it doesn't do it as well. It's less intuitive to end > > users. And because DMARC is better for anti-phishing, I would guess that's > > why it has much better traction that ADSP ever could. Speaking for a > > large(ish) email provider, DKIM is good but stopping phishing is better. > > I'd like to understand why DMARC is "better for anti-phishing". But > let's not turn this into a DMARC-vs-ADSP argument. And in either case, > it shouldn't be intuitive to end users; it shouldn't even be visible to > them. > ADSP did not provide any reporting. With failure reports and even aggregate reports the person most interested to stop the phishing (the brand), get the data to pursue the phish on a multitude of avenues. >From the old "a user reported a phish" to DMARC today "there has been 100k email phish caught by these providers", it changes your perspective and priorities. From nobody Thu Apr 24 14:52: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 38DEE1A03F8 for ; Thu, 24 Apr 2014 14:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 YF2_UNUlFn9C for ; Thu, 24 Apr 2014 14:51:56 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id D636A1A03EF for ; Thu, 24 Apr 2014 14:51:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id CF88F2AC3E1; Thu, 24 Apr 2014 16:51:49 -0500 (CDT) 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 KcMVl1QEvupg; Thu, 24 Apr 2014 16:51:49 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id AB1992AC3E5; Thu, 24 Apr 2014 16:51:49 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9B6832AC3E3; Thu, 24 Apr 2014 16:51:49 -0500 (CDT) 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 LkHGXoloon4o; Thu, 24 Apr 2014 16:51:49 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 6AD0F2AC3E1; Thu, 24 Apr 2014 16:51:49 -0500 (CDT) Date: Thu, 24 Apr 2014 16:51:48 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1195712392.118879.1398376308135.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <53594D62.4070609@isdg.net> <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_118878_233512723.1398376308134" X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF28 (Mac)/8.0.5_GA_5839) Thread-Topic: AOL Mail updates DMARC policy to 'reject' Thread-Index: XbilHn3psePAU4FduLegu8OUZ/vvZQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1ugUK-X7QXstaDQVoNhNHGVrkr0 Cc: dmarc@ietf.org, Hector Santos , DMARC Discuss , Terry Zink Subject: Re: [dmarc-ietf] [dmarc-discuss] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 21:51:59 -0000 ------=_Part_118878_233512723.1398376308134 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Terry Zink" > Cc: dmarc@ietf.org, "Hector Santos" , "DMARC Discuss" > > Sent: Thursday, April 24, 2014 11:56:03 AM > Subject: Re: [dmarc-discuss] [dmarc-ietf] FYI: AOL Mail updates DMARC policy > to 'reject' > When we did ADSP (RFC 5617), the mailing list damage it could do was > considered a showstopper for the vast majority of everyone participating, > and advocates for "strong policy" were in the rough. I note from ADSP's > author list that this included Yahoo!. The recommended practice was to split > streams, so ADSP-protected mail was in one domain and user mail was in > another. This is why domains like yahoo-inc.com , googlers.com , > paypal-inc.com , etc. began to appear. > It was still true when we revised DKIM a couple of years later, because the > concerns were unchanged yet yielded no relevant changes to DKIM itself, and > the working group produced RFC 6377 to document the problem in more detail > rather than take another run at trying to solve it. > What's changed since then appears to be that some operators now believe the > collateral damage is acceptable. Finish the sentence... ;) "... in relation to the benefits while the ecosystem adapts" ------=_Part_118878_233512723.1398376308134 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "Terry Zink" <tzink@exchange.microsoft.com>
Cc: dmarc@ietf.org, "Hector Santos" <hsantos@isdg.net>, "DMARC Discuss" <dmarc-discuss@dmarc.org>
Sent: Thursday, April 24, 2014 11:56:03 AM
Subject: Re: [dmarc-discuss] [dmarc-ietf] FYI: AOL Mail updates DMARC policy        to 'reject'


When we did ADSP (RFC 5617), the mailing list damage it could do was considered a showstopper for the vast majority of everyone participating, and advocates for "strong policy" were in the rough.  I note from ADSP's author list that this included Yahoo!.  The recommended practice was to split streams, so ADSP-protected mail was in one domain and user mail was in another.  This is why domains like yahoo-inc.com, googlers.com, paypal-inc.com, etc. began to appear.

It was still true when we revised DKIM a couple of years later, because the concerns were unchanged yet yielded no relevant changes to DKIM itself, and the working group produced RFC 6377 to document the problem in more detail rather than take another run at trying to solve it.

What's changed since then appears to be that some operators now believe the collateral damage is acceptable.

Finish the sentence... ;)

"... in relation to the benefits while the ecosystem adapts"
------=_Part_118878_233512723.1398376308134-- From nobody Thu Apr 24 15:17: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 A4F1F1A0402 for ; Thu, 24 Apr 2014 15:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy7QuTpStIjv for ; Thu, 24 Apr 2014 15:17:19 -0700 (PDT) Received: from pop3.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9871A03F8 for ; Thu, 24 Apr 2014 15:17:19 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2986; t=1398377824; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=TjFg8MjL8DzZ/vwFp9cDrubQol8=; b=A9eOnxh1doLtDnx56PPe LhF1Pys6KnA3Szl4BqKd9zzYF71Toa/VboJHi/BqNJw95BLleXLZypykG8k7pJiI giYHJjEg48YjQagGRj1Qxx/3WtIB/rw8fREzw/+ruyBgj2WceFYHlRZlfLTByvHp H8sUj5jYAzfdcsp+vqQRse4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 24 Apr 2014 18:17:04 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1486391207.666.3748; Thu, 24 Apr 2014 18:17:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2986; t=1398377738; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=g6i75s8 3wHmKQcND4xlxhgyU9ztlNaSZwXB0R7Zc/FA=; b=c38OxLBUXq+3Na3nk7ikUh/ 5Z23fzfmxeKSz3si3QdE+tCaUY7x5SmTHOCgRGcjWVu/ZPuJ9da9kYPa6Ze+XLlB nxCDTxgBszf/zr8mJwYu8asf2d7uFUmFxNL/jd5MgDF09SOvhbB3gZUJ2le8/pa+ LsDM2c2Anpx7P4vd115k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 24 Apr 2014 18:15:38 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1505914171.9.1984; Thu, 24 Apr 2014 18:15:37 -0400 Message-ID: <53598D5E.8050308@isdg.net> Date: Thu, 24 Apr 2014 18:17:02 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <53594D62.4070609@isdg.net> <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/82XhLp9kOXIjIcv_ybXPi5vDJaA Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 22:17:22 -0000 n 4/24/2014 2:27 PM, Terry Zink wrote: >> ADSP was brushed off because the same folks who believed ADSP's strong >> reject/discard policy concept will ever get used, also believed DMARC's strong >> p=reject will never be used as well, and certainly not by the likes of a AOL.COM >> and YAHOO.COM, two aged and polluted domains like millions of others who >> would major interesting in improving the security quality and brand of their domains. > > Correct me if I am wrong, but I think that there are significant differences between now and when ADSP was being investigated: > > 1. DKIM has much more prevalence in 2014 than it did in 2006, so requiring it today isn't as big an obstacle. I don't see this as any real point to be wrong or right, but DKIM was the direction then as well. > 2. DKIM doesn't tie the d= signature field to the 5322.From: address. This would be crux of the key philosophical debates and reason we have the problem you today. First, 5322.From is the only hash binding header requirement for DKIM, so it is inherently technically impossible to untie or "separate" the two domains. Second, what comes first the author (original message) or the signer? I hope you say author. :) Third, the tie-in was built into Domainkeys which DKIM was derived from with its own built-in expanded set of 1st and 3rd policies. ADSP tried to reduced it to 1st party only. But since the beginning, the original proof of DKIM concept was the AUTHOR DOMAIN POLICY layer, the selling and marketing point. That is why POLICY was also part of the DKIM-WG product work items, among its threat analysis and signing practice requirements, and also DKIM architecture. The philosophy that the two domain are separate is exactly why we have the problem today. >So, you can DKIM-sign all you want and add authorized third party signatures >all you want. No you can't just blinding resign mail. Its was always a bad idea to do so from a security and mail integration design standpoint. You can't separate two. Again, its why you have the DMARC problem today with list systems. > But if the From: address is different than what was authenticated, then the end >user won't understand the difference. The goal of POLICY was to filter the obvious deterministic highly detectable fraud. No subjective reason is required. Its persistent and consistent. You say you do X, the receiver sees Y, there is something wrong. Your X says to reject. The receiver honors it. If you don't honor it, you are not compliant and are creating security loopholes and exploits. Again, why DMARC was a problem with p=reject. It was no surprise to anyone but those who believe that a strict policy was a small use case -- it was proven wrong. > 3. DMARC is basically an anti-phishing technology, whereas while DKIM + ADSP can do that, it doesn't do it as well. I don't see the difference. This is a general DKIM + POLICY issue. -- HLS From nobody Thu Apr 24 19:58: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 B0DD71A038E for ; Thu, 24 Apr 2014 12:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.062 X-Spam-Level: X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.272, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77mCRZ-l-PcR for ; Thu, 24 Apr 2014 12:35:24 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 508A61A03D6 for ; Thu, 24 Apr 2014 12:35:23 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.12]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3OJZ04H009748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Apr 2014 12:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1398368114; bh=czbJBgGHWedv0E7WDdQegtVKFQK8H29sA4iZl0kjOB0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oP5SLgjGN8uwVglJcskWIFgn8s6Xx+G9Wb3OL02Qd+rgCAO+V2aTlTRjccKUIAR1L zwvDu31xftZjB3uXGl26LRYlUftCJStVUzuEpJRdSomguy+he2IstCnfSyt3DolS8S 7Flu0yWPqtXZrbmVNKfAhtcVM4vIQd8VidZbtWgs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1398368114; i=@elandsys.com; bh=czbJBgGHWedv0E7WDdQegtVKFQK8H29sA4iZl0kjOB0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=AtqoLYxWqPM1j7os7gvVQ0s9Pgf0xoiQ2PHkKQwQS/4624i0fy6xMPIdvV//iZgYE OFH8Wq8/zQQlRL2Fnd4dfuWIu+rKWMojrCp+RrVZw7UR/xZ58P+b/OSvRmMYSX6sqm i96gkzuhBc7gNyV1cUCfZZucNOa3i0sYj6Pvt0N0= Message-Id: <6.2.5.6.2.20140424121400.0d04d408@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 24 Apr 2014 12:33:01 -0700 To: Terry Zink , Hector Santos , Greg Colburn From: S Moonesamy In-Reply-To: <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf .exchangelabs.com> References: <8d8585be98f32a76d2a7144ac9ff0721@xmail.mwn.de> <5358DD7C.40107@isdg.net> <34B2EC58-30F4-4907-99A9-B25704509D0C@returnpath.com> <3913278320014abfa67ad2dd7d6783a8@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <53594D62.4070609@isdg.net> <489f28317a114ddebe8b4ffa8d34a0c9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/aF9QA2Um0V8YfNocHz8AuFzHv5o X-Mailman-Approved-At: Thu, 24 Apr 2014 19:58:47 -0700 Cc: Michael Storz , dmarc@ietf.org Subject: Re: [dmarc-ietf] FYI: AOL Mail updates DMARC policy to 'reject' X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2014 19:35:25 -0000 Hi Terry, At 11:27 24-04-2014, Terry Zink wrote: >1. DKIM has much more prevalence in 2014 than it did in 2006, so >requiring it today isn't as big an obstacle. > >2. DKIM doesn't tie the d= signature field to the 5322.From: >address. So, you can DKIM-sign all you want and add authorized third >party signatures all you want. But if the From: address is different >than what was authenticated, then the end user won't understand the difference. > >3. DMARC is basically an anti-phishing technology, whereas while >DKIM + ADSP can do that, it doesn't do it as well. It's less >intuitive to end users. And because DMARC is better I don't recall the time line as it's been a long time. ADSP tied the 5322.From address to the "d=" tag. ADSP was controversial (re. discussions about lost of mail, etc.). Mail usage is not as prevalent as before. The loss of mail might be considered as acceptable nowadays. There's also the "cybersecurity" [1] angle. Regards, S. Moonesamy 1. http://www.spiegel.de/international/europe/british-spy-agency-gchq-hacked-belgian-telecoms-firm-a-923406.html From nobody Thu Apr 24 23:20: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 5B5CC1A0412 for ; Thu, 24 Apr 2014 23:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.529 X-Spam-Level: X-Spam-Status: No, score=0.529 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, 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 CkZPpZrH8duj for ; Thu, 24 Apr 2014 23:20:09 -0700 (PDT) Received: from nm39.bullet.mail.ne1.yahoo.com (nm39.bullet.mail.ne1.yahoo.com [98.138.229.32]) by ietfa.amsl.com (Postfix) with SMTP id CC4431A035C for ; Thu, 24 Apr 2014 23:20:08 -0700 (PDT) Received: from [127.0.0.1] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 25 Apr 2014 06:20:02 -0000 Received: from [98.138.101.132] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 25 Apr 2014 06:17:02 -0000 Received: from [98.137.12.59] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 25 Apr 2014 06:16:15 -0000 Received: from [98.137.12.219] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2014 06:16:15 -0000 Received: from [127.0.0.1] by omp1027.mail.gq1.yahoo.com with NNFMP; 25 Apr 2014 06:16:15 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 111640.1259.bm@omp1027.mail.gq1.yahoo.com Received: (qmail 66573 invoked by uid 60001); 25 Apr 2014 06:16:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1398406575; bh=YtRjN+1sfZrf3VAtYvWtdIsZAbm55w4MQtrzSTc7joE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rnppO11Zq21vr8JWoh9N12qsRfZ5OJxsjqDb4L+R9WRF+UZMWVxsj2bv791FN/VPi2YElvACqNKwOsK/WiNjZbtIIYdOqX9FIkDgDZum8te6mexvwZGMD4CGFdyXFiyiUVBRO+hF5iyzvUFbRV9JEPXx2vaIrF3opSPWymjo6qM= X-YMail-OSG: UHzAvhAVM1ly0fhabpwPfBVwQDx4B4U4AaHikO26jB_T0Ry Iy2.hKTrOOTWm4A.1VDG9okLO285_5Lir4AdpzCY9cwwSCk4TKFXcNe.Vo2P ZL_pZXN9RvmLeXo4V1fRI99X4yCTvZUFSzQZRn2ic0nK91U_wu2mnoguHIUR ax0LcGmZ4gnMaHGNoGx8Y7GtF90vlZvNQvYADQOCGl7WwMQxgEjVJasfMsyb ziQMyH.5Z0g4_DxcFamwJZKkR6MFQvz9AlA88gu6khyCamsVUkcwVAokpd9Q keCdGR2onir_uZgJ_OxAGPBdGYu8mfJritBJpf4wTH5TBLefk6eH2bpXz3.c IwgJ4RAh83CRvZ5xtuWAdhSydYmIv9105cxvMV.0ipVy_bAakXyL9gj2Mpmx KC69NPRQJR5l5PP2dGhk058uMbKUiOTMSQOckHI83iXGg_3Gv5kVaqErjVQ7 huLi__BpjVqiWTchIvSnptDc6CddQ4IjTrqjbyYdeBuRzUij7nSp3251S.V1 NcfrXBdMBNz7E9NWPrDbUm6JtZUCzHb_gvy7KS93S2cg5kcJQn.1PbPY5qOW jB5xqZHD9wWxPV6q5WIf.rplKVqHBjk4G..dMfWG7AobEpAyKQxAgzt3HFw- - Received: from [79.175.89.237] by web164602.mail.gq1.yahoo.com via HTTP; Thu, 24 Apr 2014 23:16:14 PDT X-Rocket-MIMEInfo: 002.001, T24gVGh1cnNkYXksIEFwcmlsIDI0LCAyMDE0IDg6MjAgUE0sIEhlY3RvciBTYW50b3MgPGhzYW50b3NAaXNkZy5uZXQ.IHdyb3RlOgoKPiBUYWtlIGEgbG9vayBhdCB0aGUgMjAwNiBEU0FQIEktRCBwcm9wb3NlZCBhdXRob3IgZG9tYWluIHBvbGljeQo.IHByb3RvY29sIHdoaWNoIHByb3ZpZGVkIHRhZ3MgdG8gY292ZXJlZCB0aGUgY29tcGxldGUgMXN0IHZzIDNyZCBwYXJ0eQo.IGJvdW5kYXJ5IGNvbmRpdGlvbnMgZm9yIERLSU0gc2lnbmluZyBwcmFjdGljZXM6CgpzZWVtcyByZWFzb25hYmxlLgoKYnV0LCABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.185.657 References: <1398106456.78279.YahooMailNeo@web164602.mail.gq1.yahoo.com> <53558E41.5030704@isdg.net> <1398118135.56070.YahooMailNeo@web164605.mail.gq1.yahoo.com> <5355A739.1000409@isdg.net> <1398151254.8652.YahooMailNeo@web164605.mail.gq1.yahoo.com> <535955EA.8030006@isdg.net> Message-ID: <1398406574.27104.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Thu, 24 Apr 2014 23:16:14 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <535955EA.8030006@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/88vzB3H7cRHC4Dkb1vU-TPpprIo Subject: Re: [dmarc-ietf] DMARC Extension for 3rd party Signers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 06:20:11 -0000 On Thursday, April 24, 2014 8:20 PM, Hector Santos wrote: > Take a look at the 2006 DSAP I-D proposed author domain policy > protocol which provided tags to covered the complete 1st vs 3rd party > boundary conditions for DKIM signing practices: seems reasonable. but, believe me, there's no need to persuade me that we need 3rd party alignment support in DMARC. i don't rly care about how it's done... if it works fine and serves a purpose, great. however, it seems we will have a terrible time persuading some people here. they seems content with breaking email for the sake of "providing security". i always wanted to use this somewhere. seems like a perfect time and place: They who would give up an essential liberty for a temporary security deserve neither liberty nor security. ps. i do love how these big ESPs think that today's 90% of their email stream passing DMARC, comprising of mostly fb notifications ppl don't really care about or read, is enough of a reason to break rest of email stream, ppl actually care about, read and expect delivered without an issue. pps. i also love egotrips. it's almost unbelievable how big some egos here are... but, nothing new there. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Wed Apr 30 10:08: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 452E51A08FA for ; Wed, 30 Apr 2014 10:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E6i1sXiBjeb for ; Wed, 30 Apr 2014 10:08:02 -0700 (PDT) Received: from dkim.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 71F5E1A0798 for ; Wed, 30 Apr 2014 10:08:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5090; t=1398877676; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=rOsTPShI/JJLVIR0gI+qNu4NTH8=; b=MSDV8POVBO8pAGeNNvuQ ur7NeKltYi5hr+1qDKaj5cCueBzAgrTc91hoSh/7gVU3gqX3rqHL9XbVDF4EKOnm 9LPBmS7u3XG24F+9O+kCYXvjE6CNl7uwdaYWP2XV3iKp1x0niT4ba274Lv38gGsA OEOaLdKaeke/yplmeR4S8AE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 30 Apr 2014 13:07:56 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1986237957.3.2276; Wed, 30 Apr 2014 13:07:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5090; t=1398877585; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Roma0s7 UjCzRVZEJyTWEFNdRgFs74RHrx+M+C41feDk=; b=zooqqKiZZGFudTk+2OvU/Al Wo7MQzEQ2CyEEi2LOlhlxoolIIopRfqyuHUgb3hCCUf96WQVmz1v+FjynLAVyo8X jBew/EqyN8Ls6lh0K3ToIV+7NxT+kvkzvEMrTKwM/mmFPsh8g+oq0IoeD9m6wpe2 ox8h9LO9GwkNPSmFf3L0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 30 Apr 2014 13:06:24 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2005760703.9.12168; Wed, 30 Apr 2014 13:06:23 -0400 Message-ID: <53612DED.6060805@isdg.net> Date: Wed, 30 Apr 2014 13:07:57 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Vlatko Salaj , "dmarc@ietf.org" References: <1398106456.78279.YahooMailNeo@web164602.mail.gq1.yahoo.com> <53558E41.5030704@isdg.net> <1398118135.56070.YahooMailNeo@web164605.mail.gq1.yahoo.com> <5355A739.1000409@isdg.net> <1398151254.8652.YahooMailNeo@web164605.mail.gq1.yahoo.com> <535955EA.8030006@isdg.net> <1398406574.27104.YahooMailNeo@web164602.mail.gq1.yahoo.com> In-Reply-To: <1398406574.27104.YahooMailNeo@web164602.mail.gq1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UZcFbFBAxyP5s6chyXZ2XctcLJ0 Subject: Re: [dmarc-ietf] DMARC Extension for 3rd party Signers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 Apr 2014 17:08:05 -0000 On 4/25/2014 2:16 AM, Vlatko Salaj wrote: > On Thursday, April 24, 2014 8:20 PM, Hector Santos wrote: > >> Take a look at the 2006 DSAP I-D proposed author domain policy >> protocol which provided tags to covered the complete 1st vs 3rd party >> boundary conditions for DKIM signing practices: > > seems reasonable. > > but, believe me, there's no need to persuade me that we need 3rd party > alignment support in DMARC. i don't rly care about how it's done... > if it works fine and serves a purpose, great. Same here. > however, it seems we will have a terrible time persuading some > people here. they seems content with breaking email for the sake of > "providing security". Its a different view to consider it that way. Others will suggest, as myself, that is a by-design feature. But the problem is that we failed to provide the flexible options to be backward compatible in some way. Yahoo could of easily solved this b: 1) First use p=quarantine 2) Then use a user UI option to "confirm" with the user if the signer is ok, thus "learn" from its user base what should be "whitelisted." Its not like they lack the Mail Business data Intelligence (MBI). They always had the info from previous imported list messages that the domain and list-id was acceptable by the user and not marked as spam. In fact, we have this feature in our ANTI-SPAM system: If the user writes to a person, that person now becomes auto-whitelisted. Trust me, this was a MAJOR SUPPORT g-dsend! Resolved all sorts of first time blocking issues with customer support over a phone call, "hey, let me send you a permission list. Use this address to reply back." But from a purity standpoint, the policy needs to be honored first, otherwise, all we have done is create even more loopholes to be exploited. > ps. i do love how these big ESPs think that today's 90% of their email > stream passing DMARC, comprising of mostly fb notifications ppl don't really > care about or read, is enough of a reason to break rest of email stream, > ppl actually care about, read and expect delivered without an issue. Its all hype. They don't represent or have a clue for the MBI going on with all the million of email domain private mail operations combined -- WORLD WIDE. Its all marketing bull. But what is a fact is that if you are an aged domain, most likely, it is very spam polluted. So I agree with their strategy to finally begin to clean it the domain and enhance its security value. No doubt, in my mind, this is a major plus for all aged, spam polluted domains, including our own. The highest benefit in the SPF or DKIM author domain protocols comes form SELF-REGULATING your own domains, in other words, when main comes into your own SMTP system purporting to be coming from your own network of domains, you have the #1 highest spoof protection possible. After first protecting your own domains (which is what Yahoo is doing), you can decide if you also want to protect other REMOTE DOMAINS coming into your systems. Do you do it as a favor? Or do you do it to protect your system and/or your users? It was the latter consideration that became a major overhead and redundancy in attempting to check all domains coming in. It was considered to be a short term concern. Over the long term, the hope was the efficacy/efficiency/payoff would be improved as more and more domains published policies. I have to check where we are with this, i.e. how much of your incoming clients transaction have SPF and/or DKIM records, but no doubt, it has become significant. See your 11 years of ANTI-SPAM rejection history and statistics that shows how SPF was a near 0% and now is about mere 1.8% (as of april, 2014). But I remember it took quite a few years to get event that high: http://www.winserver.com/SpamStats I stopped at DMARC because I got sick of the IETF baloney with ADSP, but I explored all the ideas: Even if 100% of the domain published policies, it was always my concern that it would be a major waste if most policies were relaxed, i.e. policy does not say to reject/discard. So in my opinion, any SPF policy with a relaxed neutral was a BIG WASTE OF LOOKUP and processing time. Same with DKIM relaxed signing practices. So how do you handle this huge waste? Again, you have to accept the hard failures with the soft and relaxed failures, and with the hard, you honor it otherwise you just made it worst as a relaxed result. This was where the heuristic designs can play a role where it uses a combine set of non-deterministic, in between false and true, "fuzzy" logics or even combine it with user input to get some payoff from it. But to constantly process a RELAXED SPF, ADSP or even now DMARC policy is a huge waste and major overhead. That said, I think we did accept these higher overhead modes of operations. I guess people like what DMARC offers with REPORTING, but eventually even reporting becomes a redundant and wasteful operation. -- HLS