From kurt@roeckx.be Tue Feb 4 16:59: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 3BD6B1A01B2 for ; Tue, 4 Feb 2014 16:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_HELO_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 WIkQwZxVBw50 for ; Tue, 4 Feb 2014 16:59:30 -0800 (PST) Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) by ietfa.amsl.com (Postfix) with ESMTP id E825E1A01BD for ; Tue, 4 Feb 2014 16:59:29 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id B53621C2241; Wed, 5 Feb 2014 01:59:28 +0100 (CET) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 94F981FE025C; Wed, 5 Feb 2014 01:59:28 +0100 (CET) Date: Wed, 5 Feb 2014 01:59:28 +0100 From: Kurt Roeckx To: Roland Turner Message-ID: <20140205005928.GA15734@roeckx.be> References: <20140130220330.GA25608@roeckx.be> <52EB0CBF.9020607@rolandturner.com> <20140201013342.GA24125@roeckx.be> <52EC725B.1050809@rolandturner.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52EC725B.1050809@rolandturner.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 00:59:32 -0000 On Sat, Feb 01, 2014 at 12:04:43PM +0800, Roland Turner wrote: > "Non-participating" MLMs (RFC 6377) are outside DMARC's scope. This draft does not update the RFC 6377 requirements for mailinglists, but I do think it changes the requirements. But it also seems to contain the posibility to override this somehow, but it's all outside the scope of DMARC. > >it might see that SPF has a pass, but it's going to say that it > >doesn't allign with the header from. What is unclear to me is what > >the result of that should be. Is it just going to ignore this SPF > >result? > > DMARC is going to ignore it, yes. > > >Will it result in an SPF fail even though it was really a pass? > > No, DMARC does not alter SPF. If SPF passes, it does so with or > without DMARC being present. What DMARC does do is decide when to > make use of an SPF pass; in particular it only does so when the SPF > domain and 5322.From domain are aligned. Note that a DMARC > implementation therefore has to deal with two separate > interpretations of an SPF result: > > * The domain name and result from the authentication mechanism itself; > this is the auth_results section of an aggregate report. > * The relevance of the underlying results to a DMARC policy > evaluation; this is the policy_evaluated section of an aggregate > report. Any time the SPF domain is unaligned a fail will appear > here, even if SPF passed (and therefore shows a pass in the > auth_results section). >From what I understand, I have received very few aggregate report that gets all the results correct. There always seems to be something wrong with it. And I think the draft isn't helping in making things clear because it just documents the format. As I understand it, in the case of the mails you send to this list, you should receive the following: ietf.org ietf1 pass rolandturner.com 20120325 fail ietf.org mfrom pass I'm just going to guess that the results you get back contain all kinds of wrong information, but I hope you at least get some that are more or less correct. I think that because none of those that pass are alligned it should then result in: none fail fail Possibly it could have an reason there added. What is unclear to me is what happens when either dkim of spf would pass and the policy_published contains p=reject. Should it be: reject pass fail Or: none pass fail Please note that the draft seems to indicate that it should contain the value from p or sp, but that if you override it it can contain some other value. So I can read that even if you accept it because dkim says pass that the disposition should be reject. And I have to guess that's not really the intension. > Note further that DMARC is also selective about its use of DKIM, > except that the DKIM d= must match from 5322.From domain exactly > (merely being aligned isn't enough). The same two interpretations > must therefore be understood and they appear in the same two places > in the aggregate report as above. I'm not sure I understand what you're saying here. As I understand it, there is a strict and relaxed way for that? > >So in the end DMARC will say your mail is not authentic, > > Not exactly: DMARC doesn't make determinations about authenticity, DMARC seems to talk a lot about authentication, including in it's name, so I fail to understand that. Kurt From superuser@gmail.com Wed Feb 5 09:54: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 2A3BA1A010D for ; Wed, 5 Feb 2014 09:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHSINY2J7e-u for ; Wed, 5 Feb 2014 09:54:10 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DD7E91A001A for ; Wed, 5 Feb 2014 09:54:09 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id cc10so839451wib.16 for ; Wed, 05 Feb 2014 09:54:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lhJQFklaAe1H0vP5LK8/yg2kFQvPr4A+jjrTU2L7BU4=; b=Q++9OSrB/y6dSFbPl5vb+PJ3hOyRikWq4fjDwxtEsrR4pKSFbjX94DBq4HwvaAwxlv mEcSpGvUGjlCY/rioqn3tjfO3/9UPR4ykwkwYHgKuyriULDuVnro4XrCCi16FlN2a0ZP 99i9qUMyjksIo7qa2fhOSHFnmsgHu2AX1SGgqH8h/T+15jcYL3u7tkS5zCCycJPy/U+a GGtH4vdjmQjYKA3oOhCpW9yZ6Bu+JZwCzi2701nEaDX6qhvsi8f0ZCql2gaD1/dLenDV oc2b3fLATgPEjf+FNCVizRNEc92uNsNoa+RioJfO/MldSf6Kn+E9dN6JuSPRt+TDTOa4 Riqg== MIME-Version: 1.0 X-Received: by 10.180.163.206 with SMTP id yk14mr17844749wib.5.1391622848701; Wed, 05 Feb 2014 09:54:08 -0800 (PST) Received: by 10.180.90.132 with HTTP; Wed, 5 Feb 2014 09:54:08 -0800 (PST) In-Reply-To: <20140205005928.GA15734@roeckx.be> References: <20140130220330.GA25608@roeckx.be> <52EB0CBF.9020607@rolandturner.com> <20140201013342.GA24125@roeckx.be> <52EC725B.1050809@rolandturner.com> <20140205005928.GA15734@roeckx.be> Date: Wed, 5 Feb 2014 09:54:08 -0800 Message-ID: From: "Murray S. Kucherawy" To: Kurt Roeckx Content-Type: multipart/alternative; boundary=00248c0d79388ef58404f1ac71e3 Cc: "dmarc@ietf.org" , Roland Turner Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 17:54:11 -0000 --00248c0d79388ef58404f1ac71e3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 4, 2014 at 4:59 PM, Kurt Roeckx wrote: > > Not exactly: DMARC doesn't make determinations about authenticity, > > DMARC seems to talk a lot about authentication, including in it's > name, so I fail to understand that. > Neither DKIM nor SPF, upon which DMARC is built, purport to claim authenticity over the content of the message as a whole, so DMARC isn't claiming that either. Rather, it is claiming authenticated use of the domain you see in the From: field of the message; it goes no further. -MSK --00248c0d79388ef58404f1ac71e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --00248c0d79388ef58404f1ac71e3-- From tzink@exchange.microsoft.com Wed Feb 5 15:43: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 6B7EC1A0224 for ; Wed, 5 Feb 2014 15:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Pvy1DWArVsj for ; Wed, 5 Feb 2014 15:43:26 -0800 (PST) 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 C6EF51A016B for ; Wed, 5 Feb 2014 15:43:26 -0800 (PST) Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) by BY2SR01MB607.namsdf01.sdf.exchangelabs.com (10.255.93.166) with Microsoft SMTP Server (TLS) id 15.0.883.2; Wed, 5 Feb 2014 23:43:24 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.11.28]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.11.152]) with mapi id 15.00.0883.000; Wed, 5 Feb 2014 23:43:24 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Known DMARC failures of legitimate email Thread-Index: Ac8iyrQjMv34xSJmTx2j60L7isXqbw== Date: Wed, 5 Feb 2014 23:43:23 +0000 Message-ID: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.48] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(199002)(189002)(85852003)(83072002)(54316002)(77982001)(59766001)(15975445006)(56776001)(47976001)(65816001)(85306002)(81686001)(66066001)(80022001)(93516002)(53806001)(81542001)(76482001)(54356001)(81816001)(94946001)(93136001)(4396001)(74876001)(90146001)(63696002)(80976001)(83322001)(47736001)(50986001)(49866001)(19580395003)(74366001)(87266001)(51856001)(2656002)(94316002)(46102001)(87936001)(554214002)(76796001)(76786001)(47446002)(74662001)(74502001)(77096001)(81342001)(31966008)(33646001)(56816005)(15202345003)(76176001)(79102001)(74706001)(92566001)(69226001)(95416001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2SR01MB607; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; CLIP:131.107.174.48; FPR:FACBF2D8.A433978B.39E5B2BB.86A6EC21.2029D; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Subject: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:43:29 -0000 Hello, We're currently building DMARC support and before we go live, I am looking = for some numbers around known cases of DMARC quarantining/rejecting legitim= ate email. Here are cases I can think of: 1. Case 1 - sender publishes DMARC and only authenticates with SPF, user au= to-forwards their email Example: bulk sender -> Hotmail -> Gmail This would pass DMARC at Hotmail (since bulk sender publishes SPF) but fail= at Gmail (since Gmail will see Hotmail's IP but bulk sender in the 5321.Ma= ilFrom) According to Google in a blog post - http://googleonlinesecurity.blogspot.c= om/2013/12/internet-wide-efforts-to-fight-email.html, around 75% of message= s authenticate with DKIM and SPF. 15% authenticate with SPF only, 2% with D= KIM only and about 9% no authentication. The only ones that would be a problem in Case 1 is SPF-only, and only those= that publish DMARC records with p=3Dquarantine/none. Does anyone know how = much email this might be? 2. Case 2 - discussion/mailing lists. This is a known limitation of DMARC a= nd there are workarounds, but if no one does anything, the day after we tur= n on DMARC how much email would this affect? Does anyone have numbers on how much this would affect? 3. Case 3 - anything else? Possibly broken DKIM signatures? Based upon thre= ads, DKIM seems to pass anywhere between 10% and 90% of the time. Seems to = be that the higher number is more realistic since if your DKIM is breaking,= you'd want to know about it. This would be especially true for those who p= ublish DMARC. Thanks. -- Terry From jtrentadams@gmail.com Wed Feb 5 16:38: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 392011A01CC for ; Wed, 5 Feb 2014 16:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-9y9fXl8eC9 for ; Wed, 5 Feb 2014 16:38:42 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 496881A01BC for ; Wed, 5 Feb 2014 16:38:42 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id as1so224679iec.30 for ; Wed, 05 Feb 2014 16:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=WWcG9ftsvZ26q7ei3Ey3hnVHUmhQZkf3wHw7fp2K9M8=; b=DfTQbg40ZaSvHPFMAwkVrqzr2rSQOqHRL9DoyS3rirspQVZKnwJtRulVhHp2vdo6uP lo0FG0V5zeSuRcgPLB8nVxy9NEmgZP54eS8tt90f3xGCAEGA3nqK4YlcLbqBcabeHa5g W7ERJwrITYzby110qrHDQ6DCG/ynKiLJAGdj5H9h8ovpTtYJyrBcY/UoNkiBNzh9j94/ 30W1TvF2+iYmux5JhqtNyYcVZpfT33g7NqJJwNncf9TJIwnf9My+/7IDBsaOSmhYo7So g+HMQwccgBjZ4VWIdtlcKGORgIbezcmYC1JUT6GAYjNKS7mpiQZtQB3FR4cGbSmKOoop 0UyQ== X-Received: by 10.50.67.72 with SMTP id l8mr30514000igt.0.1391647121276; Wed, 05 Feb 2014 16:38:41 -0800 (PST) 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 x13sm53762125igp.2.2014.02.05.16.38.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 16:38:40 -0800 (PST) Message-ID: <52F2D990.6080604@gmail.com> Date: Wed, 05 Feb 2014 17:38:40 -0700 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> In-Reply-To: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:38:44 -0000 Terry - On 2/5/14 4:43 PM, Terry Zink wrote: > Hello, > > We're currently building DMARC support and before we go live, I am looking for some numbers around known cases of DMARC quarantining/rejecting legitimate email. Here are cases I can think of: > > 1. Case 1 - sender publishes DMARC and only authenticates with SPF, user auto-forwards their email > > Example: bulk sender -> Hotmail -> Gmail > This would pass DMARC at Hotmail (since bulk sender publishes SPF) but fail at Gmail (since Gmail will see Hotmail's IP but bulk sender in the 5321.MailFrom) > > According to Google in a blog post - http://googleonlinesecurity.blogspot.com/2013/12/internet-wide-efforts-to-fight-email.html, around 75% of messages authenticate with DKIM and SPF. 15% authenticate with SPF only, 2% with DKIM only and about 9% no authentication. > > The only ones that would be a problem in Case 1 is SPF-only, and only those that publish DMARC records with p=quarantine/none. Does anyone know how much email this might be? > > > 2. Case 2 - discussion/mailing lists. This is a known limitation of DMARC and there are workarounds, but if no one does anything, the day after we turn on DMARC how much email would this affect? > > Does anyone have numbers on how much this would affect? I think that this depends on the type of mail being sent. Our data indicates this is an issue affecting less than 2% of our customers (and it's likely much less than that). The mail we send, however, is largely transactional (i.e., mail sent from our system directly to customers such as receipts and account updates), so YMMV. - Trent > > 3. Case 3 - anything else? Possibly broken DKIM signatures? Based upon threads, DKIM seems to pass anywhere between 10% and 90% of the time. Seems to be that the higher number is more realistic since if your DKIM is breaking, you'd want to know about it. This would be especially true for those who publish DMARC. > > > Thanks. > > -- Terry > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From franck@peachymango.org Wed Feb 5 18:45: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 739451A0277 for ; Wed, 5 Feb 2014 18:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 kZGGczKKc9Hn for ; Wed, 5 Feb 2014 18:45:21 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6BF1A0214 for ; Wed, 5 Feb 2014 18:45:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A9B74398508; Wed, 5 Feb 2014 20:45:20 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcMy89d-Zzk2; Wed, 5 Feb 2014 20:45:20 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 87D5B398550; Wed, 5 Feb 2014 20:45:20 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 72074398530; Wed, 5 Feb 2014 20:45:20 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6Rgs7BXIF1Ti; Wed, 5 Feb 2014 20:45:20 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 571B1398508; Wed, 5 Feb 2014 20:45:20 -0600 (CST) Date: Wed, 5 Feb 2014 20:45:19 -0600 (CST) From: Franck Martin To: Terry Zink Message-ID: <1479727675.113174.1391654719611.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.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 - FF26 (Mac)/8.0.5_GA_5839) Thread-Topic: [dmarc-ietf] Known DMARC failures of legitimate email Thread-Index: Ac8iyrQjMv34xSJmTx2j60L7isXqb1YfA98s Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 02:45:23 -0000 ----- Original Message ----- > From: "Terry Zink" > To: dmarc@ietf.org > Sent: Wednesday, February 5, 2014 3:43:23 PM > Subject: [dmarc-ietf] Known DMARC failures of legitimate email > > Hello, > > We're currently building DMARC support and before we go live, I am looking > for some numbers around known cases of DMARC quarantining/rejecting > legitimate email. Here are cases I can think of: > > 1. Case 1 - sender publishes DMARC and only authenticates with SPF, user > auto-forwards their email > > Example: bulk sender -> Hotmail -> Gmail > This would pass DMARC at Hotmail (since bulk sender publishes SPF) but fail > at Gmail (since Gmail will see Hotmail's IP but bulk sender in the > 5321.MailFrom) hotmail does not break DKIM when forwarding AFAIK. So if a sender do DMARC with p!=none with no DKIM, they shoot themselves in the foot, and they will know quickly that it hurts. > > According to Google in a blog post - > http://googleonlinesecurity.blogspot.com/2013/12/internet-wide-efforts-to-fight-email.html, > around 75% of messages authenticate with DKIM and SPF. 15% authenticate with > SPF only, 2% with DKIM only and about 9% no authentication. > > The only ones that would be a problem in Case 1 is SPF-only, and only those > that publish DMARC records with p=quarantine/none. Does anyone know how much > email this might be? > Once again, with DMARC if you shoot yourself in the foot, you will know it hurts. > > 2. Case 2 - discussion/mailing lists. This is a known limitation of DMARC and > there are workarounds, but if no one does anything, the day after we turn on > DMARC how much email would this affect? > > Does anyone have numbers on how much this would affect? mailing list traffic is low in all legitimate mail (<10% I have heard), and some mailing lists keep DKIM. > > > 3. Case 3 - anything else? Possibly broken DKIM signatures? Based upon > threads, DKIM seems to pass anywhere between 10% and 90% of the time. Seems > to be that the higher number is more realistic since if your DKIM is > breaking, you'd want to know about it. This would be especially true for > those who publish DMARC. > In all these cases, the problem is not on the receiver side, but on the sender side. When a sender moves to p!=none it does it perfectly knowing what will be the impact based on the aggregate reports, while making sure everything is DKIM signed with SPF also on hostnames. As a sender, I would confirm the numbers Trent gave which is about 2 to 1% email loss (even lower). Which is nothing in comparison of all the spoofing mitigated and I'm not even talking about controlling mail streams and third party vendor on boarding. As a mailbox provider, you don't want to publish anything than p=none for your domain. As a receiver, you save a lot by checking DMARC on incoming emails and let the sender put the right policies. From prvs=71140a3e0a=madkins@fb.com Thu Feb 6 11:19: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 396EB1A03E4 for ; Thu, 6 Feb 2014 11:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 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_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 YVoNHssME6FX for ; Thu, 6 Feb 2014 11:19:50 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2B51A0428 for ; Thu, 6 Feb 2014 11:19:50 -0800 (PST) Received: from pps.filterd (m0044008 [127.0.0.1]) by mx0a-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id s16JAscN014508; Thu, 6 Feb 2014 11:19:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=TJhhZObPY5LVlJp2ifeyLDDAMo6BeHCGqZG8SRzYd2s=; b=StDBvY2AjDO4nPJbxT8+V0xXwPOj+X7HykrbxYe7jOUaPw1ClFvdVGkzahkQKHFcnaJp sPLp20qbd8QJQ27Hwk4mMjAtNPGZLj/aO+sdXekEDP4QkSzMxEsve4FQpyFW+prP1dKN 5tQkQTTTbKJmFtC2uBy6H9k9mGVaf3eouqw= Received: from mail.thefacebook.com (mailwest.thefacebook.com [173.252.71.148]) by mx0a-00082601.pphosted.com with ESMTP id 1hvd6x0q4v-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 06 Feb 2014 11:19:47 -0800 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.5.152]) by PRN-CHUB05.TheFacebook.com ([fe80::9886:b2c2:db18:5ba7%12]) with mapi id 14.03.0174.001; Thu, 6 Feb 2014 11:19:46 -0800 From: Michael Adkins To: Terry Zink , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Known DMARC failures of legitimate email Thread-Index: Ac8iyrQjMv34xSJmTx2j60L7isXqbwApa7IA Date: Thu, 6 Feb 2014 19:19:45 +0000 Message-ID: In-Reply-To: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [192.168.16.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <6241CE358A7C8D40B9B3588CE2F32D03@fb.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-02-06_06:2014-02-06,2014-02-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=309.927959009832 compositescore=0.0999747829979373 urlsuspect_oldscore=0.999747829979373 suspectscore=0 recipient_domain_to_sender_totalscore=651 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=32 recipient_domain_to_sender_domain_totalscore=111011 rbsscore=0.0999747829979373 spamscore=0 recipient_to_sender_domain_totalscore=37 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1402060112 X-FB-Internal: deliver Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 19:19:53 -0000 On 2/5/14 3:43 PM, "Terry Zink" wrote: >Hello, > >We're currently building DMARC support and before we go live, I am >looking for some numbers around known cases of DMARC >quarantining/rejecting legitimate email. Here are cases I can think of: > >1. Case 1 - sender publishes DMARC and only authenticates with SPF, user >auto-forwards their email > >Example: bulk sender -> Hotmail -> Gmail >This would pass DMARC at Hotmail (since bulk sender publishes SPF) but >fail at Gmail (since Gmail will see Hotmail's IP but bulk sender in the >5321.MailFrom) > >According to Google in a blog post - >https://urldefense.proofpoint.com/v1/url?u=3Dhttp://googleonlinesecurity.b= lo >gspot.com/2013/12/internet-wide-efforts-to-fight-email.html&k=3DZVNjlDMF0F= El >m4dQtryO4A%3D%3D%0A&r=3DfAk2HhpwqneloqGEFXhAtQ%3D%3D%0A&m=3DpRSJ4QiEBWv2%2= BArW >%2FhQZZWTcTmL7J2ianTBs7FiroIw%3D%0A&s=3D8cdd07fe693bdd2263ba26b7e1c918fdba= 1c >ed24fb57fcb7718ce61758fe3f14, around 75% of messages authenticate with >DKIM and SPF. 15% authenticate with SPF only, 2% with DKIM only and about >9% no authentication. > >The only ones that would be a problem in Case 1 is SPF-only, and only >those that publish DMARC records with p=3Dquarantine/none. Does anyone kno= w >how much email this might be? I suspect that this is going to vary a lot from one system to the next, so I don't know that anyone else can give you great advice on it. What I can tell you is that a large scale DMARC system needs a mechanism to automatically detect legitimate forwarding and exempt them from reject and quarantine actions. DMARC has the notion of 'trusted forwarders' defined in the spec and accounted for in the reporting. There are a few different ways to do that, some that border on secret sauce, and are mostly a combination of a reputation or trust system combined with something observable in the header or the traffic patterns. For example, you can look for authentication results headers that were added by the upstream system and choose to use their results if you trust them (aka transitive trust). You can look for other headers that are typically added to forwarded email (X-Original-To, etc) and decide to use them as a signal if you trust the upstream system. If you sign your outbound email, and you have enough volume, you will see some amount of your own signed email forwarded back to your system with the signatures still intact. That's a good signal that the upstream system legitimately forwards stuff. > > >2. Case 2 - discussion/mailing lists. This is a known limitation of DMARC >and there are workarounds, but if no one does anything, the day after we >turn on DMARC how much email would this affect? > >Does anyone have numbers on how much this would affect? Again, this is going to vary from system to system. I would recommend that you have a 'log only' mode for your DMARC implementation so you can roll it out and have it report what action it would have taken to you without actually impacting delivery. This is the other case where you need an automated mechanism to detect legitimate lists based on their behavior and exempt them. From experience, I can tell you that if you exempt email signed by google groups, yahoo groups and it's international flavors, and microsoft live groups, then you will have solved the problem for 90% of users. > > >3. Case 3 - anything else? Possibly broken DKIM signatures? Based upon >threads, DKIM seems to pass anywhere between 10% and 90% of the time. >Seems to be that the higher number is more realistic since if your DKIM >is breaking, you'd want to know about it. This would be especially true >for those who publish DMARC. Those are the two big ones. I haven't really run into other problems. > > >Thanks. > >-- Terry > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://urldefense.proofpoint.com/v1/url?u=3Dhttps://www.ietf.org/mailman/= li >stinfo/dmarc&k=3DZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=3DfAk2HhpwqneloqGEFXhAt= Q%3D >%3D%0A&m=3DpRSJ4QiEBWv2%2BArW%2FhQZZWTcTmL7J2ianTBs7FiroIw%3D%0A&s=3D7f67d= 6d41 >adc94b6e45861fa6dbdf4beae357311b2f59043d361ce6e47ca59fb From roland@rolandturner.com Thu Feb 6 21:30: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 5439A1A036F for ; Thu, 6 Feb 2014 21:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 t9H0MEGfBHIs for ; Thu, 6 Feb 2014 21:30:56 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6834C1A0375 for ; Thu, 6 Feb 2014 21:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=wWFuq/4e8niVN93WHZq63PIbnzNQ1tF84//uCW4O7Mc=; b=vpOMUVgwfZtyG4eOTkPnX9q0oabLJVRkoNUz56T3IOwbvyS1TmWkYhBEonhdfPwfhrRsKLsFDVckQicorRLEzzcbiQCL6Ad39waq/oet2s7THwjSNf2p4RmUCN8sF02CRhMq6amuUmuyzuV1vbkhtqGQ5OX5ovGGDOhu/33YMKY=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=58583 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WBe1d-00075i-2J for dmarc@ietf.org; Fri, 07 Feb 2014 05:30:54 +0000 Message-ID: <52F46F8C.1030602@rolandturner.com> Date: Fri, 07 Feb 2014 13:30:52 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> In-Reply-To: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> Content-Type: multipart/alternative; boundary="------------000105050607030006010301" Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 05:30:58 -0000 This is a multi-part message in MIME format. --------------000105050607030006010301 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/06/2014 07:43 AM, Terry Zink wrote: > Hello, > > We're currently building DMARC support and before we go live, I am looking for some numbers around known cases of DMARC quarantining/rejecting legitimate email. Here are cases I can think of: No-one is in a better position than you are to survey the DMARC breakage that affects you, and to get real numbers about the impact of each cause. It would be sensible to implement DMARC initially with no action taken on the results (apart from logging). You then have source data to mine to: * Identify DKIM-breaking forwarders that you already know have sound filtering, so DMARC processing can be skipped for them * Identify heavily spoofed domains that should be in the first batch to have Domain Owner policy execution turned on * Identify ...overly enthusiastic Domain Owners who are publishing quarantine/reject policies despite not having their message streams under control; their policies should of course not be executed while that is the case. Presumably you'll want to do this on an ongoing basis. Initially it would make sense to turn on policy execution only for those domains which are heavily phished, over time you're likely to be able to lower the threshold to the point where you're executing all Domain Owner policies apart from those observed to be broken. (See also Dave's Using DMARC draft) - Roland --------------000105050607030006010301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 02/06/2014 07:43 AM, Terry Zink wrote:

Hello,

We're currently building DMARC support and before we go live, I am looking for some numbers around known cases of DMARC quarantining/rejecting legitimate email. Here are cases I can think of:

No-one is in a better position than you are to survey the DMARC breakage that affects you, and to get real numbers about the impact of each cause. It would be sensible to implement DMARC initially with no action taken on the results (apart from logging). You then have source data to mine to:
  • Identify DKIM-breaking forwarders that you already know have sound filtering, so DMARC processing can be skipped for them
  • Identify heavily spoofed domains that should be in the first batch to have Domain Owner policy execution turned on
  • Identify ...overly enthusiastic Domain Owners who are publishing quarantine/reject policies despite not having their message streams under control; their policies should of course not be executed while that is the case.

Presumably you'll want to do this on an ongoing basis. Initially it would make sense to turn on policy execution only for those domains which are heavily phished, over time you're likely to be able to lower the threshold to the point where you're executing all Domain Owner policies apart from those observed to be broken.

(See also Dave's Using DMARC draft)

- Roland
--------------000105050607030006010301-- From roland@rolandturner.com Thu Feb 6 21:34: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 2EDB81A0375 for ; Thu, 6 Feb 2014 21:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 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.535, 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 6GsBPXCdc2K9 for ; Thu, 6 Feb 2014 21:34:45 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 00D181A036F for ; Thu, 6 Feb 2014 21:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=nIQSAfFhWaKkXtjVD+1jptGWG3ACgmLWegRSWWo+3pk=; b=CIyjv+YVgWQYym3bkE9kbeDG8SdnL3iM0ODZis1jQkN3pTgRwz2vd4x21P2Vx7AS/apsLZUd7Nrtwn2Fggu0gxSmKna9GDjtjYuhzdMbSQFXDXtVx3DKA7pDQcYv67I80f+ZddCTQwz0H1i0hL1vGRmprnsu1gxz7Srao/JBqTU=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=58601 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WBe5L-000768-89 for dmarc@ietf.org; Fri, 07 Feb 2014 05:34:43 +0000 Message-ID: <52F47072.9090405@rolandturner.com> Date: Fri, 07 Feb 2014 13:34:42 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> <1479727675.113174.1391654719611.JavaMail.zimbra@peachymango.org> In-Reply-To: <1479727675.113174.1391654719611.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 05:34:46 -0000 On 02/06/2014 10:45 AM, Franck Martin wrote: > As a receiver, you save a lot by checking DMARC on incoming emails and > let the sender put the right policies. I suspect this depends to some extent upon how captive your users are. Yours clearly are, Terry's are to a large extent, others' are not. For the latter group, user churn is a big concern. - Roland From roland@rolandturner.com Thu Feb 6 21:40: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 3007B1A05A8 for ; Thu, 6 Feb 2014 21:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 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.535, 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 PDlt06HpwiGc for ; Thu, 6 Feb 2014 21:40:34 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9423B1A0596 for ; Thu, 6 Feb 2014 21:40:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=LzQRTkWGgoRVdut1Ll80udYr8nz7/2GE89n/n827LA8=; b=Vuxm2IeenYGXNTOksMMFsSl4ze3C34Og6YbR6jC0oS9S0DP3bGg2ttYyzoKkrYXg3PWqLnFxY5TGEdcMGY6PQt6KHCGlyIEucqTqU/4UV2UYWvTXUl68OHFecWYDWyF6xy5HZt895NKIoWkfRqPHn+7t41caLtQLolLfZHX96cU=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=58604 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WBeAy-00076Z-S2 for dmarc@ietf.org; Fri, 07 Feb 2014 05:40:32 +0000 Message-ID: <52F471D0.7060405@rolandturner.com> Date: Fri, 07 Feb 2014 13:40:32 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 05:40:36 -0000 On 02/07/2014 03:19 AM, Michael Adkins wrote: > DMARC has the notion of 'trusted forwarders' defined in the spec and > accounted for in the reporting. There are a few different ways to do > that, some that border on secret sauce, and are mostly a combination > of a reputation or trust system combined with something observable in > the header or the traffic patterns. ... > From experience, I can tell you that if you exempt email signed by > google groups, yahoo groups and it's international flavors, and > microsoft live groups, then you will have solved the problem for 90% > of users. Most of the others are also pretty easy to find: any source which has a relatively stable long term message volume and a very low detected spam rate but authentication failures for a large number of domains is almost certainly a well-behaved forwarder that, at least as a first approximation, can be exempted from DMARC processing. - Roland From roland@rolandturner.com Thu Feb 6 22: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 39EDE1A05B0 for ; Thu, 6 Feb 2014 22:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.535, 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 H7wgtSxNCMwB for ; Thu, 6 Feb 2014 22:36:03 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 872941A0034 for ; Thu, 6 Feb 2014 22:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=TU/dd8DHZWukb1ldr7THojK+gJUTaMWZ10prazr1b1w=; b=bKvKYATAAtFi96NCy+G2dMAluWdwJKkNQUSBrGizrVYb1RVWqZ+jWtMXxRudlulP6s/KJr2Gq71+2UWILu88WGVdsk/2n3eHArfEg9cwgLCLZK/fWQzxM6EvN+a+mPNmtIztAhcGq54AGSjUGEUn6zjhhZ9goWYoRKbWeOmduQE=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=59169 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WBf2c-0007Cz-M0 for dmarc@ietf.org; Fri, 07 Feb 2014 06:36:01 +0000 Message-ID: <52F47ECE.7010806@rolandturner.com> Date: Fri, 07 Feb 2014 14:35:58 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140130220330.GA25608@roeckx.be> <52EB0CBF.9020607@rolandturner.com> <20140201013342.GA24125@roeckx.be> <52EC725B.1050809@rolandturner.com> <20140205005928.GA15734@roeckx.be> In-Reply-To: <20140205005928.GA15734@roeckx.be> Content-Type: multipart/alternative; boundary="------------070306070108090508010607" Subject: Re: [dmarc-ietf] dmarc and forwarding X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 06:36:06 -0000 This is a multi-part message in MIME format. --------------070306070108090508010607 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/05/2014 08:59 AM, Kurt Roeckx wrote: > On Sat, Feb 01, 2014 at 12:04:43PM +0800, Roland Turner wrote: >> "Non-participating" MLMs (RFC 6377) are outside DMARC's scope. > This draft does not update the RFC 6377 requirements for > mailinglists, but I do think it changes the requirements. But it > also seems to contain the posibility to override this somehow, > but it's all outside the scope of DMARC. I do not understand this paragraph or its relevance to the quoted sentence. > From what I understand, I have received very few aggregate report > that gets all the results correct. There always seems to be > something wrong with it. It would be very helpful for you to share those so the relevant issues can be identified and addressed. > And I think the draft isn't helping in > making things clear because it just documents the format. Would you care to propose specific improvements? > As I understand it, in the case of the mails you send to this > list, you should receive the following: > > > ietf.org > ietf1 > pass > > > rolandturner.com > 20120325 > fail > > > ietf.org > mfrom > pass > > I suspect that this conversation would proceed more quickly if you provided real examples rather than hypothetical ones but yes, sure. > I'm just going to guess that the results you get back contain all > kinds of wrong information, but I hope you at least get some that > are more or less correct. Your guess is incorrect. > I think that because none of those that pass are alligned it > should then result in: > > none > fail > fail > > > Possibly it could have an reason there added. As my published policy is none, there is no requirement for a reason. A reason is only required if the published policy is quarantine or reject and neither mechanism yields a pass that DMARC can use but the receiver has decided to override that (e.g. because the forwarder is believed by the receiver to be trustworthy, or because the Domain Owner is believed by the receiver to not have control of their legitimate message streams). > What is unclear to me is what happens when either dkim of spf > would pass and the policy_published contains p=reject. Should it > be: > > reject > pass > fail > > > Or: > > none > pass > fail > None, obviously: an aligned domain has passed SPF. (draft-kucherawy-dmarc-base-02 10.2 5) > Please note that the draft seems to indicate that it should > contain the value from p or sp, but that if you override it > it can contain some other value. So I can read that even if you > accept it because dkim says pass that the disposition should be > reject. And I have to guess that's not really the intension. No, that's the policy_published section. > >> Note further that DMARC is also selective about its use of DKIM, >> except that the DKIM d= must match from 5322.From domain exactly >> (merely being aligned isn't enough). The same two interpretations >> must therefore be understood and they appear in the same two places >> in the aggregate report as above. > I'm not sure I understand what you're saying here. As I > understand it, there is a strict and relaxed way for that? Interesting, a misunderstanding on my part. Thank you. - Roland --------------070306070108090508010607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 02/05/2014 08:59 AM, Kurt Roeckx wrote:

On Sat, Feb 01, 2014 at 12:04:43PM +0800, Roland Turner wrote:

"Non-participating" MLMs (RFC 6377) are outside DMARC's scope.

This draft does not update the RFC 6377 requirements for
mailinglists, but I do think it changes the requirements.  But it
also seems to contain the posibility to override this somehow,
but it's all outside the scope of DMARC.

I do not understand this paragraph or its relevance to the quoted sentence.

From what I understand, I have received very few aggregate report
that gets all the results correct.  There always seems to be
something wrong with it.

It would be very helpful for you to share those so the relevant issues can be identified and addressed.

And I think the draft isn't helping in
making things clear because it just documents the format.

Would you care to propose specific improvements?

As I understand it, in the case of the mails you send to this
list, you should receive the following:
    <auth_results>
      <dkim>
        <domain>ietf.org</domain>
        <selector>ietf1</selector>
        <result>pass</result>
      </dkim>
      <dkim>
        <domain>rolandturner.com</domain>
        <selector>20120325</selector>
        <result>fail</result>
      </dkim>
      <spf>
        <domain>ietf.org</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>

I suspect that this conversation would proceed more quickly if you provided real examples rather than hypothetical ones but yes, sure.

I'm just going to guess that the results you get back contain all
kinds of wrong information, but I hope you at least get some that
are more or less correct.

Your guess is incorrect.

I think that because none of those that pass are alligned it
should then result in:
        <policy_evaluated>
          <disposition>none</disposition>
          <dkim>fail</dkim>
          <spf>fail</spf>
        </policy_evaluated>

Possibly it could have an reason there added.

As my published policy is none, there is no requirement for a reason.

A reason is only required if the published policy is quarantine or reject and neither mechanism yields a pass that DMARC can use but the receiver has decided to override that (e.g. because the forwarder is believed by the receiver to be trustworthy, or because the Domain Owner is believed by the receiver to not have control of their legitimate message streams).

What is unclear to me is what happens when either dkim of spf
would pass and the policy_published contains p=reject.  Should it
be:
        <policy_evaluated>
          <disposition>reject</disposition>
          <dkim>pass</dkim>
          <spf>fail</spf>
        </policy_evaluated>

Or:
        <policy_evaluated>
          <disposition>none</disposition>
          <dkim>pass</dkim>
          <spf>fail</spf>
        </policy_evaluated>

None, obviously: an aligned domain has passed SPF. (draft-kucherawy-dmarc-base-02 10.2 5)

Please note that the draft seems to indicate that it should
contain the value from p or sp, but that if you override it
it can contain some other value.  So I can read that even if you
accept it because dkim says pass that the disposition should be
reject.  And I have to guess that's not really the intension.

No, that's the policy_published section.


Note further that DMARC is also selective about its use of DKIM,
except that the DKIM d= must match from 5322.From domain exactly
(merely being aligned isn't enough). The same two interpretations
must therefore be understood and they appear in the same two places
in the aggregate report as above.

I'm not sure I understand what you're saying here.  As I
understand it, there is a strict and relaxed way for that?

Interesting, a misunderstanding on my part. Thank you.

- Roland
--------------070306070108090508010607-- From tzink@exchange.microsoft.com Fri Feb 7 09:42: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 A5A0E1A0203 for ; Fri, 7 Feb 2014 09:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rh4an5Cq6iWN for ; Fri, 7 Feb 2014 09:42:48 -0800 (PST) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.93]) by ietfa.amsl.com (Postfix) with ESMTP id 7022B1A0128 for ; Fri, 7 Feb 2014 09:42:48 -0800 (PST) Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) by BY2SR01MB609.namsdf01.sdf.exchangelabs.com (10.255.93.168) with Microsoft SMTP Server (TLS) id 15.0.883.2; Fri, 7 Feb 2014 17:42:46 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.11.152]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.11.152]) with mapi id 15.00.0883.000; Fri, 7 Feb 2014 17:42:46 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Known DMARC failures of legitimate email Thread-Index: AQHPI8ci3Rtk6sePpE2L+Ktodijkk5qqEGIQ Date: Fri, 7 Feb 2014 17:42:45 +0000 Message-ID: <3dcd36877f294c21b5ecf603c5e317d7@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> References: <52F471D0.7060405@rolandturner.com> In-Reply-To: <52F471D0.7060405@rolandturner.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.62] x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(199002)(189002)(164054003)(13464003)(377454003)(24454002)(479174003)(74366001)(83322001)(87266001)(19580395003)(81342001)(46102001)(19580405001)(74876001)(33646001)(74706001)(81542001)(95416001)(80976001)(53806001)(65816001)(80022001)(2656002)(66066001)(93516002)(69226001)(85852003)(83072002)(92566001)(93136001)(77982001)(76796001)(76786001)(4396001)(59766001)(77096001)(56816005)(79102001)(81816001)(85306002)(47736001)(51856001)(90146001)(74502001)(15975445006)(47976001)(49866001)(47446002)(74662001)(76482001)(87936001)(81686001)(94946001)(50986001)(54316002)(54356001)(31966008)(94316002)(56776001)(63696002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2SR01MB609; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; CLIP:131.107.192.62; FPR:ECE3C9BC.AFF29FEB.7FF33D73.48E972ED.20288; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:42:50 -0000 Thanks, everyone for the advice. This has been useful. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Roland Turner Sent: Thursday, February 6, 2014 9:41 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email On 02/07/2014 03:19 AM, Michael Adkins wrote: > DMARC has the notion of 'trusted forwarders' defined in the spec and=20 > accounted for in the reporting. There are a few different ways to do=20 > that, some that border on secret sauce, and are mostly a combination=20 > of a reputation or trust system combined with something observable in=20 > the header or the traffic patterns. ... > From experience, I can tell you that if you exempt email signed by=20 > google groups, yahoo groups and it's international flavors, and=20 > microsoft live groups, then you will have solved the problem for 90%=20 > of users. Most of the others are also pretty easy to find: any source which has a rel= atively stable long term message volume and a very low detected spam rate b= ut authentication failures for a large number of domains is almost certainl= y a well-behaved forwarder that, at least as a first approximation, can be = exempted from DMARC processing. - Roland _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From jgomez@seryrich.com Sat Feb 8 12:20: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 C53151A055F for ; Sat, 8 Feb 2014 12:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, SPF_FAIL=0.001, SPF_HELO_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 I0BkihfjMJm0 for ; Sat, 8 Feb 2014 12:20:01 -0800 (PST) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 68C9F1A0465 for ; Sat, 8 Feb 2014 12:20:00 -0800 (PST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 8 Feb 2014 21:20:00 +0100 Message-ID: <1DCB32307AFD4DA8B87544C2D5D580C2@fgsr.local> From: "J. Gomez" To: References: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> Date: Sat, 8 Feb 2014 21:19:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 20:20:04 -0000 On Thursday, February 06, 2014 12:43 AM [GMT+1=3DCET], Terry Zink wrote: > 1. Case 1 - sender publishes DMARC and only authenticates with SPF, > user auto-forwards their email=20 >=20 > Example: bulk sender -> Hotmail -> Gmail > This would pass DMARC at Hotmail (since bulk sender publishes SPF) > but fail at Gmail (since Gmail will see Hotmail's IP but bulk sender > in the 5321.MailFrom) =20 I think in that case Gmail would see the bulk sender in the = 5322.MimeFrom and Hotmail in the 5321.MailFrom. Threfore, the SPF-itself = check would pass at Gmail (because that check would validate that the = email is Hotmail-authentic), although DMARC would fail its (version of = the) SPF-check at Gmail (because that check would try to validate = whether the email is BulkSender-authentic). Yes, it is a mess. The solution is to check SPF-itself before checking DMARC, and then = exempt from DMARC processing those emails which get an SPF-itself result = of pass AND come from known-good domains (according to your locally = maintained whitelist of known-good domains). > 2. Case 2 - discussion/mailing lists. This is a known limitation of > DMARC and there are workarounds, but if no one does anything, the day > after we turn on DMARC how much email would this affect? =20 >=20 > Does anyone have numbers on how much this would affect? You will have to implement mailing-list detection logic on your side, = and then exempt those emails from DMARC processing. It is either that, = or breaking mailing lists for your users (they won't be happy about it). = The other option is to never obey DMARC's p=3Dreject policy. Regards, J.Gomez From mjones@agari.com Mon Feb 10 15:28: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 E95DD1A066E for ; Mon, 10 Feb 2014 15:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1L6l-LwngdUE for ; Mon, 10 Feb 2014 15:28:31 -0800 (PST) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 75A101A040E for ; Mon, 10 Feb 2014 15:28:31 -0800 (PST) Received: by mail-yh0-f45.google.com with SMTP id i57so6040927yha.32 for ; Mon, 10 Feb 2014 15:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1q8fOKaTcUUgdh9b6ojb5RYfImRIJ9oLjtmpVnmK/oE=; b=m+Wf+ThPoyPXWIUGlt9htLkFhyArZwJ0N+3OnwWktik/o9TRuCZy5ufGiPKJFPCmET TnyXG7smv4Y7hiwuVDDBJy1lJO9JGC9UavfjeujiahM9d478FTvl2HbXWM1UlLQe+/HW AExGre58g3kI9W9ahqBJRnXPqNIg1XwhWRZ+I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1q8fOKaTcUUgdh9b6ojb5RYfImRIJ9oLjtmpVnmK/oE=; b=F/fbOoSDzS9PY4inoAeMZm6MJOIJRnROo4obPl1LqxWNv8lY2WnWAmeL21T3sVbmJ3 19UBYvFHJ4byhnte7NUVzS3MIojDESPo+wgmod7dkKRV4uNtXFJ2IY5WwhxBgO2KC32C S365LAc23wHLjFbuIZSgYlCN6Ds8jWFUOInPNWbOak8BIANbCt2xOnjEnzTynnCHfr7v nhpCM0uahsIqXuRsvoriIvgveozbMAn4lXFIwpcy7Y6XCBJMIPMWhtS+Q++ASO+N4JRT OK5LrPdc6Zu7x57EMKZZywkrxSnL0Mw9NIBBCRFkWnkHvMZK6FWQgp/+VB0PnmcW/DPJ m5Tw== X-Gm-Message-State: ALoCoQmGBlqfRg4YotRVQgSHBnf6Ey95OsqzzkP3STgicoafeLehD+Y4wXmCcvua6cnv+K2AuFLC MIME-Version: 1.0 X-Received: by 10.236.113.115 with SMTP id z79mr31160249yhg.8.1392074911043; Mon, 10 Feb 2014 15:28:31 -0800 (PST) Received: by 10.170.173.72 with HTTP; Mon, 10 Feb 2014 15:28:30 -0800 (PST) In-Reply-To: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> References: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> Date: Mon, 10 Feb 2014 15:28:30 -0800 Message-ID: From: Mike Jones To: Terry Zink Content-Type: multipart/alternative; boundary=20cf300faba992e7d004f215b29e Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:28:34 -0000 --20cf300faba992e7d004f215b29e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 5, 2014 at 3:43 PM, Terry Zink wrote: > Hello, > > We're currently building DMARC support and before we go live, I am looking > for some numbers around known cases of DMARC quarantining/rejecting > legitimate email. Here are cases I can think of: > > 1. Case 1 - sender publishes DMARC and only authenticates with SPF, user > auto-forwards their email > > Example: bulk sender -> Hotmail -> Gmail > This would pass DMARC at Hotmail (since bulk sender publishes SPF) but > fail at Gmail (since Gmail will see Hotmail's IP but bulk sender in the > 5321.MailFrom) > > According to Google in a blog post - > http://googleonlinesecurity.blogspot.com/2013/12/internet-wide-efforts-to-fight-email.html, > around 75% of messages authenticate with DKIM and SPF. 15% authenticate > with SPF only, 2% with DKIM only and about 9% no authentication. > > The only ones that would be a problem in Case 1 is SPF-only, and only > those that publish DMARC records with p=quarantine/none. Does anyone know > how much email this might be? > > > 2. Case 2 - discussion/mailing lists. This is a known limitation of DMARC > and there are workarounds, but if no one does anything, the day after we > turn on DMARC how much email would this affect? > > Does anyone have numbers on how much this would affect? > I've been looking into the DMARC data we have to see if I can come up with a number here. Only a few DMARC reporters use the "mailing_list" policy override reason in their DMARC reports. Looking at just those reporters, about 4.8% of DMARC failures are reported with a mailing_list override. That number is for all DMARC failures, not just those from domains with a reject or quarantine. Doing some further digging I looked at the traffic reported with a source IP that was identified as "mailing_list" at least once. From that list, if at least 75% of the IP's messages were tagged as "mailing_list" by those DMARC reporters, then I assumed that IP was primarily used for mailing lists. So I took that list of IPs and applied it to all DMARC reporter's data, whether they report a mailing_list reason or not. What I came up with was that across all DMARC failures reported by all DMARC reporters, about 1.4% of DMARC failures came from this list of "mailing_list" source IPs. So somewhere in the range of 1.4% - 4.8% of DMARC failures are due to mailing lists. Again, this is for all DMARC failures, regardless of the policy on the domain. So turning on DMARC would affect whatever fraction of that % is coming from domains with a reject policy/quarantine policy. Mike > > > 3. Case 3 - anything else? Possibly broken DKIM signatures? Based upon > threads, DKIM seems to pass anywhere between 10% and 90% of the time. Seems > to be that the higher number is more realistic since if your DKIM is > breaking, you'd want to know about it. This would be especially true for > those who publish DMARC. > > > Thanks. > > -- Terry > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --20cf300faba992e7d004f215b29e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 5, 2014 at 3:43 PM, Terry Zink <tzink@excha= nge.microsoft.com> wrote:
Hello,

We're currently building DMARC support and before we go live, I am look= ing for some numbers around known cases of DMARC quarantining/rejecting leg= itimate email. Here are cases I can think of:

1. Case 1 - sender publishes DMARC and only authenticates with SPF, user au= to-forwards their email

Example: bulk sender -> Hotmail -> Gmail
This would pass DMARC at Hotmail (since bulk sender publishes SPF) but fail= at Gmail (since Gmail will see Hotmail's IP but bulk sender in the 532= 1.MailFrom)

According to Google in a blog post - http://googleonlinesecurity.blogspot.com/2013/12/internet-wide-effo= rts-to-fight-email.html, around 75% of messages authenticate with DKIM = and SPF. 15% authenticate with SPF only, 2% with DKIM only and about 9% no = authentication.

The only ones that would be a problem in Case 1 is SPF-only, and only those= that publish DMARC records with p=3Dquarantine/none. Does anyone know how = much email this might be?


2. Case 2 - discussion/mailing lists. This is a known limitation of DMARC a= nd there are workarounds, but if no one does anything, the day after we tur= n on DMARC how much email would this affect?

Does anyone have numbers on how much this would affect?



I've been looking into the DMARC data we have = to see if I can come up with a number here.=A0 Only a few DMARC reporters u= se the "mailing_list" policy override reason in their DMARC repor= ts.=A0 Looking at just those reporters, about 4.8% of DMARC failures are re= ported with a mailing_list override.=A0 That number is for all DMARC failur= es, not just those from domains with a reject or quarantine.

Doing some further digging I looked at the traffic reported = with a source IP that was identified as "mailing_list" at least o= nce. From that list, if at least 75% of the IP's messages were tagged a= s "mailing_list" by those DMARC reporters, then I assumed that IP= was primarily used for mailing lists.=A0 So I took that list of IPs and ap= plied it to all DMARC reporter's data, whether they report a mailing_li= st reason or not.=A0 What I came up with was that across all DMARC failures= reported by all DMARC reporters, about 1.4% of DMARC failures came from th= is list of "mailing_list" source IPs.=A0

So somewhere in the range of 1.4% - 4.8% of DMARC failures a= re due to mailing lists. Again, this is for all DMARC failures, regardless = of the policy on the domain. So turning on DMARC would affect whatever frac= tion of that % is coming from domains with a reject policy/quarantine polic= y.

Mike



=A0


3. Case 3 - anything else? Possibly broken DKIM signatures? Based upon thre= ads, DKIM seems to pass anywhere between 10% and 90% of the time. Seems to = be that the higher number is more realistic since if your DKIM is breaking,= you'd want to know about it. This would be especially true for those w= ho publish DMARC.


Thanks.

-- Terry

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

--20cf300faba992e7d004f215b29e-- From tim@eudaemon.net Tue Feb 11 08:19: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 5E9FB1A0627 for ; Tue, 11 Feb 2014 08:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 Jf8HI9bfwDSH for ; Tue, 11 Feb 2014 08:19:06 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 608921A05E5 for ; Tue, 11 Feb 2014 08:19:06 -0800 (PST) Received: from [192.168.2.114] (24-240-160-218.static.hckr.nc.charter.com [24.240.160.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 08111CB46 for ; Tue, 11 Feb 2014 11:19:11 -0500 (EST) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <880FE4A6-25DB-4247-AAE7-AAEBF01BCB33@eudaemon.net> Date: Tue, 11 Feb 2014 11:18:32 -0500 To: "dmarc@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [dmarc-ietf] spec missing ABNF for "fo" tag X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:19:08 -0000 Hi, Section 5.3. of the DMARC spec is missing ABNF for the "fo" tag. The necessary changes could be (I'm no ABNF master): Adding to "dmarc-record" definition: [dmarc-sep dmarc-fopt] And adding the actual definition: dmarc-fopt = ( "0" / "1" / "d" / "s" ) dmarc-fo = "fo" *WSP "=" *WSP dmarc-fopt *(*WSP ":" *WSP dmarc-fopt) Hope this helps, =- Tim PS. Thanks to as astute dmarcian.com user for pointing this out! From gwzrd@yahoo.com Tue Feb 11 15:49: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 18E171A0773 for ; Tue, 11 Feb 2014 15:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] 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 j4TzDSdNQ9Vm for ; Tue, 11 Feb 2014 15:49:38 -0800 (PST) Received: from nm49.bullet.mail.gq1.yahoo.com (nm49.bullet.mail.gq1.yahoo.com [67.195.87.85]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDF21A0769 for ; Tue, 11 Feb 2014 15:49:38 -0800 (PST) Received: from [98.137.12.58] by nm49.bullet.mail.gq1.yahoo.com with NNFMP; 11 Feb 2014 23:49:37 -0000 Received: from [98.137.12.218] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 11 Feb 2014 23:49:37 -0000 Received: from [127.0.0.1] by omp1026.mail.gq1.yahoo.com with NNFMP; 11 Feb 2014 23:49:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 438962.15994.bm@omp1026.mail.gq1.yahoo.com Received: (qmail 60920 invoked by uid 60001); 11 Feb 2014 23:49:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392162577; bh=/p6hq9oIGyBSsJFto/GmSkKDRcC0DTPbgLcPrIO62pM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mvzRef+o0DVo8TDM+H/iZC5ve74a/3l/XP8xOWyZufLjpV9g6uOleLvwVD5zsUBOPNkjy2PpsHskqg89wv3YTEbRaDM0rDwCXVwjhGxw+N0w9Sn8WKyDksBSZor7+nlF0cLnMv/5PnUww9Z8ZX804p1ZwbQ5au1dG41TLmF5d94= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=q8f6VSrJ8YMCJZq2ojqu4GmQgIT0gMwlPKBuLvmqmfZBhX2O8QWWFWbCSAf8H82uWIBY9dTOf7kL2csRAWC8X0C2fZtTgvY05zpbc5r0G7LqDKlO2LznannsUdxj0cT6X+UFkQK3iR5aK9dAj6ZkOTW7Zy9lJlQGiVDuP6mQrKQ=; X-YMail-OSG: iaswYDMVM1lKzJg4Co0pel2VCsGt0LriCFNPXIIQUI89O50 7yxKVWfG4bWOZVy459v0FB07rmS_GJawO0Xg_OsAvEUv2StqkOHMpn7LxPPe svgpIdnM9hn_O1R7z0XSB3ygMul7ZmFO673euDEJm1hY_MqX7ySTh.VCkdrO 5rx6cikgfvf8d80X.IgGypz3aZNAq8XW_IfYAYfEAq9q3nSnyCPhsB6GDiMu xRRXpnnpJYtQLN0hlvCteXKp7Sw7WfztRfJGD5M8h60Ui5Kew1o6VUQtL.qN o8XIDyK3Gswf8QNQj2yyW.Pt4Sv6ZYPfPrk_3rJGniED0BDqRGGg24AE6Bra mk.m_mN7xzHFR_f4_pzavtQGxFwNcXnHXmC1JRC4ORA36jx9fM6Vqw6f96jQ bdpoQVDYp_Tk6ZRbEUuSA9RK8XFiAmdtN7zLSDDjcMYtRr9WxZzZMJWDlhtR SIOtbsLNTBMHWkDX.VsF6tfO_aj7bQqmSDyeTI6viX.hmzrJQv.3fGAFi8XM iIUM.vW7f2YcQfYOdcOWnGKiyeCSTh4IYFDYhtMopLhyP_QwKTy322By0xXc iJe2lwCIn9u0J3U6wYsYkQQBztnmAIoxp1lZdYaaR8BEc9F23wcOhYnNgLpj LstxggdroC5gUQWI3do_tpAUsHKaxIgSmI0RbAmR_6r9pJ.8WkaM- Received: from [178.253.202.235] by web164602.mail.gq1.yahoo.com via HTTP; Tue, 11 Feb 2014 15:49:37 PST X-Rocket-MIMEInfo: 002.001, PiBTZWN0aW9uIDUuMy4gb2YgdGhlIERNQVJDIHNwZWMgaXMgbWlzc2luZyBBQk5GIGZvciB0aGUgImZvIiB0YWcuCgo.IEFkZGluZyB0byAiZG1hcmMtcmVjb3JkIiBkZWZpbml0aW9uOgo.IFtkbWFyYy1zZXAgZG1hcmMtZm9wdF0KPiBBbmQgYWRkaW5nIHRoZSBhY3R1YWwgZGVmaW5pdGlvbjoKPiBkbWFyYy1mb3B0wqAgwqAgPSAoICIwIiAvICIxIiAvICJkIiAvICJzIiApCj4gZG1hcmMtZm_CoCDCoCDCoCA9ICJmbyIgKldTUCAiPSIgKldTUAo.wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqDCoCBkbWFyYy1mb3ABMAEBAQE- X-Mailer: YahooMailWebService/0.8.176.634 References: Message-ID: <1392162577.19995.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Tue, 11 Feb 2014 15:49:37 -0800 (PST) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [dmarc-ietf] spec missing ABNF for "fo" tag 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, 11 Feb 2014 23:52:08 -0000 > Section 5.3. of the DMARC spec is missing ABNF for the "fo" tag.=0A=0A> A= dding to "dmarc-record" definition:=0A> [dmarc-sep dmarc-fopt]=0A> And addi= ng the actual definition:=0A> dmarc-fopt=A0 =A0 =3D ( "0" / "1" / "d" / "s"= )=0A> dmarc-fo=A0 =A0 =A0 =3D "fo" *WSP "=3D" *WSP=0A>=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0=A0 dmarc-fopt *(*WSP ":" *WSP dmarc-fopt)=0A=0Asome comments on= this, nothing crucial:=0A=0Aif we keep the proposed names, dmarc-record ad= dition should read: [dmarc-sep dmarc-fo].=0A=0Ai guess, it should be placed= between dmarc-ainterval and dmarc-rfmt entries, as it defines failure repo= rts more closely; so, less important than aggregate report options, but mor= e valuable than rfmt one. not that order matters, as specified in txt.=0A= =0Aalso, i'm not sure if it needs two definitions, as it could be done with= only one:=0Admarc-fo=A0 =A0 =A0 =3D "fo" *WSP "=3D" *WSP=0A=A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 ( "0" / "1" / "d" / "s" )=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 *(*WSP ":" *WSP ( "0" / "1" / "d" / "s" ))=0A=0Ai was always less into = occupying memory than processor resource.=0A=0Ahowever, this also allows fo= r duplicate multiples. but i don't think that would be an issue during proc= essing.=0A=0Ahowever, as mentioned some time ago, having possibility of fo= =3D0:1 may introduce some grief.=0A=0A=0A> PS. Thanks to as astute dmarcian= .com user for pointing this out!=0A=0Ayes, i'm to blame. hi all. hopefully = my contribution will not remain at only=0Athis, and my brain will force me = to make another useful contribution eventually. seems i came to that point = of my life when this kind of activity comes naturally to me; all tnx go to = tim for inviting me here.=0A=0Ai've been rereading drafts for awhile now, a= lmost every single version. i like how dmarc progresses nicely towards a fu= ll standard. good job all.=0A=0Admarcian.com isn't the only free testing su= ite i nudged about standards before; unlock the inbox has me in their "spec= ial thanks" section somewhere too.=0A=0Awell, i guess this is enough for an= introduction. until next time.=0A=0A=0A-- =0AVlatko Salaj aka goodone=0Aht= tp://goodone.tk From gwzrd@yahoo.com Thu Feb 13 01:07: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 56EE81A015F for ; Thu, 13 Feb 2014 01:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.254 X-Spam-Level: X-Spam-Status: No, score=0.254 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.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYplvUibkcFB for ; Thu, 13 Feb 2014 01:07:24 -0800 (PST) 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 44EED1A017B for ; Thu, 13 Feb 2014 01:07:24 -0800 (PST) Received: from [127.0.0.1] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 09:07:23 -0000 Received: from [98.138.100.103] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 09:04:36 -0000 Received: from [98.137.12.188] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 09:04:36 -0000 Received: from [98.137.12.49] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 13 Feb 2014 09:04:35 -0000 Received: from [127.0.0.1] by omp1064.mail.gq1.yahoo.com with NNFMP; 13 Feb 2014 09:04:35 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 967839.5717.bm@omp1064.mail.gq1.yahoo.com Received: (qmail 13417 invoked by uid 60001); 13 Feb 2014 09:04:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392282275; bh=uQzcxvzBOOeGaGYr40DL/f7YybkZRO0PT+4XVtWGd7E=; 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=YbAvzrAvtCUsp+do8MF9DY5Lj7Ey86y9vVFwyJe2zTh5lStzC9zdD7iHffJ3HGzHZQ3D+ygDGu8Hs6UJP8SOgLk6E3rf9SsRNSwtXDwjczDgiz3WoVJg9FPeAz333bM2nvtvdYjQKAmdwxoY30vDfPULSGh20VDbhgQC1aDkyYM= 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=m3u7+clNhZGQ/iM9A3vrBXEHrdGdIOM7s5/7Xi9h1Sm+mefe7ELVJQH/u4edvt7a5hyfUbqRdabbynZe2U+KTEljC6OplNbqIxtAPcyzduPIGp084VP8jT9ZoASBKmZdrICYytJ4TKjfNrU/od9X1ax0YQEN8Kx9GjwE+3cJ5Zo=; X-YMail-OSG: 8WUgjmUVM1mjExhESRTubEQvdzSpmLqYKBlSSw0BQPJI_0o jd5xCOxv.Bmi_hoJBD6axngTKIxPqgJ2KTckMEH4e8fg22kMMzEGM4CZv_pQ Jt1Pwbr2R9_k6Wg3vS8DbLYJubJebkGG9Eysbio5QVec1IKToRqcmpFknEka oRrCv91dmcoF0I5JN4hqodlv3QAlOx10G23r8gqmjxXkXQZ7QEVPc2HDhVJs mj8g.f0jjxaXN7N_RgZ3QL_JD.ePm3SkWLXjDz2JpFQo42V2DUuXtNsljVcf A8Xt9NDtXeWRNVmaeQCSBkp6a1qCYS8_NXK8sjCQchFxT3dgDHukrLFcHQzC 96TwBKhlch_Z9xh.Q93zS51Bd5wiEEIzIp6hoHGA8zozfjdxXbkoeHN6JPf2 z2E_vCijRcEjdIsy2aBnc3lvGBH3JSxJCkmsDZEB7hqyrleYSzOZlByzpyYI ZDNnJHA7gqCVEgoFcAMIoeo.528M.80LMGiqwnysZKxUBLjxUOCuRlIvYILN 7g.zXW2HXfotJ9b9j16lpnbjcSYeZshquFzOk.oOvnmU39K.GWp9O_tGNZin mFSuwdvMKRtGnvBMY6ynI_r2TvKTMU1E8mq5DSQ26fXINFKsMZelGQv_jzzM qQ4SUIke.KfG3YT._Ksn9WwPG_1Tdegtv0KDFhoUL_otFAjoUa6HmPI89xAK 3Ko6h3iBY Received: from [178.253.202.235] by web164604.mail.gq1.yahoo.com via HTTP; Thu, 13 Feb 2014 01:04:35 PST X-Rocket-MIMEInfo: 002.001, aSdtIG5vdCBzdXJlIGlmIHRoaXMgaGFzIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZSBvciBub3QsCmhvd2V2ZXIsIGltbywgaXQgc2hvdWxkIGJlIG5vdGljZWQgaW4gc29tZSB3YXkgb3IgYW5vdGhlciwKaW4gZG1hcmMgZHJhZnQuCgpiYXNpY2FsbHksIGl0J3MgYSBwcm9ibGVtIHdpdGggZG1hcmMgYW5kIGZvcndhcmRlcnMsCm1haWxpbmcgbGlzdHMsIGFuZCBob3cgdGhleSBicmVhayBzcGYsIGFuZCB0aHVzLCBkbWFyYy4KCm5vdywgaSdtIHF1aXRlIGF3YXJlIHRoYXQgZm9yd2FyZGVycyBhbmQgbWFpbGluZyABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 Message-ID: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Thu, 13 Feb 2014 01:04:35 -0800 (PST) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dmarc-ietf] SRS helps SPF/DMARC 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, 13 Feb 2014 09:07:31 -0000 i'm not sure if this has been discussed before or not, however, imo, it should be noticed in some way or another, in dmarc draft. basically, it's a problem with dmarc and forwarders, mailing lists, and how they break spf, and thus, dmarc. now, i'm quite aware that forwarders and mailing lists have been discussed here to the point of punching corpses. however, i didn't see anyone mention SRS [Sender Rewriting Scheme] at all, even with advanced search from likes of google and bing. having researched the topic for some time, imo, SRS rly does help SPF combat issues regarding forwarders. in turn, this also helps DMARC. so, what i'm trying to propose here is some kind of mention in dmarc draft on behalf of SRS. having even a small mention should really help ppl deploying dmarc on forwarding hosts. and yes, i'm aware SRS hasn't been standardized, but mentioning it in dmarc specs may also help add some traction to that, almost completely stable and functional, technique of fixing some grief introduced by forwarders. more info on SRS: http://www.libsrs2.org -- Vlatko Salaj aka goodone http://goodone.tk From roland@rolandturner.com Thu Feb 13 01:25:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5ACE1A0176 for ; Thu, 13 Feb 2014 01:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, 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 q17PvcGsD07y for ; Thu, 13 Feb 2014 01:25:20 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 534061A00FA for ; Thu, 13 Feb 2014 01:25:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=ni+XSAziZ0mTWthUtp+X8rsxKt9sBSr1xHpuRSg0ntk=; b=GgKFhtk8wbBSUbhRo3LSK3zC1bPAQ3eIp/lN77qjWz1Fxapc4SBIC2HafjLknQJBWaymCKKIw6AKfHj+Z3YgUOu/NZYOGX8YB/+EsBCsLSJjswrW5I3k0bvSm47T0ynQQDq5jl7YTzUe0F7xCjp3TdqNWE5OxzZ5V12vDu6yWyQ=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=50946 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WDsXm-0007PW-AF for dmarc@ietf.org; Thu, 13 Feb 2014 09:25:18 +0000 Message-ID: <52FC8F7D.7090609@rolandturner.com> Date: Thu, 13 Feb 2014 17:25:17 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> In-Reply-To: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> Content-Type: multipart/alternative; boundary="------------070302090506030409050907" Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 09:25:23 -0000 This is a multi-part message in MIME format. --------------070302090506030409050907 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit For better or worse, SRS doesn't help DMARC at all. DMARC uses authentication results from DKIM and SPF purely to authenticate use of the domain in the 5322.From, SPF/DKIM passes for different/unaligned domains are ignored. An SRS rewrite can cause an SPF fail to become an SPF pass, but it will also change the domain that SPF passes to no longer be that appearing in 5322.From. The general strategies for receivers to deal with forwarders appear to break down into: * You don't care about forwarder damage (e.g. have a captive audience): ignore forwarders, let stuff break. This seems absurd, but some people - typically not receivers - think about the problem this way. * You do care about forwarder damage: identify reliable forwarders and exempt them from DMARC processing. This is generally most usefully done by IP address rather than by domain-name-plus-SPF (SPF would usually widen the exemption needlessly). SRS doesn't come up in either case which, given how rarely it's used, shouldn't be a large surprise. - Roland On 02/13/2014 05:04 PM, Vlatko Salaj wrote: > i'm not sure if this has been discussed before or not, > however, imo, it should be noticed in some way or another, > in dmarc draft. > > basically, it's a problem with dmarc and forwarders, > mailing lists, and how they break spf, and thus, dmarc. > > now, i'm quite aware that forwarders and mailing lists have > been discussed here to the point of punching corpses. however, > i didn't see anyone mention SRS [Sender Rewriting Scheme] > at all, even with advanced search from likes of google and bing. > > having researched the topic for some time, imo, SRS rly does > help SPF combat issues regarding forwarders. in turn, this also > helps DMARC. > > so, what i'm trying to propose here is some kind of mention > in dmarc draft on behalf of SRS. having even a small mention > should really help ppl deploying dmarc on forwarding hosts. > > and yes, i'm aware SRS hasn't been standardized, but > mentioning it in dmarc specs may also help add some traction to > that, almost completely stable and functional, technique > of fixing some grief introduced by forwarders. > > more info on SRS: > http://www.libsrs2.org > > --------------070302090506030409050907 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
For better or worse, SRS doesn't help DMARC at all.

DMARC uses authentication results from DKIM and SPF purely to authenticate use of the domain in the 5322.From, SPF/DKIM passes for different/unaligned domains are ignored. An SRS rewrite can cause an SPF fail to become an SPF pass, but it will also change the domain that SPF passes to no longer be that appearing in 5322.From.

The general strategies for receivers to deal with forwarders appear to break down into:
  • You don't care about forwarder damage (e.g. have a captive audience): ignore forwarders, let stuff break. This seems absurd, but some people - typically not receivers - think about the problem this way.
  • You do care about forwarder damage: identify reliable forwarders and exempt them from DMARC processing. This is generally most usefully done by IP address rather than by domain-name-plus-SPF (SPF would usually widen the exemption needlessly).
SRS doesn't come up in either case which, given how rarely it's used, shouldn't be a large surprise.

- Roland


On 02/13/2014 05:04 PM, Vlatko Salaj wrote:
i'm not sure if this has been discussed before or not,
however, imo, it should be noticed in some way or another,
in dmarc draft.

basically, it's a problem with dmarc and forwarders,
mailing lists, and how they break spf, and thus, dmarc.

now, i'm quite aware that forwarders and mailing lists have
been discussed here to the point of punching corpses. however,
i didn't see anyone mention SRS [Sender Rewriting Scheme]
at all, even with advanced search from likes of google and bing.

having researched the topic for some time, imo, SRS rly does
help SPF combat issues regarding forwarders. in turn, this also
helps DMARC.

so, what i'm trying to propose here is some kind of mention
in dmarc draft on behalf of SRS. having even a small mention
should really help ppl deploying dmarc on forwarding hosts.

and yes, i'm aware SRS hasn't been standardized, but
mentioning it in dmarc specs may also help add some traction to
that, almost completely stable and functional, technique
of fixing some grief introduced by forwarders.

more info on SRS:
http://www.libsrs2.org

--------------070302090506030409050907-- From nobody Thu Feb 13 14:05: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 278F21A0385 for ; Thu, 13 Feb 2014 14:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 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.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BN5hVYQOB1HW for ; Thu, 13 Feb 2014 14:05:04 -0800 (PST) Received: from nm38.bullet.mail.ne1.yahoo.com (nm38.bullet.mail.ne1.yahoo.com [98.138.229.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7E51A037E for ; Thu, 13 Feb 2014 14:05:03 -0800 (PST) Received: from [127.0.0.1] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 22:05:01 -0000 Received: from [98.138.101.129] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 22:02:14 -0000 Received: from [98.137.12.174] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 13 Feb 2014 22:02:13 -0000 Received: from [216.39.60.194] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 13 Feb 2014 22:02:13 -0000 Received: from [127.0.0.1] by omp1081.mail.gq1.yahoo.com with NNFMP; 13 Feb 2014 22:02:13 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 724715.50381.bm@omp1081.mail.gq1.yahoo.com Received: (qmail 73071 invoked by uid 60001); 13 Feb 2014 22:02:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392328933; bh=25gEXSola3ZgX4k4UPkaU8rVa30WT+5dkRD7BNx+OKY=; 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=ln1S+tlGVJzj0Gt7Z9qWZpdElMdlz0c2ROSthVoIEbqdrhq1t0qVGaNtwvv9Er0CqelJSotDzRsVHxk8rA67L8kMI6YKFZszgYDJNK7+Jx2l75TU1slm68hPKDRccvs7gxoy2dlmU4ybCnwbC5btyeahau56AdMvJiktz9JCfx8= 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=Smei0AzFGbRC8W0TmmpPFE83aocPeFo3vEKhILvITCAqDuHl5iW81byG3HdT6tlvhQVCxu54tgOq+l9R4J8K5Ssb4kfuB+LLtaOVYVzjQrmzqGwxQY2bZOF+LTOWZJVTe7pjh9PK+x/FQc3NQ5mMVcleLC7wQldyKoMJnqyrHuk=; X-YMail-OSG: zuQq1gAVM1mW0p5yiP5.DhKHNs3WjezrLhX5izPm8UVZYyV 25mSy8XXZUXFAr8afKfhiSd6NuUp.N6vQ3Jn5jl9lgu5nsXleftjpU6EUMOE dbHazfCIFTd_mloJDsE51W6gKQh64FiADu7ZSbXLYcDwBSVt6WS3O0mqVXWP sllLgSG7drNWmFMlO9S9y19E6a.4qqa6AjMnMDu_jE7pQ1cEL6CA6uO01aNJ p2Z7Y67QtE1vxVSlNu5Zdw1AGIkenSyWYuizNnswd1JGDOsSj0Ome3nrafPo u_CTrUh2aYnKEBuM_BoM9LmOl2Exhx5ySbR9uAwofqUdUoZIbVXYrr5jlii1 izUJWLGNwi.hxFSmE7vQEc1sPtOoHzTpSXUHJzyM1w_akD4ZDqhdlZntCFit C.9oRAf71yGsbJwASqUXSXGE7sptWK64DdMq4Sln5mjYFBkw373mJrnpKO1i t9CfSsR1XrgwgMBpTOsNMeZTk27Ssvbxz5Jcx6j9IwocIY5AmXuDnaad2qR3 zS77TpB0HCdsZ8sKTUApx3aa4Nri1kToua8SJMpsowgF2f7xjiTEpDV2Tc6V TBDWg7DFWhJ_s82tDQ8kvVEngt96w1Nd_u7.XC6YAFmkpV7HyowgFmNBeT9i 2s1O7gtp8Ftz616iKQXuXQ60rPw-- Received: from [109.121.17.22] by web164605.mail.gq1.yahoo.com via HTTP; Thu, 13 Feb 2014 14:02:13 PST X-Rocket-MIMEInfo: 002.001, PiBZb3UgZG8gY2FyZSBhYm91dCBmb3J3YXJkZXIgZGFtYWdlOiBpZGVudGlmeSByZWxpYWJsZSBmb3J3YXJkZXJzIGFuZCBleGVtcHQKPiB0aGVtIGZyb20gRE1BUkMgcHJvY2Vzc2luZy4gVGhpcyBpcwogICAgICAgICAgZ2VuZXJhbGx5IG1vc3QgdXNlZnVsbHkgZG9uZSBieSBJUAo.IGFkZHJlc3MgcmF0aGVyIHRoYW4gYnkKICAgICAgICAgIGRvbWFpbi1uYW1lLXBsdXMtU1BGIChTUEYgd291bGQgdXN1YWxseSB3aWRlbiB0aGUKPiBleGVtcHRpb24KICAgICAgICAgIG5lZWRsZXNzbHkpLgo.IFNSUyBkb2UBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 References: Message-ID: <1392328933.63627.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Thu, 13 Feb 2014 14:02:13 -0800 (PST) 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/P8LK1-JyqdbyuMNMC9Fj6zkOvwE Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC 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, 13 Feb 2014 22:05:06 -0000 > You do care about forwarder damage: identify reliable forwarders and exempt > them from DMARC processing. This is generally most usefully done by IP > address rather than by domain-name-plus-SPF (SPF would usually widen the > exemption needlessly). > SRS doesn't come up in either case which, given how rarely it's used, > shouldn't be a large surprise. forwarders running SRS would be more easily identifiable by receivers as reliable forwarders. that should have been my main point. SPF pass, provided by SRS on a forwarder, is useful data in that regard, together with other algorithms and policies a receiver may use when identifying reliable forwarders. more so, if a given forwarder doesn't mess with DKIM signature - such email would pass DMARC. and it would generate only a single error - SPF alignment. only a single fail in 4 step check could be useful data for DMARC-enabled receivers when dealing with forwarders. given that main purpose of DMARC is to help major mailbox receivers identify reliable email from major email senders, having a spec that suggests recommended behavior for forwarders could help identify such entities in email transaction, and help those receivers evaluate forwarded email more easily. doc change i'm proposing isn't big. in relevant sections, when speaking about forwarders, a simple mention of SRS as helpful technique, should suffice. imo, SPF spec did fail to do that, for whatever reason, and maybe we should try not to miss such opportunity again. current draft does talk about ADSP quite a bit, all while ADSP seems even less relevant to DMARC than SRS. it's not like we would be adding junk data to spec by mentioning SRS. in any case, that's what has been bugging me about DMARC since it's inception. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Thu Feb 13 15:41: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 783D81A0538 for ; Thu, 13 Feb 2014 15:41:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3yjlGiM6Oiy for ; Thu, 13 Feb 2014 15:41:50 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 315401A052F for ; Thu, 13 Feb 2014 15:41:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 8EB3E29C1BC; Thu, 13 Feb 2014 17:41:48 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKn626Ak7vMy; Thu, 13 Feb 2014 17:41:48 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7120929C1CE; Thu, 13 Feb 2014 17:41:48 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5BC1229C1C4; Thu, 13 Feb 2014 17:41:48 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id jzoTPpdNgOAJ; Thu, 13 Feb 2014 17:41:48 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 3E60A29C1BC; Thu, 13 Feb 2014 17:41:48 -0600 (CST) Date: Thu, 13 Feb 2014 17:41:46 -0600 (CST) From: Franck Martin To: Vlatko Salaj Message-ID: <1020249830.138100.1392334906832.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1392328933.63627.YahooMailNeo@web164605.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 - FF27 (Mac)/8.0.5_GA_5839) Thread-Topic: SRS helps SPF/DMARC Thread-Index: xCpB5UcRMmBsn/6nQeuxtlxk+sj+hQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9GZQdTWwtQ6kEdEOPD8VTOc8tPI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:41:55 -0000 ----- Original Message ----- > From: "Vlatko Salaj" > To: dmarc@ietf.org > Sent: Thursday, February 13, 2014 2:02:13 PM > Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC > > > You do care about forwarder damage: identify reliable forwarders and exempt > > them from DMARC processing. This is > generally most usefully done by IP > > address rather than by > domain-name-plus-SPF (SPF would usually widen the > > exemption > needlessly). > > SRS doesn't come up in either case which, given how rarely it's > used, > > shouldn't be a large surprise. > > forwarders running SRS would be more easily identifiable by receivers as > reliable forwarders. that should have been my main point. > > SPF pass, provided by SRS on a forwarder, is useful data in that regard, > together with other algorithms and policies a receiver may use when > identifying reliable forwarders. > Transitive trust is hard to implement and DKIM cannot sign this field. The receiver does not have any way to trust that the forwarder, just forwarded the email without altering the content or creating new content. From nobody Thu Feb 13 22:07: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 9587A1A00F3 for ; Thu, 13 Feb 2014 22:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.548, 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 r3jRFhBhk0uF for ; Thu, 13 Feb 2014 22:07:36 -0800 (PST) Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id B042D1A00F2 for ; Thu, 13 Feb 2014 22:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=XplBvN+fK2KX9eoiGkmZOP6YiRdaUiJCbBoki5L8zDI=; b=tU5mTcXiBkdC2KpzP/f3agv5CpFS3ktIQQBJjxk4xnnBIgr/o3vRaLwx7j198+eIqAosJ5x6jlj6oQOZTg0esxtpf26moYWeQalQVEYtnOkRoSYbKOL4ngFxvLzEyxzh8nb/pyyMwGnSxvXzSATK3cVXMl4NWkhKXGf6akNrERE=; Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133 Received: from [116.12.149.133] (port=59897 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WEBvw-0007yE-MW for dmarc@ietf.org; Fri, 14 Feb 2014 06:07:33 +0000 Message-ID: <52FDB2A3.6070505@rolandturner.com> Date: Fri, 14 Feb 2014 14:07:31 +0800 From: Roland Turner User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <1392328933.63627.YahooMailNeo@web164605.mail.gq1.yahoo.com> In-Reply-To: <1392328933.63627.YahooMailNeo@web164605.mail.gq1.yahoo.com> Content-Type: multipart/alternative; boundary="------------070108040907020705010508" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jmLNLPwzQrGQ5cx9kFqGSJ1JVWk Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 06:07:38 -0000 This is a multi-part message in MIME format. --------------070108040907020705010508 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02/14/2014 06:02 AM, Vlatko Salaj wrote: >> forwarders running SRS would be more easily identifiable by receivers as reliable forwarders. that should have been my main point. Parts of your post definitely move into territory that really has been done to death already, but for the sake of putting the SRS argument into context, I'll [briefly!] outline a few fairly well understood items. SRS is not relevant to identifying reliable forwarders. The relevant information is: * That a given IP address has a substantial, sustained message volume; large and persistent enough to perform meaningful statistical analysis on. * That the complaint rate for messages from that IP address is consistently negligible. * That messages from that address routinely fail authentication from a wide range of domains that otherwise pass when they deliver directly. SRS doesn't help measure any of these things. If you mean that the mere use of SRS by a sender could usefully be treated by a receiver as a signal that the sender is reliable then you've overlooked the ability of spoofers to do the same. Indeed, this came up in the early days of SPF: the fact/perception that overly enthusiastic receivers were granting senders the benefit of the doubt merely because SPF passed meant that for quite some time an SPF pass became a predictor of abuse (criminals usually adapt faster than the median honest participant). Someone else pointed this out earlier: if you trust someone to do SRS honestly and competently then you can probably exempt them from DMARC processing anyway, meaning that SRS adds nothing. Worse, you have to determine whether someone's SRS implementation is trustworthy before using it as an input into anything else, however once you've made that determination about a particular source, you can already exempt DMARC processing. SRS adds nothing here. >> SPF pass, provided by SRS on a forwarder, is useful data in that regard, together with other algorithms and policies a receiver may use when identifying reliable forwarders. Per the above, SRS provides no useful input for this purpose >> more so, if a given forwarder doesn't mess with DKIM signature - such email would pass DMARC. and it would generate only a single error - SPF alignment. only a single fail in 4 step check could be useful data for DMARC-enabled receivers when dealing with forwarders. Forwarders that don't break DKIM don't need to be exempted from DMARC processing. SRS adds nothing here. >> given that main purpose of DMARC is to help major mailbox receivers identify reliable email from major email senders, Not quite; it's to help Domain Owners of any size - not just major ones - and receivers co-operate on keeping spoofed mail out of inboxes. (Ideally receivers of any size too, but it's not yet plug-and-play for receivers, because of exactly the kind of problem that we're discussing.) >> having a spec that suggests recommended behavior for forwarders could help identify such entities in email transaction, and help those receivers evaluate forwarded email more easily. This is the same erroneous thinking that was behind specifying SRS in the first place. DMARC is about helping Domain Owners and receivers co-operate on reducing a problem. As John Levine frequently points out, forwarders tend to have $0 budgeted to solve Domain Owners' and receivers' problems for them. That said, there are several things that willing forwarders can do: * Certain kinds of forwarder [can] behave in ways which preserve DKIM. These applies to things like forwarding message copies from a user's inbox to another account held by the same user elsewhere. Mailing lists generally can't work this way because they tag Subject: headers, add footers, strip attachments, etc. * Some mailing lists can and do take authorship, meaning that they replace the 5322.From with the list's submission address. They can then readily cause both SPF and DKIM to pass. Most mailing lists don't work this way. * Given that p=reject is a clear indication from the Domain Owner that modified messages should not be delivered, a mailing list (or other forwarder) that is set up to make [DKIM-breaking] changes can reasonably reject submissions outright from such domains. * For forwarders who are determined to attempt to get the mail through even in a p=reject situation (not the Domain Owners wish, but the forwarder doesn't work for the Domain Owner), a useful adaptation is to not treat 5xx failures for mail forwarded from p=reject domains as reasons to stop sending (e.g. to unsubscribe the recipient from a mailing list). This is probably quite unwise, but is mentioned for completeness. I thought most of this was in the FAQ, but can't locate it at present. >> doc change i'm proposing isn't big. in relevant sections, when speaking about forwarders, a simple mention of SRS as helpful technique, should suffice. The relevant place for this would be the FAQ, it has no part in the DMARC protocol. That said, as SRS doesn't provide any help at all, the likely addition would read the opposite of what you have in mind. >> imo, SPF spec did fail to do that, for whatever reason, and maybe we should try not to miss such opportunity again. If you are implying that the absence of SRS from the SPF spec is any part of the reason for the non-adoption of SRS by forwarders then you are mistaken. The reasons are those described above. >> current draft does talk about ADSP quite a bit, all while ADSP seems even less relevant to DMARC than SRS. DMARC is very close to ADSP; DMARC is essentially sender-policy version 4, ADSP was version 3. (SPF -all and DomainKeys o=- were the previous serious attempts at this). ADSP's major innovation (separation of policy from authentication) is retained by DMARC. DMARC's major innovation was providing a decoupled feedback mechanism. SPF has a feedback mechanism, but it is too closely coupled to message handling to be usable by some large receivers. - Roland --------------070108040907020705010508 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 02/14/2014 06:02 AM, Vlatko Salaj wrote:

forwarders running SRS would be more easily identifiable by receivers as reliable forwarders. that should have been my main point.

Parts of your post definitely move into territory that really has been done to death already, but for the sake of putting the SRS argument into context, I'll [briefly!] outline a few fairly well understood items.

SRS is not relevant to identifying reliable forwarders. The relevant information is:

  • That a given IP address has a substantial, sustained message volume; large and persistent enough to perform meaningful statistical analysis on.
  • That the complaint rate for messages from that IP address is consistently negligible.
  • That messages from that address routinely fail authentication from a wide range of domains that otherwise pass when they deliver directly.

SRS doesn't help measure any of these things.

If you mean that the mere use of SRS by a sender could usefully be treated by a receiver as a signal that the sender is reliable then you've overlooked the ability of spoofers to do the same. Indeed, this came up in the early days of SPF: the fact/perception that overly enthusiastic receivers were granting senders the benefit of the doubt merely because SPF passed meant that for quite some time an SPF pass became a predictor of abuse (criminals usually adapt faster than the median honest participant).

Someone else pointed this out earlier: if you trust someone to do SRS honestly and competently then you can probably exempt them from DMARC processing anyway, meaning that SRS adds nothing. Worse, you have to determine whether someone's SRS implementation is trustworthy before using it as an input into anything else, however once you've made that determination about a particular source, you can already exempt DMARC processing.

SRS adds nothing here.

SPF pass, provided by SRS on a forwarder, is useful data in that regard, together with other algorithms and policies a receiver may use when identifying reliable forwarders.

Per the above, SRS provides no useful input for this purpose

more so, if a given forwarder doesn't mess with DKIM signature - such email would pass DMARC. and it would generate only a single error - SPF alignment. only a single fail in 4 step check could be useful data for DMARC-enabled receivers when dealing with forwarders.

Forwarders that don't break DKIM don't need to be exempted from DMARC processing. SRS adds nothing here.

given that main purpose of DMARC is to help major mailbox receivers identify reliable email from major email senders,

Not quite; it's to help Domain Owners of any size - not just major ones - and receivers co-operate on keeping spoofed mail out of inboxes.

(Ideally receivers of any size too, but it's not yet plug-and-play for receivers, because of exactly the kind of problem that we're discussing.)

having a spec that suggests recommended behavior for forwarders could help identify such entities in email transaction, and help those receivers evaluate forwarded email more easily.

This is the same erroneous thinking that was behind specifying SRS in the first place. DMARC is about helping Domain Owners and receivers co-operate on reducing a problem. As John Levine frequently points out, forwarders tend to have $0 budgeted to solve Domain Owners' and receivers' problems for them.

That said, there are several things that willing forwarders can do:

  • Certain kinds of forwarder [can] behave in ways which preserve DKIM. These applies to things like forwarding message copies from a user's inbox to another account held by the same user elsewhere. Mailing lists generally can't work this way because they tag Subject: headers, add footers, strip attachments, etc.
  • Some mailing lists can and do take authorship, meaning that they replace the 5322.From with the list's submission address. They can then readily cause both SPF and DKIM to pass. Most mailing lists don't work this way.
  • Given that p=reject is a clear indication from the Domain Owner that modified messages should not be delivered, a mailing list (or other forwarder) that is set up to make [DKIM-breaking] changes can reasonably reject submissions outright from such domains.
  • For forwarders who are determined to attempt to get the mail through even in a p=reject situation (not the Domain Owners wish, but the forwarder doesn't work for the Domain Owner), a useful adaptation is to not treat 5xx failures for mail forwarded from p=reject domains as reasons to stop sending (e.g. to unsubscribe the recipient from a mailing list). This is probably quite unwise, but is mentioned for completeness.

I thought most of this was in the FAQ, but can't locate it at present.

doc change i'm proposing isn't big. in relevant sections, when speaking about forwarders, a simple mention of SRS as helpful technique, should suffice.

The relevant place for this would be the FAQ, it has no part in the DMARC protocol. That said, as SRS doesn't provide any help at all, the likely addition would read the opposite of what you have in mind.

imo, SPF spec did fail to do that, for whatever reason, and maybe we should try not to miss such opportunity again.

If you are implying that the absence of SRS from the SPF spec is any part of the reason for the non-adoption of SRS by forwarders then you are mistaken. The reasons are those described above.

current draft does talk about ADSP quite a bit, all while ADSP seems even less relevant to DMARC than SRS.

DMARC is very close to ADSP; DMARC is essentially sender-policy version 4, ADSP was version 3. (SPF -all and DomainKeys o=- were the previous serious attempts at this). ADSP's major innovation (separation of policy from authentication) is retained by DMARC. DMARC's major innovation was providing a decoupled feedback mechanism. SPF has a feedback mechanism, but it is too closely coupled to message handling to be usable by some large receivers.

- Roland
--------------070108040907020705010508-- From nobody Fri Feb 14 00:26: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 CDE631A00E4 for ; Fri, 14 Feb 2014 00:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 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.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQvL4-Csdl8w for ; Fri, 14 Feb 2014 00:26:24 -0800 (PST) Received: from nm38.bullet.mail.ne1.yahoo.com (nm38.bullet.mail.ne1.yahoo.com [98.138.229.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7BA1A0114 for ; Fri, 14 Feb 2014 00:26:24 -0800 (PST) Received: from [127.0.0.1] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 08:26:23 -0000 Received: from [98.138.100.114] by nm38.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 08:23:29 -0000 Received: from [98.137.12.56] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 08:23:29 -0000 Received: from [216.39.60.194] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 08:23:29 -0000 Received: from [127.0.0.1] by omp1081.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 08:23:29 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 525367.35666.bm@omp1081.mail.gq1.yahoo.com Received: (qmail 1894 invoked by uid 60001); 14 Feb 2014 08:23:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392366209; bh=DfW7COHZV/IpSmjiTL5Tx7tKwqDmKkJjSnhP2+ZCkxM=; 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=wMJi9chmmwxUhBLya04njyMzo5U7eMb8R7X2old1OcrpERILcQOszBo+fzPKnDOOBeau1gdMyvcsQkeOnAjd/EVa0CadAjZ4XhChTgtrpmlUbBl7L50yqvEQ3a/Y6cwDRuSynGGuHQgHQjdbHUlmVeoLQjzYG7YqPGFKiYsni8A= 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=vXkOCdb5wq5VB5DbrIjGMiTA6dBZX705o3FEmKYHzwXsjqCdbtAcin0FqSYA7eqb1IzMWZFwV12tyTjUNiOfPyuScGfVzrnElcOunMaxMnInlm4DlWNYPDYX9h0PQakHKuA4z2clJvFne5QGi1/IW49HBpGNTvY6TvHIuTGL5c8=; X-YMail-OSG: VB0gvvQVM1k5BHjIAfuil4Fn1p6rMGTmBmEtZT9TgDxgtPL jUr4al5ul8MCaJZtPzdYa05DBq5ExF.EQ12lqd5Kk6czIaRMgSTMFnO2BACK bLIAPQ3_BBLxcqO4HviuAFF1XcmSVg4cpcHlbiDY3Hkk40znFClhmNxk5HN9 kYmhK2lNbUppDG7O6A8tcvWD4cHnjowm4aA0PwA14rz8YiFeGJcJ2aPSG4DF RMlwjuL4UYYenyCt5AlLeNl44qsGa0LuxDPcWoLj2FeW4r4hdF4xODnnXTwJ qBKTy.T9le78FEad.uS6oIR.o9xlnjt10.RCXiVInqiPSRCx4o_Ml0vxhPFH Ch2oq_SEbL2zEmo1f0kxkTntFC6bKCEB79KzDndZBgQmvX0c0JeF2OgmslY8 XAVDK9jyw9J5xVqIQxDN0e_WFzIkaX3iFJJM1buv_U.it1LNKcwyNn.YUUQM kO3FRuK96OCHnPZ0e9x9TfhrbhmUbF5L1edPErYL9TCTaDvxC418k.7lSZMz dDQLMUDcBBKEO_MRmNrDyfbftZhGM__yEuZL_Cmm3S2FEW7ZlQU3QnWqGX9l diu2avjKuQJ95BVV6bfP2pBAOpE2yce.GKuJVpdhwc7_HbmZMD09pjSKGbga _QNMwa3I_G.zJ6KvxIjW06w74 Received: from [109.121.17.22] by web164604.mail.gq1.yahoo.com via HTTP; Fri, 14 Feb 2014 00:23:29 PST X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCAxMjo0MiBBTSwgRnJhbmNrIE1hcnRpbiA8ZnJhbmNrQHBlYWNoeW1hbmdvLm9yZz4gd3JvdGU6CgoKPiBUcmFuc2l0aXZlIHRydXN0IGlzIGhhcmQgdG8gaW1wbGVtZW50IGFuZCBES0lNIGNhbm5vdCBzaWduIHRoaXMgZmllbGQuCgp1bmRlbmlhYmxlLiBob3dldmVyLCB0aGF0J3Mgbm8gZGlmZmVyZW50IGZyb20gYW55IG90aGVyIHNpdHVhdGlvbiwgYW5kIGl0J3Mgbm90CkRNQVJDJ3MgZ29hbCB0byBhY2hpZXZlIGVtYWlsJ3MgYXV0aGVudGljaXR5IHZlcmkBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 References: <1392328933.63627.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1020249830.138100.1392334906832.JavaMail.zimbra@peachymango.org> Message-ID: <1392366209.11198.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 00:23:29 -0800 (PST) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <1020249830.138100.1392334906832.JavaMail.zimbra@peachymango.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/pO_4bnooI1bzoe-oa__UbP6bLu8 Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC 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, 14 Feb 2014 08:26:27 -0000 On Friday, February 14, 2014 12:42 AM, Franck Martin wrote:=0A=0A=0A> Transitive trust is hard to implement and DKIM cannot s= ign this field.=0A=0Aundeniable. however, that's no different from any othe= r situation, and it's not=0ADMARC's goal to achieve email's authenticity ve= rification. we would still rely=0Aon the same premises DKIM offers us, just= have a bit more useful data for=0Aevaluation, over what DMARC tells us.=0A= =0Aan SRS-enabled forwarder could still help receivers with high volume mor= e easily=0Adistinguish a particular forwarder for a trusted one, especially= if that's a low=0Avolume forwarder, knife's edge scenario, in which receiv= er doesn't know how to=0Aproceed exactly, cause of lack of sufficient data.= =0A=0Acase scenario:=0A1. DMARC-fully-enabled sender, SPF/SRS-enabled forwa= rder, doesn't break DKIM.=0A2. DMARC passes, based on DKIM.=0A3. SPF passes= , its alignment doesn't.=0A4. low lvl forwarder, no sufficient xp data to m= ake a reliable guess at receiver=0A=A0=A0 about email authenticity.=0A5. la= ck of data from public block lists, no reputation for the forwarder.=0A=0At= his is obviously a trusted forwarder, possibly one that forwards corporate= =0Aemail to a private account residing on a major mailbox provider, using f= ilters;=0Aor a similar scenario. i'm sure almost everybody here used someth= ing like that.=0A=0A=0A=0Amy case scenario is even more useful for receiver= s' email heuristics if DKIM=0Adoesn't survive forwarding, meaning DMARC fai= led, yet sender's DMARC policy is=0A"none". in this case, since forwarder u= sed SRS, we can easily discover it as=0Asuch, and help analyze its reliabil= ity.=0A=0Asurely, additional data SRS provides is more useful for receivers= evaluating=0Aa domain than having only an SPF fail info, on that lvl. and = DMARC spec could=0Ahelp deploying forwarding hosts realize that.=0A=0Aofc, = the value of even a small side-mention in a spec document is undeniable.=0A= =0A=0A=0Aps. no, i'm not lobbying for SRS devs. my connections to all this = are limited=0Ato user area. having used SRS to fix many such issues for cli= ents on hosting=0Aservices i admin, i came to realize we need more support = for SRS in developing=0Aspecs. hopefully some will agree and we can have a = productable discussion.=0A=0A=0A=0A-- =0AVlatko Salaj aka goodone=0Ahttp://= goodone.tk From nobody Fri Feb 14 02:04: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 BD1661A01CC for ; Fri, 14 Feb 2014 02:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 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.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBfpsnNraHKu for ; Fri, 14 Feb 2014 02:04:36 -0800 (PST) Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) by ietfa.amsl.com (Postfix) with ESMTP id 844D41A00F9 for ; Fri, 14 Feb 2014 02:04:35 -0800 (PST) Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 10:04:34 -0000 Received: from [98.138.101.132] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 10:01:50 -0000 Received: from [216.39.60.184] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 10:01:49 -0000 Received: from [98.137.12.238] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 10:01:49 -0000 Received: from [127.0.0.1] by omp1046.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 10:01:49 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 577277.6157.bm@omp1046.mail.gq1.yahoo.com Received: (qmail 58982 invoked by uid 60001); 14 Feb 2014 10:01:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392372109; bh=xycQ75UWBJtGw0sgrsK+kRAbFlOVqfb2JHazxyWcvFk=; 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=cO33iVuLVheTg2qsPTVrG0MAVImEtBpu0UFbz82tRjAnIzlfNphs+/R4LCCmmrWbggI2tGQqlk2kcPJHFySjDah5Tn6IGQFlPkqrQDlgu/qe7aoVBmbEFdX5ScvVxIkCLK7oDboJ4FF0yUGVMmj4v26Yx0Hl5iZ7hfEEgyI4/sc= 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=mdRLQ8oYsdO6Bso7IIt5fzFXMNyeHzvw7NEWRdHizxh3iRKg3aEnw0MFDMTEc3pVX/dplj+bIVdReQeD2ed+Fvdkkc0+hDkGXNKQPemp584bM4OWqE8e0PAmsiIUMK2XpMh82GRPq3ztbE4xB9DfsVPgibM0MoXDea0Ow8D1+Mk=; X-YMail-OSG: WZ9rZPkVM1nE8dCknxvYrnokqTd4ydlsRbfOnl5T2M.nv2U CmNSFBmsUemFOjDM.JmgDB3t.Gbhmo3UUpcqrLHztfkXVY2.7s.puH5_JqSb 7he9OiiW75D2pToBJ0tJv9x.DIt4A3NvwdQnaa4.e1vZT3XB2TI82HRoB5E. HLhTQ9YtRKDN8XGi82VZzodTrAB6DH4CeaRWEfnuz2bITCO6faOm7qf7jbAf LW9zJpXe8i8WRmAiVjpjN4zrIGuZ3eYPIeYRYahTP_2fX4GTUeF0sB989J5k EPiuK7R.7.LeplqtByOVLvx2CfbjU0.O3mqeYIDKP6vUBL3pxyqvCgZMIdDp bwBaomflozcksbXZRZdhW3TYEzEMuE.e6BPWFkWuZTNnpM1mrOjJ8hIFV5Ju qD8YT0hWpR9fyoFiyeQZMgPiVF55D_7VOJgpFRuJ6EpfKyi.1uBNdkzf.WiK hCaZR6rFh3A6pqzndk_Pb_ZNynW5NpUU2O4L7UDDEB9e.nH9NjnKrPCFdGAS Nkj5r7zYyaIwZtoHJ8AAi4meLn.54kg45AOYK7S37ckAjV5gCIvH5osSYe.f xFOJ9H_01uxXMjh9LkmKropKnx4L5qou3SgsM2GKPHx.O0NsNGG3BCOadvOf GUzYR.Vi4hf3QDMZ6l3rfEGXbu1MET0ExxK07waUYGKGWvhyfTg-- Received: from [109.121.17.22] by web164601.mail.gq1.yahoo.com via HTTP; Fri, 14 Feb 2014 02:01:49 PST X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA5OjI2IEFNLCAiZG1hcmMtcmVxdWVzdEBpZXRmLm9yZyIgPGRtYXJjLXJlcXVlc3RAaWV0Zi5vcmc.IHdyb3RlOgoKCj4gMS4gVGhhdCBhIGdpdmVuIElQIGFkZHJlc3MgaGFzIGEgc3Vic3RhbnRpYWwsIHN1c3RhaW5lZCBtZXNzYWdlIHZvbHVtZTsKwqAgbGFyZ2UgYW5kIHBlcnNpc3RlbnQgZW5vdWdoIHRvIHBlcmZvcm0gbWVhbmluZ2Z1bCBzdGF0aXN0aWNhbCBhbmFseXNpcyBvbi4KPiAyLiBUaGF0IHRoZSBjb21wbGFpbnQgcmF0ZSBmb3IgbWVzc2FnZXMBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 References: Message-ID: <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 02:01:49 -0800 (PST) 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/o-ismO6jTYrRfwFhJKJsc7BmgWU Subject: Re: [dmarc-ietf] dmarc Digest, Vol 11, Issue 8 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, 14 Feb 2014 10:04:40 -0000 On Friday, February 14, 2014 9:26 AM, "dmarc-request@ietf.org" wrote:=0A=0A=0A> 1. That a given IP address has a substantial,= sustained message volume;=0A=A0 large and persistent enough to perform mea= ningful statistical analysis on.=0A> 2. That the complaint rate for message= s from that IP address is=0A consistently=0A=A0 negligible.=0A> 3. T= hat messages from that address routinely fail authentication=0A from= a wide=0A=A0 range of domains that otherwise pass when they deliver direct= ly.=0A=0Athese heuristics don't account for a forwarder that fails on 2nd p= oint, which=0Ais quite frequent situation on shared hosting; nor do they ac= count for a=0Aforwarder failing on 1st point.=0A=0Ahowever, heuristics look= ing at SRS-enabled forwarder DMARC-enabled message would=0Asolve even such = scenarios.=0A=0A=0A> If you mean that the mere use of SRS by a sender could= usefully be=0A treated=0A> by a receiver as a signal that the sender is= reliable=0A=0Ano, i don't. even DMARC itself doesn't offer that.=0A=0A=0A>= if you trust someone to do=0A SRS honestly and competently then you can= probably=0A> exempt them from=0A DMARC processing anyway, meaning that = SRS adds nothing.=0A=0Ano. u use SRS heuristics to determine why SPF/DMARC = have failed in the 1st=0Aplace; so other way around. however, i'm not sugge= sting we should extend DMARC=0Aspec to include that. i do suggest we mentio= n it as a useful technique when=0Adeploying a forwarder meant to observe DM= ARC as much as possible, among other=0Athings.=0A=0A=0A>> given that main p= urpose of DMARC is to help major mailbox receivers identify=0A>> reliable e= mail from major email senders,=0A> Not quite; it's to help Domain Owners of= any size - not just major=0A ones - and=0A> receivers co-operate on kee= ping spoofed mail out of=0A inboxes.=0A=0Asure, in some ideal future whe= re every domain deploys DMARC. it doesn't do that=0Acurrently, and may neve= r, considering all DMARC failures as a protocol, and=0Areservation on its u= sefulness by many developers, thought as a mere trinket for=0Amajor domain = owners against phishing.=0A=0Anot that i have anything against another prot= ocol to help us fight such things.=0A=0Abut let's be realistic. DMARC, with= its reliance on "from:" field, is basically=0Abroken for most, but cleanes= t of message transaction paths, under which its=0Ausefulness remains in are= a of what i mentioned earlier, and mostly only that.=0A=0Apersonally, i nev= er saw a domain of a small company that has such a clean=0Amessage transact= ion path. i even keep getting errors from ietf.org itself, as=0Awell as iso= c.=0A=0ADMARC just adds more mess there. i'm trying to suggest something to= help combat=0Athat, while keeping specs as they are now.=0A=0A=0A>> imo, S= PF spec did fail to do that, for whatever reason, and maybe we should=0A>> = try not to miss such opportunity again.=0A> If you are implying that the ab= sence of SRS from the SPF spec is any=0A part of=0A> the reason for the = non-adoption of SRS by forwarders then=0A you are mistaken.=0A=0Aofc it = is, at least partly. if u provide no guidance on official specs, nobody=0Aw= ill deploy it. that's the main reason SRS isn't largely deployed on SPF-ena= bled=0Aforwarders. thry have no idea about it, and even if they do, softwar= e they use=0Adoesn't.=0A=0A=0A>> current draft does talk about ADSP quite a= bit, all while ADSP seems even=0A>> less relevant to DMARC than SRS.=0A> D= MARC is very close to ADSP=0A=0Aclose, but otherwise, technically, complete= ly irrelevant.=0A=0Aeven mentioning it is a junk data nobody should waste t= ime on while reading=0ADMARC spec. ADSP-centered text in DMARC draft is one= page length, and more,=0Aall while providing no useful information on=0A D= MARC deployment in any way,=0Abut instead moves topic to a protocol =0Apart= icipants SHOULD NOT use and which=0Ahas been made obsolete by it. waste of = spec space, imo.=0A=0Athat was my impression every time i reread the doc. i= t should be removed from=0Adraft, or replaced with a simple:=0A=0ADMARC doe= sn't use ADSP, and it is not recommended that participating entities=0Adepl= oy or account for ADSP. DMARC builds on ADSP capabilities and efficiently= =0Asurpasses it.=0A=0Aquite enough. maybe it would make more space to talk = about DMARC failures and=0Ahow to alleviate them.=0A=0A=0A-- =0A=0AVlatko S= alaj aka goodone=0Ahttp://goodone.tk From nobody Fri Feb 14 07:08: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 3A4EF1A027F for ; Fri, 14 Feb 2014 07:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_FAIL=0.001, SPF_HELO_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 VRK3-QmTDno4 for ; Fri, 14 Feb 2014 07:07:57 -0800 (PST) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id C6A201A0260 for ; Fri, 14 Feb 2014 07:07:54 -0800 (PST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 14 Feb 2014 16:07:51 +0100 Message-ID: <5D1E9A0348664A3DBB24D9E5228C3AC7@fgsr.local> From: "J. Gomez" To: References: <73b74863cd154ced9d3c155500e16af9@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> Date: Fri, 14 Feb 2014 16:07:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hgwfJXfayqCsaei7KVopiHUX4so Subject: Re: [dmarc-ietf] Known DMARC failures of legitimate email X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:07:59 -0000 From: Mike Jones > On Wed, Feb 5, 2014 at 3:43 PM, Terry Zink > wrote:=20 >=20 > We're currently building DMARC support and before we go live, I am > looking for some numbers around known cases of DMARC > quarantining/rejecting legitimate email. >=20 > So somewhere in the range of 1.4% - 4.8% of DMARC failures are due to > mailing lists. Again, this is for all DMARC failures, regardless of > the policy on the domain. So turning on DMARC would affect whatever > fraction of that % is coming from domains with a reject > policy/quarantine policy. Yes, but that pertcentage is the "percentage of messages affeced of = total email", not the "percentage affected users". I think the = percentage of affected users (those who use at least one mailing list, = even if seldom), is going to be higher than that. Regards, J.Gomez From nobody Fri Feb 14 07:24: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 A7A531A02AC for ; Fri, 14 Feb 2014 07:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lewI5oXI7n3j for ; Fri, 14 Feb 2014 07:24:07 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 562C91A02A6 for ; Fri, 14 Feb 2014 07:24:07 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id e4so577155wiv.11 for ; Fri, 14 Feb 2014 07:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m55UtlWJ8ILfGtCVrEchjRJzPmytL/HIwo3thX8fW+Y=; b=QFhHz03b0F3iunm7ZTZCDKjviP8KDbyY+mtbCk7fwofICLOEwvlr+xcSrqzdI3ZBcz VGQ7cnLc6Vc/Fb7Lp1ZLCAtdDKulp+xd8p5zA9hkIvOEvdxlGS9HQ2ODduilMKan3qQn MHtjsKuG3gDFwKI/HMCmWUa8ITbENZIoNwqaFuaAA2+yPhQ4xdwpqHz+CY2i/cyz2BEn 27vzAfnd+OCpH8SPW3h5Uz/4ZJrVmoGS6TIX2Nm1LfYWqMu2K0eS0DRKjojsjXbICmwf aW2Hu5MEGzDcxG/zddYBCmsxqVBQT1pfuvQYJrYy2PmmHdfMqcdTyBnLwmObjNUdFuP2 +inw== MIME-Version: 1.0 X-Received: by 10.194.173.163 with SMTP id bl3mr1883675wjc.73.1392391445116; Fri, 14 Feb 2014 07:24:05 -0800 (PST) Received: by 10.180.90.132 with HTTP; Fri, 14 Feb 2014 07:24:04 -0800 (PST) In-Reply-To: <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com> References: <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 07:24:04 -0800 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=089e013c6220797eef04f25f65f7 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/g7rZOTgfjSchk8JJz-eQIxvoVlQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] dmarc Digest, Vol 11, Issue 8 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:24:10 -0000 --089e013c6220797eef04f25f65f7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 14, 2014 at 2:01 AM, Vlatko Salaj wrote: > no. u use SRS heuristics to determine why SPF/DMARC have failed in the 1st > place; so other way around. however, i'm not suggesting we should extend > DMARC > spec to include that. i do suggest we mention it as a useful technique when > deploying a forwarder meant to observe DMARC as much as possible, among > other > things. > There's a bit of a slippery slope here, for two reasons: (1) If some sites implement SRS checking and others don't, then a sender gets a mixed experience when some receivers see the messages as failing DMARC while others don't. On the flipside, that might be true already even without SRS. (2) Nudging people in the direction of considering SRS suggests we should also start mentioning DKIM extensions that further complicate things, like the experimental ATPS. I'm not sure of the benefit. I think there are ample valid reasons why SRS has not been widely adopted to date, and it's been around as long as SPF has. I doubt the advent of DMARC is going to change any of that. but let's be realistic. DMARC, with its reliance on "from:" field, is > basically > broken for most, but cleanest of message transaction paths, under which its > usefulness remains in area of what i mentioned earlier, and mostly only > that. > > personally, i never saw a domain of a small company that has such a clean > message transaction path. i even keep getting errors from ietf.orgitself, as > well as isoc. > > DMARC just adds more mess there. i'm trying to suggest something to help > combat > that, while keeping specs as they are now. > The data I've seen suggest otherwise. If DKIM signatures are passing the vast majority of the time, which more than one party here has claimed, then the transaction paths (be they direct or indirect) aren't all that unclean. That goes for large and small senders and receivers alike. > > >> imo, SPF spec did fail to do that, for whatever reason, and maybe we > should > >> try not to miss such opportunity again. > > If you are implying that the absence of SRS from the SPF spec is any > part of > > the reason for the non-adoption of SRS by forwarders then > you are mistaken. > > ofc it is, at least partly. if u provide no guidance on official specs, > nobody > will deploy it. that's the main reason SRS isn't largely deployed on > SPF-enabled > forwarders. thry have no idea about it, and even if they do, software they > use > doesn't. > I'll go the other direction: I think including SRS as an even optional part of SPF would have hindered SPF adoption. Keeping them apart was absolutely the right move. > even mentioning it is a junk data nobody should waste time on while reading > DMARC spec. ADSP-centered text in DMARC draft is one page length, and more, > all while providing no useful information on > DMARC deployment in any way, > but instead moves topic to a protocol > participants SHOULD NOT use and which > has been made obsolete by it. waste of spec space, imo. > I don't agree here either. An obvious question that comes up when talking about DMARC, or any new work, is "What problem is this solving?", often followed by "But doesn't other-protocol-X, which already exists, already do that?" The text we have there answers the question. It's possible we could be more brief, but I don't agree that it's "no useful information" to the general reader. -MSK --089e013c6220797eef04f25f65f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 14, 2014 at 2:01 AM, Vlatko Salaj <vlat= ko.salaj@goodone.tk> wrote:
no. u use SRS heuristics to determine why SP= F/DMARC have failed in the 1st
place; so other way around. however, i'm not suggesting we should exten= d DMARC
spec to include that. i do suggest we mention it as a useful technique when=
deploying a forwarder meant to observe DMARC as much as possible, among oth= er
things.

There's a bit of a slippery= slope here, for two reasons:

(1) If some sites implement= SRS checking and others don't, then a sender gets a mixed experience w= hen some receivers see the messages as failing DMARC while others don't= .=A0 On the flipside, that might be true already even without SRS.

(2) Nudging people in the direction of considering SRS sugge= sts we should also start mentioning DKIM extensions that further complicate= things, like the experimental ATPS.=A0 I'm not sure of the benefit.
I think there are ample valid reasons why SRS has not been w= idely adopted to date, and it's been around as long as SPF has.=A0 I do= ubt the advent of DMARC is going to change any of that.

but let's be realistic. DMARC, with its reliance on "from:" f= ield, is basically
broken for most, but cleanest of message transaction paths, under which its=
usefulness remains in area of what i mentioned earlier, and mostly only tha= t.

personally, i never saw a domain of a small company that has such a clean message transaction path. i even keep getting errors from ietf.org itself, as
well as isoc.

DMARC just adds more mess there. i'm trying to suggest something to hel= p combat
that, while keeping specs as they are now.

<= div>The data I've seen suggest otherwise.=A0 If DKIM signatures are pas= sing the vast majority of the time, which more than one party here has clai= med, then the transaction paths (be they direct or indirect) aren't all= that unclean.=A0 That goes for large and small senders and receivers alike= .
=A0

>> imo, SPF spec did fail to do that, for whatever reason, and maybe = we should
>> try not to miss such opportunity again.
> If you are implying that the absence of SRS from the SPF spec is any =A0 =A0 part of
> the reason for the non-adoption of SRS by forwarders then
=A0 =A0 you are mistaken.

ofc it is, at least partly. if u provide no guidance on official specs, nob= ody
will deploy it. that's the main reason SRS isn't largely deployed o= n SPF-enabled
forwarders. thry have no idea about it, and even if they do, software they = use
doesn't.

I'll go the other dire= ction: I think including SRS as an even optional part of SPF would have hin= dered SPF adoption.=A0 Keeping them apart was absolutely the right move.

even mentioning it is a junk data nobody should waste time on while reading=
DMARC spec. ADSP-centered text in DMARC draft is one page length, and more,=
all while providing no useful information on
=A0DMARC deployment in any way,
but instead moves topic to a protocol
participants SHOULD NOT use and which
has been made obsolete by it. waste of spec space, imo.

I don't agree here either.=A0 An obvious question that= comes up when talking about DMARC, or any new work, is "What problem = is this solving?", often followed by "But doesn't other-proto= col-X, which already exists, already do that?"=A0 The text we have the= re answers the question.=A0 It's possible we could be more brief, but I= don't agree that it's "no useful information" to the gen= eral reader.

-MSK
--089e013c6220797eef04f25f65f7-- From nobody Fri Feb 14 07:32: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 26DFE1A02C1 for ; Fri, 14 Feb 2014 07:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcliORE_65T9 for ; Fri, 14 Feb 2014 07:32:27 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 56A421A026E for ; Fri, 14 Feb 2014 07:32:24 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hi5so611710wib.3 for ; Fri, 14 Feb 2014 07:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zYvUtp+z3XAOppUMs0WBw9OkKJspBDQoGvb3BGK6G60=; b=eN+Z9/akV8pQXy4DFUYi/GJFo6PIrIwK/NokjLWn651v6MUrbDt5I2ZpLz2/1ODBny CHvzq45su/1W6ttMea7eC7csulrGd2iAhxv2d2YxhLhu8KycVoBrW4SMLVQedzcptlyU bzEHijDThTZNKqsUHZcWXwOrw8MmlxF2pyD80J8ang5bfbhrgmFrWMUxdC79JRVgb4My JSNWi/swaqgbUQ/zE44cJ4uyKaoxbP+MndJoALK1zMgxf6+0vIJAmBWegWOBGlutpOAk TVCdfhawyd2WJ8Fx83uhU9DvYsfBNJqbQortvEtDeRGPH4OF7QocQ1oL1ffnXYr+KyDt 1i7Q== MIME-Version: 1.0 X-Received: by 10.180.12.233 with SMTP id b9mr2799913wic.8.1392391942391; Fri, 14 Feb 2014 07:32:22 -0800 (PST) Received: by 10.180.90.132 with HTTP; Fri, 14 Feb 2014 07:32:22 -0800 (PST) In-Reply-To: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> References: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 07:32:22 -0800 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=001a11c241141d519004f25f83a8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AwiGf2mKyUy9WNlHOqevXQ94HqE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:32:32 -0000 --001a11c241141d519004f25f83a8 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 13, 2014 at 1:04 AM, Vlatko Salaj wrote: > and yes, i'm aware SRS hasn't been standardized, but > mentioning it in dmarc specs may also help add some traction to > that, almost completely stable and functional, technique > of fixing some grief introduced by forwarders. > > > Has anyone in the SRS community expressed interest in seeking standardization? If it's in substantial, protracted use, then it probably should be published at least with Informational status. -MSK --001a11c241141d519004f25f83a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 13, 2014 at 1:04 AM, Vlatko Salaj <vlat= ko.salaj@goodone.tk> wrote:
and yes, i'm aware SRS hasn't been s= tandardized, but
mentioning it in dmarc specs may also help add some traction to
that, almost completely stable and functional, technique
of fixing some grief introduced by forwarders.



Has anyone in the SRS community ex= pressed interest in seeking standardization?=A0 If it's in substantial,= protracted use, then it probably should be published at least with Informa= tional status.

-MSK

--001a11c241141d519004f25f83a8-- From nobody Fri Feb 14 09:57: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 CF9581A02A3 for ; Fri, 14 Feb 2014 09:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 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.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR59m_71jcrb for ; Fri, 14 Feb 2014 09:56:58 -0800 (PST) Received: from nm44.bullet.mail.ne1.yahoo.com (nm44.bullet.mail.ne1.yahoo.com [98.138.120.51]) by ietfa.amsl.com (Postfix) with SMTP id CD7741A02BE for ; Fri, 14 Feb 2014 09:56:57 -0800 (PST) Received: from [127.0.0.1] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 17:56:56 -0000 Received: from [98.138.100.117] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 17:56:45 -0000 Received: from [98.137.12.58] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 17:56:45 -0000 Received: from [98.137.12.241] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 17:56:45 -0000 Received: from [127.0.0.1] by omp1049.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 17:56:45 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 314440.79796.bm@omp1049.mail.gq1.yahoo.com Received: (qmail 58159 invoked by uid 60001); 14 Feb 2014 17:56:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392400605; bh=cgzzQNyiMG8q9GPLiZ3Qmfua2xe6H9aLAbPK/y/ilns=; 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=2iMOVHUY0qjzdmmTGUXrYAIgu03bzayTA4qw36b2QME1M56BUxJj059kioq1VTfUaeBhjFehc9xoUbFA1kiPxcBxjqA2DKOa3RYji5Kj2Fdmdb8P3Wg3DSAjhuw8Rit/TD0vD3KqfLQgLQFRLfzuo+lxNvKNVjBE19IVTYs8ttE= 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=2uOTF1/a/NwU88zGBsHZ2i/MFGuGkGdrzUjj8RQ5pa97vV+s4QSORG+4EEZg9xI8SFHRRYJCB9gLytW1/qVP11LaHLQJ0mkF2tL5Vts+OGRrGbKxWgunI25idxt01W0sLuBFB9hkzCOkulJNPTbXE1DaWj7cOWFzG8/Tn3cBOq0=; X-YMail-OSG: LMfDzBUVM1mmCk3jGqgPrkE3RadnRbxCCe.iq3m7k9ehocX WAtU4uazOizTRdMcVOrhhorLFbFmPB_M89deJCPKk6r80izWmWKtJNL2gTyq l6FyCwCQ7yYleAUt9EaIJ_iBoJ_oI1y1CU23pGhALs3MA6PzduZmvBkIxYqb Cs5rPeOBUiFWn25UjoHbJntXhVq_kC1nLxDKqI1NmcS9cyENpNoDMxR8o5HR 7syBuK_nu8ARnv20iXL01KCxN5yI2omS62G6INt_TpaigufRrKONxzYxyrJc DwSkOHsvYPsnHvCjW7SopKZFz0vVprWux1wZ6iSLkqL4qY8cvPGZt37jtyix CyMk4HD4sbrgadWYe3GUz5tOO7eTS_mpgjkJRTqu1DsXtdEVWAji9jHF_q7n qnQDsV9pOGXMx2JVFIQqj_FW3a2iGQoN0C5Zizvs6UCYOcFqOHyqkJ9AVeBg c33t.Rt6KxNyVtLs4WoMYXn0Aj.Yqa37kyNhHWx9F8V_Dx1LqWZzKcI52Jpz Ib_MA8wAS7tAw0tH1cRE6ISUvbiV2Se1GrQfpZEDuErWeJvJm5yV9Ty10b7P 9hAmxsw1gZg1QBw5HBhU8OUoblm8D7qFUucpH5VeqDZr6HVvbmH4h2fBudc0 inTDD9o3U Received: from [109.121.17.22] by web164605.mail.gq1.yahoo.com via HTTP; Fri, 14 Feb 2014 09:56:45 PST X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA0OjMyIFBNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPiB3cm90ZToKCgo.IEhhcyBhbnlvbmUgaW4gdGhlIFNSUyBjb21tdW5pdHkgZXhwcmVzc2VkIGludGVyZXN0IGluIHNlZWtpbmcgCnN0YW5kYXJkaXphdGlvbj8KPiBpdCdzIGluIHN1YnN0YW50aWFsLCBwcm90cmFjdGVkIHVzZSwgdGhlbiBpdCAKcHJvYmFibHkgc2hvdWxkIGJlIHB1Ymxpc2hlZCBhdAo.IGxlYXN0IHdpdGggSW5mb3JtYXRpb25hbCBzdGF0dXMuCgp0aGUBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 References: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> Message-ID: <1392400605.97311.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 09:56:45 -0800 (PST) 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/MCA95b07qJF0hayMzVb0F1b4pQE Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC 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, 14 Feb 2014 17:57:01 -0000 On Friday, February 14, 2014 4:32 PM, Murray S. Kucherawy wrote: > Has anyone in the SRS community expressed interest in seeking standardization? > it's in substantial, protracted use, then it probably should be published at > least with Informational status. there has been many calls for that over the years, but nobody bothered enough, mostly cause SRS was left out of SPF, asaik. it was, mainly, developed as a pair of SPF/SRS combo, at least until microsoft came in. some bad blood during SPF development, microsoft sender id crap and eventually it was all left separated, having ppl who run forwarders maintain SRS on their own. however, since sender id never came to life, at least not as imagined, SPF spec was left broken for forwarders. i guess having someone heavily involved in ietf nudge them about it could prove useful into pushing towards standardization. SRS is quite useful for shared hosting with forwarding capabilities enabled, which is, almost, every single cpanel deployment out there. so, standardization would be quite nice; at least, i wouldn't have to spend time explaining hosting providers from my client's isps how and why to enable SRS in their cpanel deployments to solve issues with lost email, instead pointing them to rfc doc. however, waking those SRS ppl up may rly require some authority figure. they are, kind of, happy with their protocol, and its stability and usage. do try, if u wish. at least i will be grateful. :) -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Feb 14 10:56: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 AE1761A0267 for ; Fri, 14 Feb 2014 10:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7qGE7UlQk69 for ; Fri, 14 Feb 2014 10:56:42 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5915B1A02D0 for ; Fri, 14 Feb 2014 10:56:42 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id n12so692913wgh.30 for ; Fri, 14 Feb 2014 10:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=51ab9RfKMCsU0PPHrLarIO14zrTXeCnBBy7jYAciZ5E=; b=iDTzJ/lMeLjTPAAADRHki6II6kgBfZt28w46xg+u6+R32yYiDu7VIgXAlcmrGX6ct0 XMyc+cWrGTI+Dj8ksAQVjZEmlaNXed0kOuvENicLaYftrebAW5xeWoLDr+m5siRkRybF r9WTEmgZi1MdFy998xq7Q+tqqVPo3KAR9F7V97AoRVVsR5YrKStY5VvbrovRBxRMwQbA Cea4ZRNZoc33jcuQDSznOw6W05plb1Vs//aIiGmKGLde4b0P/9ZTVLiUXeLQfqG1Z1u8 4fZIBjT6XfMP9hufcrneOSNyagHf7kE0aJZ89VoFIkEMj7+mSeJnnz1+afFXzY6I9i06 jwyg== MIME-Version: 1.0 X-Received: by 10.180.97.72 with SMTP id dy8mr3523428wib.5.1392404200257; Fri, 14 Feb 2014 10:56:40 -0800 (PST) Received: by 10.180.90.132 with HTTP; Fri, 14 Feb 2014 10:56:40 -0800 (PST) In-Reply-To: <1392400605.97311.YahooMailNeo@web164605.mail.gq1.yahoo.com> References: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1392400605.97311.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 10:56:40 -0800 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=f46d04430670bd7e4404f2625df1 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/RW5rEcpxKGgWa8lCdslpzrvVJZg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:56:44 -0000 --f46d04430670bd7e4404f2625df1 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 14, 2014 at 9:56 AM, Vlatko Salaj wrote: > however, waking those SRS ppl up may rly require some authority figure. > they are, > kind of, happy with their protocol, and its stability and usage. do try, > if u > wish. at least i will be grateful. :)= > It's kind of telling, to me at least, when a community doesn't feel like putting the energy into pushing their own work toward standardization. It would be far better for DMARC to be able to point at a stable reference for SRS, assuming the DMARC community wants to include such a reference. But that's about the extent of the motivation I can really provide, since I've never encountered SRS in production. -MSK --f46d04430670bd7e4404f2625df1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 14, 2014 at 9:56 AM, Vlatko Salaj <vlat= ko.salaj@goodone.tk> wrote:
however, waking those SRS ppl up may rly req= uire some authority figure. they are,
kind of, happy with their protocol, and its stability and usage. do try, if= u
wish. at least i will be grateful. :)=3D

It's kind of telling, to me at least, when a community doesn't fe= el like putting the energy into pushing their own work toward standardizati= on.

It would be far better for DMARC to be able to point at a stable refere= nce for SRS, assuming the DMARC community wants to include such a reference= .=A0 But that's about the extent of the motivation I can really provide= , since I've never encountered SRS in production.

-MSK

--f46d04430670bd7e4404f2625df1-- From nobody Fri Feb 14 11:00: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 29D5D1A02F6 for ; Fri, 14 Feb 2014 11:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJXlRVuTYk7V for ; Fri, 14 Feb 2014 11:00:26 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 311AB1A02D0 for ; Fri, 14 Feb 2014 11:00:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 60697398936; Fri, 14 Feb 2014 13:00:23 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITo6BGfGmXo4; Fri, 14 Feb 2014 13:00:23 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 92E1939898F; Fri, 14 Feb 2014 13:00:22 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 73F23398981; Fri, 14 Feb 2014 13:00:22 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iiH6pF_apmSR; Fri, 14 Feb 2014 13:00:22 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 26E773989A4; Fri, 14 Feb 2014 13:00:05 -0600 (CST) Date: Fri, 14 Feb 2014 13:00:03 -0600 (CST) From: Franck Martin To: Vlatko Salaj Message-ID: <1623205664.157481.1392404403695.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1392328933.63627.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1020249830.138100.1392334906832.JavaMail.zimbra@peachymango.org> <1392366209.11198.YahooMailNeo@web164604.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 - FF27 (Mac)/8.0.5_GA_5839) Thread-Topic: SRS helps SPF/DMARC Thread-Index: OwTSuAEDmCaf9mXYyqR8Eb2PwjSeMA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kvqylWuVkV8Q-EDj9DzUS5CDonU Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:00:33 -0000 ----- Original Message ----- > From: "Vlatko Salaj" > To: dmarc@ietf.org > Sent: Friday, February 14, 2014 12:23:29 AM > Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC > > On Friday, February 14, 2014 12:42 AM, Franck Martin > wrote: > > > > Transitive trust is hard to implement and DKIM cannot sign this field. > > undeniable. however, that's no different from any other situation, and it's > not > DMARC's goal to achieve email's authenticity verification. we would still > rely > on the same premises DKIM offers us, just have a bit more useful data for > evaluation, over what DMARC tells us. > I kind of see your point, and yes it could be used to detect good forwarders and therefore provide a mechanism for the DMARC overwrite "forwarder". However, like for the other policy overrides in DMARC, I don't think we want to standardize any of this, and this is more a capability for the receiver to alleviate certain peculiar situations. I think DMARC aim is to be as binary as possible for the receiver, with no exception, removing the guess work that weakened SPF policy part. So we are looking at the hard work here which is: if a forwarder breaks DKIM, then it should fix their infrastructure to not break DKIM (changing charset, encoding, converting the email to an internal format and then back to an Internet format,...) Saying that, mailing list is different because of the end user visible modifications in the message. From nobody Fri Feb 14 11:06: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 5FBA81A02AF for ; Fri, 14 Feb 2014 11:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5p6kLLXinSv for ; Fri, 14 Feb 2014 11:05:53 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 840FE1A030A for ; Fri, 14 Feb 2014 11:05:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 22A2B29C24D; Fri, 14 Feb 2014 13:05:47 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nr3KIdMPGhfC; Fri, 14 Feb 2014 13:05:47 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0539729C226; Fri, 14 Feb 2014 13:05:47 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id DD81129C24D; Fri, 14 Feb 2014 13:05:46 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BBoVLkWfdnzM; Fri, 14 Feb 2014 13:05:46 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id A964429C226; Fri, 14 Feb 2014 13:05:46 -0600 (CST) Date: Fri, 14 Feb 2014 13:05:46 -0600 (CST) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1727112676.157637.1392404746485.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1392400605.97311.YahooMailNeo@web164605.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_157636_1879901620.1392404746484" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF27 (Mac)/8.0.5_GA_5839) Thread-Topic: SRS helps SPF/DMARC Thread-Index: oXVGTd9Jn9UavlTq4rC43NY4vlEU3w== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/igZ_rvU8YigxH01RHx16xh_j_ow Cc: Vlatko Salaj , dmarc@ietf.org Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:05:56 -0000 ------=_Part_157636_1879901620.1392404746484 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Vlatko Salaj" > Cc: dmarc@ietf.org > Sent: Friday, February 14, 2014 10:56:40 AM > Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC > On Fri, Feb 14, 2014 at 9:56 AM, Vlatko Salaj < vlatko.salaj@goodone.tk > > wrote: > > however, waking those SRS ppl up may rly require some authority figure. > > they > > are, > > > kind of, happy with their protocol, and its stability and usage. do try, if > > u > > > wish. at least i will be grateful. :)= > > It's kind of telling, to me at least, when a community doesn't feel like > putting the energy into pushing their own work toward standardization. > It would be far better for DMARC to be able to point at a stable reference > for SRS, assuming the DMARC community wants to include such a reference. But > that's about the extent of the motivation I can really provide, since I've > never encountered SRS in production. Vlatko, If I'm not mistaken, even if you did not create SRS, if the Intellectual property does not restrict you, you can submit an Internet-Draft and then additional IETF work can reference this Internet Draft. This is the first bar that needs to be passed now. ------=_Part_157636_1879901620.1392404746484 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Vlatko Salaj" <vlatko.salaj@goodone.tk><= br>Cc: dmarc@ietf.org
Sent: Friday, February 14, 2014 10:5= 6:40 AM
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
On Fri, Feb 14, 2014 at 9:56 AM, Vlatko Salaj <vlatko.salaj@goodone.tk> wrote:
however, waki= ng those SRS ppl up may rly require some authority figure. they are,
kind of, happy with their protocol, and its stability and usage. do try, if= u
wish. at least i will be grateful. :)=3D

It's kind of telling, to me at least, when a community doesn't feel like = putting the energy into pushing their own work toward standardization.
<= br>It would be far better for DMARC to be able to point at a stable referen= ce for SRS, assuming the DMARC community wants to include such a reference.=   But that's about the extent of the motivation I can really provide, = since I've never encountered SRS in production.
=
Vlatko,

If I'm not mistaken,= even if you did not create SRS, if the Intellectual property does not rest= rict you, you can submit an Internet-Draft and then additional IETF work ca= n reference this Internet Draft. This is the first bar that needs to be pas= sed now.
------=_Part_157636_1879901620.1392404746484-- From nobody Fri Feb 14 11:17: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 493061A0068 for ; Fri, 14 Feb 2014 11:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 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.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOk8bBwfMLt6 for ; Fri, 14 Feb 2014 11:17:40 -0800 (PST) Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) by ietfa.amsl.com (Postfix) with ESMTP id 46B181A02D0 for ; Fri, 14 Feb 2014 11:17:36 -0800 (PST) Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 19:17:34 -0000 Received: from [98.138.100.117] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 19:14:50 -0000 Received: from [98.137.12.190] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 19:14:50 -0000 Received: from [98.137.12.242] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 19:14:50 -0000 Received: from [127.0.0.1] by omp1050.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 19:14:49 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 991741.16215.bm@omp1050.mail.gq1.yahoo.com Received: (qmail 67777 invoked by uid 60001); 14 Feb 2014 19:14:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392405289; bh=QK57Cdnbg8vX1im47NY6n8ZtomkzC+MtZzKmMP8NVi0=; 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=xbC1L1E/EbJHvvq7v5bpTfZiPXzzVQp4u2PIx1ICFXFsogGlU1dVx+HgpSMqDr0gS/yuqDhfgCPxGcFTJW8mf9OQuqDWr4xn/pVo54s3dk0yrHyaTQSXGWIYHrwqBXJPG5DjGf281ZNqKcI7FB7A9WmO+8mdMw6lLLr1wyx9OEg= 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=SJRmzqxtEJpcAGQnPbgnSlsDzUgYu07RZyMo7u/Bd1R92WaFww5FIjqom8Z2fUP9eh9vUxNc9e7nnityJIUdZ+Ny1jVh8iU44Ui0+oyd0WjPpB/kJLnGtm/+xpDRSepu9CdZFfGN8PZCgs2GgQFChkrQ1Q82FWi2S+88tX8LfJ4=; X-YMail-OSG: efJj.zsVM1ncW1TAvGBXKw5UqPkucrCWTL.DMIBtzbjV92y c_RT9W1WSwIN1MmQPY9SHV2Dk9g7a6KDq8RG.VuJ3b4o3OZkoalyCWdeqHRR bThl2s7w0ZgaLmDCBmNkT9ycMVj89RPgx7pouIscO11OIMpHwT8qfedCVEBa sU_vbzuD2TcUfryfFV94qUCb8VbqqTgRl88Wigq9soAE8AADs7Vfq2n.9yoQ WXCx3xs.bEnSVF40BTgx8UGxScU.vGIUnaEIqxyYUPrgC_ArHtfhr6zX4yT1 53kHzE8Q.rygxkSj9yOtqn69ML0YwiJ79xHtcopYWS2K3voFfyY9Tqi2HqGM 4gjcgugncdGCiJPPrqOv5hc7DFVggrI_Iq3PXFEl6JEBLV_F6hrm4yxGllUO a3LM1Nmd2JmPp3GGPS.d0ReX9cEaEKTO3WbrM1N7zGmxG2dwddRdmfgnl5QT u5vnVMm.0K5.BQvPLVnzzOibu_ZLuAZ6ITvg8M9vlKzZmiBGOCGP4FM9yJuv 5psirtkmJQemvSAe_QrNIv39MPZCB0SYH.Z85pLxf6Sor4FmQodaF0xOGqva .FyD21pIhfUbV37dtsPp_PKRssrit58J7GoeEL1aWMAquqsHfYq.QQNCbiVF LiLkPcnaF Received: from [109.121.17.22] by web164605.mail.gq1.yahoo.com via HTTP; Fri, 14 Feb 2014 11:14:49 PST X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA0OjI0IFBNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPiB3cm90ZToKCgo.ICgyKSBOdWRnaW5nIHBlb3BsZSBpbiB0aGUgZGlyZWN0aW9uIG9mIGNvbnNpZGVyaW5nIFNSUyBzdWdnZXN0cyB3ZSBzaG91bGQgYWxzbwo.IHN0YXJ0IG1lbnRpb25pbmcgREtJTSBleHRlbnNpb25zIHRoYXQgZnVydGhlciBjb21wbGljYXRlIHRoaW5ncywgbGlrZSB0aGUKPiBleHBlcmltZW50YWwgQVRQUy4gSSdtIG5vdCBzdXJlIG9mIHRoZSBiZW4BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 References: <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com> Message-ID: <1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 11:14:49 -0800 (PST) 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/fsPKsC3NfynKZ-K3Nk5NqxqAHv8 Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC 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, 14 Feb 2014 19:17:48 -0000 On Friday, February 14, 2014 4:24 PM, Murray S. Kucherawy wrote:=0A=0A=0A> (2) Nudging people in the direction of considering SR= S suggests we should also=0A> start mentioning DKIM extensions that further= complicate things, like the=0A> experimental ATPS. I'm not sure of the ben= efit.=0A=0AATSP solves another scenario, and has little to no connection to= DMARC. one can=0Ause it with DMARC or not, changes little.=0A=0Aon the oth= er hand, SRS solves situations in which a domain owner is forced to=0Ause "= none" DMARC policy cause its messages go through forwarders. a situation=0A= which basically trashes all benefits DMARC, SPF and DKIM provide for such d= omain.=0A=0Aif forwarders have SRS enabled, such domain owner would at leas= t be able to rely=0Aon SPF evaluation on receivers' side, which would pass,= even if DMARC doesn't.=0A=0Athat's why this problem is connected to DMARC.= protocol as it is creates=0Aadditional mess for forwarders, but suggests n= o proper solution in any way.=0A=0ADMARC draft should include such info, wh= atever it is. and SRS is such info.=0A=0Aalso, SRS is not alone. mentioning= , for example, that mailing list providers=0Ashould do their best not to br= eak DKIM in their processing should also be added=0Aas guidance in DMARC sp= ecs. and i'm sure there are some other suggestions=0Afor solving DMARC inef= ficiencies that should go into this category too.=0A=0Aif u waste so much d= raft space to compare DMARC to ADSP, it's reasonable to=0Ainclude at least = some info on dealing with grief DMARC requirements would=0Aintroduce in the= email world.=0A=0A=0A>> but let's be realistic. DMARC, with its reliance o= n "from:" field, is=0A>> basically broken for most, but cleanest of message= transaction paths,=0A> The data I've seen suggest otherwise.=A0 If DKIM si= gnatures are passing the vast=0A> majority of the time, which more than one= party here has claimed, then the=0A> transaction paths (be they direct or = indirect) aren't all that unclean.=0A> That goes for large and small sender= s and receivers alike.=0A=0Ai'm not sure that goes for all types of senders= . i didn't see any DKIM stats=0Athat actually try do differentiate between = major senders, like fb, paypal=0Aand small senders like millions of compani= es running on cpanel shared hosts.=0A=0Ahowever, stats about DKIM signature= s say nothing about DKIM DMARC alignment,=0Awhich numbers are probably quit= e lower. so, even if DKIM is saved, alignments?=0A=0A=0A> I'll go the other= direction: I think including SRS as an even optional part=0A> of SPF would= have hindered SPF adoption. Keeping them apart was absolutely the=0A> righ= t move.=0A=0Ahow so? considering SRS is required by, and only by, forwarder= s... i see little=0Areason for SPF adoption to be affected.=0A=0Abut, we wi= ll never know, will we? actually, if SPF wasn't so broken by=0Aforwarders i= n the 1st place, maybe we would have no need for DKIM or DMARC now.=0Abut t= hat's what you get when you have microsoft involved into specs discussion.= =0Aat least back then.=0A=0A=0A>> ADSP-centered text in DMARC draft is one = page length, and more, all while=0A>> providing no useful information on DM= ARC deployment in any way, but instead=0A>> moves topic to a protocol parti= cipants SHOULD NOT use and which has been=0A>> made obsolete by it. waste o= f spec space, imo.=0A> It's possible we could be more brief=0A=0Ai'm quite = sure many ppl would be quite thankful for that.=0A=0A=0A-- =0AVlatko Salaj = aka goodone=0Ahttp://goodone.tk From nobody Fri Feb 14 11:36:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456A91A02F2 for ; Fri, 14 Feb 2014 11:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTtSvvqkrdmi for ; Fri, 14 Feb 2014 11:36:08 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id A83741A02AF for ; Fri, 14 Feb 2014 11:36:07 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id f8so802698wiw.15 for ; Fri, 14 Feb 2014 11:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tpj/09Klo0pVKZUIlYd2d4EEvsYXVKyQ8g3asGXNNUo=; b=MUb+MWeMLxb/1Oj5rqxVhnrvFwr9CdGX0egTska3w0gGsy3z8iIhXx5fWk/xIFkx7J zJ8EostYqAUhuepUD6vOhWRNOGdrwUdKCH7evuQqLEV9cFisXGZJgDqc/cKZUYPcfv/7 Ak2XWa6XDug8sqYGZ4t/dto2w2WAo14Zk2fNJj0XgNILpN9XsXW1IAb96Z5DPrHWraDd 23YyAMFv/fGcQR3h7vmzDvqDk/SaMXek0CoBh/KekW8cY0smScoGIEoGPYQpFmoWizzs K2xUjM0Rdqnyui8IzFNhectz5I9ccvB9yKG0Xbzq8GiaueE+zPU0oaubZ5ZCXKr+seg7 WE8g== MIME-Version: 1.0 X-Received: by 10.194.240.7 with SMTP id vw7mr14345wjc.75.1392406565635; Fri, 14 Feb 2014 11:36:05 -0800 (PST) Received: by 10.180.90.132 with HTTP; Fri, 14 Feb 2014 11:36:05 -0800 (PST) In-Reply-To: <1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com> References: <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 11:36:05 -0800 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=001a11c1b3ceba4d7104f262ea2e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/yFZ98CTh-C5XN-lGZYH_f1TpZuI Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 19:36:12 -0000 --001a11c1b3ceba4d7104f262ea2e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 14, 2014 at 11:14 AM, Vlatko Salaj wrote: > > (2) Nudging people in the direction of considering SRS suggests we > should also > > start mentioning DKIM extensions that further complicate things, like the > > experimental ATPS. I'm not sure of the benefit. > > ATSP solves another scenario, and has little to no connection to DMARC. > one can > use it with DMARC or not, changes little. > I think they solve different scenarios, but both are arguably important to some sub-community of the email world. In that sense, they look the same to me. It may not be that ATPS solves any of your problems, but the ATPS community (small as it is) can similarly say that SRS doesn't solve theirs. on the other hand, SRS solves situations in which a domain owner is forced > to > use "none" DMARC policy cause its messages go through forwarders. a > situation > which basically trashes all benefits DMARC, SPF and DKIM provide for such > domain. > ATPS solves situations in which the domain owner is forced to use "none" DMARC policy because its messages are signed by third-parties, a situation which basically trashes all benefits DMARC, SPF and DKIM provide for such a domain. :-) > DMARC draft should include such info, whatever it is. and SRS is such info. > So the same argument could be made for ATPS, or any other logic that augments the core of what DKIM provides. And ATPS has the advantage of being documented in an RFC. > also, SRS is not alone. mentioning, for example, that mailing list > providers > should do their best not to break DKIM in their processing should also be > added > as guidance in DMARC specs. and i'm sure there are some other suggestions > for solving DMARC inefficiencies that should go into this category too. > A lot of this is written down in RFC6377, at least as it pertains to DKIM. Perhaps DMARC should reference that as well. > if u waste so much draft space to compare DMARC to ADSP, it's reasonable to > include at least some info on dealing with grief DMARC requirements would > introduce in the email world. > I get that you think this is wasted space. Does anyone else concur? Does someone want to propose simpler text to replace what's there? i'm not sure that goes for all types of senders. i didn't see any DKIM stats > that actually try do differentiate between major senders, like fb, paypal > and small senders like millions of companies running on cpanel shared > hosts. > The statistics OpenDKIM collects at http://www.opendkim.org/stats/report.html#passfail don't include feeds from any major receivers, but rather a few smaller ones. It still concurs with the general anecdotal data of an over 90% pass rate. If you have statistics to the contrary, I'm sure we'd love to see them. however, stats about DKIM signatures say nothing about DKIM DMARC alignment, > which numbers are probably quite lower. so, even if DKIM is saved, > alignments? > Wouldn't that be visible in the DMARC aggregate reports? > > I'll go the other direction: I think including SRS as an even optional > part > > of SPF would have hindered SPF adoption. Keeping them apart was > absolutely the > > right move. > > how so? considering SRS is required by, and only by, forwarders... i see > little > reason for SPF adoption to be affected. > My recollection of most of the SPF and IETF community at the time was that SRS didn't get a favorable reaction. It was seen as ugly and the problem space was not large enough to warrant the added complexity. Including it in what became RFC4408 wouldn't have done it any favors. > but, we will never know, will we? actually, if SPF wasn't so broken by > forwarders in the 1st place, maybe we would have no need for DKIM or DMARC > now. > but that's what you get when you have microsoft involved into specs > discussion. > at least back then. > SPF has not been around as long as forwarders have been, so I think making the argument that this is forwarders' fault is a bit silly. I also think casting blame for past problems isn't going to help here. We need to focus on moving forward from where we are now. > > It's possible we could be more brief > > i'm quite sure many ppl would be quite thankful for that. > > I saw that you proposed some brief text to replace what's there. What do others think? -MSK --001a11c1b3ceba4d7104f262ea2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 14, 2014 at 11:14 AM, Vlatko Salaj <v= latko.salaj@goodone.tk> wrote:
=
> (2) Nudging people i= n the direction of considering SRS suggests we should also
> start mentioning DKIM extensions that further complicate things, like = the
> experimental ATPS. I'm not sure of the benefit.

ATSP solves another scenario, and has little to no connection to DMARC. one= can
use it with DMARC or not, changes little.

I think they solve different scenarios, but both are arguably important = to some sub-community of the email world.=A0 In that sense, they look the s= ame to me.=A0 It may not be that ATPS solves any of your problems, but the = ATPS community (small as it is) can similarly say that SRS doesn't solv= e theirs.

on the other hand, SRS solves situations in which a domain owner is forced = to
use "none" DMARC policy cause its messages go through forwarders.= a situation
which basically trashes all benefits DMARC, SPF and DKIM provide for such d= omain.

ATPS solves situations in which = the domain owner is forced to use "none" DMARC policy because its= messages are signed by third-parties, a situation which basically trashes = all benefits DMARC, SPF and DKIM provide for such a domain.=A0 :-)
=A0
DMARC draft should include such info, whatever it is. and SRS is such info.=

So the same argument could be made for= ATPS, or any other logic that augments the core of what DKIM provides.=A0 = And ATPS has the advantage of being documented in an RFC.
=A0
also, SRS is not alone. mentioning, for example, that mailing list provider= s
should do their best not to break DKIM in their processing should also be a= dded
as guidance in DMARC specs. and i'm sure there are some other suggestio= ns
for solving DMARC inefficiencies that should go into this category too.
=

A lot of this is written down in RFC6377, = at least as it pertains to DKIM.=A0 Perhaps DMARC should reference that as = well.
=A0
if u waste so much draft space to compare DMARC to ADSP, it's reasonabl= e to
include at least some info on dealing with grief DMARC requirements would introduce in the email world.

I get tha= t you think this is wasted space.=A0 Does anyone else concur?=A0 Does someo= ne want to propose simpler text to replace what's there?

i'm not sure that goes for all types of senders. i didn't see any D= KIM stats
that actually try do differentiate between major senders, like fb, paypal and small senders like millions of companies running on cpanel shared hosts= .

The statistics OpenD= KIM collects at http://www.opendkim.org/stats/report.html#passfail don't includ= e feeds from any major receivers, but rather a few smaller ones.=A0 It stil= l concurs with the general anecdotal data of an over 90% pass rate.=A0 If y= ou have statistics to the contrary, I'm sure we'd love to see them.=

however, stats about DKIM signatures say nothing about DKIM DMARC alignment= ,
which numbers are probably quite lower. so, even if DKIM is saved, alignmen= ts?

Wouldn't that be visible in the= DMARC aggregate reports?
=A0
> I'll go the other direction: I think including SRS as an even opti= onal part
> of SPF would have hindered SPF adoption. Keeping them apart was absolu= tely the
> right move.

how so? considering SRS is required by, and only by, forwarders... i see li= ttle
reason for SPF adoption to be affected.

My recollection of most of the SPF and IETF community at the time was that= SRS didn't get a favorable reaction.=A0 It was seen as ugly and the pr= oblem space was not large enough to warrant the added complexity.=A0 Includ= ing it in what became RFC4408 wouldn't have done it any favors.
=A0
but, we will never know, will we? actually, if SPF wasn't so broken by<= br> forwarders in the 1st place, maybe we would have no need for DKIM or DMARC = now.
but that's what you get when you have microsoft involved into specs dis= cussion.
at least back then.

SPF has not been ar= ound as long as forwarders have been, so I think making the argument that t= his is forwarders' fault is a bit silly.=A0 I also think casting blame = for past problems isn't going to help here.=A0 We need to focus on movi= ng forward from where we are now.
=A0
> It's possible we could be more brief

i'm quite sure many ppl would be quite thankful for that.


I saw that you= proposed some brief text to replace what's there.=A0 What do others th= ink?

-MSK

--001a11c1b3ceba4d7104f262ea2e-- From nobody Fri Feb 14 11:57: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 4C1FB1A02F7 for ; Fri, 14 Feb 2014 11:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 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.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cj9YXGpB_SJ for ; Fri, 14 Feb 2014 11:57:20 -0800 (PST) Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) by ietfa.amsl.com (Postfix) with ESMTP id 2D97A1A02AF for ; Fri, 14 Feb 2014 11:57:18 -0800 (PST) Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 19:57:17 -0000 Received: from [98.138.100.112] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 19:54:18 -0000 Received: from [98.137.12.55] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 19:54:18 -0000 Received: from [98.137.12.247] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 19:54:18 -0000 Received: from [127.0.0.1] by omp1055.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 19:54:18 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 35859.29343.bm@omp1055.mail.gq1.yahoo.com Received: (qmail 66853 invoked by uid 60001); 14 Feb 2014 19:54:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392407657; bh=wEAkSMqQGHAycOJ4SCzF3w0IrKWmQvg/bZDvg9G0tVw=; 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=T7EaAExHSsXrUL3xysFXnzw2eRJdsjVckb8R7nqDAJcUeVQUKsbR1nBTXe8sAreVwOhhW8N1lujDkXtzPATWgZltsAunjfxMp4KjKuuZj4ooMb7CV7oKtnhff6+kV4hBw4+L69eYnMqref8NX9CgMek+Swe4rkdrFHOdj9tqJZc= 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=D6pc5DhnczQP8u5rPpiAmRE0sGOC+ywnr6nHpfHoyWKy3BwH8bSax2y9B8mw0dL4fV5w47Igqgp5/WU+45zwAZ7OVrdHMcnzZXIVmqwdrSNU5dkNjJYwTSaQyVdnr54BYz0VJiBXYInzkJyno3gWYD94CdpVxegg3NXsXChojKM=; X-YMail-OSG: BDy61IgVM1lF2he5aW3tjj2Dlgwqkzhz0f.u_nPidbKqiC_ mp54.7nXeLJfPk9ecMcYzgCria0LgefYrnQwgBJ6em4DHL3u_Lp138RM.qqE NzsaygBqiu1sVyWBfaZZ9hKPWY.rg44.PwOaymv1Oae42risxkikeDNiKesh DtSpnn3VDjWgXlwcALCEw7XRvnE5B_ZvdosH9s6uZrZz7G7foYRD2OPsuMyW oCgrYZN1P.I_siDpDZInrxIj2uz5fTMS32.5Jc8FoSar86AwEDE_Ke3wuOlj SpKPZ_nU3O9iWxVC60ehu0GUfPG3Wb_BMDCcKGmJWlir19iFIK499FFGWzeF OAe4jpX1K2nKE6seK5zAICFjSvX_wHI35HdVKDaeFjm7JXy41X7ZX255NLWW 3KhakwbZXnaGK7k_4aucIalGcKy3E98lG5N6Vf3dUahyrb2UNAm0_8tqRccT AUISG1KyYfZ0yHgWsyBYNoIKtkw7bJEn_C.UK_BxTqhZ4wMhFU9..MD1.6M2 6JpdJCA_jbTa8QHsR3MkuZ5SShmWCqQmojaovOlf4H9JBTC4Wrall000lxyj 0amYn6JiEzgCdlp0Kcjizj46JliT5vay_dx4pQl8c8dEobSyCXJwU96S8aNM q4vkIjB0JfOICweRPsQAFJRe0 Received: from [109.121.17.22] by web164601.mail.gq1.yahoo.com via HTTP; Fri, 14 Feb 2014 11:54:17 PST X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA4OjA2IFBNLCBGcmFuY2sgTWFydGluIDxmcmFuY2tAcGVhY2h5bWFuZ28ub3JnPiB3cm90ZToKCgo.PiBJdCB3b3VsZCBiZSBmYXIgYmV0dGVyIGZvciBETUFSQyB0byBiZSBhYmxlIHRvIHBvaW50IGF0IGEgc3RhYmxlIHJlZmVyZW5jZSBmb3IKPj4gU1JTLCBhc3N1bWluZyB0aGUgRE1BUkMgY29tbXVuaXR5IHdhbnRzIHRvIGluY2x1ZGUgc3VjaCBhIHJlZmVyZW5jZS4KPiBJZiBJJ20gbm90IG1pc3Rha2VuLCBldmVuIGlmIHlvdSBkaWQgbm90IGNyZWF0ZSABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 References: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1392400605.97311.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1727112676.157637.1392404746485.JavaMail.zimbra@peachymango.org> Message-ID: <1392407657.15164.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 11:54:17 -0800 (PST) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <1727112676.157637.1392404746485.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9TKUSnjua4PlC96DFpPaB02w4WI Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC 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, 14 Feb 2014 19:57:22 -0000 On Friday, February 14, 2014 8:06 PM, Franck Martin wrote: >> It would be far better for DMARC to be able to point at a stable reference for >> SRS, assuming the DMARC community wants to include such a reference. > If I'm not mistaken, even if you did not create SRS, if the Intellectual > property does not restrict you, you can submit an Internet-Draft and the > additional IETF work can reference this Internet Draft. This is the first bar > that needs to be passed now. yeah, lovely, more work for me. huraaaay. :D actually, how crazy i am, i may actually do it. given enough time, ofc. however, i may consider it worthwhile quest only if at least some of major DMARC contributors actually agree this info could be beneficial to DMARC draft txt. i do not want to step on any toes here, being a newbie and stuff. it's not my place to defy all collective wisdom that pushed DMARC where it is now. at least, not yet. so, will we agree we should make a section explaining about some DMARC shortcomings and how to alleviate them - including SRS among others? -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Feb 14 12:26: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 9B5861A03E1 for ; Fri, 14 Feb 2014 12:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig17epWclz9S for ; Fri, 14 Feb 2014 12:26:36 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 848411A0405 for ; Fri, 14 Feb 2014 12:26:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id EE9EA29C2D7; Fri, 14 Feb 2014 14:26:32 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSkfHJRU9gN9; Fri, 14 Feb 2014 14:26:32 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id CE3F429C2D6; Fri, 14 Feb 2014 14:26:32 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id BF6FB29C2D7; Fri, 14 Feb 2014 14:26:32 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VfaK4VYkoIp4; Fri, 14 Feb 2014 14:26:32 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id A3DF129C2D6; Fri, 14 Feb 2014 14:26:32 -0600 (CST) Date: Fri, 14 Feb 2014 14:26:31 -0600 (CST) From: Franck Martin To: Vlatko Salaj Message-ID: <1913841692.160868.1392409591676.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1392282275.22098.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1392400605.97311.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1727112676.157637.1392404746485.JavaMail.zimbra@peachymango.org> <1392407657.15164.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 - FF27 (Mac)/8.0.5_GA_5839) Thread-Topic: SRS helps SPF/DMARC Thread-Index: 7PYVjXRHkAx9m3W44U45uzGwWkzYpg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZmIp8AHb7R_gkRaWJVZAIRA5wcE Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 20:26:40 -0000 ----- Original Message ----- > From: "Vlatko Salaj" > To: dmarc@ietf.org > Sent: Friday, February 14, 2014 11:54:17 AM > Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC > > On Friday, February 14, 2014 8:06 PM, Franck Martin > wrote: > > > >> It would be far better for DMARC to be able to point at a stable reference > >> for > >> SRS, assuming the DMARC community wants to include such a reference. > > If I'm not mistaken, even if you did not create SRS, if the Intellectual > > property does not restrict you, you can submit an Internet-Draft and the > > additional IETF work can reference this Internet Draft. This is the first > > bar > > that needs to be passed now. > > yeah, lovely, more work for me. huraaaay. :D > actually, how crazy i am, i may actually do it. given enough time, ofc. > > however, i may consider it worthwhile quest only if at least some of major > DMARC > contributors actually agree this info could be beneficial to DMARC draft txt. > i do not want to step on any toes here, being a newbie and stuff. it's not my > place to defy all collective wisdom that pushed DMARC where it is now. at > least, > not yet. > > so, will we agree we should make a section explaining about some DMARC > shortcomings > and how to alleviate them - including SRS among others? > I believe, the collective wisdom is to make the SPEC as short as possible, to just describe the protocol and that's about it. However there is a BCP type being developed to explain the SPEC, deployment, shortcomings, etc.. I guess this would be a better fit there. http://tools.ietf.org/html/draft-crocker-dmarc-bcp-03 From nobody Fri Feb 14 13:54: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 0A6451A0449 for ; Fri, 14 Feb 2014 13:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 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.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNqcE9YBk0bI for ; Fri, 14 Feb 2014 13:54:28 -0800 (PST) Received: from nm34.bullet.mail.ne1.yahoo.com (nm34.bullet.mail.ne1.yahoo.com [98.138.229.27]) by ietfa.amsl.com (Postfix) with ESMTP id 613341A043D for ; Fri, 14 Feb 2014 13:54:25 -0800 (PST) Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 21:54:23 -0000 Received: from [98.138.226.176] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 21:51:43 -0000 Received: from [98.137.12.63] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 14 Feb 2014 21:51:43 -0000 Received: from [98.137.12.223] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 21:51:43 -0000 Received: from [127.0.0.1] by omp1031.mail.gq1.yahoo.com with NNFMP; 14 Feb 2014 21:51:43 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 14723.85536.bm@omp1031.mail.gq1.yahoo.com Received: (qmail 84025 invoked by uid 60001); 14 Feb 2014 21:51:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392414702; bh=/GGiPgC6aww/PIEmXcpD2Xmg9Du28wP+T2mENtHYMQc=; 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=Zt0r9et7kWaP4tZQXpCDvsm0qRVReyYBfE1I6wf9CUTJxm/5kMjeRd+adJyqivf1+UbOm238FP6WR8ItylbpEPamRjgB9MseJgmjlG/OBCVMNTcY3WutQ/S/Se19Luoi5Q+LwQMg/8u21Zb0ANeSfwbcPt+9N8JYtH569NKNv4s= 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=elT6JO+KlurLJAgYwRZIFKMsLoFMwEGU06nwD/TAZoz7dS9u2y09eNHsq/qg+Rb//DS7EtUv3saMm7/h6X4ZXUczsrh/ppEAhg7Q3RMs6PpLU8V6WLLysuvDytydkgmHcwD9FPZhsa0Pv/4zGfD5jqf9s5HsYPeIFoyHNjkUnbI=; X-YMail-OSG: oDt8h50VM1mQLdjyFF2OPwe0VLLmXECeyYgUNYt1YGcR9TT QG5x_KJ203D4Y2SYEj_hPtC7lbyjEyQxQhTdV8fCoOI7yYMmGFFrEq67WzNd pjpqVwQi9cI5c3XRlhqVfqlhNFExcig.q1AMssI57iShv.5tlmiyeMMPBeuZ IMWeUJtWPuJOqxu9LhEZaV.FLv1bXM5mOkyzOXgIzmrv8JJ.FA3BETcxwEYW u_x35eXnN3Gu85W4y09YbDrgUaNeyby7LZqt515YR5L75T5m4RoZTWcbsyBJ QsC.M8cuW17mAmeB62p2ZmMVDID5zC7kBqhbavSOvXm0MSOOhC98BQ0wAZJ. he4QygSBt7pwuiNiECqaSI3mxV34_n.e7KNblgbbsXTKOA0FMED68jq4wdpZ jApv.dSVHwT3kxoTPDoZ2Qf6TU8HeYBy7TUzdPz8gF8mTzv5TY36KmpDoqR0 uiHMEo_fUQc7PoWU9C1q08XVBbiho6Y9X9Tmc.8oNg4y7pi3sl6n0Po.pw8i v6g2bSnozrclj_C01KuiGIOp5cKfVOgT3apBuJc6k8KY4e.otyWsKT9fWixW Nuw9js3OAkPqjp617xgVHaTIls5XU0iRqemwKthfvQj1JJAjUHvqi1c_3FWZ xyD5rx.9sBZHP2jE- Received: from [109.121.17.22] by web164604.mail.gq1.yahoo.com via HTTP; Fri, 14 Feb 2014 13:51:42 PST X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBGZWJydWFyeSAxNCwgMjAxNCA4OjM2IFBNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPiB3cm90ZToKCgo.IEl0IG1heSBub3QgYmUgdGhhdCBBVFBTIHNvbHZlcyBhbnkgb2YgeW91ciBwcm9ibGVtcywgYnV0IHRoZSBBVFBTIGNvbW11bml0eQo.IChzbWFsbCBhcyBpdCBpcykgY2FuIHNpbWlsYXJseSBzYXkgdGhhdCBTUlMgZG9lc24ndCBzb2x2ZSB0aGVpcnMuCgp3ZWxsLCBpIGRvIG5vdCBoYXZlIGFueSBwcm9wb3NhbCBvbiBob3cgdG8gZml4IEFUUFMtaW4BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 References: <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com> Message-ID: <1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 13:51:42 -0800 (PST) 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/4pAIFbqM-LjylT9H81L1vuBjgo0 Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC 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, 14 Feb 2014 21:54:33 -0000 On Friday, February 14, 2014 8:36 PM, Murray S. Kucherawy wrote: > It may not be that ATPS solves any of your problems, but the ATPS community > (small as it is) can similarly say that SRS doesn't solve theirs. well, i do not have any proposal on how to fix ATPS-induced DKIM DMARC-alignment fail. it simply seems DMARC and ATPS are mutually exclusive, as presently defined. maybe ATPS should be revised to account for DMARC compatibility. however, that's not the case with SRS. it affects nothing in DMARC processing, just helps solve some of its shortcomings; shortcomings introduced with same alignment requirements, but on SPF side. and we can't exclude SPF, or revise it; it's an essential part of spec as defined already. ATPS doesn't solve DMARC shortcomings, it makes them. also, two points: 1. domain owners control ATPS deployment; 2. they have an alternative that works with DMARC. however, domain owners have no control over forwarders, nor they have much of an alternative. maybe spec should have a note about incompatibility with ATPS. but that's it. or is there a better idea flying around? >> also, SRS is not alone. mentioning, for example, that mailing list providers >> should do their best not to break DKIM in their processing should also be >> added as guidance in DMARC specs. and i'm sure there are some other >> suggestions for solving DMARC inefficiencies that should go into this >> category too. > A lot of this is written down in RFC6377, at least as it pertains to DKIM. > Perhaps DMARC should reference that as well. actually, that may not be a bad idea. >> however, stats about DKIM signatures say nothing about DKIM DMARC alignment, >> which numbers are probably quite lower. so, even if DKIM is saved, >> alignments? > Wouldn't that be visible in the DMARC aggregate reports? where? i'm not aware of any publicly released stats, beside those big numbers last year. but those were more of an ad, than real statistical data. > My recollection of most of the SPF and IETF community at the time was that > SRS didn't get a favorable reaction. are you sure that wasn't about microsoft's version of it, later part of sender id spec? asaik, plain SRS wasn't hated, it was merely a special case handling and thus less important to SPF. >> but, we will never know, will we? actually, if SPF wasn't so broken by >> forwarders in the 1st place, maybe we would have no need for DKIM or DMARC >> now. > SPF has not been around as long as forwarders have been, so I think making > the argument that this is forwarders' fault is a bit silly. my point was that cause SPF was never finished accounting for forwarders, mainly of bad blood caused by sender id, it was, unfortunately, broken from the start. and yes, forwarders do introduce quite a bit of grief into email world. but, its late to think about that problem now. we can, however, devise workarounds. let me ask a public question: was there any intention at all by original DMARC authors to consider replacing SPF with SenderID, or to use PRA instead of "from:" header alignment? while controversial in many ways, not everything in that algorithm was useless. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Feb 14 17:41: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 74A001A0021 for ; Fri, 14 Feb 2014 17:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waNyPCGVl1R9 for ; Fri, 14 Feb 2014 17:41:53 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id DB0931A002F for ; Fri, 14 Feb 2014 17:41:52 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id l18so809979wgh.0 for ; Fri, 14 Feb 2014 17:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1SRX05i3aT068iwtYZK4q/hTJDCmTHSya98/cWNjAwY=; b=DL3u2f4Oq4HhI2UFIcnIvAaICS9bQK2cCd6lxhhEZ8v0i2+Amfx68zd9QrDaQbMo5I PBgH+0i2ht2opPUyp4YIFfT3Ewh2qInS4y2o1E/lmM6qr+yFUyMMg5cjUDzaplOgjUcG 6WYWM9gFriQyuS9i0rZrR7zv2t7Wu4qzxjz7pM58OmNOZr73qrmJ0G0YDY/QfprNm8Hc FLC6yO5lfFNMj/Xx9nzffvmhduUU/PBR+nkE48EhrLwnH2SQ9DpuVoWJK+niquYLZPug zENyn52SnLDgT46wTAE9l41cUz9UWErZjIJvNg9al5TjMsxhNDGop+x2UEoS7uuQ2lfy 0hwQ== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr8668104wjc.9.1392428510596; Fri, 14 Feb 2014 17:41:50 -0800 (PST) Received: by 10.180.90.132 with HTTP; Fri, 14 Feb 2014 17:41:50 -0800 (PST) In-Reply-To: <1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com> References: <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Fri, 14 Feb 2014 17:41:50 -0800 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=047d7b873a10bfd5bf04f2680654 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_2ZbYlRqUjb95PCBeldvHP3vQB4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:41:56 -0000 --047d7b873a10bfd5bf04f2680654 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 14, 2014 at 1:51 PM, Vlatko Salaj wrote: > > It may not be that ATPS solves any of your problems, but the ATPS > community > > (small as it is) can similarly say that SRS doesn't solve theirs. > > well, i do not have any proposal on how to fix ATPS-induced DKIM > DMARC-alignment fail. it simply seems DMARC and ATPS are mutually > exclusive, as presently defined. maybe ATPS should be revised to account > for > DMARC compatibility. > Are we talking about the same thing? ATPS doesn't induce DKIM failures; it suggests a way to indicate a message signer can be endorsed by an author, saying "treat this signature as if it were my own". That brings an unaligned DKIM signature into alignment, in DMARC terms. I don't see how it can deteriorate things. Rather, its problem is that it's a corner case with limited adoption. > > maybe spec should have a note about incompatibility with ATPS. but that's > it. > > ...but they aren't incompatible. > >> however, stats about DKIM signatures say nothing about DKIM DMARC > alignment, > >> which numbers are probably quite lower. so, even if DKIM is saved, > >> alignments? > > Wouldn't that be visible in the DMARC aggregate reports? > > where? i'm not aware of any publicly released stats, beside those big > numbers > last year. but those were more of an ad, than real statistical data. > Anyone receiving large amounts of mail and generating reports based on them (Yahoo, for example) has enough data to tell you what percentage of DKIM signatures are passing, and what percentage of those are DMARC-aligned. > > My recollection of most of the SPF and IETF community at the time was > that > > SRS didn't get a favorable reaction. > > are you sure that wasn't about microsoft's version of it, later part of > sender id spec? asaik, plain SRS wasn't hated, it was merely a special case > handling and thus less important to SPF. > Yes, I'm sure. And I don't recall there being multiple versions of SRS back then. I could be wrong, but it could also be the case that people only knew about one version. I also don't recall a version of SRS put forward by Microsoft. > my point was that cause SPF was never finished accounting for forwarders, > mainly > of bad blood caused by sender id, it was, unfortunately, broken from the > start. > > and yes, forwarders do introduce quite a bit of grief into email world. > but, its > late to think about that problem now. we can, however, devise workarounds. > The people working on it had a choice: A version of SPF that didn't deal with forwarding (which is what we got), or a version of SPF that did deal with forwarding in a manner the community at the time felt was unpalatable. It appears to have chosen the former, for better or worse. SPF (the document, not so much the protocol) was just revised to change its status from Experimental to Proposed Standard. SRS didn't come up there either; the consensus supported a version that continued not to deal with forwarding directly. let me ask a public question: was there any intention at all by original > DMARC > authors to consider replacing SPF with SenderID, or to use PRA instead of > "from:" header alignment? while controversial in many ways, not everything > in that algorithm was useless. > Including Sender-ID support was considered and discarded, though DMARC is also extensible to include it later if it turns out to be desirable. However, Sender-ID appears to be drifting into history, so we instead went with the algorithm that's there now. -MSK --047d7b873a10bfd5bf04f2680654 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 14, 2014 at 1:51 PM, Vlatko Salaj <vlat= ko.salaj@goodone.tk> wrote:
> It may not be that ATPS= solves any of your problems, but the ATPS community
> (small as it is) can similarly say that SRS doesn't solve theirs.<= br>
well, i do not have any proposal on how to fix ATPS-induced DKIM
DMARC-alignment fail. it simply seems DMARC and ATPS are mutually
exclusive, as presently defined. maybe ATPS should be revised to account fo= r
DMARC compatibility.

Are we talking abo= ut the same thing?=A0 ATPS doesn't induce DKIM failures; it suggests a = way to indicate a message signer can be endorsed by an author, saying "= ;treat this signature as if it were my own".=A0 That brings an unalign= ed DKIM signature into alignment, in DMARC terms.=A0 I don't see how it= can deteriorate things.=A0 Rather, its problem is that it's a corner c= ase with limited adoption.
=A0

maybe spec should have a note about incompatibility with ATPS. but that'= ;s it.


...but they aren't incompatible.=A0
>> however, stats about= DKIM signatures say nothing about DKIM DMARC alignment,
>> which numbers are probably quite lower. so, even if DKIM is saved,=
>> alignments?
> Wouldn't that be visible in the DMARC aggregate reports?

where? i'm not aware of any publicly released stats, beside those= big numbers
last year. but those were more of an ad, than real statistical data.

Anyone receiving large amounts of mail and ge= nerating reports based on them (Yahoo, for example) has enough data to tell= you what percentage of DKIM signatures are passing, and what percentage of= those are DMARC-aligned.
=A0
> My recollection of most of the SPF and IETF community = at the time was that
> SRS didn't get a favorable reaction.

are you sure that wasn't about microsoft's version of it, lat= er part of
sender id spec? asaik, plain SRS wasn't hated, it was merely a special = case
handling and thus less important to SPF.

Yes, I'm sure.=A0 And I don't recall there being multiple version= s of SRS back then.=A0 I could be wrong, but it could also be the case that= people only knew about one version.=A0 I also don't recall a version o= f SRS put forward by Microsoft.
=A0
my point was that cause SPF was= never finished accounting for forwarders, mainly
of bad blood caused by sender id, it was, unfortunately, broken from the st= art.

and yes, forwarders do introduce quite a bit of grief into email world. but= , its
late to think about that problem now. we can, however, devise workarounds.<= br>

The people working on it had a choice: = A version of SPF that didn't deal with forwarding (which is what we got= ), or a version of SPF that did deal with forwarding in a manner the commun= ity at the time felt was unpalatable.=A0 It appears to have chosen the form= er, for better or worse.

SPF (the document, not so much t= he protocol) was just revised to change its status from Experimental to Pro= posed Standard.=A0 SRS didn't come up there either; the consensus suppo= rted a version that continued not to deal with forwarding directly.

let me ask a public question: was there any intention at all by original DM= ARC
authors to consider replacing SPF with SenderID, or to use PRA instead of "from:" header alignment? while controversial in many ways, not e= verything
in that algorithm was useless.

Includin= g Sender-ID support was considered and discarded, though DMARC is also exte= nsible to include it later if it turns out to be desirable.=A0 However, Sen= der-ID appears to be drifting into history, so we instead went with the alg= orithm that's there now.

-MSK
--047d7b873a10bfd5bf04f2680654-- From nobody Sat Feb 15 00:48:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBE71A00E1 for ; Sat, 15 Feb 2014 00:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 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_14=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] 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 2t5ev7c4Ou8Z for ; Sat, 15 Feb 2014 00:48:32 -0800 (PST) Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) by ietfa.amsl.com (Postfix) with ESMTP id 865FE1A00E5 for ; Sat, 15 Feb 2014 00:48:31 -0800 (PST) Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2014 08:48:29 -0000 Received: from [98.138.226.177] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2014 08:45:49 -0000 Received: from [98.137.12.190] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2014 08:45:48 -0000 Received: from [98.137.12.236] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 15 Feb 2014 08:45:48 -0000 Received: from [127.0.0.1] by omp1044.mail.gq1.yahoo.com with NNFMP; 15 Feb 2014 08:45:48 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 736728.85432.bm@omp1044.mail.gq1.yahoo.com Received: (qmail 29857 invoked by uid 60001); 15 Feb 2014 08:45:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392453948; bh=V9YrUB3bMvH4ARR/vaQpNTLgJtZScvSIsLNEF6R/Lrw=; 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=NqQS/kplfk5dokxVGFSrqVQDNZBCy0LLjbhE1mKXIvbp0IgupELQ7fJEhrguKNg5EnlT4K5VbQbnP8wOc7wo7J/+0gEkQDSkOwUqIA6rT3DNTaeBG/BzWq7l+UyCgx0EGJoGgN220UJbsN6b/mAPWSoplPFYJXr8cLQB9enzltU= 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=w5jUzdZbZa2XiqKudada+va8ZUgz4yumkQu3stdhxbhMsBfr/HvEP/amoHjVs5uBpBmMquAkKYKG49xt+6M68pEjT3XHn84ILKB46vmGSdZh4xS6ehkn0sC0HGSbDawWh0WAi+o6tcTWo6sAu50/61gzHToIyC4S9bWfDw91faU=; X-YMail-OSG: 7mC4SuQVM1l10VRdqK2dJ.tbq6PHnx6nsd.Jmv7JuhYCPX9 xdkaBiG1hLWLLw7Wz92AsXN_GQzvT2UUAvQ3hxIRA3H7iqw2jOFC_SJvKpY0 Mip3N0mi0vNFGlo0Q2RQoihkzhn.m_y6FnUEPdGeQ56aUUp0KQZYV7nkqYOq SnxQ_FAyK3MLYIAfhbxvAWa6XdxS9uoJ_8NibkaKmLivF4Uwng75Xsv.X3IM FCpTW.tnMa6A9oSUEjk5EImOdTe83XLR0bBGphc6W_VLnCvqhmZ5bz66tGfd G7ZXf7yAn61CISKVk3w7aP.d_YOHxWqtrumWhJNzZWUXTgOVBYBLCwh2.6mN kdt_V3WJedaetkffqmSpIfJCGDF8MX1BwahbqAH6W279IIs23WXEVf4sxoE9 SVeXe1Z.hL6TuUGXUmh36tQx.1PH1WV.GhjboNY95r082LMJkHwnSIXSzfVd 88.ZYzuyykSVvk5xdvi16zcB37kvuTsbZA8IZQfI33drINMw8rCuCoeI1YSu JVefgljhnz4ECkKL1llWcbs.YlJGwUvORpvy1.GiGBDHc0kq7jJVeoH1585Q HP1J2M0.yWqY9G2SuiFeH9fY0KqibURW2L5MMJD5NJ5ld4ZK4Yi8MTOE_IhH nALxHjZGv Received: from [109.121.17.22] by web164601.mail.gq1.yahoo.com via HTTP; Sat, 15 Feb 2014 00:45:48 PST X-Rocket-MIMEInfo: 002.001, T24gU2F0dXJkYXksIEZlYnJ1YXJ5IDE1LCAyMDE0IDI6NDIgQU0sIE11cnJheSBTLiBLdWNoZXJhd3kgPHN1cGVydXNlckBnbWFpbC5jb20.IHdyb3RlOgoKCj4.IG1heWJlIHNwZWMgc2hvdWxkIGhhdmUgYSBub3RlIGFib3V0IGluY29tcGF0aWJpbGl0eSB3aXRoIEFUUFMuIGJ1dCB0aGF0J3MgaXQuCj4gLi4uYnV0IHRoZXkgYXJlbid0IGluY29tcGF0aWJsZS4KCmkgb25seSBza2ltbWVkIEFUUFMgc3BlY3MsIHNvIG1heWJlIGkgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcuIGhvd2V2ZXIsIGFzIGZhcgphcyABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 References: <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com> Message-ID: <1392453948.82337.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Sat, 15 Feb 2014 00:45:48 -0800 (PST) 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/2feI3OrxXhIcqqeGhza7EDRuOCQ Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC 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, 15 Feb 2014 08:48:34 -0000 On Saturday, February 15, 2014 2:42 AM, Murray S. Kucherawy wrote: >> maybe spec should have a note about incompatibility with ATPS. but that's it. > ...but they aren't incompatible. i only skimmed ATPS specs, so maybe i misunderstood something. however, as far as i see it, the way it's defined is incompatible with DMARC. ATPS changes "d=" tag to 3rd party, while "from:" header remains 1st party. essentially, this breaks DKIM alignment, in DMARC terms. the only way ATPS could be compatible is as a DMARC policy override, similarly to the way ATPS defines compatibility with ADSP. so, mutually exclusive. imo, since ATPS standard is still in its making, it should be changed to account for DMARC. however, i'm not sure if that's possible, without making significant changes to DKIM as well. or just use it as a policy override. > Anyone receiving large amounts of mail and generating reports based on them > (Yahoo, for example) has enough data to tell you what percentage of DKIM > signatures are passing, and what percentage of those are DMARC-aligned. reports i'm dealing with go around 10%. however, my pool is too small to be considered deal-breaking. however, in my experience, DMARC alignment is a b*atch. > SPF (the document, not so much the protocol) was just revised to change > its status from Experimental to Proposed Standard. SRS didn't come up > there either; the consensus supported a version that continued not to deal > with forwarding directly. i guess that answers a question i woke up today with: would any major mailbox provider be interested into adding SRS into their forwarding logic? considering how they look at SPF as annoyance as it is [yahoo not publishing any SPF records, for example], no wonder they don't like making that protocol even more hard to deploy. >> are you sure that wasn't about microsoft's version of it, later part of >> sender id spec? asaik, plain SRS wasn't hated, it was merely a special case >> handling and thus less important to SPF. > Yes, I'm sure. And I don't recall there being multiple versions of SRS > back then. I could be wrong, but it could also be the case that people > only knew about one version. I also don't recall a version of SRS put > forward by Microsoft. SRS was made to deal with forwarders, in SPF terms. however, before SPF was finished, microsoft worked on expanding it to something we know now as SenderID. SenderID used plain SPF with no SRS, but instead introduced its own type of dealing with forwarders, mailing lists, u name it - called PRA [Purported Responsible Address]. considering microsoft pushed for its version quite a bit, and how SRS made SPF more difficult to implement, SRS never got enough interests or attention, it was left sidetracked, pushed away by a new promising idea - PRA. however, PRA was so bad at the end, the entire working group ceased functioning cause of conflicts, causing riples between major mailbox owners... and now SenderID is dead, SPFs is easily broken in real world and SRS never got any ietf work. pity actually. but history always repeats itself now and then, i guess. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Sat Feb 15 03:40: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 AE9E41A01BA for ; Sat, 15 Feb 2014 03:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 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.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfO4s2VP-Bf6 for ; Sat, 15 Feb 2014 03:40:48 -0800 (PST) Received: from nm31.bullet.mail.ne1.yahoo.com (nm31.bullet.mail.ne1.yahoo.com [98.138.229.24]) by ietfa.amsl.com (Postfix) with ESMTP id AB6611A00D5 for ; Sat, 15 Feb 2014 03:40:46 -0800 (PST) Received: from [127.0.0.1] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2014 11:40:44 -0000 Received: from [98.138.100.103] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2014 11:38:00 -0000 Received: from [216.39.60.180] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 15 Feb 2014 11:38:00 -0000 Received: from [98.137.12.241] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 15 Feb 2014 11:38:00 -0000 Received: from [127.0.0.1] by omp1049.mail.gq1.yahoo.com with NNFMP; 15 Feb 2014 11:38:00 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 499631.78755.bm@omp1049.mail.gq1.yahoo.com Received: (qmail 48833 invoked by uid 60001); 15 Feb 2014 11:38:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392464280; bh=71T8BV1+dCiTeJiOIbQ842QIxFXqDSI8VSj0Htwfw08=; 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=wQ3keVGy2nAeHgLICWd9Ruu64IAapE86uj3C5CibjOtWHjsPjTmlSPDpnbyXDVrZVM1/9bGmW7+cdIDnmUaHTM3Wv48UwC0XdvyE9f8B2fNwDHcMHQZ6x4Z1ADHw6396/iJvgez7hFtFizk6QccLFvD/dECGOAk5KjPDlsJWnU0= 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=397rbkGjhRH6hODZ3v25yiU7H0DCYzc3M5pvqcIoZ/ZCLgcyYCWsnb5h3oEFjRjIlQNxp49MDLLIDbReemBpxAx3U4m2EnkZB4fOfpLasj9vIDK10RCB2PW4W0I+UDrrxsbH8hr2GnQSR/nWyo5ZpsKCxWMT9iXKzenbvoH/osc=; X-YMail-OSG: u6pyiHIVM1mkZdLowFgvSf.TkNNH22eGHs2DUmUVvpOSn.S HWwoROPfUqlf75.7LH8BuwGLU7MKOslm4i4CZrb0_8MsHsShrGkiBjSP9WP3 EvmSVpgCO3JtCFQl.lysfD5Go.oBy16TlxUjRlQnZlC6gRYI7jF5J_SXMGdr 7Rre8j.VEOIliziJH6aKlal71nEzlLUsE1Snv4nGEjxdqza3F3LFqHYMGGKv SM.a1INAX9YB.rNe.O_vqcRxyDWy_pNLCTmD0FP_pt_YZZbFHdv0ogb._2kL nJCucZ3pGzVDjG2E3leRCJUPiT_pSIFo_JOLZ39Je8aPtU7be0toyNoENNBE tnQKMK1YpbU92Z9kuJnm6Dmo0DNxDWBsOJyk2QbOWPeKyrp1PCbZ42tBV1JH SMdBof4WUYdjVdbGpeYfSdtDEtr1Gpe2EAN0P98shcmO7cUqr7Y055sgm.d8 0tzoBJeMkY_O55a83NIlwU9yER0U87speqIEZpNI9Ia4d7m.AnoPemzsz..m DMBm9rSDiID5TUS_697GHeKzauoZ4QXT.XlqjzuE1XnluSrgx5EaFNY0q6ej 62RhlzrdJN8v98KxXcG84rbqD4dQMEtv2hho59cw1MvU_7.Qr3HqOEazKU27 ckOjF5aG.rlokSc7Ox7bsFFgtjLrNf8775gCCHrhMnLRZVfTkFrk- Received: from [109.121.17.22] by web164601.mail.gq1.yahoo.com via HTTP; Sat, 15 Feb 2014 03:38:00 PST X-Rocket-MIMEInfo: 002.001, aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpc3Qvd2cKCnN0aWxsIGhhcyBubyB3Z2Mgb3I_CgoKLS0gCgpWbGF0a28gU2FsYWogYWthIGdvb2RvbmUKaHR0cDovL2dvb2RvbmUudGsBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.177.636 Message-ID: <1392464280.83879.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Sat, 15 Feb 2014 03:38:00 -0800 (PST) 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/hiRGsaR_Vpw3HyaEG3la3XBo2PY Subject: [dmarc-ietf] DMARC missing? 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, 15 Feb 2014 11:40:52 -0000 http://datatracker.ietf.org/list/wg still has no wgc or? -- Vlatko Salaj aka goodone http://goodone.tk From nobody Sat Feb 15 05:26:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24C31A0207 for ; Sat, 15 Feb 2014 05:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 pEhWUqc3Y6L1 for ; Sat, 15 Feb 2014 05:26:39 -0800 (PST) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id D552A1A01D8 for ; Sat, 15 Feb 2014 05:26:38 -0800 (PST) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3fRC0S0tbMz5Mhct; Sat, 15 Feb 2014 14:26:32 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3fRC0R6S6yz5Mhcs; Sat, 15 Feb 2014 14:26:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 69436122E76; Sat, 15 Feb 2014 14:26:31 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sYzZw5fy9WHm; Sat, 15 Feb 2014 14:26:28 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 03728122E6D; Sat, 15 Feb 2014 14:26:27 +0100 (CET) Message-ID: <52FF6B03.1090008@sonnection.nl> Date: Sat, 15 Feb 2014 14:26:27 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Vlatko Salaj , "dmarc@ietf.org" References: <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com> <1392453948.82337.YahooMailNeo@web164601.mail.gq1.yahoo.com> In-Reply-To: <1392453948.82337.YahooMailNeo@web164601.mail.gq1.yahoo.com> Content-Type: multipart/alternative; boundary="------------030602040504060001090605" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1392470792; bh=o36iRcIwTPUHNgOI2w5RoSDcpahqEFImo4iqceoqcPc=; h=Message-ID:Date:From:To:Subject:From; b=UQ7u5nGw26eN1LD8uXCCBZPJpyejA5YuugjRYz0c/J3B13cKavq4yKUU3qUjbuHTx ohoBdQ7va9YgcaagEHQ286X119qR7oWKbbBOb1ycASD6pSkKvf6SeB86qrYT72EUv2 AdWuPJA79Kh8DBL2u5DQzB9WBoz8+qW3FmhtAdTo= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3fRC0S0tbMz5Mhct Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/81zajPRazvp2p-R1hEgaBjSML6c Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 13:26:42 -0000 This is a multi-part message in MIME format. --------------030602040504060001090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/15/2014 09:45 AM, Vlatko Salaj wrote: > On Saturday, February 15, 2014 2:42 AM, Murray S. Kucherawy wrote: > > >>> maybe spec should have a note about incompatibility with ATPS. but that's it. >> ...but they aren't incompatible. > i only skimmed ATPS specs, so maybe i misunderstood something. however, as far > as i see it, the way it's defined is incompatible with DMARC. > > ATPS changes "d=" tag to 3rd party, while "from:" header remains 1st party. > essentially, this breaks DKIM alignment, in DMARC terms. the only way ATPS > could be compatible is as a DMARC policy override, similarly to the way > ATPS defines compatibility with ADSP. > > so, mutually exclusive. imo, since ATPS standard is still in its making, > it should be changed to account for DMARC. One can argue whether it is correct to require to change ATPS, which has (Expirimental) RFC status, to accomodate for DMARC, which has no IETF status yet. > however, i'm not sure if that's > possible, without making significant changes to DKIM as well. > > or just use it as a policy override. > > >> Anyone receiving large amounts of mail and generating reports based on them >> (Yahoo, for example) has enough data to tell you what percentage of DKIM >> signatures are passing, and what percentage of those are DMARC-aligned. Not sure why you (Murray) mention Yahoo here, but in general it would help us when the major ESPs would share their statistics on things like DMARC alignment, SPF pass/fail rate, DKIM pass/fail rate, DKIM+SPF fail/fail rate etc. The most interesting question here being: what percentage of legitimate mail fails both SPF and DKIM (DMARC). > reports i'm dealing with go around 10%. however, my pool is too small to > be considered deal-breaking. however, in my experience, DMARC alignment > is a b*atch. > > >> SPF (the document, not so much the protocol) was just revised to change >> its status from Experimental to Proposed Standard. SRS didn't come up >> there either; the consensus supported a version that continued not to deal >> with forwarding directly. > i guess that answers a question i woke up today with: would any major > mailbox provider be interested into adding SRS into their forwarding > logic? considering how they look at SPF as annoyance as it is [yahoo > not publishing any SPF records, for example], no wonder they don't > like making that protocol even more hard to deploy. Forget about SRS. To paraphrase John Levines statement about the budget that receivers have to fix the problems of the sender: "The total budget at all _forwarders_ for solving senders' problems is $0." For senders and receivers there can be (some) mutual interest in solving problems at either side (this is true for 'transactional' mail), but there is no mutual interest between senders and forwarders and there's no mutual interest between forwarders and receivers. /rolf --------------030602040504060001090605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/15/2014 09:45 AM, Vlatko Salaj wrote:
On Saturday, February 15, 2014 2:42 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:



maybe spec should have a note about incompatibility with ATPS. but that's it.

...but they aren't incompatible.

i only skimmed ATPS specs, so maybe i misunderstood something. however, as far
as i see it, the way it's defined is incompatible with DMARC.

ATPS changes "d=" tag to 3rd party, while "from:" header remains 1st party.
essentially, this breaks DKIM alignment, in DMARC terms. the only way ATPS
could be compatible is as a DMARC policy override, similarly to the way
ATPS defines compatibility with ADSP.

so, mutually exclusive. imo, since ATPS standard is still in its making,
it should be changed to account for DMARC.

One can argue whether it is correct to require to change ATPS, which has (Expirimental) RFC status, to accomodate for DMARC, which has no IETF status yet.

 however, i'm not sure if that's
possible, without making significant changes to DKIM as well.

or just use it as a policy override.



Anyone receiving large amounts of mail and generating reports based on them
(Yahoo, for example) has enough data to tell you what percentage of DKIM
signatures are passing, and what percentage of those are DMARC-aligned.

Not sure why you (Murray) mention Yahoo here, but in general it would help us when the major ESPs would share their statistics on things like DMARC alignment, SPF pass/fail rate, DKIM pass/fail rate, DKIM+SPF fail/fail rate etc. The most interesting question here being: what percentage of legitimate mail fails both SPF and DKIM (DMARC).


      

      
reports i'm dealing with go around 10%. however, my pool is too small to
be considered deal-breaking. however, in my experience, DMARC alignment
is a b*atch.




      

        
SPF (the document, not so much the protocol) was just revised to change
its status from Experimental to Proposed Standard. SRS didn't come up
there either; the consensus supported a version that continued not to deal
with forwarding directly.


      

      
i guess that answers a question i woke up today with: would any major
mailbox provider be interested into adding SRS into their forwarding
logic? considering how they look at SPF as annoyance as it is [yahoo
not publishing any SPF records, for example], no wonder they don't
like making that protocol even more hard to deploy.

    

    

    Forget about SRS. To paraphrase John Levines statement about the
    budget that receivers have to fix the problems of the sender:

    

    "The
        total budget at all _forwarders_ for solving senders' problems
        is $0."

        

        For senders and receivers there can be (some) mutual interest in
        solving problems at either side (this is true for
        'transactional' mail), but there is no mutual interest between
        senders and forwarders and there's no mutual interest between
        forwarders and receivers.

        

        /rolf

  


--------------030602040504060001090605--


From nobody Sat Feb 15 05:37: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 741EC1A0202 for ; Sat, 15 Feb 2014 05:37:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cQQOnxriVr2 for ; Sat, 15 Feb 2014 05:36:59 -0800 (PST)
Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 870251A01CE for ; Sat, 15 Feb 2014 05:36:59 -0800 (PST)
Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3fRCDT01VVz1L8fN; Sat, 15 Feb 2014 14:36:56 +0100 (CET)
Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3fRCDS5tdnz1L8fM; Sat, 15 Feb 2014 14:36:56 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 8EA61122E76; Sat, 15 Feb 2014 14:36:56 +0100 (CET)
X-Virus-Scanned: amavisd-new at sonnection.nl
Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id d3eiSqKN9Th0; Sat, 15 Feb 2014 14:36:53 +0100 (CET)
Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id BEADF122E6D; Sat, 15 Feb 2014 14:36:53 +0100 (CET)
Message-ID: <52FF6D75.50000@sonnection.nl>
Date: Sat, 15 Feb 2014 14:36:53 +0100
From: "Rolf E. Sonneveld" 
Organization: Sonnection B.V.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Vlatko Salaj , "dmarc@ietf.org" 
References: <1392464280.83879.YahooMailNeo@web164601.mail.gq1.yahoo.com>
In-Reply-To: <1392464280.83879.YahooMailNeo@web164601.mail.gq1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1392471417; bh=NlhDai4TtHR+B6vrN4gJ0JdO7Vk17uiRnOlah4m7UQI=; h=Message-ID:Date:From:To:Subject:From; b=ILeGZKP1cHBlAHb/HvueK92YDVhk8sQB1UOqnaR4/OT4W8oszsC1huzQe/rkwGx+E zzxlqnGNpbRhLDTjlsFinUshYBh/ObJxvt8zgfLFtu3OMynctA7SGLB+hdaAkbB+F1 2ZsW+vjYj+eVUJJw5oe6+oxA2hyWvFVxnK/xxie0=
DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3fRCDT01VVz1L8fN
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TimVzzScljPTm-GtYjXb2oIbqzo
Subject: Re: [dmarc-ietf] DMARC missing?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: R.E.Sonneveld@sonnection.nl
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Feb 2014 13:37:01 -0000

Hi, Vlatko,

On 02/15/2014 12:38 PM, Vlatko Salaj wrote:
> http://datatracker.ietf.org/list/wg
>
> still has no wgc or?

last IETF 87 Berlin there was a BoF session on DMARC. The outcome was 
that there was no consensus to start a WG on DMARC. AFAIK The DMARC spec 
has been submitted as an AD sponsored submission.

Anyone know what the current status of this submission is? I have not 
yet seen a last call. Apart from that quite a number of people in Berlin 
found the text of the DMARC spec not yet ready for publication, so I 
wonder what will be the next steps for DMARC within the IETF?

/rolf


From nobody Sat Feb 15 06:20: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 168071A020A for ; Sat, 15 Feb 2014 06:20:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level: 
X-Spam-Status: No, score=-2.446 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.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwUB7VF0wE6t for ; Sat, 15 Feb 2014 06:20:16 -0800 (PST)
Received: from nm24-vm4.bullet.mail.gq1.yahoo.com (nm24-vm4.bullet.mail.gq1.yahoo.com [98.136.217.99]) by ietfa.amsl.com (Postfix) with ESMTP id A78F41A0203 for ; Sat, 15 Feb 2014 06:20:16 -0800 (PST)
Received: from [98.137.12.191] by nm24.bullet.mail.gq1.yahoo.com with NNFMP; 15 Feb 2014 14:20:14 -0000
Received: from [216.39.61.239] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 15 Feb 2014 14:20:14 -0000
Received: from [127.0.0.1] by omp1074.mail.gq1.yahoo.com with NNFMP; 15 Feb 2014 14:20:14 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 598084.65235.bm@omp1074.mail.gq1.yahoo.com
Received: (qmail 94738 invoked by uid 60001); 15 Feb 2014 14:20:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392474014; bh=cZZe7QACVlIdz2+bFua/A+QqdI5eBYNnKupQwntHiGE=; 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=yz1GLwqWQacUPz27LVneDF1aHPsAA8PH/Z0HrE4sLifXdIxQ6E7Pm2W/1ePa6C+B2VUSKc84hYxKd83E0nhqWXyFllkXBCjJYHRI8oNlIKAUr43+6SpTwobgbeFC7ekeXVRKnh4ZBs2U635rDEIBgNPmkAXjuNAswqbEnxgFNG8=
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=b4vkmPxffgf/y+eMSWZWxSsBBatL2XKxf1135cMhhLS5FVK+KnxbRXZdNe5gqdvh/lhPGMFUbB9iM+HSELiTqklPU+62pI0AuWDBPMtK3UgQ7RhIlJqi5ubg77x2legqe8Ikak/1fl8sRUSmvDkKkI/nfcAx8huFin1/vborAoU=;
X-YMail-OSG: auNPoFMVM1nsau9jlmYNznWqPu42fLTVL5TxRylMon4p5PV C0W8u2YJMwfkpR4IDWTl3l6B0fyxCOl2lw_lKzFQBbth5bFy4kFIRLtn6HHw rZYgyIrWptZNwhydj_7JqoxNudsLf1Tl_UMv.PywQkWzQXhQsZbs.ZCrGvPn 09OoPFgKB1PvS2DiV.4Bnjzz1LYDONBzTPDiC9lwI6YSikTO.cuudXZC8BDJ y2wxjV6m3G6GsLXzNaP1xww5FFftd5ruXR7aYElndqf_B8YaveWr9tH7FNtG 1bINsCNVzAvrQpgiRVuGnyRFhCKQlHrKdE7Yddo4zWhDUm7CWx1Yshiy6JtH SDsk5S73_Q.tjRAe6dzyVQ53KBStez_cib0T.zPMRZmMd18bH52H4aH3gFuL o_BkbfGYcVxbfW8IkW._Oxi8SQSY3CfQXWMw4.VpARrSv1SCwohIy00YGq2O 639fViYayjv0lsCOndUPOpTBJ4yCZZlX8YGdJkEDBUmK67se6CfiEeNC0MEe Mgb0tab21CCQG7GENL5oyPzY4PQO0ocBDxuAAIhA8YOZIQSfWeu0FPN7Bng_ Isv4YiiXGwIAsNIv3dkJirSnW.lzToTy3HJYYGKFS8f6obTBGlqZMi2MRtLa 8V__oefzUrQ8m42wd8NshSdmm
Received: from [109.121.17.22] by web164602.mail.gq1.yahoo.com via HTTP; Sat, 15 Feb 2014 06:20:14 PST
X-Rocket-MIMEInfo: 002.001, T24gU2F0dXJkYXksIEZlYnJ1YXJ5IDE1LCAyMDE0IDI6MjYgUE0sIFJvbGYgRS4gU29ubmV2ZWxkIDxSLkUuU29ubmV2ZWxkQHNvbm5lY3Rpb24ubmw.IHdyb3RlOgoKCj4gRm9yIHNlbmRlcnMgYW5kIHJlY2VpdmVycyB0aGVyZSBjYW4gYmUgKHNvbWUpIG11dHVhbCBpbnRlcmVzdCBpbiBzb2x2aW5nCj4gcHJvYmxlbXMgYXQgZWl0aGVyIHNpZGUgKHRoaXMgaXMgdHJ1ZSBmb3IgJ3RyYW5zYWN0aW9uYWwnIG1haWwpLCBidXQgdGhlcmUgaXMKPiBubyBtdXR1YWwgaW50ZXJlc3QgYmV0d2VlbiBzZW5kZXJzIGEBMAEBAQE-
X-RocketYMMF: gwzrd
X-Mailer: YahooMailWebService/0.8.177.636
References: 	<1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com>		<1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com>		<1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com>  <1392453948.82337.YahooMailNeo@web164601.mail.gq1.yahoo.com> <52FF6B03.1090008@sonnection.nl> 
Message-ID: <1392474014.27844.YahooMailNeo@web164602.mail.gq1.yahoo.com>
Date: Sat, 15 Feb 2014 06:20:14 -0800 (PST)
From: Vlatko Salaj 
To: "dmarc@ietf.org" 
In-Reply-To: <52FF6B03.1090008@sonnection.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oqPlrZJefnh1nkuEvQhopxiwgSk
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
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, 15 Feb 2014 14:20:19 -0000

On Saturday, February 15, 2014 2:26 PM, Rolf E. Sonneveld  wrote:


> For senders and receivers there can be (some) mutual interest in solving
> problems at either side (this is true for 'transactional' mail), but there is
> no mutual interest between senders and forwarders and there's no mutual
> interest between forwarders and receivers.

i beg to differ. there's barely a single forwarder online that's not connected
to either party in some way, and many are controlled, to a degree, by them.

so, basically, forwarders' problems are either receivers problems or senders
problems. however, solutions usually don't offer removing forwarders out of the
message path, for whatever reason. i've seen it many times.

so, we should work on protocols helping us to overcome whatever problems
forwarding brings into equation.


on the side note, i have contacted SRS main author about moving SRS to
IETF process. we'll see how that goes.


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


From nobody Sat Feb 15 15:55: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 7C4F81A022B for ; Sat, 15 Feb 2014 15:55:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8e9jVFUKZ9I for ; Sat, 15 Feb 2014 15:55:34 -0800 (PST)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 81D621A00E0 for ; Sat, 15 Feb 2014 15:55:34 -0800 (PST)
Received: by mail-we0-f169.google.com with SMTP id t61so9820902wes.28 for ; Sat, 15 Feb 2014 15:55:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B8WLZS5csIK7CNUqHCO1pM4aA9kh8JUUb2/cdyo3ups=; b=LTfVxHX+Dbvz1oCEcFHFOfsYWvGk3wLY/U/YTJL8bo6IoqgirYZ9H7dmAUAiwWJ0zr kEG35OVKEHo+8NOlVl/iWXHlEWTTFZ9/4ooi/Bl9Qy5rShGLIQDUWLJ5/3cRs5kUfe1y ZbNVtUDEs2Z3HOMEIC/tQBWB1wjpxaEm6kPmXOEfrvN4rNYn+qgIWRC6GiSP3AXQz90o 4lVzb6uWZmr9Mmrrbq3FSmMtvBSUgdnclzvZyRJ/RsDUTbkTNe3WCdVu8X8smsHFFnc1 6FMw5A0O7uh1MzbSSbJ3llNxcTvzL4VNMH8SzlBglBu9bmppzKe7a+1E9iEOBb7yWLhI nq/w==
MIME-Version: 1.0
X-Received: by 10.180.187.16 with SMTP id fo16mr7445046wic.26.1392508532059; Sat, 15 Feb 2014 15:55:32 -0800 (PST)
Received: by 10.180.90.132 with HTTP; Sat, 15 Feb 2014 15:55:31 -0800 (PST)
In-Reply-To: <1392464280.83879.YahooMailNeo@web164601.mail.gq1.yahoo.com>
References: <1392464280.83879.YahooMailNeo@web164601.mail.gq1.yahoo.com>
Date: Sat, 15 Feb 2014 15:55:31 -0800
Message-ID: 
From: "Murray S. Kucherawy" 
To: Vlatko Salaj 
Content-Type: multipart/alternative; boundary=001a11c266c466737a04f27aa813
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/f14txHa_x-C-eva2w7qGX1bHe-o
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] DMARC missing?
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Feb 2014 23:55:36 -0000

--001a11c266c466737a04f27aa813
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Feb 15, 2014 at 3:38 AM, Vlatko Salaj wrote:

> http://datatracker.ietf.org/list/wg
>
> still has no wgc or?


Right, there isn't a working group yet.  Discussions about what path it
should take through the IETF, if any, are ongoing.

-MSK

--001a11c266c466737a04f27aa813
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sat, Feb 15, 2014 at 3:38 AM, Vlatko Salaj <vlat=
ko.salaj@goodone.tk> wrote:


http://datatracker.ietf.org/list/wg



still has no wgc or?

Right, there isn't=
 a working group yet.=A0 Discussions about what path it should take through=
 the IETF, if any, are ongoing.

-MSK 




--001a11c266c466737a04f27aa813--


From nobody Sat Feb 15 16:02: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 7C1E61A00E0 for ; Sat, 15 Feb 2014 16:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWPHyEFVk9Hk for ; Sat, 15 Feb 2014 16:02:20 -0800 (PST)
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 4BC351A02C7 for ; Sat, 15 Feb 2014 16:02:20 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id a1so1292878wgh.34 for ; Sat, 15 Feb 2014 16:02:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/1T1SniHVKo7xx+4elsZkA4mE9i3uAXBb8hDjkY2Iy0=; b=jMcuy6xn23UdRTmg7vBwd2E/H4UIdLF9AVNC57NwQrhEbkhlZWMIuKnR4kx/pGcQ+l jabUcDZ0pN7Tdawf1fDn29uCX2vGIf6nyktKcspKE0KO4LsO68W528x6KmvcqGdjrV/g a4z4mssNANKkW+kbfoCA2uMAwzcjZ/3lSGhIl/fQCY7bgBGzxQiEoPDHcgVFkNDW648p PsZwO7H0ez1IxODITTyKYeFqbzQep1/bWvVdPE9fVHvBtp9hNvfW2SX/TpR7JFaSgR9c Kiq+vjtwgogugvSDi5uT6V0XyD6zPdtY1qzXETUgv5pGkrpJ7G+HWocr2U8Mxr/8EBhJ 5Y4w==
MIME-Version: 1.0
X-Received: by 10.180.97.72 with SMTP id dy8mr7421011wib.5.1392508937855; Sat, 15 Feb 2014 16:02:17 -0800 (PST)
Received: by 10.180.90.132 with HTTP; Sat, 15 Feb 2014 16:02:17 -0800 (PST)
In-Reply-To: <1392453948.82337.YahooMailNeo@web164601.mail.gq1.yahoo.com>
References:  <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com>  <1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com>  <1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com>  <1392453948.82337.YahooMailNeo@web164601.mail.gq1.yahoo.com>
Date: Sat, 15 Feb 2014 16:02:17 -0800
Message-ID: 
From: "Murray S. Kucherawy" 
To: Vlatko Salaj 
Content-Type: multipart/alternative; boundary=f46d04430670966be104f27ac095
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DNxtZCOMirCztxuae8yNVCanb-A
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 16 Feb 2014 00:02:23 -0000

--f46d04430670966be104f27ac095
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Feb 15, 2014 at 12:45 AM, Vlatko Salaj wrote:

> >> maybe spec should have a note about incompatibility with ATPS. but
> that's it.
> > ...but they aren't incompatible.
>
> i only skimmed ATPS specs, so maybe i misunderstood something. however, as
> far
> as i see it, the way it's defined is incompatible with DMARC.
>
> ATPS changes "d=" tag to 3rd party, while "from:" header remains 1st party.
> essentially, this breaks DKIM alignment, in DMARC terms. the only way ATPS
> could be compatible is as a DMARC policy override, similarly to the way
> ATPS defines compatibility with ADSP.
>

Correct, but a DKIM verifier that encounters proper ATPS use would simply
report to the DMARC module that the first party signed the message, and
alignment is thus not violated.  In the same way, an SPF module could
report a "pass" where SRS tells it so, even if pure SPF were to fail.
Thus, to me, they're the same kind of thing.


> so, mutually exclusive. imo, since ATPS standard is still in its making,
> it should be changed to account for DMARC. however, i'm not sure if that's
> possible, without making significant changes to DKIM as well.
>

It doesn't make sense to modify ATPS, which is a DKIM adjunct, to account
for DMARC, which is a layer above.


> or just use it as a policy override.
>

That's closer to what really happens.


> > SPF (the document, not so much the protocol) was just revised to change
> > its status from Experimental to Proposed Standard. SRS didn't come up
> > there either; the consensus supported a version that continued not to
> deal
> > with forwarding directly.
>
> i guess that answers a question i woke up today with: would any major
> mailbox provider be interested into adding SRS into their forwarding
> logic? considering how they look at SPF as annoyance as it is [yahoo
> not publishing any SPF records, for example], no wonder they don't
> like making that protocol even more hard to deploy.
>

I don't think they see SPF as an annoyance, but I also get the impression
that the forwarding issue is not enough of a pain point to roll out another
chunk of infrastructure.  (Don't make the mistake of underestimating the
cost in that for large operators.)


> SRS was made to deal with forwarders, in SPF terms. however, before SPF was
> finished, microsoft worked on expanding it to something we know now as
> SenderID. SenderID used plain SPF with no SRS, but instead introduced its
> own type of dealing with forwarders, mailing lists, u name it - called PRA
> [Purported Responsible Address]. considering microsoft pushed for its
> version
> quite a bit, and how SRS made SPF more difficult to implement, SRS never
> got
> enough interests or attention, it was left sidetracked, pushed away by a
> new
> promising idea - PRA.
>

That sounds closer to the history I remember, specifically the "made SPF
more difficult to implement".  The payoff for the added complexity didn't
seem to be there.


> however, PRA was so bad at the end, the entire working group ceased
> functioning cause of conflicts, causing riples between major mailbox
> owners...
>
> and now SenderID is dead, SPFs is easily broken in real world and SRS never
> got any ietf work.
>
> pity actually. but history always repeats itself now and then, i guess.
>

I think you just explained why DMARC went with the (SPF || DKIM) logic.

-MSK

--f46d04430670966be104f27ac095
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sat, Feb 15, 2014 at 12:45 AM, Vlatko Salaj <v=
latko.salaj@goodone.tk> wrote:
=



>> maybe spec should h=
ave a note about incompatibility with ATPS. but that's it.

> ...but they aren't incompatible.




i only skimmed ATPS specs, so maybe i misunderstood something. howeve=
r, as far

as i see it, the way it's defined is incompatible with DMARC.



ATPS changes "d=3D" tag to 3rd party, while "from:" hea=
der remains 1st party.

essentially, this breaks DKIM alignment, in DMARC terms. the only way ATPS<=
br>
could be compatible is as a DMARC policy override, similarly to the way

ATPS defines compatibility with ADSP.

C=
orrect, but a DKIM verifier that encounters proper ATPS use would simply re=
port to the DMARC module that the first party signed the message, and align=
ment is thus not violated.=A0 In the same way, an SPF module could report a=
 "pass" where SRS tells it so, even if pure SPF were to fail.=A0 =
Thus, to me, they're the same kind of thing.

=A0

so, mutually exclusive. imo, since ATPS standard is still in its making,
it should be changed to account for DMARC. however, i'm not sure if tha=
t's

possible, without making significant changes to DKIM as well.

It doesn't make sense to modify ATPS, which is a=
 DKIM adjunct, to account for DMARC, which is a layer above.
=A0



or just use it as a policy override.

Th=
at's closer to what really happens.
=A0

> SPF (the document, not so much the protocol) was just revised to chang=
e

> its status from Experimental to Proposed Standard. SRS didn't come=
 up

> there either; the consensus supported a version that continued not to =
deal

> with forwarding directly.




i guess that answers a question i woke up today with: would any major=


mailbox provider be interested into adding SRS into their forwarding

logic? considering how they look at SPF as annoyance as it is [yahoo

not publishing any SPF records, for example], no wonder they don't

like making that protocol even more hard to deploy.
I don't think they see SPF as an annoyance, but I also get=
 the impression that the forwarding issue is not enough of a pain point to =
roll out another chunk of infrastructure.=A0 (Don't make the mistake of=
 underestimating the cost in that for large operators.)

=A0
SRS was made to deal with forwa=
rders, in SPF terms. however, before SPF was

finished, microsoft worked on expanding it to something we know now as

SenderID. SenderID used plain SPF with no SRS, but instead introduced its
own type of dealing with forwarders, mailing lists, u name it - called PRA<=
br>
[Purported Responsible Address]. considering microsoft pushed for its versi=
on

quite a bit, and how SRS made SPF more difficult to implement, SRS never go=
t

enough interests or attention, it was left sidetracked, pushed away by a ne=
w

promising idea - PRA.

That sounds close=
r to the history I remember, specifically the "made SPF more difficult=
 to implement".=A0 The payoff for the added complexity didn't seem=
 to be there.

=A0

however, PRA was so bad at the end, the entire working group ceased

functioning cause of conflicts, causing riples between major mailbox owners=
...



and now SenderID is dead, SPFs is easily broken in real world and SRS never=


got any ietf work.



pity actually. but history always repeats itself now and then, i guess.
=


I think you just explained why DMARC went =
with the (SPF || DKIM) logic.

-MSK 




--f46d04430670966be104f27ac095--


From nobody Sun Feb 16 03:07: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 454491A0193 for ; Sun, 16 Feb 2014 03:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level: 
X-Spam-Status: No, score=-2.446 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.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf6X2DS5FbbY for ; Sun, 16 Feb 2014 03:07:03 -0800 (PST)
Received: from nm37.bullet.mail.ne1.yahoo.com (nm37.bullet.mail.ne1.yahoo.com [98.138.229.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6D51A01B6 for ; Sun, 16 Feb 2014 03:07:02 -0800 (PST)
Received: from [127.0.0.1] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 16 Feb 2014 11:07:00 -0000
Received: from [98.138.100.112] by nm37.bullet.mail.ne1.yahoo.com with NNFMP;  16 Feb 2014 11:04:05 -0000
Received: from [216.39.60.183] by tm103.bullet.mail.ne1.yahoo.com with NNFMP;  16 Feb 2014 11:04:05 -0000
Received: from [98.137.12.203] by tm19.bullet.mail.gq1.yahoo.com with NNFMP; 16 Feb 2014 11:04:05 -0000
Received: from [127.0.0.1] by omp1011.mail.gq1.yahoo.com with NNFMP; 16 Feb 2014 11:04:05 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 326501.4845.bm@omp1011.mail.gq1.yahoo.com
Received: (qmail 59022 invoked by uid 60001); 16 Feb 2014 11:04:05 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392548645; bh=lbEzSSqohnXaxUZVPepXXdZRo8/PWuUm6yCnIEJhNcQ=; 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=cRj4QspAG31N4JTqImsRO4C0CndV3ZfBvzdYtaV8U0UlesH/McdkwsTPml2b4NZ+7FbIcl6TpNVtrslIihPNw86GiHsTa8aAJHGKa3nNlpLhiEfnK3GcvwVRgSH5xIORe9yOCg3ovLueAlDU26v+MDileP0vx9nZKblQ58DTMCo=
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=sprXkJBPhw2W2qImLop+yGOfqHfmRNAfmpsOfALs6lf/ACA8i9UAJxI7SfP1KpN1V8dc/G65RcD8QMi27/eX9mV3tPZuhK1RWbZBCW+CgmWcJmaoTMX4Ayuex2vNmDhQb0/5vME963BP0xu21SbKbYRkW8nYoIGxc5zlgNh2eFk=;
X-YMail-OSG: JxN9BiwVM1mNLWqCMyiCrhkl3BUfyCIp0xZ3FEAB7P_KDRL vSSlOQfBLpcwbILoAUkuCR8S8Fx.dNbz4FauFTQYliPBA2Cnj_kMT2Wdvd9U tJIU7NGj6napTvv8KNrJMApXrdaeDYILnJnkH8NjBEqvWJinZAta_hGcnxaG vuoR8jLov5gZKRWU95QYA4Tpl1i1EYzIpC7w98F8cPGwVqs71GnNq2htRhi2 ZvvbqHB_EN14hgrZAZeimrmtg1SNfNRbB2KblAv73Z.7x49..Va.pFLez_6t usycrzcovFIS3aCehdxK.WBqjnzkK0K7361mM6qdgmJdK4e8yzJqXxT5wylp gqDrklOCDEugjrmSmmSDw1JywH4gK9IjB6kzdSObTetJ8huMefC_QRxgB.yl uZHnL3QV7TdwEFJ4gpuj8889spTdZisNTqxJ24RfntT8U4BBR9f6Kk2Co77c UNOysflkrdmJlrJxWZ1wYXfv4qXkckLp0xC_fRdSPbXFgIfVze2aNT9OSCYo ..FkOBNeWV3CGCOjcrqwcw6VFWZa9nOUzP_zmRAVcfKSZJk0kSgzruBOfO0x uKs8rIaisXxH5L62JFle8CQOkh.QRe7mLCZuSwE0oRI2lKtjhUAzJAObG7_z xv1YAqV3zAJIRVpk-
Received: from [79.175.120.161] by web164603.mail.gq1.yahoo.com via HTTP; Sun, 16 Feb 2014 03:04:05 PST
X-Rocket-MIMEInfo: 002.001, T24gU3VuZGF5LCBGZWJydWFyeSAxNiwgMjAxNCAxOjAyIEFNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPiB3cm90ZToKCgo.PiBBVFBTIGNoYW5nZXMgImQ9IiB0YWcgdG8gM3JkIHBhcnR5LCB3aGlsZSAiZnJvbToiIGhlYWRlciByZW1haW5zIDFzdCBwYXJ0eS4KPiBDb3JyZWN0LCBidXQgYSBES0lNIHZlcmlmaWVyIHRoYXQgZW5jb3VudGVycyBwcm9wZXIgQVRQUyB1c2Ugd291bGQgc2ltcGx5Cj4gcmVwb3J0IHRvIHRoZSBETUFSQyBtb2R1bGUgdGhhdCB0aGUgZmlyc3QgcGEBMAEBAQE-
X-RocketYMMF: gwzrd
X-Mailer: YahooMailWebService/0.8.177.636
References: 	<1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com>		<1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com>		<1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com>		<1392453948.82337.YahooMailNeo@web164601.mail.gq1.yahoo.com>  
Message-ID: <1392548645.55280.YahooMailNeo@web164603.mail.gq1.yahoo.com>
Date: Sun, 16 Feb 2014 03:04:05 -0800 (PST)
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/xR6DlSLJBAaef-qaXBeWBiMIz2Q
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
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, 16 Feb 2014 11:07:05 -0000

On Sunday, February 16, 2014 1:02 AM, Murray S. Kucherawy  wrote:


>> ATPS changes "d=" tag to 3rd party, while "from:" header remains 1st party.
> Correct, but a DKIM verifier that encounters proper ATPS use would simply
> report to the DMARC module that the first party signed the message, and
> alignment is thus not violated.

if, and only if, we change DMARC specs to accommodate. and section 3.1.4.1.
is 1st in the line. we need to remove all "d=" references, and just stick
with: "DKIM authenticated domain".

but, yes, this seems right way to go, and doesn't seem a big problem to fix.


> In the same way, an SPF module could report a "pass" where SRS tells it so,
> even if pure SPF were to fail. Thus, to me, they're the same kind of thing.

it's not completely similar to ATPS. even when we use SRS, SPF alignment will
fail. however, SPF will pass, and this way, a receiver has additional data to
evaluate such sending host as a probable reliable forwarder. it helps much in
situations when receiver has little useful data to make such evaluation using
other mechanisms, or evaluation between mechanisms is contradicting.

SRS helps with DMARC policy override, as Franck concluded previously.


>> i guess that answers a question i woke up today with: would any major
>> mailbox provider be interested into adding SRS into their forwarding
>> logic? considering how they look at SPF as annoyance as it is [yahoo
>> not publishing any SPF records, for example], no wonder they don't
>> like making that protocol even more hard to deploy.
> I don't think they see SPF as an annoyance, but I also get the impression that
> the forwarding issue is not enough of a pain point to roll out another chunk
> of infrastructure.

they should. all of major ESPs provide forwarding as a service, thus breaking
more than one protocol. and i am not sure if any of them tries to accommodate
for such issues, while doing so.


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


From nobody Mon Feb 17 04:59: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 EE6541A01DA for ; Mon, 17 Feb 2014 04:59:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.547
X-Spam-Level: 
X-Spam-Status: No, score=-0.547 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.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NABsQlRCHsAQ for ; Mon, 17 Feb 2014 04:59:23 -0800 (PST)
Received: from nm36.bullet.mail.ne1.yahoo.com (nm36.bullet.mail.ne1.yahoo.com [98.138.229.29]) by ietfa.amsl.com (Postfix) with ESMTP id CF76E1A01C5 for ; Mon, 17 Feb 2014 04:59:22 -0800 (PST)
Received: from [127.0.0.1] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 17 Feb 2014 12:59:19 -0000
Received: from [98.138.100.113] by nm36.bullet.mail.ne1.yahoo.com with NNFMP;  17 Feb 2014 12:56:19 -0000
Received: from [98.137.12.60] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 17 Feb 2014 12:56:19 -0000
Received: from [98.137.12.225] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 17 Feb 2014 12:56:19 -0000
Received: from [127.0.0.1] by omp1033.mail.gq1.yahoo.com with NNFMP; 17 Feb 2014 12:56:19 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 156263.41650.bm@omp1033.mail.gq1.yahoo.com
Received: (qmail 98079 invoked by uid 60001); 17 Feb 2014 12:56:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392641778; bh=C5IpQ2jXoBQkKxzQ/21xcR5wh9rxPYQ0HkDj4BEvAdo=; 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=tMh5kN667h4rs/cS860b9PI3rP83jiqiQoRpxBf1JAEVQ8KAlLXi2HJZpSxiEtkYlmzma1T7SuYrpw8hGOmMq9yjegC6n8BvdVFKsOywwdEAIxqDjLFSkNtPfflTtvZxjcqd6/9rwwzdZuUKQ45TYZXEIspRl8Qekhfw38FVpnA=
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=SFpvNvdY+5HUgsUGOy5oikcSNlXlnBj0PWLjjf6Tu2JM1DYxa9Xs87csS0ojzWk4ONhoUyc5eabWogFun9HkECvVPwXKbqUfwzbsbDKQaLkuszmHuM2wDxDh4KGCtePuCXsziGkgb7bsZaTPtdf6RcjNMS45PtB7ddOSxyr8+FM=;
X-YMail-OSG: skAhjjoVM1nxUImGi5ZQamsUO5PO3XVijpNEyKp1Ya9M1fE fWKl897opqgsrlvebwl5w_kj5CzwB0M5IjkGnTj86tpXZuoDXQKkKUpGwNbF lTNZbv4PxBWMaDkVGpcDWwQ6BM8j_fBziphR1Kwct2Y0OjM3kHL.uGqguym6 5OVM3OaNy3JoBa6.DHlvYZix1gZ9_SsXGFKo198nwU_P1vg4QGwwrSHhJT1a gZMrq.f5Vsu2wo8rcaeGA52c7epIuvhNmwzyqPgqXBC3bJ4RDOqQYtMoD0h_ iJQNEmSU1zkwsmlEiiPF6B5C_wnphodR9kjN4LG_HiiL9wUxOCnwJOU.GPJj XbzEtpvotF__7gR1k7ecfvuDwF6J3NufsM9U34HMHQQIYjMdCvCjy9vJhaA1 dl0fQ3FAhdNGm5Xu2PumZP32ELAu8Ab4TDJ2M_79VsliDCBabkfAP5cNpiP0 e.LRcls1qUfc5iJWk9poAua07EhPuXwqqB7DKr3U3uSryvoCsCv6rvWYimnR T7uZ1XE1Yf1J7GoDmSG7LqKf1Mrb6929eKEdO4_vzLPoPg3OqnpUT.bi1Tlb CngPiZnALYqC4JAVxdeTSmJKJclfy.JqAzm8KTrYBZqOSSOl.JvE35wCqtDP h7um_L9N9QQQOt3K.CJiCwA--
Received: from [79.175.120.161] by web164606.mail.gq1.yahoo.com via HTTP; Mon, 17 Feb 2014 04:56:18 PST
X-Rocket-MIMEInfo: 002.001, b21nLCBhbSBpIGdvbm5hIG1ha2Ugc29tZSBwcGwgYW5ub3llZCBub3cuLi4gOkQKCgppJ20gc3VyZSB0aGVyZSBpcyBhYnVuZGFuY2Ugb2YgYnJhaW4gcG93ZXIgb24gdGhpcyBsaXN0LCBzbyBpJ20gZ29ubmEgc3RhcnQKYSBuZXcgaWRlYSwgc29tZXRoaW5nIHRoYXQgY2FtZSB0byBtZSBpbiBkcmVhbXMgbGFzdCBuaWdodCBbbm8gbWF0dGVyIGhvdwpvZGQgdGhhdCBtYXkgc2VlbV0uCgp0aGUgaXNzdWUgaXMgc2ltcGxlLCBidXQgZG9lcyByYWlzZSBzb21lIHBvc3NpYmxlIGJlbmVmaXQgZm9yIERNQVJDLCABMAEBAQE-
X-RocketYMMF: gwzrd
X-Mailer: YahooMailWebService/0.8.177.636
References:  
Message-ID: <1392641778.96007.YahooMailNeo@web164606.mail.gq1.yahoo.com>
Date: Mon, 17 Feb 2014 04:56:18 -0800 (PST)
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/tqyxYBCPzio8WbgUgcEBQ49Q-D8
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
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, 17 Feb 2014 12:59:26 -0000

omg, am i gonna make some ppl annoyed now... :D=0A=0A=0Ai'm sure there is a=
bundance of brain power on this list, so i'm gonna start=0Aa new idea, some=
thing that came to me in dreams last night [no matter how=0Aodd that may se=
em].=0A=0Athe issue is simple, but does raise some possible benefit for DMA=
RC, in context=0Aof verbatim forwarders.=0A=0A=0Ait seems to me that SRS co=
uld be useful to DMARC well beyond the point of policy=0Aoverride. it can h=
elp report original sender domain to DMARC, and thus help=0ASPF pass both c=
hecks - itself and its alignment.=0A=0Aconsidering SPF was changed recently=
, in 4408bis draft, to prefer EHLO/HELO=0Aidentity to MAIL FROM, a change t=
hat actually deals with the same problem SRS=0Adeals with, to a degree, thu=
s making the forwarding issue less pronounced in SPF=0Aspecs, it's no longe=
r so important to get SRS inside that spec. the fact that=0ASPF is currentl=
y under review for a full fledged standard makes this even less=0Adesirable=
.=0A=0Aon the other side, the issue of SPF alignment check, in DMARC evalua=
tion of=0Aa message passing through a verbatim forwarder, is still a presen=
t problem.=0Anot only the most common forwarder deployment breaks SPF align=
ment, it usually=0Abreaks DKIM signature too, by removing or changing some =
presigned headers -=0Alike "sender:" header.=0A=0A=0Aso, what if we were to=
 include SRS as an additional mechanism to DMARC, one that=0Awould help wit=
h alignment issues on messages that pass SPF checks but fail=0Aalignment.=
=0A=0A=0Ait would work something like this:=0A=0A1. SPF verifier checks SPF=
 on a message,=0A=0A2. if SPF verification passes, make a check: is MAIL FR=
OM an SRS type address?=0A=0A3. if MAIL FROM is an SRS type address, extrac=
t original sender domain from it,=0A=A0=A0 and use it for DMARC SPF-alignme=
nt purposes.=0A=0A=0Ai realize this is a long shot. but the idea is running=
 around my head, and=0Ai can't shake it off.=0A=0Anow, we need some big min=
ds to evaluate any weaknesses in this mechanism, and=0Adevise as simple as =
possible solutions to prevent abuse, if any exists. if we=0Awere to devise =
such solution, this would be a complete fix for forwarders=0Ain SPF/DMARC a=
lignment context, possibly raising the capability bar of DMARC=0Aand loweri=
ng its false evaluation of legitimate mail, which is, currently,=0Asomewhat=
 of a problem, cause it doesn't cover the wide range of email=0Asolutions a=
nd techniques.=0A=0Aactually, SRS could even be extended to a fully fledged=
 supported protocol,=0Aa 3rd one, in DMARC terms, somewhat of a fallback ca=
se when SPF/DKIM checks=0Aare insufficient.=0A=0Aas far as i can tell, the =
only viable abuse comes from hosts that spoof email.=0Ahowever, nothing for=
bids them from spoofing DKIM also, thus passing DMARC, so=0Asuch hosts are =
already candidates to other anti-abuse algorithms. farther=0Amore, SRS enab=
led DMARC could help receivers discover abusive hosts with=0Amuch greater d=
egree of probability.=0A=0Aactually, to deal with this problem too, if SRS =
checks were to be accepted as=0A3rd DMARC protocol, DMARC could be changed =
from OR OR to AND AND evaluation=0Acase. this would, if not close, then tig=
hten the area for abuse even further.=0A=0A=0Ai know i'm proposing a great =
deal of change. however, imo, this SHOULD be=0Awelcomed, as defined in RFC =
2119. :D=0A=0A=0Aur thoughts? plz, try to be open-minded as much as possibl=
e.=0A=0A=0Aps. SRS will b moving to IETF. shevek, original developer and ma=
intainer of=0ASRS, has welcomed the idea. now, if only we could find time t=
o learn how and=0Aactually make such thing happen. :)=0A=0A=0A-- =0AVlatko =
Salaj aka goodone=0Ahttp://goodone.tk


From nobody Mon Feb 17 07:31: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 063681A04A5 for ; Mon, 17 Feb 2014 07:31:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 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, 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 I3ZCb_6n7Qxg for ; Mon, 17 Feb 2014 07:31:26 -0800 (PST)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 57AA21A03EC for ; Mon, 17 Feb 2014 07:31:26 -0800 (PST)
Received: by mail-wi0-f169.google.com with SMTP id e4so2493158wiv.4 for ; Mon, 17 Feb 2014 07:31:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=nfexAqCx/3MCA1ZDeQC3OaAqO+SNenEXtFOB0g8N17c=; b=JZ4Tq7pQVZM4EPvEgb2EftfoEA+m4nhLSUP6iScjtMSL9ewreVuGeB/NYlm8RlLbsr ExeVdENg4degbc8NcXJDJPjT+cXRyWj93oYARMmbjcAb/EQPkXahbICLDqcK/MjMtb3+ 7dHSJoSn0k3Fq5BZcQJIWe046LuAHROl4xzpk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nfexAqCx/3MCA1ZDeQC3OaAqO+SNenEXtFOB0g8N17c=; b=Ra9L3FG+1jpk3gVDavHnzp5xePAO4UYzBNIrFJt8OaWjQqQFnEzWXM8pPmo7xNpwS+ T7QkGx1S79lxjPOkC/y4HyEbzRvyb5snWwaYcgsTC7r2hhAw7pR6XCDgEdPDW5noFCJ7 hcAuYNdmZ4L2tiVkrVZ6zTWu776IapoYkaFzSseTEwtVISsUo/MzhN44q3rh58KE149s i2g4tDqYcdunJ9gV88oYx914YHvIQ0dol5eMX8DQqzN9JbLq3YXMJLmvs1JGP/5tuXBI YztZlSFUCZty8KD58X6pkgVqR2kkopaMW3ZeJOUprpBbh43Eurld4Wk4ZcjgnLATPehZ 7FpA==
X-Gm-Message-State: ALoCoQlU9E+XXZPJqvbwDfhuopmMUZIcU/mwA0T18D7tN1ZpUrRTKHATOGeGaDeRMU+21RvKZlvN
MIME-Version: 1.0
X-Received: by 10.181.13.40 with SMTP id ev8mr13740945wid.16.1392651076041; Mon, 17 Feb 2014 07:31:16 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.195.12.137 with HTTP; Mon, 17 Feb 2014 07:31:15 -0800 (PST)
In-Reply-To: <1392641778.96007.YahooMailNeo@web164606.mail.gq1.yahoo.com>
References:  <1392641778.96007.YahooMailNeo@web164606.mail.gq1.yahoo.com>
Date: Mon, 17 Feb 2014 07:31:15 -0800
X-Google-Sender-Auth: hcIF_49lyfhVPdfIdGE_JImCt8U
Message-ID: 
From: Kurt Andersen 
To: Vlatko Salaj 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/pH_Wrs3OJO6i9adMujoQ2uPwZkI
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 17 Feb 2014 15:31:28 -0000

On Mon, Feb 17, 2014 at 4:56 AM, Vlatko Salaj  wrote:
> [Proposes SRS as an alternate authentication mechanism]. . .
> as far as i can tell, the only viable abuse comes from hosts that spoof email.
> however, nothing forbids them from spoofing DKIM also, . . .

Spoofing of email is exactly the problem. Using SRS as you propose
actually would give abusers a clear path to spoof any domain that they
would like to emulate.

I don't understand your contention that anyone can spoof DKIM for a
domain not within their control. . .

--Kurt Andersen


From nobody Mon Feb 17 07:46: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 EB9D41A0502 for ; Mon, 17 Feb 2014 07:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v0pGq_VA53p for ; Mon, 17 Feb 2014 07:46:07 -0800 (PST)
Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5EACC1A024B for ; Mon, 17 Feb 2014 07:46:05 -0800 (PST)
Received: by mail-pb0-f50.google.com with SMTP id rq2so15506671pbb.37 for ; Mon, 17 Feb 2014 07:45:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3TMC6szU7Cx+ET5kUjEs1qPNcpKdpPrhc4YmebgRNxk=; b=WU4xIXDKsL28f8GxWc5BD5XVjQYrRIoFWUC+fbkxqchANNz6TSchO9bfMTTqzioYDM DwMIBlz1hhQJTqwK0jArq9BszvDnPtLHI+7kPO/OZpTQF0t94Hi2+Tf8UL29kMtfC7yK WVAUpF3ZOt0m0sT+Q2pvQ7qGzje14o6YZaH6HLhYeyAqIoiBxLWAk8dzZauX9gOehWXl uuqj8cFl5oUfLt/RMT64C7gFzt8HbidSbMOdgdARyCpIYYqXQUL3c+ZQS12Mpo+NIgfd RIA9bRIpENg/EONExXqIJ3N1yVHSLqerp4DK6cT6ktnUspQi3xhNO52fWlYRBuEzE0N8 gGSQ==
X-Received: by 10.66.253.33 with SMTP id zx1mr27287851pac.28.1392651927905; Mon, 17 Feb 2014 07:45:27 -0800 (PST)
Received: from [192.168.19.2] ([172.56.38.141]) by mx.google.com with ESMTPSA id bz4sm46910406pbb.12.2014.02.17.07.45.14 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Feb 2014 07:45:16 -0800 (PST)
Message-ID: <53022E55.9070604@gmail.com>
Date: Mon, 17 Feb 2014 07:44:21 -0800
From: Dave Crocker 
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:  <1392641778.96007.YahooMailNeo@web164606.mail.gq1.yahoo.com>
In-Reply-To: <1392641778.96007.YahooMailNeo@web164606.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/lbQBlRXQkIXBRdGY7aLohgxivZ8
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 17 Feb 2014 15:46:09 -0000

On 2/17/2014 4:56 AM, Vlatko Salaj wrote:
> nothing forbids them from spoofing DKIM also,


1.  In precise technical terms, what do you mean by "spoofing DKIM"?


2.  If you are suggesting anything like a claim that DKIM's 
authentication signature can be forged, you are suggesting that its 
cryptographic mechanisms are insufficient.  If so, please explain /very/ 
carefully.  DKIM uses established crypto.


3.  If you mean that some other mechanism in a DKIM system is 
compromised, please explain that /very/ carefully.



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Mon Feb 17 08:18: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 3DB5B1A050A for ; Mon, 17 Feb 2014 08:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Mm-xUwRfyqX for ; Mon, 17 Feb 2014 08:18:50 -0800 (PST)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDAA1A050C for ; Mon, 17 Feb 2014 08:18:50 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id y10so2383857wgg.28 for ; Mon, 17 Feb 2014 08:18:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wCzn7ZPPg1fV/c0mmz85dn3xikIuaRrNbBv14w677rg=; b=jYWTzu3era9yok1iRfwDJK4tIJHqrJtMhV6J6QfshDsl4/kMBiGqfngpWrc3g1miks AbwZjQKkXwiJAs1AXx6BmFtT4IcuC+3jwEL9Bb9ENR0uDOddfoaRliiLAb56Gv9JQHw2 ecpQv+hqJNLW6S+x+ty3TE6Ddhxs1tfHqFP7pOIM8zq4Z87ezrYzdQx8iL4oMY9Ns2dG 82vFVoUxmb0XADbhjChPM9dLBtbr72rSBmYPuD5o0AO10IJ9D+bGp10/0cehS7wm/1QU l2ZGqOfQITyXuG/QLLfGZHkBt8FaYntYS4lDUBTVN++/MSudRsk743iC3kSJgE6MD+/S QNxA==
MIME-Version: 1.0
X-Received: by 10.180.12.233 with SMTP id b9mr13706877wic.8.1392653927044; Mon, 17 Feb 2014 08:18:47 -0800 (PST)
Received: by 10.180.90.132 with HTTP; Mon, 17 Feb 2014 08:18:46 -0800 (PST)
In-Reply-To: <1392548645.55280.YahooMailNeo@web164603.mail.gq1.yahoo.com>
References:  <1392372109.24291.YahooMailNeo@web164601.mail.gq1.yahoo.com>  <1392405289.65268.YahooMailNeo@web164605.mail.gq1.yahoo.com>  <1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com>  <1392453948.82337.YahooMailNeo@web164601.mail.gq1.yahoo.com>  <1392548645.55280.YahooMailNeo@web164603.mail.gq1.yahoo.com>
Date: Mon, 17 Feb 2014 08:18:46 -0800
Message-ID: 
From: "Murray S. Kucherawy" 
To: Vlatko Salaj 
Content-Type: multipart/alternative; boundary=001a11c241149dde0304f29c823e
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BYyn2vlqDKVl-IGENJIQCL2i88I
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 17 Feb 2014 16:18:53 -0000

--001a11c241149dde0304f29c823e
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Feb 16, 2014 at 3:04 AM, Vlatko Salaj wrote:

> > In the same way, an SPF module could report a "pass" where SRS tells it
> so,
> > even if pure SPF were to fail. Thus, to me, they're the same kind of
> thing.
>
> it's not completely similar to ATPS. even when we use SRS, SPF alignment
> will
> fail. however, SPF will pass, and this way, a receiver has additional data
> to
> evaluate such sending host as a probable reliable forwarder. it helps much
> in
> situations when receiver has little useful data to make such evaluation
> using
> other mechanisms, or evaluation between mechanisms is contradicting.
>
> SRS helps with DMARC policy override, as Franck concluded previously.
>

This has devolved into hair-splitting now.  Both of them provide
information for DMARC policy overrides.  You can either modify your SPF or
DKIM module to return a modified result based on the SRS or ATPS,
respectively, or the information can be provided separately.  The result is
the same: alignment where there was none previously.


> > I don't think they see SPF as an annoyance, but I also get the
> impression that
> > the forwarding issue is not enough of a pain point to roll out another
> chunk
> > of infrastructure.
>
> they should. all of major ESPs provide forwarding as a service, thus
> breaking
> more than one protocol. and i am not sure if any of them tries to
> accommodate
> for such issues, while doing so.
>

Perhaps, but again, it has not created enough of a problem to warrant
action.  Action is expensive.  If more people complained about it, the
answer might be different.  But, apparently, they don't.

-MSK

--001a11c241149dde0304f29c823e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Sun, Feb 16, 2014 at 3:04 AM, Vlatko Salaj <vlat=
ko.salaj@goodone.tk> wrote:


> In the same way, an SPF module could re=
port a "pass" where SRS tells it so,

> even if pure SPF were to fail. Thus, to me, they're the same kind =
of thing.




it's not completely similar to ATPS. even when we use SRS, SPF al=
ignment will

fail. however, SPF will pass, and this way, a receiver has additional data =
to

evaluate such sending host as a probable reliable forwarder. it helps much =
in

situations when receiver has little useful data to make such evaluation usi=
ng

other mechanisms, or evaluation between mechanisms is contradicting.



SRS helps with DMARC policy override, as Franck concluded previously.

This has devolved into hair-splitting now.=
=A0 Both of them provide information for DMARC policy overrides.=A0 You can=
 either modify your SPF or DKIM module to return a modified result based on=
 the SRS or ATPS, respectively, or the information can be provided separate=
ly.=A0 The result is the same: alignment where there was none previously.
=A0


> I don't think they see SPF as an annoyance, but I =
also get the impression that

> the forwarding issue is not enough of a pain point to roll out another=
 chunk

> of infrastructure.




they should. all of major ESPs provide forwarding as a service, thus =
breaking

more than one protocol. and i am not sure if any of them tries to accommoda=
te

for such issues, while doing so.

Perhap=
s, but again, it has not created enough of a problem to warrant action.=A0 =
Action is expensive.=A0 If more people complained about it, the answer migh=
t be different.=A0 But, apparently, they don't.


-MSK


--001a11c241149dde0304f29c823e--


From nobody Mon Feb 17 08:22: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 4EB461A0512 for ; Mon, 17 Feb 2014 08:22:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaj47jHr8nJi for ; Mon, 17 Feb 2014 08:22:03 -0800 (PST)
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 309671A050F for ; Mon, 17 Feb 2014 08:22:03 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id t61so10650678wes.22 for ; Mon, 17 Feb 2014 08:22:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nrbq8mIH3lPbn80vSEMoAI787O34pW8as854krK8nhQ=; b=nRL8y3X+gwen4TzC8U4qAMccBrIQYiffLNaW1eWaEvfHWLOPgfjcZchy2FKs4mkjPA 0eeHe+xXgS+HP+AsvAdCbh9mseHm0ySRhHUUXPtwKaZkLt0iTXjFI0CfDvRjTHOi9ICh SlNSeuhSiSWlBXdjy+xRE6p0nahPspFkJ8aft3aJhipMHeAQWA9dwSSNUpRtI5AN+nLX M11c6eKA6TTrKJg5YtrNNeOE5CaEafJs7/hLKmqahWMWo+bZlNvTTmG81p49TJ8mVaQ2 VaBcaTjolUSd8Z0Jff6yo7Hui3fnLWIf9XfkgguNgW7UBtDV8xKN1yTNDr084KQEVQRi DagQ==
MIME-Version: 1.0
X-Received: by 10.180.187.16 with SMTP id fo16mr13788945wic.26.1392654120145;  Mon, 17 Feb 2014 08:22:00 -0800 (PST)
Received: by 10.180.90.132 with HTTP; Mon, 17 Feb 2014 08:21:59 -0800 (PST)
In-Reply-To: <1392641778.96007.YahooMailNeo@web164606.mail.gq1.yahoo.com>
References:  <1392641778.96007.YahooMailNeo@web164606.mail.gq1.yahoo.com>
Date: Mon, 17 Feb 2014 08:21:59 -0800
Message-ID: 
From: "Murray S. Kucherawy" 
To: Vlatko Salaj 
Content-Type: multipart/alternative; boundary=001a11c266c420582304f29c8e70
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/b6RLYt7uOXuV4LaP5HHHAac4PeM
Cc: "dmarc@ietf.org" 
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 17 Feb 2014 16:22:05 -0000

--001a11c266c420582304f29c8e70
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 17, 2014 at 4:56 AM, Vlatko Salaj wrote:

>
> considering SPF was changed recently, in 4408bis draft, to prefer EHLO/HELO
> identity to MAIL FROM, a change that actually deals with the same problem
> SRS
> deals with, to a degree, thus making the forwarding issue less pronounced
> in SPF
> specs, it's no longer so important to get SRS inside that spec. the fact
> that
> SPF is currently under review for a full fledged standard makes this even
> less
> desirable.
>

I was a participant in the SPFBIS working group, and I don't remember
anything about changing to prefer HELO/EHLO over MAIL FROM.  Can you point
me to that change?

ps. SRS will b moving to IETF. shevek, original developer and maintainer of
> SRS, has welcomed the idea. now, if only we could find time to learn how
> and
> actually make such thing happen. :)
>

There's plenty of documentation online to get him started.  We can provide
links to reading materials if he needs such.

-MSK

--001a11c266c420582304f29c8e70
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On Mon, Feb 17, 2014 at 4:56 AM, Vlatko Salaj <vlat=
ko.salaj@goodone.tk> wrote:




considering SPF was changed recently, in 4408bis draft, to prefer EHLO/HELO=


identity to MAIL FROM, a change that actually deals with the same problem S=
RS

deals with, to a degree, thus making the forwarding issue less pronounced i=
n SPF

specs, it's no longer so important to get SRS inside that spec. the fac=
t that

SPF is currently under review for a full fledged standard makes this even l=
ess

desirable.

I was a participant in the S=
PFBIS working group, and I don't remember anything about changing to pr=
efer HELO/EHLO over MAIL FROM.=A0 Can you point me to that change?




ps. SRS will b moving to IETF. shevek, original developer and maintainer of=


SRS, has welcomed the idea. now, if only we could find time to learn how an=
d

actually make such thing happen. :)

The=
re's plenty of documentation online to get him started.=A0 We can provi=
de links to reading materials if he needs such.

-MSK 




--001a11c266c420582304f29c8e70--


From nobody Mon Feb 17 09:16: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 9F6FB1A0081 for ; Mon, 17 Feb 2014 09:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e_QyOtW3G7Ek for ; Mon, 17 Feb 2014 09:16:09 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id CEC0D1A00B4 for ; Mon, 17 Feb 2014 09:16:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 46C423F40EC; Mon, 17 Feb 2014 11:16:07 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkuvDlyyojXa; Mon, 17 Feb 2014 11:16:07 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 206D93F40ED; Mon, 17 Feb 2014 11:16:07 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 09CE43F40EC; Mon, 17 Feb 2014 11:16:07 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6Ev8FKqrrADr; Mon, 17 Feb 2014 11:16:06 -0600 (CST)
Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 2AC813F40EB; Mon, 17 Feb 2014 11:16:05 -0600 (CST)
Date: Mon, 17 Feb 2014 11:16:04 -0600 (CST)
From: Franck Martin 
To: "Murray S. Kucherawy" 
Message-ID: <39520223.21433.1392657364901.JavaMail.zimbra@peachymango.org>
In-Reply-To: 
References:  <1392414702.25295.YahooMailNeo@web164604.mail.gq1.yahoo.com>  <1392453948.82337.YahooMailNeo@web164601.mail.gq1.yahoo.com>  <1392548645.55280.YahooMailNeo@web164603.mail.gq1.yahoo.com>  
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_21432_467652149.1392657364901"
X-Originating-IP: [64.1.211.245]
X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF27 (Mac)/8.0.5_GA_5839)
Thread-Topic: SRS helps SPF/DMARC
Thread-Index: DzuO/dhpQL9m8lCQbbJIF1Gs/bhl1Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jR6nFTcSujiSGQeuwsKuGYhFg08
Cc: Vlatko Salaj , dmarc@ietf.org
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 17 Feb 2014 17:16:12 -0000

------=_Part_21432_467652149.1392657364901
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


----- Original Message -----

From: "Murray S. Kucherawy"  
To: "Vlatko Salaj"  
Cc: dmarc@ietf.org 
Sent: Monday, February 17, 2014 8:18:46 AM 
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC 

On Sun, Feb 16, 2014 at 3:04 AM, Vlatko Salaj < vlatko.salaj@goodone.tk > wrote: 


> In the same way, an SPF module could report a "pass" where SRS tells it so, 
> even if pure SPF were to fail. Thus, to me, they're the same kind of thing. 

it's not completely similar to ATPS. even when we use SRS, SPF alignment will 
fail. however, SPF will pass, and this way, a receiver has additional data to 
evaluate such sending host as a probable reliable forwarder. it helps much in 
situations when receiver has little useful data to make such evaluation using 
other mechanisms, or evaluation between mechanisms is contradicting. 

SRS helps with DMARC policy override, as Franck concluded previously. 




No, I said, it may help, but this is for each receiver to decide how it applies overrides at the sole risk of the receiver. Any override opens a security hole, therefore this is discouraged and should not be standardized. 

I think you need to implement DMARC, apply some of these techniques, and come back to us with some data, experience. 

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


------=_Part_21432_467652149.1392657364901
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable



From: "Murray S. K=
ucherawy" <superuser@gmail.com>
To: "Vlatko Salaj" <vlat=
ko.salaj@goodone.tk>
Cc: dmarc@ietf.org
Sent: Monday=
, February 17, 2014 8:18:46 AM
Subject: Re: [dmarc-ietf] SRS help=
s SPF/DMARC

On Sun, Feb 16, 2014 at 3:04=
 AM, Vlatko Salaj <=
vlatko.salaj@goodone.tk> wrote:
&g=
t; In the same way, an SPF module could report a "pass" where SRS tells it =
so,
> even if pure SPF were to fail. Thus, to me, the=
y're the same kind of thing.
 
it's not completely similar to A=
TPS. even when we use SRS, SPF alignment will
 fail. however, SPF will p=
ass, and this way, a receiver has additional data to
 evaluate such send=
ing host as a probable reliable forwarder. it helps much in
 situations =
when receiver has little useful data to make such evaluation using
 othe=
r mechanisms, or evaluation between mechanisms is contradicting.
 
 S=
RS helps with DMARC policy override, as Franck concluded previously.

No, I said, it may help, but this is for each rece=
iver to decide how it applies overrides at the sole risk of the receiver. A=
ny override opens a security hole, therefore this is discouraged and should=
 not be standardized.

I think you need to implement DMARC, apply some of thes=
e techniques, and come back to us with some data, experience.

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



------=_Part_21432_467652149.1392657364901--


From nobody Mon Feb 17 23:49: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 E3C3F1A042F for ; Mon, 17 Feb 2014 23:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level: 
X-Spam-Status: No, score=-1.846 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_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] 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 x5PrgwREf_pD for ; Mon, 17 Feb 2014 23:49:01 -0800 (PST)
Received: from nm47.bullet.mail.ne1.yahoo.com (nm47.bullet.mail.ne1.yahoo.com [98.138.120.54]) by ietfa.amsl.com (Postfix) with ESMTP id B4ECC1A0056 for ; Mon, 17 Feb 2014 23:49:00 -0800 (PST)
Received: from [127.0.0.1] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 07:48:57 -0000
Received: from [98.138.100.115] by nm47.bullet.mail.ne1.yahoo.com with NNFMP;  18 Feb 2014 07:46:00 -0000
Received: from [98.137.12.56] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 07:46:00 -0000
Received: from [98.137.12.224] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2014 07:46:00 -0000
Received: from [127.0.0.1] by omp1032.mail.gq1.yahoo.com with NNFMP; 18 Feb 2014 07:46:00 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 96457.34693.bm@omp1032.mail.gq1.yahoo.com
Received: (qmail 24543 invoked by uid 60001); 18 Feb 2014 07:46:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392709559; bh=+IXtxrsB51yrDmlZF6ICV3H7ypKlC1CPiRp85szf0Iw=; 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=w0yVbcn5hN2iR8641aXwvrEEex+rg/1v/qsIrT5JNQHqhNd0QqsESB4fhrR8CEwKm5g3BhTdrIVg5itmBtRURW6BU8yJLpLZON+0+aWZxBmmFWC+UT1ld0wtxhv/LQjNdCVXOE80eykF4RDyS4f9hWkbBMK1wpxr4EP22jo6LWM=
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=IUL9+ubPavn6ZNr6xfC+OIBbNfqJcl7oVHyiuVHTo+um3G4ViOrJfZiM9zAWwALxBaHgVfrakLmWwdSf4Hi/sS5DlfgNLTZ0jHA1g/TEQaesy7tTdZVxpkhqfZ7Eb5n7fWnjnChKCGqzbRC3+xAYnpp3jjWQwIlSwh+1VDqYaMk=;
X-YMail-OSG: I.Er3aUVM1l3H4sdJyVu...CdB51w4r.R82RnB31siDQcIl tiOyWGf7Mfw0f4c.PlnHqmcnoXcdkdCZ1EAdKhTH4VxBhOGHtLsT7KlJdQev v.tvUy0FExE41B1dgtGsXHqYeeL9qVQ1vmEkGVJVEC_FGlNirX6.yUearj6e WOxHrQI1n.LsOMed09qClcxYD2gyrUZ0rdx3N_4SZU8sp1x_a7sCIDcg_h1q UjsKDz8danXRSWhX04mx15vFYQw2UFqRJsVcPD5H05UK6DnSynvf0irquyP. He2U__.IkFPzypFvLGdYWsqQnwmtBx9qhQtbKCLwSxjuvZpTRCifKAbkfkbv paBJIIzfvQfc2A8zjGMc_X6WBotgORdvR6GMygF9Qa70uTIeX4b36dVGce47 CU9XLTTZJuqO3mth9wWRNcLsIgC6a7aojtMHsZMRjvsrsU0ui6N0fxsB__sG Eh1N8Z2Lq2iEqHUXkMNNu9Ts8j2jNDjUfgWogCVYcwL752Y2ViE1ew9OmGw8 tajhuPw8jNm1FppYPYHHgo9X5lTF15slX1c3xx5JheMcEtKmOMm_QGtNPAYN JcNTtx3lQleqH9UG0S1mSriwekE1oPgyLAXSeq8Q3pqM4K3Boq8UpxAaAGG1 Y60uCYKy0Fu0CXetNWyZRRuzY1yko_ZWUJYjd58wgkCGwqpmYd9Szk5AAz_. nXjGa22aIixOFyYcgI81wiIOEWhz2bNjnvoHeTLJPO0jTq4LFCPb0
Received: from [79.175.81.4] by web164605.mail.gq1.yahoo.com via HTTP; Mon, 17 Feb 2014 23:45:59 PST
X-Rocket-MIMEInfo: 002.001, T24gTW9uZGF5LCBGZWJydWFyeSAxNywgMjAxNCA1OjIyIFBNLCAiZG1hcmMtcmVxdWVzdEBpZXRmLm9yZyIgPGRtYXJjLXJlcXVlc3RAaWV0Zi5vcmc.IHdyb3RlOgoKCj4.IFtQcm9wb3NlcyBTUlMgYXMgYW4gYWx0ZXJuYXRlIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbV0KPj4gYXMgZmFyIGFzIGkgY2FuIHRlbGwsIHRoZSBvbmx5IHZpYWJsZSBhYnVzZSBjb21lcyBmcm9tIGhvc3RzCj4.IHRoYXQgc3Bvb2YgZW1haWwuIGhvd2V2ZXIsIG5vdGhpbmcgZm9yYmlkcyB0aGVtIGZyb20gc3Bvb2ZpbmcgREtJTSABMAEBAQE-
X-RocketYMMF: gwzrd
X-Mailer: YahooMailWebService/0.8.177.636
References:   
Message-ID: <1392709559.24387.YahooMailNeo@web164605.mail.gq1.yahoo.com>
Date: Mon, 17 Feb 2014 23:45:59 -0800 (PST)
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/bIH5yPRwLOh2imwdefyjzu5_2dY
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
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, 18 Feb 2014 07:49:04 -0000

On Monday, February 17, 2014 5:22 PM, "dmarc-request@ietf.org"  wrote:


>> [Proposes SRS as an alternate authentication mechanism]
>> as far as i can tell, the only viable abuse comes from hosts
>> that spoof email. however, nothing forbids them from spoofing DKIM also
> Spoofing of email is exactly the problem. Using SRS as you propose
> actually would give abusers a clear path to spoof any domain that they
> would like to emulate.

that's why i'm suggesting switching to AND, instead of OR. until now, u couldn't
do that, since SPF evaluation was broken in so many cases. however, we introduce
SRS and those cases are accounted for too.

DMARC = ( SPF AND SRS AND DKIM ) and now u can actually say DMARC tightens abuse
path, with low amount of false positives.

what stays broken is already handled by override policy. and even some of those
cases could be fixed if developers accounted for this kind of DMARC, hoping
for its benefits.


> I don't understand your contention that anyone can spoof DKIM for a
> domain not within their control.
> In precise technical terms, what do you mean by "spoofing DKIM"?

http://tools.ietf.org/html/draft-otis-dkim-harmful-04
http://www.zdnet.com/7000019351

and let's not go there further.


>> they should. all of major ESPs provide forwarding as a service, thus breaking
>> more than one protocol. and i am not sure if any of them tries to accommodate
>> for such issues, while doing so.
> Perhaps, but again, it has not created enough of a problem to warrant action.
> Action is expensive. If more people complained about it, the answer might be
> different. But, apparently, they don't.

they may start, once DMARC kicks in. alignment is a problem, and will break
many things.


>> considering SPF was changed recently, in 4408bis draft, to prefer EHLO/HELO
>> identity over MAIL FROM
> I was a participant in the SPFBIS working group, and I don't remember anything
> about changing to prefer HELO/EHLO over MAIL FROM. Can you point me to that
> change?

sure. section 2.3 of 4408bis.


> I think you need to implement DMARC, apply some of these techniques,
> and come back to us with some data, experience.

i did deploy DMARC, manually, on my personal systems and some clients, around
2 years ago, when 1st draft was published. i also reviewed every change made
to it since then, and currently running on last version on my systems. all done
for the sake of local evaluations, i don't send any reports. its a dirty hack
and there's no point beyond my evaluation.

all because i love to experiment with promising new standards.

what i can tell u - forwarding breaks things.

13 of 15 of my clients, all small to middle sized businesses, use forwarding.
and they don't tend to stop using it, actually the opposite - they will use it
even more as BYOD and similar tendencies get more popular etc etc.

i also gave it a great deal of thought over the time. many things bothered me,
but i didn't push myself to contribute until Tim nudged me to "chime in" here,
while thanking me for feedback about an issue with dmarcian.org DMARC verifier.

btw, i tried my experiments with SRS. and actually, solved the forwarding
problem. where i had DMARC errors, now i have clean passes. obviously, i see
no abuse accounting for this change, but i do not really advertise this
difference in DMARC processing to public.

now i'm running on last version which tries AND in DMARC evaluation. so far,
where i had false positives, now i have clear messages. i actually believe this
change in DMARC spec could be useful, but sure, it's too soon to say.

also, i can't pretend to be a big receiver. ppl need to experiment with this
on their side too.

that is, if anybody actually gives a f*ck about DMARC.
i apologize for the language.


> We can provide links to reading materials if he needs such.

tnx.


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


From nobody Tue Feb 18 03:24: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 A26E81A047F for ; Tue, 18 Feb 2014 03:24:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 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.548, 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 LvzEdteW1x2P for ; Tue, 18 Feb 2014 03:24:22 -0800 (PST)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id BBD971A032F for ; Tue, 18 Feb 2014 03:24:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=0Np8txCleWgQQJUhTj94FSJqeuujXtObpCsOaiwvLsk=;  b=tJn1tUDWoa8CaYi/BIZiWjX3IOGuf3iEc13vM0eO3gF3lc3bxyCMivSWx2g60dfi+K40/grJ5AsswKHTMtOw4up/otalDB1ti2nG/BFZtTsrfJKcu1/XTQYJParTJO01B2RO2ssrUJJlezh0SVWZwxlP2bFT9667lDvIwaLVlWI=;
Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133
Received: from [116.12.149.133] (port=53125 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WFime-0002kB-VW for dmarc@ietf.org; Tue, 18 Feb 2014 11:24:17 +0000
Message-ID: <530342E0.8090309@rolandturner.com>
Date: Tue, 18 Feb 2014 19:24:16 +0800
From: Roland Turner 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "dmarc@ietf.org" 
References: <20140130220330.GA25608@roeckx.be> <52EACDBF.2050003@bluepopcorn.net> <20140130222320.GB25641@roeckx.be>  <1762762424.26365.1391121588323.JavaMail.zimbra@peachymango.org> <20140130225152.GA27685@roeckx.be>  <20140131001732.GA29928@roeckx.be>  
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/J0y14pzTxufQqPUKNSWuXW5I--0
Subject: Re: [dmarc-ietf] dmarc and forwarding
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 11:24:23 -0000

I meant to respond to this earlier:

On 01/31/2014 02:38 PM, Mike Jones wrote:
> Roland gave an excellent explanation of the reason for the alignment 
> requirement the DMARC specifies.  One point in his reply I will 
> disagree on though is that domains without a current spoofing problem 
> should not implement a DMARC quarantine or reject policy.  This thing 
> about spoofing is that one never knows when one will become a victim.  
> We often see domains that go periods of time without a spoofing issue 
> and then are hit hard on one day.  If the your domain has excellent 
> SPF and DKIM with a high overall DMARC pass rate, you have fully 
> analyzed your DMARC reports to understand the risk of failures due to 
> mailing lists or forwarding, and everything looks good then why not 
> protect yourself from future attacks with a DMARC quarantine or reject?

I may have overstated slightly, but as a practical matter there really 
is a bound below which p=quarantine/reject does more harm than good to a 
Domain Owner, not because smaller organisations are immune from spoofing 
but because there is a non-zero cost in monitoring and interpreting 
authentication failures and responding when appropriate. Whether this 
cost is borne as a monetary subscription to an authentication 
specialist, as yet another demand on the time of an IT guy who's already 
spread far too thinly, or simply in disruption to business when neither 
of the above is in place and something breaks, the cost isn't zero. If 
the expected benefit of protection (the likely - not worst case - impact 
of an incident multiplied by the probability of an incident - a number 
which is vanishingly close to zero for most organisations) is less than 
the cost of monitoring, interpreting and responding then quarantine and 
reject are harmful choices.

The challenge, of course, is where to draw the line. F500s are clearly 
in the cross-hairs, Alexa's top thousand (and some distance beyond) 
likewise. Somewhere a little further along this continuum however, is a 
point beyond which the costs of monitoring, interpreting and responding 
(or of disruption) exceed the benefit. My guess, although I admit that I 
have no credible quantitative model, is that this applies to a 
substantial majority of all domains which are used in 5322.From headers.

- Roland


From nobody Tue Feb 18 08:44: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 6A5D71A04CB for ; Tue, 18 Feb 2014 08:44:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5rcEO5zgm-9 for ; Tue, 18 Feb 2014 08:44:52 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAA71A04CC for ; Tue, 18 Feb 2014 08:44:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5D88A3F41BC for ; Tue, 18 Feb 2014 10:44:49 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FufxCw6Nzde for ; Tue, 18 Feb 2014 10:44:49 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 40D243F4627 for ; Tue, 18 Feb 2014 10:44:49 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 2A2813F44B1 for ; Tue, 18 Feb 2014 10:44:49 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oeRdRHeLZTuQ for ; Tue, 18 Feb 2014 10:44:49 -0600 (CST)
Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id A90683F41BC for ; Tue, 18 Feb 2014 10:44:48 -0600 (CST)
Date: Tue, 18 Feb 2014 10:44:47 -0600 (CST)
From: Franck Martin 
To: dmarc@ietf.org
Message-ID: <252837180.50681.1392741887926.JavaMail.zimbra@peachymango.org>
In-Reply-To: <430905932.50668.1392741878447.JavaMail.zimbra@peachymango.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_50680_1054399232.1392741887925"
X-Originating-IP: [69.28.149.129]
X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF27 (Mac)/8.0.5_GA_5839)
Thread-Topic: 7.3 and 7.4 have same title
Thread-Index: RLbeDdZZZJX1nYDN1K8S5NUBEv4KoA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_4OdPMsRGNfAW466cMFNH-NJWJ8
Subject: [dmarc-ietf] 7.3 and 7.4 have same title
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 16:44:54 -0000

------=_Part_50680_1054399232.1392741887925
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

7.3 and 7.4 have the same title, failure reports, we may want to differentiate the 2 

------=_Part_50680_1054399232.1392741887925
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


7.3 and 7.4 have the same title, failure reports, we may want to differentiate the 2

------=_Part_50680_1054399232.1392741887925--


From nobody Tue Feb 18 12:24: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 094251A0688 for ; Tue, 18 Feb 2014 12:24:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  SPF_FAIL=0.001, SPF_HELO_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 ZsEWd1vvQiYo for ; Tue, 18 Feb 2014 12:24:18 -0800 (PST)
Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 907761A0533 for ; Tue, 18 Feb 2014 12:24:18 -0800 (PST)
Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 18 Feb 2014 21:24:13 +0100
Message-ID: <4CE6510A38A748D8B7A4BA3E127B95B7@fgsr.local>
From: "J. Gomez" 
To: Vlatko Salaj 
References:  <1392709559.24387.YahooMailNeo@web164605.mail.gq1.yahoo.com>
Date: Tue, 18 Feb 2014 21:24:13 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.3790.4657
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Eb9Y_PJGaflWMG50vQGZJaDCjT8
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 20:24:21 -0000

On Tuesday, February 18, 2014 8:45 AM [GMT+1=3DCET], Vlatko Salaj wrote:

> > > considering SPF was changed recently, in 4408bis draft, to prefer
> > > EHLO/HELO identity over MAIL FROM
> > I was a participant in the SPFBIS working group, and I don't
> > remember anything about changing to prefer HELO/EHLO over MAIL
> > FROM. Can you point me to that change?
>=20
> sure. section 2.3 of 4408bis.

Hmm, according to that, checking HELO/EHLO is optional (RECOMMENDED), =
and checking MAIL-FROM is obligatory (MUST). What 4408bis says is that =
both SHOULD be checked, but checking HELO/EHLO is still optional.

And I prefer it that way: checking that the return-path (or at least the =
domain in the return path) is not spoofed I think is more important that =
checking for a non-spoofed HELO/EHLO. After all, a working return-path =
has a non-zero cost to maintain, whereas SPF-validating HELO/EHLO with a =
disposable sub.sub.domain would be almost free. The point of SPF is that =
spoofing MAIL-FROM becomes expensive, therefore less spam.

And that MAIL-FROM/SPF issue brings me to the SRS issue: my opinion is =
that email forwarding is WRONG, OBSOLETE, and should be abandoned =
altogether. Therefore SRS serves no real purpose, and DMARC should not =
deal with it at all.

Email forwarding is akin to doing FTP-through-email: a relic of times =
long gone, when you received your email at =
my.name@deptartment.faculty.entity.edu and you logged in there via =
telnet to check it with PINE, and you preferred (obviously) to forward =
that email somewhere else to check it with Eudora and to keep it locally =
once received in Eudora. It was then that forwarding had a reason to be. =
Nowadays, not so much.

Regards,

J.Gomez


From nobody Tue Feb 18 13:26: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 E80A21A0296 for ; Tue, 18 Feb 2014 13:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4s7bIiC_rCQ for ; Tue, 18 Feb 2014 13:26:23 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 7B23D1A027B for ; Tue, 18 Feb 2014 13:26:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id F1991294289; Tue, 18 Feb 2014 15:26:19 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vtam8UViaFbE; Tue, 18 Feb 2014 15:26:19 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C96FF294265; Tue, 18 Feb 2014 15:26:19 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B3A15294289; Tue, 18 Feb 2014 15:26:19 -0600 (CST)
X-Virus-Scanned: amavisd-new at smtp-out-1.01.com
Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kG8PLoSHsCRg; Tue, 18 Feb 2014 15:26:19 -0600 (CST)
Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id 839CF294225; Tue, 18 Feb 2014 15:26:15 -0600 (CST)
Date: Tue, 18 Feb 2014 15:26:14 -0600 (CST)
From: Franck Martin 
To: "J. Gomez" 
Message-ID: <1056507980.64740.1392758774378.JavaMail.zimbra@peachymango.org>
In-Reply-To: 
References:  <1392709559.24387.YahooMailNeo@web164605.mail.gq1.yahoo.com> <4CE6510A38A748D8B7A4BA3E127B95B7@fgsr.local> 
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 - FF27 (Mac)/8.0.5_GA_5839)
Thread-Topic: SRS helps SPF/DMARC
Thread-Index: 44OLFl2d+AfiwlE0daHBZh15up25qw==
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MtTSZPYm1K3rmn66R_PCIuVee2Y
Cc: Vlatko Salaj , dmarc@ietf.org
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Feb 2014 21:26:28 -0000

----- Original Message -----
> From: "J. Gomez" 
> To: "Vlatko Salaj" 
> Cc: dmarc@ietf.org
> Sent: Tuesday, February 18, 2014 12:24:13 PM
> Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
> 
> On Tuesday, February 18, 2014 8:45 AM [GMT+1=CET], Vlatko Salaj wrote:
> 
> > > > considering SPF was changed recently, in 4408bis draft, to prefer
> > > > EHLO/HELO identity over MAIL FROM
> > > I was a participant in the SPFBIS working group, and I don't
> > > remember anything about changing to prefer HELO/EHLO over MAIL
> > > FROM. Can you point me to that change?
> > 
> > sure. section 2.3 of 4408bis.
> 
> Hmm, according to that, checking HELO/EHLO is optional (RECOMMENDED), and
> checking MAIL-FROM is obligatory (MUST). What 4408bis says is that both
> SHOULD be checked, but checking HELO/EHLO is still optional.
> 
> And I prefer it that way: checking that the return-path (or at least the
> domain in the return path) is not spoofed I think is more important that
> checking for a non-spoofed HELO/EHLO. After all, a working return-path has a
> non-zero cost to maintain, whereas SPF-validating HELO/EHLO with a
> disposable sub.sub.domain would be almost free. The point of SPF is that
> spoofing MAIL-FROM becomes expensive, therefore less spam.

Read: http://trac.tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-10.1.3

For a more detailed explanation.


From nobody Tue Feb 18 15:35: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 7AC541A02AE for ; Tue, 18 Feb 2014 15:35:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.446
X-Spam-Level: 
X-Spam-Status: No, score=-2.446 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.548] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ohtHfcJeBJ7 for ; Tue, 18 Feb 2014 15:35:13 -0800 (PST)
Received: from nm34.bullet.mail.ne1.yahoo.com (nm34.bullet.mail.ne1.yahoo.com [98.138.229.27]) by ietfa.amsl.com (Postfix) with ESMTP id 044261A0106 for ; Tue, 18 Feb 2014 15:35:12 -0800 (PST)
Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 23:35:09 -0000
Received: from [98.138.101.129] by nm34.bullet.mail.ne1.yahoo.com with NNFMP;  18 Feb 2014 23:32:10 -0000
Received: from [98.137.12.59] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 18 Feb 2014 23:32:10 -0000
Received: from [98.137.12.201] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 18 Feb 2014 23:32:10 -0000
Received: from [127.0.0.1] by omp1009.mail.gq1.yahoo.com with NNFMP; 18 Feb 2014 23:32:10 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 3716.94909.bm@omp1009.mail.gq1.yahoo.com
Received: (qmail 41581 invoked by uid 60001); 18 Feb 2014 23:32:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1392766329; bh=PP94Xmct0Qi0iBlWP5oLtnj4qYjtoMX41FVY1tPQwTs=; 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=gXRDHJ20hS43yVYTBDfIYIiNf2Duju8LIgmsBEXMe1cUu7yjyVlApsXnWjIuFjMgag06XBf0xQl8obVNB14nnyDN7VC5RIspP+42nWVtEA1/oT8TcV+BYWekilYcLBYSvGEaLJFfEzPZP2CSRkkz8TuzxW87HXDvSayHu+U1aBE=
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=SrJlXHkoKmhV9h+Qgo5PhChBYmH60dosEEibTMsbol7xpbPESDkBYBsEbIoz0JfY9QOC9UbYYfgB1J5jYWAhIa3JfDiF+Ob2L8+5tjfXL381jfd6yk/8WxLvV5wkAFWeciO+fUABqT8Ad9XP0XB7O/UGmsq1vklzJYGcRvFYF5M=;
X-YMail-OSG: 7TFnrSgVM1kLxyuF6B_jO76bAMfXBuJC_qdbgLscjzPN.Yr OC9uT_xtjkqQ0hlNYjEkk7wKeE_o8yx624daBkTL7P49TOfGW389JD8.f5Cf HucyB.e3hVnKqCvnPukcuK6WvpatmyC_uEN1jzkXJ.wZdKw3wwqSU2u48V1w Yam9knDui5HNs4kIhOqDbZ5eF2CLmce41kYloHRobQiH7RCnPeLic3lCWK.3 pwSLoRZXl7xiam6zL9JEE5HU.2RCxMqMnNcPSrEfp3BZpWNhVbjCJFKnLJj8 i8fyo8wWJQPn4ISGjYngWDZpYt2urXy1kQ1EE2w.ncQy9SODSDhk0rD_IgeU fCsP2YnqpjavJ379j0oZ7MHNdc7lNm41cq7bm70QU4I8LDA_1wM1A5nq9i54 jPRapSBcy2.ARs_TBLDvHT7liAiFbBD2LeWCb3bPhVoKT1ULX3n1efp_nak9 EBKxpHTqMdhDpr8s2Ndht442iS4RAtc8Mcal.L68j_nLnWhzfzLpOVpxQIDE aROw4drBLMxw40uJhF4xYsEgurnXeNQlRnRkbGhW720vvK6G5zu44P.YmyZB DF1sDvCSupPum.S4CF6BCiKdm3fyg0u4M5K0niI61PREMjJjz17UAZxnwEGt 6fw1EFlDuvj6TZtU5PZbWa7w-
Received: from [79.175.81.4] by web164605.mail.gq1.yahoo.com via HTTP; Tue, 18 Feb 2014 15:32:09 PST
X-Rocket-MIMEInfo: 002.001, PiBIbW0sIGFjY29yZGluZyB0byB0aGF0LCBjaGVja2luZyBIRUxPL0VITE8gaXMgb3B0aW9uYWwgKFJFQ09NTUVOREVEKSwgYW5kCj4gY2hlY2tpbmcgTUFJTC1GUk9NIGlzIG9ibGlnYXRvcnkgKE1VU1QpLiBXaGF0IDQ0MDhiaXMgc2F5cyBpcyB0aGF0IGJvdGgKPiBTSE9VTEQgYmUgY2hlY2tlZCwgYnV0IGNoZWNraW5nIEhFTE8vRUhMTyBpcyBzdGlsbCBvcHRpb25hbC4KCmEgZnVsbHkgNDQwOGJpcyBjb21wbGlhbnQgU1BGIGFsZ29yaXRobSB3b3VsZCBjaGVjayBIRUxPIGlkZW50aXR5IGFuZCBza2lwCk0BMAEBAQE-
X-RocketYMMF: gwzrd
X-Mailer: YahooMailWebService/0.8.177.636
References:  <1392709559.24387.YahooMailNeo@web164605.mail.gq1.yahoo.com> <4CE6510A38A748D8B7A4BA3E127B95B7@fgsr.local>  <1056507980.64740.1392758774378.JavaMail.zimbra@peachymango.org> 
Message-ID: <1392766329.79550.YahooMailNeo@web164605.mail.gq1.yahoo.com>
Date: Tue, 18 Feb 2014 15:32:09 -0800 (PST)
From: Vlatko Salaj 
To: "dmarc@ietf.org" 
In-Reply-To: <1056507980.64740.1392758774378.JavaMail.zimbra@peachymango.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/anZyjiwJNHGFDDIzeu2KDIKaxf4
Subject: Re: [dmarc-ietf] SRS helps SPF/DMARC
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, 18 Feb 2014 23:35:15 -0000

> Hmm, according to that, checking HELO/EHLO is optional (RECOMMENDED), and
> checking MAIL-FROM is obligatory (MUST). What 4408bis says is that both
> SHOULD be checked, but checking HELO/EHLO is still optional.

a fully 4408bis compliant SPF algorithm would check HELO identity and skip
MAIL FROM. what spec allows is sticking to plain old rfc4408's way, but
that's not what 4408bis recommends.


> And that MAIL-FROM/SPF issue brings me to the SRS issue: my opinion is that
> email forwarding is WRONG, OBSOLETE, and should be abandoned altogether.

forwarding is here, and it will stay. it's not going anywhere. and to think
otherwise is essentially a thing that should be abandoned altogether.

finally, what's WRONG is creating a protocol which says it serves a purpose
and then make it so frigid to only work in a parallel universe, or for
immortal entities like facebook, google and alike. it has no other purpose,
no matter what some ppl here would like to believe.

if u don't account for everyone, don't bother creating anything. that
concept works well for human rights as well as IT.

time will tell if DMARC fate is sealed, as some FOSS developers see it.


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


From nobody Sun Feb 23 12: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 66F381A06F1 for ; Sun, 23 Feb 2014 12:07:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.401
X-Spam-Level: ***
X-Spam-Status: No, score=3.401 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 oZ8siCem6AYH for ; Sun, 23 Feb 2014 12:07:25 -0800 (PST)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1741A06F4 for ; Sun, 23 Feb 2014 12:07:24 -0800 (PST)
Received: by mail-pd0-f178.google.com with SMTP id fp1so5425861pdb.37 for ; Sun, 23 Feb 2014 12:07:24 -0800 (PST)
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 :mime-version:content-type; bh=IYQJXgG/ce7o1yl0CT0w6dTQJnpdtj+uzDeWZM/830A=; b=DVS+MuUETG2npprFkQHwqS/mDi9MI1NSZEys0a30o3PEy+rwqeO370ILURB66NtWSn wUCFu6b8sK1IupUxahfaOHheGnC6kbQ6N7BNqTtAvHaT5Kork5P3ff2miKKX+Qg+CBEX 2jfcrqL3a9cEL0R5QoJ0qi72RqpJEBFALhW5k=
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:mime-version:content-type; bh=IYQJXgG/ce7o1yl0CT0w6dTQJnpdtj+uzDeWZM/830A=; b=cPlCEqmaCtq+e+vJqtMcNF5XCcybAprnXsMsbVvZuxxSjRQOUjpC1BysbdwAxlY8eX NQpzy/17AstxS2486t+uGAgBKjH6jjsxBuvHVd/XFXYrKFkE+/YliEnzB3dz5bGckz2x SWr8mH6Ai7i1xal4QhPahWJ7Ge7/s7Ocr98CXv/o4t22X7pTxJzkCz28U//wsqjxIOxn Qs/E4TwoqE5IJ7SbG+R1uIIpLtyGPmlKs49t4d332BWp/YPPTwiiqebrbIIZSpnDwBAx 5JP+/War4lRXzdwpG6EPf+b1PyiCyW8JbwspJITqyEF1eOOSSjYWq+b/GtVzyE6sz8Q2 F+IA==
X-Gm-Message-State: ALoCoQkOS6AjpD6BaIIfkwmPDuX4qq8D07u9BZSoXPUBSP1pu2Znh80CaBboMuURGSmYLeKdCA//
X-Received: by 10.66.145.199 with SMTP id sw7mr20532864pab.143.1393186043944;  Sun, 23 Feb 2014 12:07:23 -0800 (PST)
Received: from [192.168.1.4] (c-24-6-244-51.hsd1.ca.comcast.net. [24.6.244.51]) by mx.google.com with ESMTPSA id om6sm42738116pbc.43.2014.02.23.12.07.20 for  (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 23 Feb 2014 12:07:23 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.3.9.131030
Date: Sun, 23 Feb 2014 12:07:14 -0800
From: Tomki Camp 
To: 
Message-ID: 
Thread-Topic: XML empty sp tag 
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3476002041_19252829"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-ER3rOF4XztD5PJDpopG7h8Sg1M
Subject: [dmarc-ietf] XML empty sp tag
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 23 Feb 2014 20:07:26 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3476002041_19252829
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

I am seeing some RUA reports come in where an sp tag is present in the XML,
but with no value.

Such as:
  
    yahoo.com
    r
    r
    
none

    
    100
  

It=E2=80=99s unclear to me, from the spec, whether this is allowed.

The schema definition
http://www.blackops.org/~msk/dmarc/draft-dmarc-base.html#xml_schema shows
that PolicyPublishedType has both the p and sp elements as DispositionType,
neither of them with a minOccurs.  At the very least, the former probably
should have that, right?

What would be an appropriate way to indicate in the spec whether the empty
sp tagset is allowed, and what it indicates?


Regards,
=E2=80=94Tomki





--B_3476002041_19252829
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable


I am seeing some RUA reports com=
e in where an sp tag is present in the XML, but with no value.

=
Such as:
 =
 <policy_published>
    <domain>yahoo.com</domain>
=
    <adkim>r</adki=
m>
    =
<aspf>r</aspf>
    <p>none</p>
    <sp></sp>
    <pct>100</pc=
t>
  </po=
licy_published>

It’s unclear to me, from the spec, whether this is allo=
wed.

The schema definition http://www.blackops.org/~msk/dmarc/draft-dmarc-base.html#xml_schema show=
s that PolicyPublishedType has both the p and sp elements as DispositionType=
, neither of them with a minOccurs.  At the very least, the former prob=
ably should have that, right?  

What would be an appropriate way to indicate in the spec=
 whether the empty sp tagset is allowed, and what it indicates? 


Regards,
=

—Tomki




--B_3476002041_19252829--



From nobody Sun Feb 23 23:27: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 77DAD1A036C for ; Sun, 23 Feb 2014 23:27:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.152
X-Spam-Level: 
X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 98kN_m1Ola6K for ; Sun, 23 Feb 2014 23:27:31 -0800 (PST)
Received: from sg.rolandturner.com (sg.rolandturner.com [175.41.138.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2D82D1A0356 for ; Sun, 23 Feb 2014 23:27:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=rolandturner.com; s=20120325;  h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=m+20OSJo659/c1F/7i3silmdGljgptJ6GisxqPf4XpY=;  b=pzs/9tjY9DTXxXDrNIBbFfSzYXy28dhgChuiHZPfHE38m+uhJcsnV7/e048HpcpJZ4QPX/SHTguR5YbdcEv0r58k0pgBeM9uzBzKzr3qc2WVi/Q+CvDd5K53Jlsg8KWYD7tnivjA5682aq9ZUlyPb64/2tDKtovfb+TEs71GEyg=;
Authentication-Results: sg.rolandturner.com; none; iprev=fail policy.iprev=116.12.149.133
Received: from [116.12.149.133] (port=36215 helo=[10.100.1.157]) by sg.rolandturner.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1WHpwm-0002fk-NB for dmarc@ietf.org; Mon, 24 Feb 2014 07:27:29 +0000
Message-ID: <530AF460.6000601@rolandturner.com>
Date: Mon, 24 Feb 2014 15:27:28 +0800
From: Roland Turner 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: dmarc@ietf.org
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070208060907010108000609"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ublLJxEM-RwusSjSRVcDubLSa_0
Subject: Re: [dmarc-ietf] XML empty sp tag
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 24 Feb 2014 07:27:33 -0000

This is a multi-part message in MIME format.
--------------070208060907010108000609
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Give or take what the spec says about the XML generated (I've not dug 
into this part), presumably it is desirable for the policy_published 
section to contain what the receiver saw, rather than shoe-horning it 
into something valid. E.g. if the Domain Owner published:

    v=DMARC1; p=none; sp= ;


then the fragment below would be the sensible thing to send.

As _dmarc.yahoo.com doesn't look like this it is likely that there is a 
problem in the report generator that created this report (so a bug 
should be filed with the implementer), but more broadly I'd suggest that 
DMARC shouldn't be over-specifying here.

- Roland


On 02/24/2014 04:07 AM, Tomki Camp wrote:
> I am seeing some RUA reports come in where an sp tag is present in the 
> XML, but with no value.
>
> Such as:
> 
> yahoo.com
> r
> r
> 
none

> 
> 100
> 
>
> It’s unclear to me, from the spec, whether this is allowed.
>
> The schema definition 
> http://www.blackops.org/~msk/dmarc/draft-dmarc-base.html#xml_schema 
> shows that PolicyPublishedType has both the p and sp elements as 
> DispositionType, neither of them with a minOccurs.  At the very least, 
> the former probably should have that, right?
>
> What would be an appropriate way to indicate in the spec whether the 
> empty sp tagset is allowed, and what it indicates?
>
>
> Regards,
> —Tomki
>
> *
> *
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc


--------------070208060907010108000609
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Give or take what the spec says about
      the XML generated (I've not dug into this part), presumably it is
      desirable for the policy_published section to contain what the
      receiver saw, rather than shoe-horning it into something valid.
      E.g. if the Domain Owner published:

      

      
v=DMARC1; p=none; sp= ; 

      

      

      then the fragment below would be the sensible thing to send.

      

      As _dmarc.yahoo.com doesn't look like this it is likely that there
      is a problem in the report generator that created this report (so
      a bug should be filed with the implementer), but more broadly I'd
      suggest that DMARC shouldn't be over-specifying here.

      

      - Roland

      

      

      On 02/24/2014 04:07 AM, Tomki Camp wrote:

    

    

      
      
I am seeing some RUA reports come in where an
        sp tag is present in the XML, but with no value.

      

        


          

        
Such as:

        

          
 
              <policy_published>

          
   
              <domain>yahoo.com</domain>

          
   
              <adkim>r</adkim>

          
   
              <aspf>r</aspf>

          
   
              <p>none</p>

          
   
              <sp></sp>

          
   
              <pct>100</pct>

          
 
              </policy_published>

        

        


          

        
It’s unclear to me,
            from the spec, whether this is allowed.

        


          

        
The schema
            definition http://www.blackops.org/~msk/dmarc/draft-dmarc-base.html#xml_schema
          shows that PolicyPublishedType has both the p and sp elements
          as DispositionType, neither of them with a minOccurs.  At the
          very least, the former probably should have that, right?  

        


          

        
What would be an
            appropriate way to indicate in the spec whether the empty
            sp tagset is allowed, and what it indicates? 

        


        

        


          

        
Regards,

        
—Tomki

        


              

        


            

      

      

      

      

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


    

    

  


--------------070208060907010108000609--


From nobody Mon Feb 24 09:12:04 2014
Return-Path: 
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF2E1A019E for ; Mon, 24 Feb 2014 09:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.22
X-Spam-Level: 
X-Spam-Status: No, score=-14.22 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIcUAJOxrXI2 for ; Mon, 24 Feb 2014 09:11:54 -0800 (PST)
Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id C69DD1A00F0 for ; Mon, 24 Feb 2014 09:11:52 -0800 (PST)
Received: from GQ1-EX10-CAHT19.y.corp.yahoo.com (gq1-ex10-caht19.corp.gq1.yahoo.com [10.73.119.200]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s1OHAZpw011248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Feb 2014 09:10:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1393261836; bh=nCAg2BOZguXZll7Z1XLPHfqQO9dScf5mr/F339ZFVfM=; h=From:Subject:Date:References:In-Reply-To; b=f+mZs5ttdasU/A6g/JQq6AgjIOyDe2oE595VmEsobgxpqCiVBrzXEr/xmMORsBTKq PTz0ugEV8zsan9Y4Po+tk6JzDQMlI8P2CeYyl+PP76LG+OwZerKxpK9rrJZh/3xbRH axCSU2G7tJLBCRS1BvbNRKEM4jYR3pOJSyb/IwJw=
Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT19.y.corp.yahoo.com ([fe80::5414:d2cc:4b69:55ef%14]) with mapi id 14.03.0174.002; Mon, 24 Feb 2014 09:10:35 -0800
From: Elizabeth Zwicky 
To: Tomki Camp , "dmarc@ietf.org" 
Thread-Topic: [dmarc-ietf] XML empty sp tag
Thread-Index: AQHPMNLzJDin5Wn4REm62VNn8jkIsprEpQ2A
Date: Mon, 24 Feb 2014 17:10:34 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [216.145.54.7]
Content-Type: multipart/alternative; boundary="_000_CF30BB9F11EA6Ezwickyyahooinccom_"
MIME-Version: 1.0
X-Milter-Version: master.31+4-gbc07cd5+
X-CLX-ID: 261836004
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/K_9U3xjxbhXg6GbhtEc-fUOcEhg
Subject: Re: [dmarc-ietf] XML empty sp tag
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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, 24 Feb 2014 17:12:02 -0000

--_000_CF30BB9F11EA6Ezwickyyahooinccom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Somebody determined along the way that the default minOccurs in this XML is=
 1.
On the other hand,  does occur -- the question is whether it is sy=
ntactically valid for it to be null, which, as far as I can tell, it is not=
 (it's an enumeration of strings).

As Roland points out, that leaves the question of what you're supposed to d=
o if the sender's domain has a syntactically invalid DMARC record, and prod=
ucing a matching, harmlessly incorrect report looks like the least bad opti=
on, at least unless we want to change dispositionType to have INVALID as a =
possible value.

Elizabeth

From: Tomki Camp >
Date: Sunday, February 23, 2014 12:07 PM
To: "dmarc@ietf.org" >
Subject: [dmarc-ietf] XML empty sp tag

I am seeing some RUA reports come in where an sp tag is present in the XML,=
 but with no value.

Such as:
  
    yahoo.com
    r
    r
    
none

    
    100
  

It=92s unclear to me, from the spec, whether this is allowed.

The schema definition http://www.blackops.org/~msk/dmarc/draft-dmarc-base.h=
tml#xml_schema shows that PolicyPublishedType has both the p and sp element=
s as DispositionType, neither of them with a minOccurs.  At the very least,=
 the former probably should have that, right?

What would be an appropriate way to indicate in the spec whether the empty =
sp tagset is allowed, and what it indicates?


Regards,
=97Tomki



--_000_CF30BB9F11EA6Ezwickyyahooinccom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Somebody determined along the way that the default minOccurs in this X=
ML is 1.


On the other hand, <sp></sp> does occur -- the question is=
 whether it is syntactically valid for it to be null, which, as far as I ca=
n tell, it is not (it's an enumeration of strings).  







As Roland points out, that leaves the question of what you're supposed=
 to do if the sender's domain has a syntactically invalid DMARC record, and=
 producing a matching, harmlessly incorrect report looks like the least bad=
 option, at least unless we want
 to change dispositionType to have INVALID as a possible value.







Elizab=
eth









From: Tomki Camp <tcamp@agari.com>

Date: Sunday, February 23, 2014 12:=
07 PM

To: "dmarc@ietf.org" <dma=
rc@ietf.org>

Subject: [dmarc-ietf] XML empty sp =
tag














I am seeing some RUA reports come in where an sp tag is present in the XML,=
 but with no value.











Such as:




  <policy_published=
>


    <domain>=
;yahoo.com</domain>


    <adkim>=
r</adkim>


    <aspf>r=
</aspf>


    <p>none=
</p>


    <sp><=
;/sp>


    <pct>10=
0</pct>


  </policy_publishe=
d>










It=92s unclear to me, from =
the spec, whether this is allowed.







The schema definition =
http://www.blackops.org/~msk/dmarc/draft-dmarc-base.html#xml_sc=
hema shows that PolicyPublishedType has
 both the p and sp elements as DispositionType, neither of them with a minO=
ccurs.  At the very least, the former probably should have that, right=
?  








What would be an appropriat=
e way to indicate in the spec whether the empty sp tagset is allowed, =
and what it indicates? 












Regards,


=97Tomki






















--_000_CF30BB9F11EA6Ezwickyyahooinccom_--


From nobody Fri Feb 28 17:06: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 ADCF41A035B for ; Fri, 28 Feb 2014 17:06:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVw1yjuc7r3I for ; Fri, 28 Feb 2014 17:06:39 -0800 (PST)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 88C891A01CB for ; Fri, 28 Feb 2014 17:06:39 -0800 (PST)
Received: by mail-ie0-f181.google.com with SMTP id tp5so863119ieb.12 for ; Fri, 28 Feb 2014 17:06:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=BaFXcWPWK1imOw1ezrrqZUplyU6alWdBPNHPOZaR4Jc=; b=VVIctCTHo/YwJKNZ8g0fyh1Zjl/AG6E/qjqtZvnaH85PPq1MfudIKkD3H5BG3yBKEf XCUvjR2t/ETWm0V+xpqcNC/LRk7O759xE3t7G5vwlrJvfFfYK6GB6ZiEx2BOi3u/XE62 UcoAcMAmnOZZ4LHfaJAk7HvobDK2ylKqtMYDR/w6BRVG8a+b+fUIAKy/ghh7gkMS0XNa L7myfTv70Vev4mBxEIz9PF1MjFNTgYpEWa69jOursYZCehzVHsDmi8DxK9ZOnhJrCe3g afRLLC961fg2tb9GLkwb0IKXVLhxy2axor/OCZSjbfecs518VUiQ7paDrWT/zGRalbgl UM8g==
X-Received: by 10.50.103.101 with SMTP id fv5mr7708254igb.2.1393635997421; Fri, 28 Feb 2014 17:06:37 -0800 (PST)
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 v5sm22759243igb.0.2014.02.28.17.06.36 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 17:06:36 -0800 (PST)
Message-ID: <5311329C.1030902@gmail.com>
Date: Fri, 28 Feb 2014 18:06:36 -0700
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: "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/Xo5MPcEtYK_YDdSLtZw3uHUyckg
Subject: [dmarc-ietf] Calling for Input on DMARC Draft
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Mar 2014 01:06:42 -0000

DMARC Folks -

As you know, the authors of the DMARC specification have been looking to
find a home for the base document somewhere within the IETF.  We've
explored various options in the past year, and now it looks like we've
found the right path.

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.

A primary reason for this shift is that DMARC is already a mature
specification with broad adoption. We also want to help support its
continued deployment and provide a foundation for potential future
evolution. There are some related issues that still need to mature
further, such as reporting practices, domain boundary identification,
etc. To facilitate those work streams, it is important to publish a
referenceable version of the specification.

To support this effort, we are asking the community for input as we
prepare the current version for submission to the ISE. We are seeking
concise statements that can be incorporated into the specification
primarily with a focus toward clarity, readability, and utility. While
we're happy to continue cataloging suggestions for future work, our goal
is primarily to tighten up this version of the document. Please send
your comments to this IETF discussion list within the next week as we
intend to submit the final version of the specification to the ISE by
the close of the meeting in London.

Current Specification:
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/

Also, if you happen to be at IETF 89 in London, you can corner Murray
Kucherawy and share your thoughts with him (as he has the pen on the
current draft)... though he'll probably suggest you send your specific
suggestions to the list, anyway.

Once the specification is published, our intent is to wind down the
loose collaboration effort known as DMARC.org.  The goal is to clearly
turn DMARC over to the community to maintain like any other open
specification.

On behalf of the original authors, we would like to extend our thanks to
everyone for being part of the effort thus far. DMARC is not perfect but
it's clear that it is having a substantial positive influence across the
ecosystem. We look forward to your final comments and hope to engage
with everyone on some other new and exciting work that will help improve
trust in email.

Thank you all,
Trent


-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams


From nobody Fri Feb 28 18:44: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 9F4381A031D for ; Fri, 28 Feb 2014 18:44:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.103
X-Spam-Level: 
X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9NoaL7BaAaG for ; Fri, 28 Feb 2014 18:44:47 -0800 (PST)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 517EE1A02CC for ; Fri, 28 Feb 2014 18:44:47 -0800 (PST)
Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 98EC995620E; Fri, 28 Feb 2014 21:44:44 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1393641884; bh=4UVQXW68tFC5YBZ5OMLfIClpZL3sHj+u1aZ5AJsOR/g=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mYy0oqnWeP7YbNF56jUJInpKY6zYXWowf9CQ4SDDzg+qgnPJPf/UUP8f1Tf1Zg5lO NLgVTBK0aAtsqnlqEhFiLg+YQ/RreGE72xI/KbYzStKHm6H3vnI3wjTzqfF2gaPylp C4Xinqb5ZuniOSesy+MHmFqdPNl8CI+ruW31qESY=
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 69170D0413B; Fri, 28 Feb 2014 21:44:44 -0500 (EST)
From: Scott Kitterman 
To: dmarc@ietf.org
Date: Fri, 28 Feb 2014 21:44:42 -0500
Message-ID: <1923216.NluQbZhEOe@scott-latitude-e6320>
User-Agent: KMail/4.11.5 (Linux/3.11.0-17-generic; KDE/4.11.5; x86_64; ; )
In-Reply-To: <5311329C.1030902@gmail.com>
References: <5311329C.1030902@gmail.com>
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/if2mryGz0jhPWH14y-BJOJr7QU0
Subject: Re: [dmarc-ietf] Calling for Input on DMARC Draft
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 01 Mar 2014 02:44:49 -0000

On Friday, February 28, 2014 18:06:36 J. Trent Adams wrote:
> DMARC Folks -
...
> To support this effort, we are asking the community for input as we
> prepare the current version for submission to the ISE. We are seeking
> concise statements that can be incorporated into the specification
> primarily with a focus toward clarity, readability, and utility. While
> we're happy to continue cataloging suggestions for future work, our goal
> is primarily to tighten up this version of the document. Please send
> your comments to this IETF discussion list within the next week as we
> intend to submit the final version of the specification to the ISE by
> the close of the meeting in London.
> 
> Current Specification:
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
...

I didn't have time for a detailed review of the entire document, but I did 
take a look at the SPF aspects of it and do have comments:

In Section 4, the next to last paragraph currently is:

   A Domain Owner may find that although its messages pass a particular
   authentication scheme's checks, it wishes not to have Mail Receivers
   consider those results as evidence that the message was authorized.
   In this case, the Domain Owner simply declines to advertise
   participation in those schemes.  For example, if the results of path
   authorization checks ought not be considered as part of the overall
   DMARC result for a given Author Domain, then the Domain Owner does
   not publish an SPF policy record.

It's slightly more correct to end with "SPF policy record that can produce an 
SPF pass result."  It is rare, but I have seen SPF records published that were 
only meant to produce fail results from known forgery sources.  Something like 
"v=spf1 -ip4:xxx.xxx.xxx.xxx ?all".  A record like this could never trigger a 
DMARC pass.

Section 3.1.4.2.  SPF-authenticated Identifiers says:

   DMARC provides the option of applying SPF in a strict mode or a
   relaxed mode.

   In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
   domain must have the same Organizational Domain.  In strict mode,
   only an exact DNS domain match is considered to produce identifier
   alignment.

5.2.  General Record Format includes:

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

The language doesn't seem quite parallel between the two.  3.1.4.2 talks about 
strict or relaxed mode while 5.2 talks about strict or relaxed SPF identifier 
alignment.  I figured out what it means, but it confused me for a minute (and I 
knew what meant to say before I read it).  I'd recommend changing (in 
3.1.4.2):

   DMARC provides the option of applying SPF in a strict mode or a
   relaxed mode.

to

   DMARC provides the option of applying SPF in strict or relaxed
   identifier alignment modes

and also changing (in section 5)

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

to

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

I think similar changes for DKIM in 3.1.4.1 and the adkim definition would be 
an improvement.

Since I've bitched about it enough previously, I'll mention that the 
discussion about SPF policy versus DMARC policy in 6.  Policy Enforcement 
Considerations (from -01) resolves my concerns about that text.

In section 10.2.4 there is a discussion about what must be included from the 
validation checks if there is an SPF pass.  I don't see any companion in 
formation about what information to carry forward from the SPF validation if 
it's not pass.  I wonder if it should be included.  It should be, in addition 
to the domain, the SPF result (there are several possible results that would 
cause it not to pass for DMARC purposes) along with any explanatory text (most 
all SPF implementations provide information beyond the bare result to assist 
in troubleshooting).

In 15.5, there is the phrase, "If malicious or unaware users can gain control 
of the SPF record or signing practices for a subdomain, ...".  I think that 
should be "If malicious or unaware users can gain control of the SPF record or 
DKIM signing practices for a subdomain, ..."

I B.1.1, the SPF alignment examples, I think it might be a bit confusing.  
When Mail From is in the same organizational domain and not the same, it's (in 
my experience) a subdomain to the From domain, not the other way around (which 
is what the example has).  I think the example would make more sense to most 
readers if the Mail From/From was reversed in the second example.  This would 
also be more consistent with the example in B.3.1.

I think this is significantly improved from -00, which is the last one I really 
had a chance to review.

Scott K