From tony@att.com Mon Apr 1 07:09:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62E21F8F87 for ; Mon, 1 Apr 2013 07:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.275 X-Spam-Level: X-Spam-Status: No, score=-106.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opu6IGQ9M0BF for ; Mon, 1 Apr 2013 07:09:44 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 10BC821F8F7B for ; Mon, 1 Apr 2013 07:09:44 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 72599515.0.111980.00-488.300967.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 01 Apr 2013 14:09:44 +0000 (UTC) X-MXL-Hash: 5159952818312d13-3c1079eb12fb9652b154d46365266d44f8e1451a Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r31E9hIW027978 for ; Mon, 1 Apr 2013 10:09:43 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r31E9dHm027968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 1 Apr 2013 10:09:40 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Mon, 1 Apr 2013 15:09:22 +0100 Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r31E9MBk005533 for ; Mon, 1 Apr 2013 10:09:22 -0400 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r31E9IxS005384 for ; Mon, 1 Apr 2013 10:09:19 -0400 Received: from [135.70.63.39] (vpn-135-70-63-39.vpn.west.att.com[135.70.63.39]) by maillennium.att.com (mailgw1) with ESMTP id <20130401140736gw1000m5boe> (Authid: tony); Mon, 1 Apr 2013 14:07:36 +0000 X-Originating-IP: [135.70.63.39] Message-ID: <5159950C.5030404@att.com> Date: Mon, 01 Apr 2013 10:09:16 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: dmarc@ietf.org X-Enigmail-Version: 1.5.1 Content-Type: multipart/alternative; boundary="------------080709040203010207060007" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=DLo4FVxb c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=aBIn1KdeK48A:10 a=z55uD49gxukA:10 a=qP9V8_J-TbkA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=zQP7CpKOAAAA:8 a=HqtFnf-_] X-AnalysisOut: [yEgA:10 a=sDN6jlLyAAAA:8 a=O8BSH_48AAAA:8 a=48vgC7mUAAAA:8] X-AnalysisOut: [ a=ndya8yifQQlSgwsg9KUA:9 a=wPNLvfGTeEIA:10 a=khjfVWLSQ80A] X-AnalysisOut: [:10 a=TPWu9s1A7C8A:10 a=zVl14GKDjh72P4J6V5EA:9 a=_W_S_7Vec] X-AnalysisOut: [oQA:10] Subject: Re: [dmarc-ietf] Changes in draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:09:45 -0000 This is a multi-part message in MIME format. --------------080709040203010207060007 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >From Scott Kitterman > > Is there a diff between this and the spec on dmarc.org available? > > Scott K rfcdiff is your friend: http://tools.ietf.org/rfcdiff?url1=http://www.dmarc.org/draft-dmarc-base-00-02.txt&url2=http://tools.ietf.org/id/draft-kucherawy-dmarc-base-00.txt --------------080709040203010207060007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
From Scott Kitterman <sklist at kitterman.com>
> Is there a diff between this and the spec on dmarc.org available?
>
> Scott K
rfcdiff is your friend:

http://tools.ietf.org/rfcdiff?url1=http://www.dmarc.org/draft-dmarc-base-00-02.txt&url2=http://tools.ietf.org/id/draft-kucherawy-dmarc-base-00.txt
--------------080709040203010207060007-- From dhc@dcrocker.net Mon Apr 1 07:26:10 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C669811E80C5 for ; Mon, 1 Apr 2013 07:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygy0kI0FU9cI for ; Mon, 1 Apr 2013 07:26:09 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 80F9F11E80BA for ; Mon, 1 Apr 2013 07:26:09 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r31EQ8eN031782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 1 Apr 2013 07:26:09 -0700 Message-ID: <51599900.6000408@dcrocker.net> Date: Mon, 01 Apr 2013 07:26:08 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130401142527.31707.37034.idtracker@ietfa.amsl.com> In-Reply-To: <20130401142527.31707.37034.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130401142527.31707.37034.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 01 Apr 2013 07:26:09 -0700 (PDT) Subject: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-bcp-01.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:26:10 -0000 -------- Original Message -------- Subject: New Version Notification for draft-crocker-dmarc-bcp-01.txt Date: Mon, 01 Apr 2013 07:25:27 -0700 From: internet-drafts@ietf.org To: dcrocker@bbiw.net A new version of I-D, draft-crocker-dmarc-bcp-01.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Filename: draft-crocker-dmarc-bcp Revision: 01 Title: Using DMARC Creation date: 2013-04-01 Group: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-crocker-dmarc-bcp-01.txt Status: http://datatracker.ietf.org/doc/draft-crocker-dmarc-bcp Htmlized: http://tools.ietf.org/html/draft-crocker-dmarc-bcp-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-crocker-dmarc-bcp-01 Abstract: Email abuse often relies on unauthorized use of a domain name, such as one belonging to a well-known company (brand). SPF and DKIM provide basic domain name authentication methods for email. A recent industry effort built an additional authentication-based layer, called Domain-based Message Authentication, Reporting & Conformance (DMARC). It allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes; it also provides a reporting mechanism, from receivers back to domain owners. Such capabilities over the public Internet are unusual and their use is not yet well-understood. This document formulates a set of best practices for the use of DMARC. The IETF Secretariat -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From sklist@kitterman.com Mon Apr 1 07:54:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B025E21E8041 for ; Mon, 1 Apr 2013 07:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hffwZaJBUq1Y for ; Mon, 1 Apr 2013 07:54:43 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48021E8037 for ; Mon, 1 Apr 2013 07:54:42 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 307E920E40D5; Mon, 1 Apr 2013 10:54:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364828082; bh=IJ+e515OdwT0gW7GphsDWcOvXDMXgCqT1375tOACGWo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Aqtba1WgR14FYMfqvDnvv6lxhUEHX5OjjgS5RhDp2lHrrcGblzw4c61Cz0PqQp2uC EUYU/KZo1rBCkLa7vOJsAtMmJIn7j27h+BaCZ6m0Tn+bOEq64PICpRYfHyZ5JxvgTJ xxuoZTdy1sLniz/0nvcJgtVxJztQLUWBXnxXXmy8= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 1373A20E4090; Mon, 1 Apr 2013 10:54:41 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 01 Apr 2013 10:54:41 -0400 Message-ID: <6117359.58SJt6qTnh@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <5159950C.5030404@att.com> References: <5159950C.5030404@att.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Changes in draft-kucherawy-dmarc-base X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:54:43 -0000 On Monday, April 01, 2013 10:09:16 AM Tony Hansen wrote: > From Scott Kitterman > > > Is there a diff between this and the spec on dmarc.org available? > > > > Scott K > > rfcdiff is your friend: > > http://tools.ietf.org/rfcdiff?url1=http://www.dmarc.org/draft-dmarc-base-00- > 02.txt&url2=http://tools.ietf.org/id/draft-kucherawy-dmarc-base-00.txt I know, but it was late and I was tired. I think it's useful to have that diff published somewhere, not just for my use. Scott K From jgomez@seryrich.com Mon Apr 1 13:01:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A7811E80E6 for ; Mon, 1 Apr 2013 13:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAvuTafqi9OD for ; Mon, 1 Apr 2013 13:01:19 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 6265D11E80E8 for ; Mon, 1 Apr 2013 13:01:18 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 1 Apr 2013 22:01:16 +0200 Message-ID: <793049D3538C4764B7160CDED756D076@fgsr.local> From: "J. Gomez" To: Date: Mon, 1 Apr 2013 22:02:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: [dmarc-ietf] Missing part in section 7.1 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 20:05:05 -0000 Hello. In the current draft "draft-kucherawy-dmarc-base-00" ( = http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00 ), the second = paragraph en section 7.1 does not make much sense. It currently reads: For example, in the presence of "pct=3D50" in the DMARC policy = record=20 for "example.com", half of the mesages with "example.com" in the=20 RFC5322.From field which fail the DMARC test would be subjected to=20 "reject" action, and the remainder subjected to "quarantine" action. My guess is it should begin with: For example, in the presence of "pct=3D50" and "p=3Dreject" in the = DMARC policy record (...) Regards, J. Gomez From tzink@exchange.microsoft.com Mon Apr 1 14:15:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55CD21E80A5 for ; Mon, 1 Apr 2013 14:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_41=0.6, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8z2ukpCzWwz for ; Mon, 1 Apr 2013 14:15:18 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD221E803C for ; Mon, 1 Apr 2013 14:15:18 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.670.5; Mon, 1 Apr 2013 21:15:17 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) with mapi id 15.00.0670.000; Mon, 1 Apr 2013 21:15:16 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: Ac4vHeGtF3P4hm3YSDmZ3O/llvHH6g== Date: Mon, 1 Apr 2013 21:15:15 +0000 Message-ID: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.124.132] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:15:20 -0000 Hi, everyone, I am proposing an extension to DMARC. Whereas today DMARC requires one of a= DKIM pass or SPF pass, I propose we extend DMARC so that is has the *optio= n* to require both. This is going to be a long post (sorry), but here's why: My company (Microsoft Forefront) runs a shared service. Other companies lik= e GoDaddy and MessageLabs would have similar issues. Because we are a share= d service, a larger set of customers use our limited set of outbound IPs to= relay email to the rest of the world. We scan this email for spam and take= action appropriately if we find a company or user is sending too much of i= t. Here's what it looks like with a set of fictional names if they were all ou= r customers and were using us for outbound mail: 1. example.com ----+ | 2. BigBank.com ----+----> Microsoft Forefront IPs ----> Internet | 3. Learning.edu ---+ Each of these customers would put the following into their SPF records: "v=3Dspf1 ip4: ip4:" This means that a message going from bob@example.com to joe@hotmail.com wou= ld undergo two SPF checks: 1. The first is when example.com sends the message to us for relaying to th= e Internet. We look up the SPF record for example.com, see it is coming fro= m example.com's IP range, and it passes the check. 2. The second is when the message arrives at joe@hotmail.com. Hotmail looks= up the SPF record for example.com, sees it is coming from Microsoft Forefr= ont's IP range, and it passes the check. In this scenario, everything is well and good. We know every IP that is associated with each of our customers. However, we= do not know every single domain associated with them. For example, BigBank= .com might have the following sending domains: - bigbank.com - email.bigbank.com - security.bigbank.com - littlebank.com - us.bigbank.com - uk.bigbank.com - cn.bigbank.com - partner.com And so forth. We may only know about bigbank.com (the customer goes into th= e admin portal and manually enters them in). Sometimes, bigbank.com will se= nd email from communications@uk.bigbank.com. This is an acceptable scenario= . We don't know about all their domains, but we scan the message and it is = clean and so we relay it to the Internet. They've even set up their SPF rec= ord properly. This is not the only valid case when this occurs (sending mai= l from domains they have not told us about previously), but it is one of th= em. In this scenario, everything is well and good. (As an aside, our internal d= ata indicates that the majority of this type of "unattributed" mail is non-= spam. I have to explain this to executives every time they want to shut it = down every two years; this capability is very popular with customers). Let's assume that BigBank.com has been dutiful and has published a DMARC re= cord. The problem occurs when Learning.edu gets compromised and starts send= ing out spam. If a user starts sending out spam from joe@learning.edu, we c= an detect this and shut it down. But what happens if they start sending out= mail as security@bigbank.com?=20 example.com ------------+ | BigBank.com ------------+----> Microsoft Forefront IPs ----> Internet | Learning.edu | security@bigbank.com --+ =20 If this is a zero-day attack, when the message hits Microsoft, we may not d= etect it as spam and it gets relayed to the outside world (perhaps BigBank.= com uses a ~all in their SPF record). What happens when it hits Hotmail? We= ll, Hotmail performs a DMARC check. There's no DKIM record, so Hotmail performs an SPF check on BigBank.com. It= sees that the mail came from Microsoft Forefront's IPs, and lo-and-behold,= Microsoft Forefront's IPs are listed in BigBank's SPF record! Therefore, t= his passes a DMARC check. But it shouldn't have passed! Not only should this have failed, it's worse = than failing because Hotmail believes that this message *is* from BigBank.c= om but it's a spoofed message! Shared services are susceptible to this prob= lem. And this is why I propose an optional extension to DMARC. Rather than DMARC= requiring SPF or DKIM, what if DMARC let a domain specify SPF *and* DKIM? = Let's look through what would happen in my above example: 1. Hotmail performs an SPF validation on BigBank.com and it passes, even th= ough it really came through a compromised account from learning.edu. 2. Hotmail performs a DKIM validation on BigBank.com and it fails because l= earning.edu does not know BigBank's private DKIM key. However, since BigBank.com says both SPF and DKIM must pass, this will fail= a DMARC validation. This is the case we want to catch - spoofing of users = behind shared IP space. I propose we extend the DMARC specification by extending the syntax. From h= ttp://dmarc.org/draft-dmarc-base-00-02.txt, section 6.2: adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether or not strict DKIM identifier alignment is required by the Domain Owner. If and only if the value of the string is "s", strict mode is in use. See Section 4.2.1 for details. aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether or not strict SPF identifier alignment is required by the Domain Owner. If and only if the value of the string is "s", strict mode is in use. See Section 4.2.2 for details. We could do something like add the letter "p" which means that the mechanis= m *must* pass. So, if BigBank.com had the following: adkim=3Dp aspf=3Dp It would mean that the domain BigBank.com requires both DKIM and SPF to pas= s, and they are both in relaxed mode since it defaults to r. Or we could ma= ke this explicit: adkim=3Drp aspf=3Drp ...where the first letter is strict vs. relaxed identifier alignment and th= e second is whether or not it must pass. Extending DMARC this way lets brands/domains protect their outbound reputat= ion behind a shared service without worrying whether or not some other cust= omer will spoof them. Make sense? -- Terry Zink | Program Manager - Antispam | My Antispam Blog From dcrocker@gmail.com Mon Apr 1 14:57:56 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC0E11E80F8 for ; Mon, 1 Apr 2013 14:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG7zF-rt5l0U for ; Mon, 1 Apr 2013 14:57:53 -0700 (PDT) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C211E80F5 for ; Mon, 1 Apr 2013 14:57:51 -0700 (PDT) Received: by mail-qe0-f51.google.com with SMTP id nd7so1513118qeb.10 for ; Mon, 01 Apr 2013 14:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yTfPvK5eZ5iknNbu0/XPNMdSSHauHXhpwjHrffcJvaA=; b=TxXFev3iM/4+UbuaKEz3OYUl80Dt+iWit8ZfEfAtFzZ8yvfB8iZWvGiCyUZuQXm/Q8 LccNKt5k9jU8l3cuSUd1Kz/jiYbKk/O7eivXbr/oow2l1s544cFf7MGiVvN52WcnAcrf DKVA7RKotgyPd+Iw6VLfPJTrzWXDSAJCt+/v8RZYyPOUqt7djtWBasJyx8zQoLhi1MGT FkinFekJusrf4mvEHZG1ENJ1gDtva3Ov//mDEnMxGStjuBCawoDOT8NiDjeQHerFE2nl 3KP3zAo2obr7iNrPl0ddH4gS9PSfTTKFBDj2XlCLnJjJIgIEBr5RUQWApHBOriATc2IX Wg3w== X-Received: by 10.224.71.77 with SMTP id g13mr5310001qaj.93.1364853470988; Mon, 01 Apr 2013 14:57:50 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id hm4sm166678qab.2.2013.04.01.14.57.48 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Apr 2013 14:57:50 -0700 (PDT) Message-ID: <515A02DB.2010309@gmail.com> Date: Mon, 01 Apr 2013 14:57:47 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Terry Zink References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:57:56 -0000 Terry, On 4/1/2013 2:15 PM, Terry Zink wrote: > I am proposing an extension to DMARC. Whereas today DMARC requires > one of a DKIM pass or SPF pass, I propose we extend DMARC so that is > has the*option* to require both. The draft working group charter that Murray just circulated would make this effort out of scope, since it explicitly prohibits protocol enhancement. Are you suggesting a change to the draft charter? An alternative might be to find a way for this example scenario to provide the basis for some discussion, in the draft BCP, about the proper limits of DMARC. It wouldn't solve your protocol problem, but it might provide good pedagogy. Perhaps there are other alternatives? > Let's assume that BigBank.com has been dutiful and has published a > DMARC record. The problem occurs when Learning.edu gets compromised > and starts sending out spam. If a user starts sending out spam > fromjoe@learning.edu, we can detect this and shut it down. But what > happens if they start sending out mail assecurity@bigbank.com? I tend to draw a distinction between protection against internal problems, versus protection against external ones. Internal means that the misbehavior is caused by an activity within the administrative scope of the entity needing protection. External means that the problem behavior comes from some other administrative scope. The usual examples of the distinction are misbehaviors by a department, within the company owning the domain name, versus misbehavior from a classic spammer who is using the domain name without authorization. On the average, the tendency has been to pursue standardization that protect against external threats rather than internal ones. Internal ones are thought to be best handled... internally. > 1. example.com ----+ > | > 2. BigBank.com ----+----> Microsoft Forefront IPs ----> Internet > | > 3. Learning.edu ---+ The scenario you give might be considered as internal misbehavior, since there is a contractual relationship between Forefront and the sources of messages that you list. That is, the essence of the challenge is for Forefront to have mechanisms that distinguish what mail is authorized from what source, and what mail isn't. Per your example, it would require that it enforce its /own/ dmarc-ish policy to require that mail it is relaying for learning.edu be attributed to learning.edu, and so on. If I understand your note correctly, the problem that you cite with this is that Forefront doesn't know all of the acceptable domains for a given customer. Wouldn't it make more sense to fix this issue, rather than change the public standard and burden all recipients with the added complexity in software and operations? Without have thought about it much, I suspect that one approach to fixing this is for Forefront to /privately/ assert the type of dmarc-ish enhancement that you propose. That is, impose the requirement on its customers, thereby assuring that the mail it is relaying to the public Internet is 'safe', at least along this one line of concern. d/ -- Dave Crocker bbiw.net From superuser@gmail.com Mon Apr 1 15:02:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAFF21F8439 for ; Mon, 1 Apr 2013 15:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LizrGoWlEMh7 for ; Mon, 1 Apr 2013 15:02:23 -0700 (PDT) Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC6211E8100 for ; Mon, 1 Apr 2013 15:00:02 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id m15so2470380wgh.3 for ; Mon, 01 Apr 2013 14:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jPMB6B+x4FWcDEZiP+Mf5ZGInQ+CZapAQPiFcRagFQw=; b=gCm7F76kPcCOFcEUcHia1tGjc2goD53HaPiDzlVPU4nFzQUiJBEVvy8CUBOxVHEFw3 ScvGVpce2oJ8ac3M8ij60s2aZIuPQG9X0XsfRqRZN7p+SxDpgKc+etGP1RfUrRn2cnm1 7ag69HW8WPebBwNPM87Hl6s+qN+GkbCj78nfs+lafHsQcoOzVdqK1C2ysKmMu96B6arC 2RpTlpc/FcWU5qc5L7dtyZBjzw2csGAWvQ/6f6biKfz6/7eQiFB5PT7VGqNpB9sTfnA9 323BL+/ZgZEp8jcOg3BErbTM+d6dC6sWnHrp5bYW+gNYiK4nhfekdT7ScoGrJcer4/7e 7DHA== MIME-Version: 1.0 X-Received: by 10.180.94.39 with SMTP id cz7mr12149390wib.21.1364853599382; Mon, 01 Apr 2013 14:59:59 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Mon, 1 Apr 2013 14:59:59 -0700 (PDT) In-Reply-To: <793049D3538C4764B7160CDED756D076@fgsr.local> References: <793049D3538C4764B7160CDED756D076@fgsr.local> Date: Mon, 1 Apr 2013 14:59:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d04426de6f6338204d953bd19 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Missing part in section 7.1 X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 22:02:29 -0000 --f46d04426de6f6338204d953bd19 Content-Type: text/plain; charset=ISO-8859-1 Quite right. Fixed in the source. -MSK On Mon, Apr 1, 2013 at 1:02 PM, J. Gomez wrote: > Hello. > > In the current draft "draft-kucherawy-dmarc-base-00" ( > http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00 ), the second > paragraph en section 7.1 does not make much sense. > > It currently reads: > > For example, in the presence of "pct=50" in the DMARC policy record > for "example.com", half of the mesages with "example.com" in the > RFC5322.From field which fail the DMARC test would be subjected to > "reject" action, and the remainder subjected to "quarantine" action. > > My guess is it should begin with: > > For example, in the presence of "pct=50" and "p=reject" in the DMARC > policy record (...) > > > Regards, > > J. Gomez > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f46d04426de6f6338204d953bd19 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Quite right.=A0 Fixed in the source.

-MS= K


On= Mon, Apr 1, 2013 at 1:02 PM, J. Gomez <jgomez@seryrich.com> wrote:
Hello.

In the current draft "draft-kucherawy-dmarc-base-00" ( http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00 ), the secon= d paragraph en section 7.1 does not make much sense.

It currently reads:

=A0 =A0 For example, in the presence of "pct=3D50" in the DMARC p= olicy record
=A0 =A0 for "example.= com", half of the mesages with "example.com" in the
=A0 =A0 RFC5322.From field which fail the DMARC test would be subjected to<= br> =A0 =A0 "reject" action, and the remainder subjected to "qua= rantine" action.

My guess is it should begin with:

=A0 =A0 For example, in the presence of "pct=3D50" and "p=3D= reject" in the DMARC policy record (...)


Regards,

J. Gomez


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

--f46d04426de6f6338204d953bd19-- From johnl@iecc.com Mon Apr 1 15:17:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC86F21E80B5 for ; Mon, 1 Apr 2013 15:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.9 X-Spam-Level: X-Spam-Status: No, score=-106.9 tagged_above=-999 required=5 tests=[AWL=4.300, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvCxgTygL83L for ; Mon, 1 Apr 2013 15:17:26 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 363CD21E80B4 for ; Mon, 1 Apr 2013 15:17:25 -0700 (PDT) Received: (qmail 71156 invoked from network); 1 Apr 2013 22:17:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Apr 2013 22:17:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a0774.xn--i8sz2z.k1304; i=johnl@user.iecc.com; bh=PAZDRtK82FkKETA6HK+J59u1+g7HBzCztEpYgYfl7yo=; b=IHkCDz73e76lfCSaswMlYdbWj3cKbgeBD7qoX6WOFJ3eqA5JlxCzyvV1puskIJrl6fQDQbL+56phUgNBjqaeWsMXWsBSiomkxBdesKjxZutBl2F8o7uqHT8V1GZzUR29EJ88nEM0spx/fc1Wm6/s2o5vuaTLGlf1fXUSArvg+8E= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 1 Apr 2013 22:17:02 -0000 Message-ID: <20130401221702.5500.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 22:17:31 -0000 >Extending DMARC this way lets brands/domains protect their outbound reputation behind a shared service without worrying >whether or not some other customer will spoof them. > >Make sense? Well, no. Your problem as I understand it is that you have a shared infrastructure accessed by untrusted clients, and you want to defend against the threat that one client sends mail impersonating another. The DKIM signatures are secure, a client can only sign for itself, but there's no way to map an IP address to a particular sender. The solution here is quite simple: adjust the SPF records to reflect what's actually going on. An SPF pass means, approximately, yes this message is really from the alleged sender. But you can't say that, you can only say that it might be or it might not be. So an appropriate SPF record would be something like this (using a handful of the of Frontbridge IP ranges as an example): bigbank.com txt "v=spf1 ?ip4:157.55.158.0/23 ?ip4:157.55.234.0/24 ?ip4:157.56.112.0/24 ~all" Those question marks in the record on the Frontbridge ranges make them neutral rather than pass, which is appropriate in this case. Since all of the real mail the client sends through your system will have a DKIM signature, it will still pass DMARC. If the bank has its own private ranges for its non-bulk mail, those could go in as SPF pass, e.g. bigbank.comm txt "v=spf1 +ip4:22.22.22.22 ?ip4:157.55.158.0/23 ?ip4:157.55.234.0/24 ?ip4:157.56.112.0/24 ~all" Remember that a major point of DKIM is to attach an identity to mail that is independent of the mail's path. DKIM currently works just great for the usual kinds of forwarded mail. If you insist on both SPF and DKIM, you lose the path independence and break the forwarding while gaining nothing, since the DKIM signature still tells you what you need to know. If the bank sends its own unsigned mail through its own mail servers, the SPF record reflects that, and it'll pass DMARC, too (give or take the known SPF forwarding issues.) Bonus advantage of this approach: existing software supports it now, no upgrades needed. R's, John From MHammer@ag.com Mon Apr 1 16:01:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DDA21F8F17 for ; Mon, 1 Apr 2013 16:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_BIZOP=0.7] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2-NI1-BwzPw for ; Mon, 1 Apr 2013 16:01:16 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id C179221F8F0F for ; Mon, 1 Apr 2013 16:01:15 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 19:01:14 -0400 From: "MH Michael Hammer (5304)" To: Dave Crocker , Terry Zink Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: AQHOLyQDr9vuaJVnrUmomkiXMf3sBZjB9p9w Date: Mon, 1 Apr 2013 23:01:13 +0000 Message-ID: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <515A02DB.2010309@gmail.com> In-Reply-To: <515A02DB.2010309@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 23:01:20 -0000 Comments in-line. > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Dave Crocker > Sent: Monday, April 01, 2013 5:58 PM > To: Terry Zink > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally > require SPF and DKIM >=20 > Terry, >=20 > On 4/1/2013 2:15 PM, Terry Zink wrote: > > I am proposing an extension to DMARC. Whereas today DMARC requires > one > > of a DKIM pass or SPF pass, I propose we extend DMARC so that is has > > the*option* to require both. >=20 This is a bad idea. While it solves your internal problem it potentially in= creases false positives for bigbank.com externally, thus trading one proble= m for another. I've been implementing SPF (ending with -all) and DKIM with = private channel assertions since the end of 2007. One of the reasons for us= ing the combination of SPF and DKIM ( and requiring only one to pass) is th= e reduction of false positives.=20 Before trying to extend DMARC to account for internal problems - as Dave po= ints out - I would look for other ways of resolving the problem. As I have = said many times regarding email authentication implementation, one needs to= get control of their mail flows. That is true in this case. If bigbank.com= cannot control it's managers/employees and how they send mail then that is= an internal problem that bigbank needs to address. There are plenty of oth= er mechanisms for bigbank to control what it emits (in the case of spam). P= erhaps MS should offer bigbank dedicated IPs - ESPs do this all the time fo= r their customers. It may not be so critical for other customers. Sounds li= ke a business opportunity to me. > The draft working group charter that Murray just circulated would make th= is > effort out of scope, since it explicitly prohibits protocol enhancement. >=20 > Are you suggesting a change to the draft charter? >=20 I prefer to avoid relying on limitations in the charter and focusing on the= merits which IMHO don't rise to a level justifying this extension. One of = the key merits of DMARC is that it focuses on solving a particular problem = and based on the data it does that very well. > An alternative might be to find a way for this example scenario to provid= e the > basis for some discussion, in the draft BCP, about the proper limits of > DMARC. It wouldn't solve your protocol problem, but it might provide goo= d > pedagogy. >=20 This sounds like a good idea. > Perhaps there are other alternatives? >=20 >=20 > > Let's assume that BigBank.com has been dutiful and has published a > > DMARC record. The problem occurs when Learning.edu gets compromised > > and starts sending out spam. If a user starts sending out spam > > fromjoe@learning.edu, we can detect this and shut it down. But what > > happens if they start sending out mail assecurity@bigbank.com? >=20 It sounds like someone needs btter internal controls to prevent this. > I tend to draw a distinction between protection against internal problems= , > versus protection against external ones. Internal means that the > misbehavior is caused by an activity within the administrative scope of t= he > entity needing protection. External means that the problem behavior come= s > from some other administrative scope. >=20 +1 > The usual examples of the distinction are misbehaviors by a department, > within the company owning the domain name, versus misbehavior from a > classic spammer who is using the domain name without authorization. On th= e > average, the tendency has been to pursue standardization that protect > against external threats rather than internal ones. Internal ones are tho= ught > to be best handled... internally. >=20 > > 1. example.com ----+ > > | > > 2. BigBank.com ----+----> Microsoft Forefront IPs ----> Internet > > | > > 3. Learning.edu ---+ >=20 >=20 > The scenario you give might be considered as internal misbehavior, since > there is a contractual relationship between Forefront and the sources of > messages that you list. That is, the essence of the challenge is for For= efront > to have mechanisms that distinguish what mail is authorized from what > source, and what mail isn't. Per your example, it would require that it > enforce its /own/ dmarc-ish policy to require that mail it is relaying fo= r > learning.edu be attributed to learning.edu, and so on. >=20 > If I understand your note correctly, the problem that you cite with this = is that > Forefront doesn't know all of the acceptable domains for a given customer= . > Wouldn't it make more sense to fix this issue, rather than change the pub= lic > standard and burden all recipients with the added complexity in software > and operations? >=20 +1 > Without have thought about it much, I suspect that one approach to fixing > this is for Forefront to /privately/ assert the type of dmarc-ish enhance= ment > that you propose. That is, impose the requirement on its customers, ther= eby > assuring that the mail it is relaying to the public Internet is 'safe', a= t least > along this one line of concern. >=20 >=20 From johnl@iecc.com Mon Apr 1 16:02:38 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5A621E80FD for ; Mon, 1 Apr 2013 16:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.456 X-Spam-Level: X-Spam-Status: No, score=-110.456 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B++ma4OrLgKE for ; Mon, 1 Apr 2013 16:02:37 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF6B21E80FB for ; Mon, 1 Apr 2013 16:02:37 -0700 (PDT) Received: (qmail 84638 invoked from network); 1 Apr 2013 23:02:37 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 1 Apr 2013 23:02:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a120c.xn--yuvv84g.k1304; i=johnl@user.iecc.com; bh=bu79e4OU72qRCbSpF/JjL29rmVTleDoW42RyugpWl9o=; b=BM9QNuZRUY4018mypG0Z91MPD1hc+MjcDDeAngkAFusU7cI9qoASJX8yRhFHNuuf6A90BPI7pz97TKdoYfLvp0kOYxikL4AsrcJGTnd8zpPxDTrMi1EIe5vBnjH+t8Uf2EPKJ8gaoOKDWgHOBe38jvei++jyE+gT/ggfAzXkofI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a120c.xn--yuvv84g.k1304; olt=johnl@user.iecc.com; bh=bu79e4OU72qRCbSpF/JjL29rmVTleDoW42RyugpWl9o=; b=suD8Xxhs2H4YoVi9+ACTnH2tbn45e4kSP7XSE20cWLRu8ot3321NwdkPyZiqfQMbxfRrbWmxKXKzsYWVpvh5ij0xYJfDdSCYQPekS+Br3Va5uE6gln+BPhPQ6t24VGCbKphHPiIHNUyFYXxutrlXo+hQyM3iRde8kIGItztQskw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 1 Apr 2013 23:02:14 -0000 Message-ID: <20130401230214.5709.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <515A02DB.2010309@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 23:02:38 -0000 >If I understand your note correctly, the problem that you cite with this >is that Forefront doesn't know all of the acceptable domains for a given >customer. Wouldn't it make more sense to fix this issue, rather than >change the public standard and burden all recipients with the added >complexity in software and operations? That's also a good idea. It'd make sense to change the SPF records now, then if they can fix the internal systems so that they have the domains on injected mail under control, they could change the SPF back to make stronger assertions. From jgomez@seryrich.com Mon Apr 1 16:13:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15ABF21E8102 for ; Mon, 1 Apr 2013 16:13:47 -0700 (PDT) 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=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn4ssMMEyogA for ; Mon, 1 Apr 2013 16:13:46 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id EB5C521E80FB for ; Mon, 1 Apr 2013 16:13:45 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Apr 2013 01:13:44 +0200 Message-ID: <80FFAE6594A84EB9BDC60EA75BC91597@fgsr.local> From: "J. Gomez" To: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Tue, 2 Apr 2013 01:15:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 23:13:47 -0000 On Monday, April 01, 2013 11:15 PM [GMT+1=3DCET], Terry Zink wrote: > I am proposing an extension to DMARC. Whereas today DMARC requires > one of a DKIM pass or SPF pass, I propose we extend DMARC so that is > has the *option* to require both. =20 > > (...) > > Let's assume that BigBank.com has been dutiful and has published a > DMARC record. The problem occurs when Learning.edu gets compromised > and starts sending out spam. If a user starts sending out spam from > joe@learning.edu, we can detect this and shut it down. But what > happens if they start sending out mail as security@bigbank.com? =20 >=20 > example.com ------------+ > | > BigBank.com ------------+----> Microsoft Forefront IPs ----> Internet > | > Learning.edu | > security@bigbank.com --+ > > (...) > > Extending DMARC this way lets brands/domains protect their outbound > reputation behind a shared service without worrying whether or not > some other customer will spoof them. =20 >=20 > Make sense? I does make sense. I also like the explanation in your blog: http://blogs.msdn.com/b/tzink/archive/2012/10/18/how-should-large-financi= al-institutions-use-hosted-filtering.aspx In a multitenant cloud environment, and/or when you are giving customers = a MTA-smarthost service to gateway their mail to the Internet, you = cannot be sure that they will always be signing their email with DKIM, = and you usually will not have their private DKIM keys to sign their = email yourself as it flows through the smarthost towards the Internet, = so taking the DMARC oportunity to close this hole in SPF is golden. When we will all be on IPv6, and sharing IPs will be a thing of the = past, this will be a non issue. But it is an issue now, and will be even = a bigger issue as we remain in IPv4 and more and more things move to the = cloud. Your proposal for DMARC would solve this problem scenario of SPF = just fine. Also, your proposal has more benefits: -- makes DMARC more resilient in case any of its underliying = authentications mechanisms becomes compromised/broken/moot in the = future. -- future is hard to predict, this would build into the DMARC = specification an optional more strict authentication threshold which may = be useful in the future. As to how to fit your suggestion in the syntax of the DMARC record, I = would add an additional (and optional) tag to the specification, "m=3D" = (mechanisms required to pass) with the possible values of "all" and = "any", where "all" would require all the mechanisms of DMARC to pass for = a DMARC pass itself to be gotten, and where "any" would be the default. Regards, J. Gomez From prvs=7962611cc=fmartin@linkedin.com Mon Apr 1 16:28:10 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764E211E810D for ; Mon, 1 Apr 2013 16:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG98acz8IZKe for ; Mon, 1 Apr 2013 16:28:09 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9411E80FA for ; Mon, 1 Apr 2013 16:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1364858889; x=1396394889; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=9Pi4D1pUC5aVPAqT5gF+u42L2ImnB+YsYbJQGyvdnrM=; b=qtGVDfueYhI5BGZ9zCPrrbgsb8K5aaqidLekXYNz49pKNNAfwgyA9EqY vpO+1AeBZO6UIMWcDxmEhjI1K70JDKikAdGQY8Clvn8pGNapL07n+MJ20 S+VZkW4gsBbkypy/bHOVLel/+vkouvPs6wuuGHj80+kFYwPkdUzWf/X+5 c=; X-IronPort-AV: E=Sophos;i="4.87,390,1363158000"; d="scan'208";a="43783513" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 1 Apr 2013 16:28:03 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 16:28:03 -0700 From: Franck Martin To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM Thread-Index: AQHOLzCOK/oLwi2Bx0KDLQhISA58Tw== Date: Mon, 1 Apr 2013 23:28:03 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EA0C4E@ESV4-MBX01.linkedin.biz> In-Reply-To: <80FFAE6594A84EB9BDC60EA75BC91597@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="utf-8" Content-ID: <160E39875DC214459A6475EAD42EB975@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 23:28:10 -0000 DQoNCk9uIDQvMS8xMyA0OjE1IFBNLCAiSi4gR29tZXoiIDxqZ29tZXpAc2VyeXJpY2guY29tPiB3 cm90ZToNCg0KPk9uIE1vbmRheSwgQXByaWwgMDEsIDIwMTMgMTE6MTUgUE0gW0dNVCsxPUNFVF0s IFRlcnJ5IFppbmsgd3JvdGU6DQo+DQo+PiBJIGFtIHByb3Bvc2luZyBhbiBleHRlbnNpb24gdG8g RE1BUkMuIFdoZXJlYXMgdG9kYXkgRE1BUkMgcmVxdWlyZXMNCj4+IG9uZSBvZiBhIERLSU0gcGFz cyBvciBTUEYgcGFzcywgSSBwcm9wb3NlIHdlIGV4dGVuZCBETUFSQyBzbyB0aGF0IGlzDQo+PiBo YXMgdGhlICpvcHRpb24qIHRvIHJlcXVpcmUgYm90aC4NCj4+DQo+PiAoLi4uKQ0KPj4NCj4+IExl dCdzIGFzc3VtZSB0aGF0IEJpZ0JhbmsuY29tIGhhcyBiZWVuIGR1dGlmdWwgYW5kIGhhcyBwdWJs aXNoZWQgYQ0KPj4gRE1BUkMgcmVjb3JkLiBUaGUgcHJvYmxlbSBvY2N1cnMgd2hlbiBMZWFybmlu Zy5lZHUgZ2V0cyBjb21wcm9taXNlZA0KPj4gYW5kIHN0YXJ0cyBzZW5kaW5nIG91dCBzcGFtLiBJ ZiBhIHVzZXIgc3RhcnRzIHNlbmRpbmcgb3V0IHNwYW0gZnJvbQ0KPj4gam9lQGxlYXJuaW5nLmVk dSwgd2UgY2FuIGRldGVjdCB0aGlzIGFuZCBzaHV0IGl0IGRvd24uIEJ1dCB3aGF0DQo+PiBoYXBw ZW5zIGlmIHRoZXkgc3RhcnQgc2VuZGluZyBvdXQgbWFpbCBhcyBzZWN1cml0eUBiaWdiYW5rLmNv bT8NCj4+IA0KPj4gZXhhbXBsZS5jb20gLS0tLS0tLS0tLS0tKw0KPj4gICAgICAgICAgICAgICAg ICAgICAgICAgfA0KPj4gQmlnQmFuay5jb20gLS0tLS0tLS0tLS0tKy0tLS0+IE1pY3Jvc29mdCBG b3JlZnJvbnQgSVBzIC0tLS0+IEludGVybmV0DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICB8 DQo+PiBMZWFybmluZy5lZHUgICAgICAgICAgICB8DQo+PiAgc2VjdXJpdHlAYmlnYmFuay5jb20g LS0rDQo+Pg0KPj4gKC4uLikNCj4+DQo+PiBFeHRlbmRpbmcgRE1BUkMgdGhpcyB3YXkgbGV0cyBi cmFuZHMvZG9tYWlucyBwcm90ZWN0IHRoZWlyIG91dGJvdW5kDQo+PiByZXB1dGF0aW9uIGJlaGlu ZCBhIHNoYXJlZCBzZXJ2aWNlIHdpdGhvdXQgd29ycnlpbmcgd2hldGhlciBvciBub3QNCj4+IHNv bWUgb3RoZXIgY3VzdG9tZXIgd2lsbCBzcG9vZiB0aGVtLg0KPj4gDQo+PiBNYWtlIHNlbnNlPw0K Pg0KPkkgZG9lcyBtYWtlIHNlbnNlLiBJIGFsc28gbGlrZSB0aGUgZXhwbGFuYXRpb24gaW4geW91 ciBibG9nOg0KPg0KPmh0dHA6Ly9ibG9ncy5tc2RuLmNvbS9iL3R6aW5rL2FyY2hpdmUvMjAxMi8x MC8xOC9ob3ctc2hvdWxkLWxhcmdlLWZpbmFuY2lhDQo+bC1pbnN0aXR1dGlvbnMtdXNlLWhvc3Rl ZC1maWx0ZXJpbmcuYXNweA0KPg0KPkluIGEgbXVsdGl0ZW5hbnQgY2xvdWQgZW52aXJvbm1lbnQs IGFuZC9vciB3aGVuIHlvdSBhcmUgZ2l2aW5nIGN1c3RvbWVycw0KPmEgTVRBLXNtYXJ0aG9zdCBz ZXJ2aWNlIHRvIGdhdGV3YXkgdGhlaXIgbWFpbCB0byB0aGUgSW50ZXJuZXQsIHlvdSBjYW5ub3QN Cj5iZSBzdXJlIHRoYXQgdGhleSB3aWxsIGFsd2F5cyBiZSBzaWduaW5nIHRoZWlyIGVtYWlsIHdp dGggREtJTSwgYW5kIHlvdQ0KPnVzdWFsbHkgd2lsbCBub3QgaGF2ZSB0aGVpciBwcml2YXRlIERL SU0ga2V5cyB0byBzaWduIHRoZWlyIGVtYWlsDQo+eW91cnNlbGYgYXMgaXQgZmxvd3MgdGhyb3Vn aCB0aGUgc21hcnRob3N0IHRvd2FyZHMgdGhlIEludGVybmV0LCBzbw0KPnRha2luZyB0aGUgRE1B UkMgb3BvcnR1bml0eSB0byBjbG9zZSB0aGlzIGhvbGUgaW4gU1BGIGlzIGdvbGRlbi4NCg0KR29v Z2xlIGFwcHMsIHNlbmQgZ3JpZCwgbWVzc2FnZWJ1cywgKGFuZCBtYW55IG90aGVyIEVTUHMpIGRv IG5vdCBoYXZlDQpwcm9ibGVtIHRvIGNyZWF0ZSBhIERLSU0ga2V5IGZvciBlYWNoIGN1c3RvbWVy LCB0byBzaWduIHRoZSBlbWFpbHMgdGhhdA0KcGFzcyB0aHJvdWdoIHRoZW0uIFdlIHVzZWQgdG8g aGF2ZSBvcGVuLXJlbGF5cyBiZWNhdXNlIHRoZXkgd2VyZSBlYXN5IHRvDQpzZXR1cC9tYW5hZ2Us IGJ1dCB3ZSBtb3ZlZCBhd2F5IGZyb20gdGhlbSBiZWNhdXNlIHRoZXkgd2VyZSBpbnNlY3VyZS4N Cg0K From jgomez@seryrich.com Mon Apr 1 17:24:49 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF7511E80F8 for ; Mon, 1 Apr 2013 17:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC89QZh4Kcgm for ; Mon, 1 Apr 2013 17:24:48 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 9493C11E80E2 for ; Mon, 1 Apr 2013 17:24:44 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Apr 2013 02:24:42 +0200 Message-ID: From: "J. Gomez" To: References: <77426B543150464AA3F30DF1A91365DE52EA0C4E@ESV4-MBX01.linkedin.biz> Date: Tue, 2 Apr 2013 02:26:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:24:50 -0000 On Tuesday, April 02, 2013 1:28 AM [GMT+1=3DCET], Franck Martin wrote: > On 4/1/13 4:15 PM, "J. Gomez" wrote: >=20 >> On Monday, April 01, 2013 11:15 PM [GMT+1=3DCET], Terry Zink wrote: >>=20 >>> I am proposing an extension to DMARC. Whereas today DMARC requires >>> one of a DKIM pass or SPF pass, I propose we extend DMARC so that is >>> has the *option* to require both. >>>=20 >>> (...) >>>=20 >>> Let's assume that BigBank.com has been dutiful and has published a >>> DMARC record. The problem occurs when Learning.edu gets compromised >>> and starts sending out spam. If a user starts sending out spam from >>> joe@learning.edu, we can detect this and shut it down. But what >>> happens if they start sending out mail as security@bigbank.com? >>>=20 >>> example.com ------------+ >>> | >>> BigBank.com ------------+----> Microsoft Forefront IPs ----> >>> Internet | >>> Learning.edu | >>> security@bigbank.com --+ >>>=20 >>> (...) >>>=20 >>> Extending DMARC this way lets brands/domains protect their outbound >>> reputation behind a shared service without worrying whether or not >>> some other customer will spoof them. >>>=20 >>> Make sense? >>=20 >> I does make sense. I also like the explanation in your blog: >>=20 >> = http://blogs.msdn.com/b/tzink/archive/2012/10/18/how-should-large-financi= a >> l-institutions-use-hosted-filtering.aspx >>=20 >> In a multitenant cloud environment, and/or when you are giving >> customers a MTA-smarthost service to gateway their mail to the >> Internet, you cannot be sure that they will always be signing their >> email with DKIM, and you usually will not have their private DKIM >> keys to sign their email yourself as it flows through the smarthost >> towards the Internet, so taking the DMARC oportunity to close this >> hole in SPF is golden.=20 >=20 > Google apps, send grid, messagebus, (and many other ESPs) do not have > problem to create a DKIM key for each customer, to sign the emails > that pass through them. We used to have open-relays because they were > easy to setup/manage, but we moved away from them because they were > insecure.=20 If your worry is moving away from insecure, then Terry Zink's proposal = is just making DMARC more secure, as it is raising the bar on the = mechanisms that have (optionally) to concur to obtain a DMARC-pass. Apart from that, you would need to control your client's DNS to sign = their DKIM in their behalf, and that only works with very small clients = which lack in-house technical people and outsource the whole thing to = you. But if you want to have clients of medium size which gateway their = mail to the Internet through your cloud service, good luck getting their = technical people to surrender their administrative control of their DNS = to you. I would like to hear, instead of suggestions for Terry to "fix" his = infrastructure and his business model, some contributions as to why his = proposal is detrimental to the goals of DMARC. Regards, J. Gomez From prvs=797119cd4=fmartin@linkedin.com Mon Apr 1 17:31:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC23F21E8108 for ; Mon, 1 Apr 2013 17:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7g+gfYhPOjl for ; Mon, 1 Apr 2013 17:31:40 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9E11E80E2 for ; Mon, 1 Apr 2013 17:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1364862699; x=1396398699; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=wyJ6JT6XQJLionJ09IFtiWCvKU3BJziddELaGypCP+k=; b=tFWEtOaXY+MfbBlaHtLoFDda07bvsHVUp0Y+uVIBfrT/NEWXWvSGSKrX oa2v9RYj6DipPOZD2UXuiJoTUei6Iz8pc86fpZFAq7gvrITXdT61vujUi rYNVVJ41ifslcHPOFqpWSTxT0yhytRs9ACraY8jUqVXk3jnqaeWNmmq0D w=; X-IronPort-AV: E=Sophos;i="4.87,390,1363158000"; d="scan'208";a="42730468" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 1 Apr 2013 17:31:30 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 17:31:30 -0700 From: Franck Martin To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: AQHOLzlrMFmZeDohV0et6KgQ/yQZZQ== Date: Tue, 2 Apr 2013 00:31:30 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EA0E4A@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:31:41 -0000 DQoNCk9uIDQvMS8xMyA1OjI2IFBNLCAiSi4gR29tZXoiIDxqZ29tZXpAc2VyeXJpY2guY29tPiB3 cm90ZToNCg0KPk9uIFR1ZXNkYXksIEFwcmlsIDAyLCAyMDEzIDE6MjggQU0gW0dNVCsxPUNFVF0s IEZyYW5jayBNYXJ0aW4gd3JvdGU6DQo+DQo+PiBPbiA0LzEvMTMgNDoxNSBQTSwgIkouIEdvbWV6 IiA8amdvbWV6QHNlcnlyaWNoLmNvbT4gd3JvdGU6DQo+PiANCj4+PiBPbiBNb25kYXksIEFwcmls IDAxLCAyMDEzIDExOjE1IFBNIFtHTVQrMT1DRVRdLCBUZXJyeSBaaW5rIHdyb3RlOg0KPj4+IA0K Pj4+PiBJIGFtIHByb3Bvc2luZyBhbiBleHRlbnNpb24gdG8gRE1BUkMuIFdoZXJlYXMgdG9kYXkg RE1BUkMgcmVxdWlyZXMNCj4+Pj4gb25lIG9mIGEgREtJTSBwYXNzIG9yIFNQRiBwYXNzLCBJIHBy b3Bvc2Ugd2UgZXh0ZW5kIERNQVJDIHNvIHRoYXQgaXMNCj4+Pj4gaGFzIHRoZSAqb3B0aW9uKiB0 byByZXF1aXJlIGJvdGguDQo+Pj4+IA0KPj4+PiAoLi4uKQ0KPj4+PiANCj4+Pj4gTGV0J3MgYXNz dW1lIHRoYXQgQmlnQmFuay5jb20gaGFzIGJlZW4gZHV0aWZ1bCBhbmQgaGFzIHB1Ymxpc2hlZCBh DQo+Pj4+IERNQVJDIHJlY29yZC4gVGhlIHByb2JsZW0gb2NjdXJzIHdoZW4gTGVhcm5pbmcuZWR1 IGdldHMgY29tcHJvbWlzZWQNCj4+Pj4gYW5kIHN0YXJ0cyBzZW5kaW5nIG91dCBzcGFtLiBJZiBh IHVzZXIgc3RhcnRzIHNlbmRpbmcgb3V0IHNwYW0gZnJvbQ0KPj4+PiBqb2VAbGVhcm5pbmcuZWR1 LCB3ZSBjYW4gZGV0ZWN0IHRoaXMgYW5kIHNodXQgaXQgZG93bi4gQnV0IHdoYXQNCj4+Pj4gaGFw cGVucyBpZiB0aGV5IHN0YXJ0IHNlbmRpbmcgb3V0IG1haWwgYXMgc2VjdXJpdHlAYmlnYmFuay5j b20/DQo+Pj4+IA0KPj4+PiBleGFtcGxlLmNvbSAtLS0tLS0tLS0tLS0rDQo+Pj4+ICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4+Pj4gQmlnQmFuay5jb20gLS0tLS0tLS0tLS0tKy0tLS0+IE1p Y3Jvc29mdCBGb3JlZnJvbnQgSVBzIC0tLS0+DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAgICAg IEludGVybmV0IHwNCj4+Pj4gTGVhcm5pbmcuZWR1ICAgICAgICAgICAgfA0KPj4+PiAgc2VjdXJp dHlAYmlnYmFuay5jb20gLS0rDQo+Pj4+IA0KPj4+PiAoLi4uKQ0KPj4+PiANCj4+Pj4gRXh0ZW5k aW5nIERNQVJDIHRoaXMgd2F5IGxldHMgYnJhbmRzL2RvbWFpbnMgcHJvdGVjdCB0aGVpciBvdXRi b3VuZA0KPj4+PiByZXB1dGF0aW9uIGJlaGluZCBhIHNoYXJlZCBzZXJ2aWNlIHdpdGhvdXQgd29y cnlpbmcgd2hldGhlciBvciBub3QNCj4+Pj4gc29tZSBvdGhlciBjdXN0b21lciB3aWxsIHNwb29m IHRoZW0uDQo+Pj4+IA0KPj4+PiBNYWtlIHNlbnNlPw0KPj4+IA0KPj4+IEkgZG9lcyBtYWtlIHNl bnNlLiBJIGFsc28gbGlrZSB0aGUgZXhwbGFuYXRpb24gaW4geW91ciBibG9nOg0KPj4+IA0KPj4+ IA0KPj4+aHR0cDovL2Jsb2dzLm1zZG4uY29tL2IvdHppbmsvYXJjaGl2ZS8yMDEyLzEwLzE4L2hv dy1zaG91bGQtbGFyZ2UtZmluYW5jDQo+Pj5pYQ0KPj4+IGwtaW5zdGl0dXRpb25zLXVzZS1ob3N0 ZWQtZmlsdGVyaW5nLmFzcHgNCj4+PiANCj4+PiBJbiBhIG11bHRpdGVuYW50IGNsb3VkIGVudmly b25tZW50LCBhbmQvb3Igd2hlbiB5b3UgYXJlIGdpdmluZw0KPj4+IGN1c3RvbWVycyBhIE1UQS1z bWFydGhvc3Qgc2VydmljZSB0byBnYXRld2F5IHRoZWlyIG1haWwgdG8gdGhlDQo+Pj4gSW50ZXJu ZXQsIHlvdSBjYW5ub3QgYmUgc3VyZSB0aGF0IHRoZXkgd2lsbCBhbHdheXMgYmUgc2lnbmluZyB0 aGVpcg0KPj4+IGVtYWlsIHdpdGggREtJTSwgYW5kIHlvdSB1c3VhbGx5IHdpbGwgbm90IGhhdmUg dGhlaXIgcHJpdmF0ZSBES0lNDQo+Pj4ga2V5cyB0byBzaWduIHRoZWlyIGVtYWlsIHlvdXJzZWxm IGFzIGl0IGZsb3dzIHRocm91Z2ggdGhlIHNtYXJ0aG9zdA0KPj4+IHRvd2FyZHMgdGhlIEludGVy bmV0LCBzbyB0YWtpbmcgdGhlIERNQVJDIG9wb3J0dW5pdHkgdG8gY2xvc2UgdGhpcw0KPj4+IGhv bGUgaW4gU1BGIGlzIGdvbGRlbi4NCj4+IA0KPj4gR29vZ2xlIGFwcHMsIHNlbmQgZ3JpZCwgbWVz c2FnZWJ1cywgKGFuZCBtYW55IG90aGVyIEVTUHMpIGRvIG5vdCBoYXZlDQo+PiBwcm9ibGVtIHRv IGNyZWF0ZSBhIERLSU0ga2V5IGZvciBlYWNoIGN1c3RvbWVyLCB0byBzaWduIHRoZSBlbWFpbHMN Cj4+IHRoYXQgcGFzcyB0aHJvdWdoIHRoZW0uIFdlIHVzZWQgdG8gaGF2ZSBvcGVuLXJlbGF5cyBi ZWNhdXNlIHRoZXkgd2VyZQ0KPj4gZWFzeSB0byBzZXR1cC9tYW5hZ2UsIGJ1dCB3ZSBtb3ZlZCBh d2F5IGZyb20gdGhlbSBiZWNhdXNlIHRoZXkgd2VyZQ0KPj4gaW5zZWN1cmUuIA0KPg0KPklmIHlv dXIgd29ycnkgaXMgbW92aW5nIGF3YXkgZnJvbSBpbnNlY3VyZSwgdGhlbiBUZXJyeSBaaW5rJ3Mg cHJvcG9zYWwgaXMNCj5qdXN0IG1ha2luZyBETUFSQyBtb3JlIHNlY3VyZSwgYXMgaXQgaXMgcmFp c2luZyB0aGUgYmFyIG9uIHRoZSBtZWNoYW5pc21zDQo+dGhhdCBoYXZlIChvcHRpb25hbGx5KSB0 byBjb25jdXIgdG8gb2J0YWluIGEgRE1BUkMtcGFzcy4NCj4NCj5BcGFydCBmcm9tIHRoYXQsIHlv dSB3b3VsZCBuZWVkIHRvIGNvbnRyb2wgeW91ciBjbGllbnQncyBETlMgdG8gc2lnbg0KPnRoZWly IERLSU0gaW4gdGhlaXIgYmVoYWxmLCBhbmQgdGhhdCBvbmx5IHdvcmtzIHdpdGggdmVyeSBzbWFs bCBjbGllbnRzDQo+d2hpY2ggbGFjayBpbi1ob3VzZSB0ZWNobmljYWwgcGVvcGxlIGFuZCBvdXRz b3VyY2UgdGhlIHdob2xlIHRoaW5nIHRvDQo+eW91LiBCdXQgaWYgeW91IHdhbnQgdG8gaGF2ZSBj bGllbnRzIG9mIG1lZGl1bSBzaXplIHdoaWNoIGdhdGV3YXkgdGhlaXINCj5tYWlsIHRvIHRoZSBJ bnRlcm5ldCB0aHJvdWdoIHlvdXIgY2xvdWQgc2VydmljZSwgZ29vZCBsdWNrIGdldHRpbmcgdGhl aXINCj50ZWNobmljYWwgcGVvcGxlIHRvIHN1cnJlbmRlciB0aGVpciBhZG1pbmlzdHJhdGl2ZSBj b250cm9sIG9mIHRoZWlyIEROUw0KPnRvIHlvdS4NCj4NCg0KV2UgZG8gdGhhdCBhbGwgdGhlIHRp bWUgd2l0aCBzdWIgZG9tYWlucy4gRG9uJ3Qgc2VlIHdoZXJlIGlzIHRoZSBpc3N1ZS4NCg0K From tzink@exchange.microsoft.com Mon Apr 1 17:31:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4121E8130 for ; Mon, 1 Apr 2013 17:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_74=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ7b1F2n46-S for ; Mon, 1 Apr 2013 17:31:43 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) by ietfa.amsl.com (Postfix) with ESMTP id BC6E121E812C for ; Mon, 1 Apr 2013 17:31:43 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.670.5; Tue, 2 Apr 2013 00:31:41 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) with mapi id 15.00.0670.000; Tue, 2 Apr 2013 00:31:41 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: AQHOLy0CZmyrYeBOG0qtiVE1WNJYrZjCEprw Date: Tue, 2 Apr 2013 00:31:40 +0000 Message-ID: <3ba7c7a04f5f45cb95930ec99926ccc9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <515A02DB.2010309@gmail.com> <20130401230214.5709.qmail@joyce.lan> In-Reply-To: <20130401230214.5709.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.221] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:31:44 -0000 Thanks for the responses, everyone. I am going to respond to them one at a = time but combine multiple email responses. John Levine: > bigbank.com txt "v=3Dspf1 ?ip4:157.55.158.0/23 ?ip4:157.55.234.0/24 ?ip4:= 157.56.112.0/24 ~all" > > Those question marks in the record on the Frontbridge ranges make them ne= utral rather than pass,=20 > which is appropriate in this case. Since all of the real mail the client= sends through your=20 > system will have a DKIM signature, it will still pass DMARC. >=20 > If the bank has its own private ranges for its non-bulk mail, those could= go in as SPF pass, e.g. >=20 > bigbank.comm txt "v=3Dspf1 +ip4:22.22.22.22 ?ip4:157.55.158.0/23 ?ip4:157= .55.234.0/24=20 > ?ip4:157.56.112.0/24 ~all" BigBank.com puts both Frontbridge/Forefront's IPs into its SPF records as w= ell as its own IPs. We validate BigBank.com's IPs when it hits us the first= time, and then 3rd parties validate our IPs when it hits them.=20 But yes, I think you understand our issue (I think). > If you insist on both SPF and DKIM, you lose the path independence and br= eak the forwarding=20 > while > gaining nothing, since the DKIM signature still tells you what yo= u need to know. =20 > If the bank sends its own unsigned mail through its own mail servers, the= SPF record reflects=20 > that, and it'll pass DMARC, too (give or take the known SPF forwarding is= sues.) You are correct that you lose the path independence. But it is incorrect to= say you gain nothing - you gain the ability to say "Nobody else can spoof = me." Shouldn't it be the choice of the sender whether or not they want to m= ake this assertion and subsequent trade-off? -- Terry -----Original Message----- From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of J= ohn Levine Sent: Monday, April 01, 2013 4:02 PM To: dmarc@ietf.org Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally req= uire SPF and DKIM >If I understand your note correctly, the problem that you cite with=20 >this is that Forefront doesn't know all of the acceptable domains for a=20 >given customer. Wouldn't it make more sense to fix this issue, rather=20 >than change the public standard and burden all recipients with the=20 >added complexity in software and operations? That's also a good idea. =20 It'd make sense to change the SPF records now, then if they can fix the int= ernal systems so that they have the domains on injected mail under control,= they could change the SPF back to make stronger assertions. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From prvs=797119cd4=fmartin@linkedin.com Mon Apr 1 17:37:27 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA50821F8F31 for ; Mon, 1 Apr 2013 17:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn8D6kfYmRki for ; Mon, 1 Apr 2013 17:37:27 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4115911E80E2 for ; Mon, 1 Apr 2013 17:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1364863047; x=1396399047; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=bRRd/8VMWT2Q2HArEIW2gWJQ1kU1q+vx2MmV78BNKZE=; b=BAh5N5pQYfa3j9VFFboM5MJ9FBwyAvjoa+8R8eBusS00PqK1ww58bM9k mdR3nUD7Mc8eYPMTPNtzXArJYaCqwh6ZZvsMDtQoy0xjaFg1XqvBIyRmu i4plN4oFgCx4xGp98hqFy2czWCe+7zw4KBfDsZYqsc9TAGb6qtRVyJ8RV 0=; X-IronPort-AV: E=Sophos;i="4.87,390,1363158000"; d="scan'208";a="42730805" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 1 Apr 2013 17:37:20 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 17:37:20 -0700 From: Franck Martin To: Terry Zink , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: AQHOLzo7WIcKgMm6jkaL17mX29pwBQ== Date: Tue, 2 Apr 2013 00:37:19 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EA0E87@ESV4-MBX01.linkedin.biz> In-Reply-To: <3ba7c7a04f5f45cb95930ec99926ccc9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.254] Content-Type: text/plain; charset="utf-8" Content-ID: <250FE33FDB28EA41997D7C44D2F47F51@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:37:28 -0000 DQoNCk9uIDQvMS8xMyA1OjMxIFBNLCAiVGVycnkgWmluayIgPHR6aW5rQGV4Y2hhbmdlLm1pY3Jv c29mdC5jb20+IHdyb3RlOg0KDQo+VGhhbmtzIGZvciB0aGUgcmVzcG9uc2VzLCBldmVyeW9uZS4g SSBhbSBnb2luZyB0byByZXNwb25kIHRvIHRoZW0gb25lIGF0DQo+YSB0aW1lIGJ1dCBjb21iaW5l IG11bHRpcGxlIGVtYWlsIHJlc3BvbnNlcy4NCj4NCj5Kb2huIExldmluZToNCj4NCj4+IGJpZ2Jh bmsuY29tIHR4dCAidj1zcGYxID9pcDQ6MTU3LjU1LjE1OC4wLzIzID9pcDQ6MTU3LjU1LjIzNC4w LzI0DQo+Pj9pcDQ6MTU3LjU2LjExMi4wLzI0IH5hbGwiDQo+Pg0KPj4gVGhvc2UgcXVlc3Rpb24g bWFya3MgaW4gdGhlIHJlY29yZCBvbiB0aGUgRnJvbnRicmlkZ2UgcmFuZ2VzIG1ha2UgdGhlbQ0K Pj5uZXV0cmFsIHJhdGhlciB0aGFuIHBhc3MsDQo+PiB3aGljaCBpcyBhcHByb3ByaWF0ZSBpbiB0 aGlzIGNhc2UuICBTaW5jZSBhbGwgb2YgdGhlIHJlYWwgbWFpbCB0aGUNCj4+Y2xpZW50IHNlbmRz IHRocm91Z2ggeW91cg0KPj4gc3lzdGVtIHdpbGwgaGF2ZSBhIERLSU0gc2lnbmF0dXJlLCBpdCB3 aWxsIHN0aWxsIHBhc3MgRE1BUkMuDQo+PiANCj4+IElmIHRoZSBiYW5rIGhhcyBpdHMgb3duIHBy aXZhdGUgcmFuZ2VzIGZvciBpdHMgbm9uLWJ1bGsgbWFpbCwgdGhvc2UNCj4+Y291bGQgZ28gaW4g YXMgU1BGIHBhc3MsIGUuZy4NCj4+IA0KPj4gYmlnYmFuay5jb21tIHR4dCAidj1zcGYxICtpcDQ6 MjIuMjIuMjIuMjIgP2lwNDoxNTcuNTUuMTU4LjAvMjMNCj4+P2lwNDoxNTcuNTUuMjM0LjAvMjQN Cj4+ID9pcDQ6MTU3LjU2LjExMi4wLzI0IH5hbGwiDQo+DQo+QmlnQmFuay5jb20gcHV0cyBib3Ro IEZyb250YnJpZGdlL0ZvcmVmcm9udCdzIElQcyBpbnRvIGl0cyBTUEYgcmVjb3JkcyBhcw0KPndl bGwgYXMgaXRzIG93biBJUHMuIFdlIHZhbGlkYXRlIEJpZ0JhbmsuY29tJ3MgSVBzIHdoZW4gaXQg aGl0cyB1cyB0aGUNCj5maXJzdCB0aW1lLCBhbmQgdGhlbiAzcmQgcGFydGllcyB2YWxpZGF0ZSBv dXIgSVBzIHdoZW4gaXQgaGl0cyB0aGVtLg0KPg0KPkJ1dCB5ZXMsIEkgdGhpbmsgeW91IHVuZGVy c3RhbmQgb3VyIGlzc3VlIChJIHRoaW5rKS4NCj4NCj4+IElmIHlvdSBpbnNpc3Qgb24gYm90aCBT UEYgYW5kIERLSU0sIHlvdSBsb3NlIHRoZSBwYXRoIGluZGVwZW5kZW5jZSBhbmQNCj4+YnJlYWsg dGhlIGZvcndhcmRpbmcNCj4+IHdoaWxlID4gZ2FpbmluZyBub3RoaW5nLCBzaW5jZSB0aGUgREtJ TSBzaWduYXR1cmUgc3RpbGwgdGVsbHMgeW91IHdoYXQNCj4+eW91IG5lZWQgdG8ga25vdy4NCj4+ IElmIHRoZSBiYW5rIHNlbmRzIGl0cyBvd24gdW5zaWduZWQgbWFpbCB0aHJvdWdoIGl0cyBvd24g bWFpbCBzZXJ2ZXJzLA0KPj50aGUgU1BGIHJlY29yZCByZWZsZWN0cw0KPj4gdGhhdCwgYW5kIGl0 J2xsIHBhc3MgRE1BUkMsIHRvbyAoZ2l2ZSBvciB0YWtlIHRoZSBrbm93biBTUEYgZm9yd2FyZGlu Zw0KPj5pc3N1ZXMuKQ0KPg0KPllvdSBhcmUgY29ycmVjdCB0aGF0IHlvdSBsb3NlIHRoZSBwYXRo IGluZGVwZW5kZW5jZS4gQnV0IGl0IGlzIGluY29ycmVjdA0KPnRvIHNheSB5b3UgZ2FpbiBub3Ro aW5nIC0geW91IGdhaW4gdGhlIGFiaWxpdHkgdG8gc2F5ICJOb2JvZHkgZWxzZSBjYW4NCj5zcG9v ZiBtZS4iIFNob3VsZG4ndCBpdCBiZSB0aGUgY2hvaWNlIG9mIHRoZSBzZW5kZXIgd2hldGhlciBv ciBub3QgdGhleQ0KPndhbnQgdG8gbWFrZSB0aGlzIGFzc2VydGlvbiBhbmQgc3Vic2VxdWVudCB0 cmFkZS1vZmY/DQo+DQoNCldlIGRpZCBTUEYgb3IgREtJTSBiZWNhdXNlIGJvdGggd2VyZSBub3Qg c29sdmluZyB0aGUgcHJvYmxlbSBvbiB0aGVpciBvd24uDQpTbyBib3RoIGNvbWJpbmVkIHRvZ2V0 aGVyIGhhcyBhbGwgdGhlIGFkdmFudGFnZXMgbGVzcyB0aGUgaW5jb252ZW5pZW5jZXMuDQoNCklm IHlvdSB3YW50IHRvIHNheSwgbm9ib2R5IGVsc2UgY2FuIHNwb29mIG1lLCB0aGVuIHlvdSBjYW4g ZG8gU1BGIC1hbGwsDQpidXQgdGhlbiBubyBsYXJnZSByZWNlaXZlciBuZXZlciByZWFsbHkgdHJ1 c3RlZCB0aGlzIHBvbGljeSBhc3NlcnRpb24uDQpBbHNvLCB5b3UgY2FuIHB1dCBhIERNQVJDIHJl Y29yZCBhbmQgU1BGIGFuZCBub3QgREtJTSBzaWduLCB5b3Ugd2lsbCBnZXQNCnRoZSBzYW1lIGJl bmVmaXRzLg0KDQo= From tzink@exchange.microsoft.com Mon Apr 1 17:45:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605FB21F8B04 for ; Mon, 1 Apr 2013 17:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, SARE_BIZOP=0.7, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jytvVCXbFtz for ; Mon, 1 Apr 2013 17:45:39 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBBE21F8AE3 for ; Mon, 1 Apr 2013 17:45:39 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.670.5; Tue, 2 Apr 2013 00:45:37 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) with mapi id 15.00.0670.000; Tue, 2 Apr 2013 00:45:37 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: Ac4vHeGtF3P4hm3YSDmZ3O/llvHH6gABhBGAAAI3JIAAAylrUA== Date: Tue, 2 Apr 2013 00:45:36 +0000 Message-ID: <9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <515A02DB.2010309@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.221] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:45:40 -0000 Hi, Mike. > This is a bad idea. While it solves your internal problem it potentially = increases false=20 > positives for bigbank.com externally, thus trading one problem for anothe= r I agree that there is the potential for false positives. But shouldn't this= choice be given to the sender? If they understand the risks then they shou= ld be able to say "Yes, this can cause false positives. But we can get thos= e under control (or delegate sub-domains for third parties, or some other w= orkaround like using DMARC to collect feedback on where the unsigned mail o= riginates). The bottom line is we don't want anyone spoofing our domain." > If bigbank.com cannot control it's managers/employees and how they send m= ail then that=20 > is an internal problem that bigbank needs to address. There are plenty of= other=20 > mechanisms for bigbank to control what it emits (in the case of spam).=20 True enough. But it happens with regularity. At a large company, people mov= e on all the time. Groups change and people retire, change jobs, or otherwi= se move on. The people in charge of maintaining all this IT stuff do not ke= ep pace with the scope of change. This is especially true in a large organi= zation (it is one of our own challenges). But even beyond that, it's not the only legitimate case we have to deal wit= h. We have companies like real estate companies (e.g., Remax -- if they wer= e a customer) that have independent sales agents. The inbound mail is agent= @remax.com. The independent agent gets the mail forwarded to their personal= email account and then they send outbound mail through us agent@yahoo.com.= Remax does not own yahoo.com, but this is a legitimate case where a user "= spoofs" a legitimate domain that they do not own. Thus, shutting down this case is not going to work. The majority of the mai= l from "legitimately spoofed" senders is non-spam. But the cases of spoofin= g a domain maliciously is what I want to target. > Perhaps MS should offer bigbank dedicated IPs - ESPs do this all the time= for their customers.=20 > It may not be so critical for other customers. Sounds like a business opp= ortunity to me. This would solve one problem but introduces other: a) We have plenty of small businesses that sign up for our service. They ma= y all want their own IPs. Microsoft has plenty of IPs but we don't have an = near-infinite amount (the ones Microsoft has, we share them with the rest o= f the company; they don't all belong to our division). b) Even if we did give customers their own IPs, they each would get at leas= t two IPs - one in two different data centers for redundancy. This reduces = the available pool of IPs. c) The networking challenge of maintaining IPs-to-customers mapping is pain= ful. Running a service with as much redundancy, failover, cross-datacenter = routing as ours is difficult and maintaining all these network mappings add= s too much complexity. We can barely keep track of our own IPs. Thus, the cost/benefit tradeoff of giving everyone (or even some customers)= their own IP skews heavier towards the costs compared the benefits. -- Terry -----Original Message----- From: MH Michael Hammer (5304) [mailto:MHammer@ag.com]=20 Sent: Monday, April 01, 2013 4:01 PM To: Dave Crocker; Terry Zink Cc: dmarc@ietf.org Subject: RE: [dmarc-ietf] Proposing an extension to DMARC to optionally req= uire SPF and DKIM Comments in-line. > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf=20 > Of Dave Crocker > Sent: Monday, April 01, 2013 5:58 PM > To: Terry Zink > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to=20 > optionally require SPF and DKIM >=20 > Terry, >=20 > On 4/1/2013 2:15 PM, Terry Zink wrote: > > I am proposing an extension to DMARC. Whereas today DMARC requires > one > > of a DKIM pass or SPF pass, I propose we extend DMARC so that is has > > the*option* to require both. >=20 This is a bad idea. While it solves your internal problem it potentially in= creases false positives for bigbank.com externally, thus trading one proble= m for another. I've been implementing SPF (ending with -all) and DKIM with = private channel assertions since the end of 2007. One of the reasons for us= ing the combination of SPF and DKIM ( and requiring only one to pass) is th= e reduction of false positives.=20 Before trying to extend DMARC to account for internal problems - as Dave po= ints out - I would look for other ways of resolving the problem. As I have = said many times regarding email authentication implementation, one needs to= get control of their mail flows. That is true in this case. If bigbank.com= cannot control it's managers/employees and how they send mail then that is= an internal problem that bigbank needs to address. There are plenty of oth= er mechanisms for bigbank to control what it emits (in the case of spam). P= erhaps MS should offer bigbank dedicated IPs - ESPs do this all the time fo= r their customers. It may not be so critical for other customers. Sounds li= ke a business opportunity to me. > The draft working group charter that Murray just circulated would make=20 > this effort out of scope, since it explicitly prohibits protocol enhancem= ent. >=20 > Are you suggesting a change to the draft charter? >=20 I prefer to avoid relying on limitations in the charter and focusing on the= merits which IMHO don't rise to a level justifying this extension. One of = the key merits of DMARC is that it focuses on solving a particular problem = and based on the data it does that very well. > An alternative might be to find a way for this example scenario to=20 > provide the basis for some discussion, in the draft BCP, about the=20 > proper limits of DMARC. It wouldn't solve your protocol problem, but=20 > it might provide good pedagogy. >=20 This sounds like a good idea. > Perhaps there are other alternatives? >=20 >=20 > > Let's assume that BigBank.com has been dutiful and has published a=20 > > DMARC record. The problem occurs when Learning.edu gets compromised=20 > > and starts sending out spam. If a user starts sending out spam=20 > > fromjoe@learning.edu, we can detect this and shut it down. But what=20 > > happens if they start sending out mail assecurity@bigbank.com? >=20 It sounds like someone needs btter internal controls to prevent this. > I tend to draw a distinction between protection against internal=20 > problems, versus protection against external ones. Internal means=20 > that the misbehavior is caused by an activity within the=20 > administrative scope of the entity needing protection. External means=20 > that the problem behavior comes from some other administrative scope. >=20 +1 > The usual examples of the distinction are misbehaviors by a=20 > department, within the company owning the domain name, versus=20 > misbehavior from a classic spammer who is using the domain name=20 > without authorization. On the average, the tendency has been to pursue=20 > standardization that protect against external threats rather than=20 > internal ones. Internal ones are thought to be best handled... internally= . >=20 > > 1. example.com ----+ > > | > > 2. BigBank.com ----+----> Microsoft Forefront IPs ----> Internet > > | > > 3. Learning.edu ---+ >=20 >=20 > The scenario you give might be considered as internal misbehavior,=20 > since there is a contractual relationship between Forefront and the=20 > sources of messages that you list. That is, the essence of the=20 > challenge is for Forefront to have mechanisms that distinguish what=20 > mail is authorized from what source, and what mail isn't. Per your=20 > example, it would require that it enforce its /own/ dmarc-ish policy=20 > to require that mail it is relaying for learning.edu be attributed to lea= rning.edu, and so on. >=20 > If I understand your note correctly, the problem that you cite with=20 > this is that Forefront doesn't know all of the acceptable domains for a g= iven customer. > Wouldn't it make more sense to fix this issue, rather than change the=20 > public standard and burden all recipients with the added complexity in=20 > software and operations? >=20 +1 > Without have thought about it much, I suspect that one approach to=20 > fixing this is for Forefront to /privately/ assert the type of=20 > dmarc-ish enhancement that you propose. That is, impose the=20 > requirement on its customers, thereby assuring that the mail it is=20 > relaying to the public Internet is 'safe', at least along this one line o= f concern. >=20 >=20 From johnl@iecc.com Mon Apr 1 17:46:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DA911E80E2 for ; Mon, 1 Apr 2013 17:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.642 X-Spam-Level: X-Spam-Status: No, score=-110.642 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lwpj5bvjjBMf for ; Mon, 1 Apr 2013 17:46:07 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C675421F8CEE for ; Mon, 1 Apr 2013 17:45:51 -0700 (PDT) Received: (qmail 15061 invoked from network); 2 Apr 2013 00:45:51 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Apr 2013 00:45:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a2a3e.xn--9vv.k1304; i=johnl@user.iecc.com; bh=cHt3J2/Jj8NB5JVIFz059XztI8IMiLUlS7sl5jKv7Jk=; b=TR8nDYMhPwLL6VVtnHWXykUA7H+JM5GL1JA3+ytn5a9bNdQRworlOpgK5owLJ1W2+lJCvwj467x0XptySXxoozOueTrw6MTxzPIsBxGPFYoOmsBBTDicOrOqyaUM3e2F5tfwtcpqZj9PyGyOMyZ5+d3NnVY+Jev3k3+MFTDjgYg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a2a3e.xn--9vv.k1304; olt=johnl@user.iecc.com; bh=cHt3J2/Jj8NB5JVIFz059XztI8IMiLUlS7sl5jKv7Jk=; b=dvcN/e14KDRzM+WU53gSGsi6X/hEJ094ItgCHPhEDDKCHxzcRfJ7iSH2io9lIA9avpcisiR5hrxwW1Ys2cqJEMFWKMiMrrQ1IpibT+qZUlNCtBkysYeowzkvwuodjQigJ0GiOPGuw9V1Wz71dXM9epzWdgtZ+Lhk+eG+qYwUmgs= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Apr 2013 00:45:28 -0000 Message-ID: <20130402004528.6146.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <3ba7c7a04f5f45cb95930ec99926ccc9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:46:07 -0000 > You are correct that you lose the path independence. But it is > incorrect to say you gain nothing - you gain the ability to say > "Nobody else can spoof me." Nope. As I said, Terry's proposal adds nothing beyond the configuration I described. Please reread the message to which you were responding more carefully, paying particular attention to the difference between SPF pass and neutral. Really, you gain nothing. >Shouldn't it be the choice of the sender whether or not they want to make this assertion and subsequent >trade-off? The sender can make any assertion it wants, but it better not assume that anyone is paying attention. The more complicated the assertions, the less likely that receivers will think it's worth the effort to interpret them. R's, John From johnl@iecc.com Mon Apr 1 17:48:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A7A11E80F8 for ; Mon, 1 Apr 2013 17:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.453 X-Spam-Level: X-Spam-Status: No, score=-110.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_16=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCZiZBtCwIHC for ; Mon, 1 Apr 2013 17:48:37 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A9B2D11E80E2 for ; Mon, 1 Apr 2013 17:48:36 -0700 (PDT) Received: (qmail 15810 invoked from network); 2 Apr 2013 00:48:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Apr 2013 00:48:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a2ae4.xn--30v786c.k1304; i=johnl@user.iecc.com; bh=ry2picfEAvbUZ3CeQIYBnmEs308C0lP/3u34T1vHEyg=; b=Sov0gCmVtvwduFy7P3V+yK99Hft4AQgAvLZkzXuP64Lk0rndi1DL7Pycd7pGFGcFVJYwSZrEN6QGY7+W/sWFjTcN1EWUXOYUpZvHGyyy6FYf98zZzJ9f7+pcQj7pOt2L/OSbVDIqagKx0JeFITsyb5iFsHVTZoix4+QclUVUewo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a2ae4.xn--30v786c.k1304; olt=johnl@user.iecc.com; bh=ry2picfEAvbUZ3CeQIYBnmEs308C0lP/3u34T1vHEyg=; b=fUb7ePPY7+jDd+YzbNRez3o1M+zO++3X/0+GQhRQ8EV75LlxrlCSo9Dkx30qlossq3bpUm5MDPWHiW59fDmgKODcyJfTkzOSRCJa3HeSL4mTTUBh4dO7HoIFxMwXjRz6lATrCOgLcp+NmFAJyiy6niFog8IoPfN1jVCnot/Bfys= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Apr 2013 00:48:13 -0000 Message-ID: <20130402004813.6168.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EA0E87@ESV4-MBX01.linkedin.biz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: fmartin@linkedin.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:48:37 -0000 >If you want to say, nobody else can spoof me, then you can do SPF -all, Or you can sign all your mail with DKIM, publish no SPF at all, and use DMARC p=reject. (If anyone used ADSP, you could use ADSP discardable. too.) One of the strengths of DMARC is that SPF and DKIM are each optional, and senders can use them in whatever combination best describes their mail setup. From jgomez@seryrich.com Mon Apr 1 17:52:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD3521E804A for ; Mon, 1 Apr 2013 17:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZK0RXpgoj4E for ; Mon, 1 Apr 2013 17:52:14 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 2410E11E80F8 for ; Mon, 1 Apr 2013 17:52:13 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Apr 2013 02:52:11 +0200 Message-ID: From: "J. Gomez" To: References: <77426B543150464AA3F30DF1A91365DE52EA0E87@ESV4-MBX01.linkedin.biz> Date: Tue, 2 Apr 2013 02:53:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:52:16 -0000 On Tuesday, April 02, 2013 2:37 AM [GMT+1=3DCET], Franck Martin wrote: > We did SPF or DKIM because both were not solving the problem on their > own. So both combined together has all the advantages less the > inconveniences.=20 >=20 > If you want to say, nobody else can spoof me, then you can do SPF > -all, but then no large receiver never really trusted this policy > assertion. Also, you can put a DMARC record and SPF and not DKIM > sign, you will get the same benefits. Hmm, are you missing the part where several independent clients send to = the Internet through the same cloud-based email gateway, and therefore = "-all" in SPF still allows for spoofing if any of those clients is = trojanized, and DMARC in its current form does nothing to solve this = problem? Ok, DMARC has been devised by brand-companies (Facebook, Linkedin, = Big-Bank-X) and mailbox-providers (Hotmail, Yahoo, Gmail), I see that = and I understand their needs to reliably exchange email policies. But = there is more people in the email ecosystem, like for example = cloud-services providers, who also happen to do email. I think the needs of everyone (exchanging email policies, and securing = authentication in a multitenant cloud service) can be met easily with = DMARC, without harm for any of those camps. Regards, J. Gomez From johnl@iecc.com Mon Apr 1 17:52:55 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49B811E811E for ; Mon, 1 Apr 2013 17:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.778 X-Spam-Level: X-Spam-Status: No, score=-110.778 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELDYORhmLdfk for ; Mon, 1 Apr 2013 17:52:55 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D408311E80F8 for ; Mon, 1 Apr 2013 17:52:54 -0700 (PDT) Received: (qmail 17091 invoked from network); 2 Apr 2013 00:52:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Apr 2013 00:52:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a2be6.xn--9vv.k1304; i=johnl@user.iecc.com; bh=mxKF4RvsNNmWh5VbIFo6IEhaRT6HHKl0eYmAb3GATEE=; b=E/8cGPY5AFCO9AVUWMMhc8coApYoPGuUoZksw4AE+5NBNQ5lc4DpirTvBNmAEBso7a7FDBNs5DJPoMnDEHPQXUeKI3Vc3A99piHWZth/lPhM9SrHdBIIYMojp7GF7bts05xiwxlKaaiIaaR3LD/LYkogSUU8n/4VXHgkWcOd+i4= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a2be6.xn--9vv.k1304; olt=johnl@user.iecc.com; bh=mxKF4RvsNNmWh5VbIFo6IEhaRT6HHKl0eYmAb3GATEE=; b=Fft5kjYbmpwgaaXIdQ1GDafgDi/zbI+2TDUA04qUdYlfoUtrIpy/wJgqdbgZn3BGrlBkZR2A/X2nGhyktAjrayNk41eXo/Viz5OeLgTozOGAjpwc6DCQ/+/ucQnZX0Cy2I0mSRSCeEUMDDw7YMUl2AridhUGGY4+N7hZ/XjtqN4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Apr 2013 00:52:31 -0000 Message-ID: <20130402005231.6202.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:52:55 -0000 >I agree that there is the potential for false positives. But shouldn't this choice be given to the sender? No, of course not. You don't get the complaints when my users lose mail due to false positives. If the sender can make any choice he wants, I choose to charge $5 to everyone who reads this message. Pay up, please. More seriously, receivers are not going to implement complex stuff that offers no useful extra function, particularly if they make their lives harder and the extra stuff is to work around problems that are better fixed at the sender's end. R's, John From johnl@iecc.com Mon Apr 1 17:57:36 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D242011E811A for ; Mon, 1 Apr 2013 17:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.838 X-Spam-Level: X-Spam-Status: No, score=-110.838 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZn8wGeCB0rD for ; Mon, 1 Apr 2013 17:57:36 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9520811E80F8 for ; Mon, 1 Apr 2013 17:57:35 -0700 (PDT) Received: (qmail 18405 invoked from network); 2 Apr 2013 00:57:35 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Apr 2013 00:57:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a2cfe.xn--30v786c.k1304; i=johnl@user.iecc.com; bh=0gUpkdcR6aSm7L6Ggz09AJZfE733OMvDD3k3ws4WnEk=; b=CWWWaM20GlBh8bwJUD3g8O6du0skOMH18gWKqo4Nymq4E5M1CcRENoU3RS4zFHO7csVFKLrx7DQP6numtF/gvKdjsYtqdaUp/oHhmHHWq9YMy23tFMLJNtXRocSP90EWWIPIsn96ot5TEXLUbaBILb0j2MOj+AepytvecixkyjM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a2cfe.xn--30v786c.k1304; olt=johnl@user.iecc.com; bh=0gUpkdcR6aSm7L6Ggz09AJZfE733OMvDD3k3ws4WnEk=; b=B12fKUaQeNnKf9jURVfO4oLVYcHqOknbsTvUyYS6Eb+1ED1eFx1c8SVNezvBIeMTLH8xEh1UeTDskRs5gMf9pc7lIQNXr0VhULa8cRgk3Y++xbE8Rlw5HKx46HaTmJmoH7SJIt4zldXrCKb4dOUzJgXdUETI5AK7dkHk/De/4gA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Apr 2013 00:57:12 -0000 Message-ID: <20130402005712.6238.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: jgomez@seryrich.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:57:36 -0000 > Hmm, are you missing the part where several independent clients send > to the Internet through the same cloud-based email gateway, and > therefore "-all" in SPF still allows for spoofing if any of those > clients is trojanized, and DMARC in its current form does nothing to > solve this problem? DMARC works fine if the senders behind the cloud each have different DKIM signatures, which I gather is what Terry was describing, and the SPF correctly describes the outgoing mail policy. If you believe that DKIM signatures do not adequately identify a mail stream, I'd appreciate it if you could explain in detail why not. R's, John From tzink@exchange.microsoft.com Mon Apr 1 17:59:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1712911E811F for ; Mon, 1 Apr 2013 17:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.974 X-Spam-Level: X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f6TwnvnA5k1 for ; Mon, 1 Apr 2013 17:59:22 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.23]) by ietfa.amsl.com (Postfix) with ESMTP id 69E0411E80F8 for ; Mon, 1 Apr 2013 17:59:22 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.670.5; Tue, 2 Apr 2013 00:59:20 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) with mapi id 15.00.0670.000; Tue, 2 Apr 2013 00:59:20 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: AQHOLzvTHt+cvTe3uUu+i2ndboug7ZjCGeFQ Date: Tue, 2 Apr 2013 00:59:19 +0000 Message-ID: References: <77426B543150464AA3F30DF1A91365DE52EA0E87@ESV4-MBX01.linkedin.biz> <20130402004813.6168.qmail@joyce.lan> In-Reply-To: <20130402004813.6168.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.221] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 00:59:24 -0000 John, I'm going to combine your responses. Please bear with me to ensure I unders= tand what you are saying. > Nope. As I said, Terry's proposal adds nothing beyond the configuration = I described. > Please reread the message to which you were responding more carefully, pa= ying particular=20 > attention to the difference between SPF pass and neutral. Really, you ga= in nothing. >=20 > bigbank.com txt "v=3Dspf1 +ip4:22.22.22.22 ?ip4:157.55.158.0/23=20 > ?ip4:157.55.234.0/24 ?ip4:157.56.112.0/24 ~all" example.com ------------+ | BigBank.com ------------+----> Microsoft Forefront IPs ----> Internet | Learning.edu | security@bigbank.com --+ Case 1 - Mail comes from 22.22.22.22 -> Forefront scans it and it SPF passe= s -> Relays to Internet (e.g., Hotmail) who scans it and it is Neutral (sin= ce it came from Forefront IP range) Case 2 - Mail comes from 1.2.3.4 (Learning.edu malicious spoof) -> Forefron= t scans it and it SPF fails -> Relays to Internet (e.g., Hotmail) who scans= it and it is Neutral But real mail from BigBank.com would have a DKIM header and so therefore it= would DMARC pass at the Hotmail side. Is that right? But wouldn't it mean that a 3rd party who didn't validate DKIM or DMARC wou= ld always get SPF Neutral in the case of a legitimate message? > Or you can sign all your mail with DKIM, publish no SPF at all, and use D= MARC p=3Dreject. I've thought of that, too. I think that would be a good solution if DMARC c= ompliance was more widespread than it is (it's pretty good now but there's = still a very long tail of receivers who just use SPF and don't validate DKI= M... I don't want to mention any names but there's at least one large MTA t= hat still doesn't validate DKIM natively). Thus, if you don't publish SPF r= ecords, for the long tail of receivers that don't do DKIM or DMARC, they ar= e even more prone to spoofing since they wouldn't pass SPF. > (If anyone used ADSP, you could use ADSP discardable. too.) I've thought of that, too. But I heard ADSP was basically dead and supersed= ed by DMARC. -- Terry -----Original Message----- From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of J= ohn Levine Sent: Monday, April 01, 2013 5:48 PM To: dmarc@ietf.org Cc: fmartin@linkedin.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally req= uire SPF and DKIM >If you want to say, nobody else can spoof me, then you can do SPF -all, Or you can sign all your mail with DKIM, publish no SPF at all, and use DMA= RC p=3Dreject. (If anyone used ADSP, you could use ADSP discardable. too.= ) One of the strengths of DMARC is that SPF and DKIM are each optional, and s= enders can use them in whatever combination best describes their mail setup= . _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From sklist@kitterman.com Mon Apr 1 18:08:49 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1243C11E811B for ; Mon, 1 Apr 2013 18:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KeDoj8Mq53z for ; Mon, 1 Apr 2013 18:08:45 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEF511E811A for ; Mon, 1 Apr 2013 18:08:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8092220E40D5; Mon, 1 Apr 2013 21:08:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364864923; bh=FCn4DWvxv2VVOXyd7rLIkz/wJLOIzNuEhYJUUNaFqcA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=c1K1HKypmTn6F0PG6JU2cmoTA73mamyo9fQFo5HHUjwIRsbTKuoL48IdX4Jl7B2eP v8Eg7ta/utNxClSYBu9rmpM/M9n3UrQaR4QyhwCaMWtEd23x2ritCxfSZxQZpRrliu MJlZjUiLLHaucKDUcrqLm9FahLIYEjjCuSzfRF38= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 51DD820E4090; Mon, 1 Apr 2013 21:08:42 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 01 Apr 2013 21:08:42 -0400 Message-ID: <3458691.6JUdcXG44l@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <77426B543150464AA3F30DF1A91365DE52EA0C4E@ESV4-MBX01.linkedin.biz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 01:08:49 -0000 On Tuesday, April 02, 2013 02:26:01 AM J. Gomez wrote: > On Tuesday, April 02, 2013 1:28 AM [GMT+1=CET], Franck Martin wrote: > > On 4/1/13 4:15 PM, "J. Gomez" wrote: > >> On Monday, April 01, 2013 11:15 PM [GMT+1=CET], Terry Zink wrote: > >>> I am proposing an extension to DMARC. Whereas today DMARC requires > >>> one of a DKIM pass or SPF pass, I propose we extend DMARC so that is > >>> has the *option* to require both. > >>> > >>> (...) > >>> > >>> Let's assume that BigBank.com has been dutiful and has published a > >>> DMARC record. The problem occurs when Learning.edu gets compromised > >>> and starts sending out spam. If a user starts sending out spam from > >>> joe@learning.edu, we can detect this and shut it down. But what > >>> happens if they start sending out mail as security@bigbank.com? > >>> > >>> example.com ------------+ > >>> > >>> BigBank.com ------------+----> Microsoft Forefront IPs ----> > >>> > >>> Internet | > >>> > >>> Learning.edu | > >>> > >>> security@bigbank.com --+ > >>> > >>> (...) > >>> > >>> Extending DMARC this way lets brands/domains protect their outbound > >>> reputation behind a shared service without worrying whether or not > >>> some other customer will spoof them. > >>> > >>> Make sense? > >> > >> I does make sense. I also like the explanation in your blog: > >> > >> http://blogs.msdn.com/b/tzink/archive/2012/10/18/how-should-large-financi > >> a > >> l-institutions-use-hosted-filtering.aspx > >> > >> In a multitenant cloud environment, and/or when you are giving > >> customers a MTA-smarthost service to gateway their mail to the > >> Internet, you cannot be sure that they will always be signing their > >> email with DKIM, and you usually will not have their private DKIM > >> keys to sign their email yourself as it flows through the smarthost > >> towards the Internet, so taking the DMARC oportunity to close this > >> hole in SPF is golden. > > > > Google apps, send grid, messagebus, (and many other ESPs) do not have > > problem to create a DKIM key for each customer, to sign the emails > > that pass through them. We used to have open-relays because they were > > easy to setup/manage, but we moved away from them because they were > > insecure. > > If your worry is moving away from insecure, then Terry Zink's proposal is > just making DMARC more secure, as it is raising the bar on the mechanisms > that have (optionally) to concur to obtain a DMARC-pass. > > Apart from that, you would need to control your client's DNS to sign their > DKIM in their behalf, and that only works with very small clients which > lack in-house technical people and outsource the whole thing to you. But if > you want to have clients of medium size which gateway their mail to the > Internet through your cloud service, good luck getting their technical > people to surrender their administrative control of their DNS to you. Not true at all. I've done this many times where the domain owner publishes a CNAME to the relevant DNS entry in the provider's DNS. That way the provider can manage the specifics/use their own private key (for DKIM) without any zone delegation being required. Scott K From sklist@kitterman.com Mon Apr 1 18:15:22 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6849711E811A for ; Mon, 1 Apr 2013 18:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFpvcaNtaKp7 for ; Mon, 1 Apr 2013 18:15:21 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BFBCC11E8116 for ; Mon, 1 Apr 2013 18:15:21 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 47F0220E40D5; Mon, 1 Apr 2013 21:15:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364865321; bh=NHkAJauqB02YvyA6WPGPou07Pqt4ISpvCJpzNz8kvzU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RW1rSh43Y9+uD6nIb44KbuWur3nPsdupYh9hfTBapnMi3T0U+f5UZS0qmMXZIBnpK G5Rfruq9Nn8lk95uPELWlTNLK5kEGO0ktv1PP0xXpx48U10O3zR2o+Zlou0OQch0eB GlryBM0Xj4ksuvf8i7GvMG3VL3fR1MhRce5PJdFM= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 20D7A20E4090; Mon, 1 Apr 2013 21:14:50 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 01 Apr 2013 21:14:50 -0400 Message-ID: <3539257.rshtJ9z1rl@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <77426B543150464AA3F30DF1A91365DE52EA0E87@ESV4-MBX01.linkedin.biz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 01:15:22 -0000 On Tuesday, April 02, 2013 02:53:30 AM J. Gomez wrote: > Hmm, are you missing the part where several independent clients send to the > Internet through the same cloud-based email gateway, and therefore "-all" > in SPF still allows for spoofing if any of those clients is trojanized, and > DMARC in its current form does nothing to solve this problem? There's no way a internet facing protocol can fix local validation failures. This is not news. http://tools.ietf.org/html/rfc4408#section-10.4 https://tools.ietf.org/html/rfc4871#page-53 If you're telling your customer's they can trust you not to let your other customers spoof them, then you actually have to do that. No one else can do it for you. Scott K From jgomez@seryrich.com Mon Apr 1 18:18:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A39A611E811B for ; Mon, 1 Apr 2013 18:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49ONmo1B0hvd for ; Mon, 1 Apr 2013 18:18:06 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id AD5D811E811A for ; Mon, 1 Apr 2013 18:18:05 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Apr 2013 03:18:04 +0200 Message-ID: <07885B3D9573426085184C6B2CD2504C@fgsr.local> From: "J. Gomez" To: References: <20130402004528.6146.qmail@joyce.lan> Date: Tue, 2 Apr 2013 03:19:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 01:18:06 -0000 On Tuesday, April 02, 2013 2:45 AM [GMT+1=3DCET], John Levine wrote: > The sender can make any assertion it wants, but it better not assume > that anyone is paying attention. The more complicated the assertions, > the less likely that receivers will think it's worth the effort to > interpret them. While true for non-standarized "things", it would be reasonably expected = that if you make an assertion backed by a "official" standard, it should = be accepted by others, at least, as "yeah you did make that assertion" = and perhaps even as "yeah you did make that assertion and we believe you = meant to assert it so we will follow through". The point remains: in what form or shape Terry's optional DMARC = extension hinders DMARC's goals? After all, that "complication" will be dealt with by a code library, = just painlessly. Regards, J. Gomez From MHammer@ag.com Mon Apr 1 18:20:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC7021F8B0A for ; Mon, 1 Apr 2013 18:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKbdSAwC4Xiu for ; Mon, 1 Apr 2013 18:20:46 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id A417721F8202 for ; Mon, 1 Apr 2013 18:20:44 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 21:20:37 -0400 From: "MH Michael Hammer (5304)" To: Terry Zink , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: AQHOLyQDr9vuaJVnrUmomkiXMf3sBZjB9p9wgABk7gD//74yQA== Date: Tue, 2 Apr 2013 01:20:37 +0000 Message-ID: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <515A02DB.2010309@gmail.com> <9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: <9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 01:20:47 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Terry Zink > Sent: Monday, April 01, 2013 8:46 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally > require SPF and DKIM >=20 > Hi, Mike. >=20 > > This is a bad idea. While it solves your internal problem it > > potentially increases false positives for bigbank.com externally, thus > > trading one problem for another >=20 > I agree that there is the potential for false positives. But shouldn't th= is choice > be given to the sender? If they understand the risks then they should be > able to say "Yes, this can cause false positives. But we can get those un= der > control (or delegate sub-domains for third parties, or some other > workaround like using DMARC to collect feedback on where the unsigned > mail originates). The bottom line is we don't want anyone spoofing our > domain." >=20 Then don't let people "spoof" your domain. You have another problem with sh= ared IPs that hasn't been brought into the discussion. By sharing IPs you a= re sharing reputation across customers. If one of those customers starts sp= ewing abusive mail then the other customers suffer as a consequence. I'd re= ally like to hear you explain to the other customers when their mail is bei= ng rejected because the shared IP is on a blocklist. DMARC doesn't help you= r customers in this case. > > If bigbank.com cannot control it's managers/employees and how they > > send mail then that is an internal problem that bigbank needs to > > address. There are plenty of other mechanisms for bigbank to control wh= at > it emits (in the case of spam). >=20 > True enough. But it happens with regularity. At a large company, people > move on all the time. Groups change and people retire, change jobs, or > otherwise move on. The people in charge of maintaining all this IT stuff = do > not keep pace with the scope of change. This is especially true in a larg= e > organization (it is one of our own challenges). >=20 I'm not sympathetic. My company has multiple divisions, brands and operatin= g units around the globe, 10s of thousands of employees and yet we seem to = be able to manage it. Other large organizations manage it as well. What I'm= hearing is "we are out of control and want to modify DMARC to account for = this".=20 > But even beyond that, it's not the only legitimate case we have to deal w= ith. > We have companies like real estate companies (e.g., Remax -- if they were= a > customer) that have independent sales agents. The inbound mail is > agent@remax.com. The independent agent gets the mail forwarded to their > personal email account and then they send outbound mail through us > agent@yahoo.com. Remax does not own yahoo.com, but this is a legitimate > case where a user "spoofs" a legitimate domain that they do not own. >=20 Again, DMARC is not intended for organizations that do this. It's not a que= stion of "legitimate case of spoofing". It's a question of whether a domain= /brand owner wishes to prevent direct domain abuse using DMARC. The reason = that large (and small) mailbox providers - including your own - got on boar= d with DMARC and the private channel assertions that preceded it is because= it works. DMARC only works to the extent that mailbox providers are willin= g to buy into it. I'd also point out that domains with end users such as th= e example you use above are simply not good candidates for implementing DMA= RC policy. Ask John Levine to explain the mailing list issue with regard to= DMARC policy assertions. > Thus, shutting down this case is not going to work. The majority of the m= ail > from "legitimately spoofed" senders is non-spam. But the cases of spoofin= g a > domain maliciously is what I want to target. >=20 And this is only relevant to the extent that this legitimate mail is origin= ating from domains subject to direct domain abuse and which do not have unc= ontrolled end users sending mail. > > Perhaps MS should offer bigbank dedicated IPs - ESPs do this all the ti= me > for their customers. > > It may not be so critical for other customers. Sounds like a business > opportunity to me. >=20 > This would solve one problem but introduces other: >=20 > a) We have plenty of small businesses that sign up for our service. They = may > all want their own IPs. Microsoft has plenty of IPs but we don't have an = near- > infinite amount (the ones Microsoft has, we share them with the rest of t= he > company; they don't all belong to our division). >=20 Not all businesses (with domains) are candidates for having their own IPs o= r implementing DMARC. This includes most small businesses. > b) Even if we did give customers their own IPs, they each would get at le= ast > two IPs - one in two different data centers for redundancy. This reduces = the > available pool of IPs. >=20 There is this very new standard called IPv6. I hear this provides a couple = of extra IPs to the mix. Someone on this list even brought up NIST working = on requirements for IPv6 only mail sending hosts. I would argue that the ca= se you are putting forward is an unwillingness to address internal implemen= tation/business structure issues. > c) The networking challenge of maintaining IPs-to-customers mapping is > painful. Running a service with as much redundancy, failover, cross- > datacenter routing as ours is difficult and maintaining all these network > mappings adds too much complexity. We can barely keep track of our own > IPs. >=20 A lot of ESPs do this on some scale with much more limited resources. Other= large providers are dealing with the issue. > Thus, the cost/benefit tradeoff of giving everyone (or even some customer= s) > their own IP skews heavier towards the costs compared the benefits. >=20 The other option is to propose to externalize those costs to everyone else. Mike From tzink@exchange.microsoft.com Mon Apr 1 18:51:55 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80711E80A6 for ; Mon, 1 Apr 2013 18:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbDFpk28BckH for ; Mon, 1 Apr 2013 18:51:54 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2F96A11E80A5 for ; Mon, 1 Apr 2013 18:51:53 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.670.5; Tue, 2 Apr 2013 01:51:52 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) with mapi id 15.00.0670.000; Tue, 2 Apr 2013 01:51:51 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: Ac4vHeGtF3P4hm3YSDmZ3O/llvHH6gABhBGAAAI3JIAAAylrUAABtOqAAACFoTA= Date: Tue, 2 Apr 2013 01:51:51 +0000 Message-ID: <3cc1dd69471d4f059fff49ecd3c6f45d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <515A02DB.2010309@gmail.com> <9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.221] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 01:51:55 -0000 Hi, Mike, thanks for your response. > I'd really like to hear you explain to the other customers when their mai= l is being=20 > rejected because the shared IP is on a blocklist. DMARC doesn't help your= customers=20 > in this case. I'm not sure where this comment comes from, protecting and monitoring our o= utbound IP reputation is something I have spent many years working on but is orthogona= l to this=20 discussion (you don't need one for the other, although they help).=20 Please let me know if you believe otherwise. > Not all businesses (with domains) are candidates for having their own IPs= or implementing=20 > DMARC. This includes most small businesses. I disagree. I think that small businesses are great candidates for DMARC. A= s an industry we should help them move there. > There is this very new standard called IPv6. I hear this provides a coupl= e of extra IPs=20 > to the mix. Someone on this list even brought up NIST working on requirem= ents for IPv6=20 > only mail sending hosts. I would argue that the case you are putting forw= ard is an=20 > unwillingness to address internal implementation/business structure issue= s. IPv6 adoption is still in its infancy. Are you really proposing that simply= giving each sender its own IPv6 address is the solution, when there are ma= ny email receivers who don't receive any mail over IPv6 (e.g., Hotmail)? I agree that there are things that can be done in parallel. But at the same= time, some of these implementations do not have critical mass.=20 >> c) The networking challenge of maintaining IPs-to-customers mapping is=20 >> painful. Running a service with as much redundancy, failover, cross-=20 >> datacenter routing as ours is difficult and maintaining all these=20 >> network mappings adds too much complexity. We can barely keep track of=20 >> our own IPs. >> > A lot of ESPs do this on some scale with much more limited resources. Oth= er=20 > large providers are dealing with the issue. Without knowing the implementation details of various ESPs, I don't think i= t's useful to say Company A does this and therefore so should Company Y. Or= ganizations have varying needs and have their own reasons for pursuing the = things they do. >> Thus, the cost/benefit tradeoff of giving everyone (or even some=20 >> customers) their own IP skews heavier towards the costs compared the ben= efits. > > The other option is to propose to externalize those costs to everyone els= e. I understand your point. My goal in this discussion is to bring the problem= of shared IP space and how to authenticate. DMARC seems like a natural pla= ce to do it since it is still a new protocol. -- Terry -----Original Message----- From: MH Michael Hammer (5304) [mailto:MHammer@ag.com]=20 Sent: Monday, April 01, 2013 6:21 PM To: Terry Zink; dmarc@ietf.org Subject: RE: [dmarc-ietf] Proposing an extension to DMARC to optionally req= uire SPF and DKIM > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf=20 > Of Terry Zink > Sent: Monday, April 01, 2013 8:46 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to=20 > optionally require SPF and DKIM >=20 > Hi, Mike. >=20 > > This is a bad idea. While it solves your internal problem it=20 > > potentially increases false positives for bigbank.com externally,=20 > > thus trading one problem for another >=20 > I agree that there is the potential for false positives. But shouldn't=20 > this choice be given to the sender? If they understand the risks then=20 > they should be able to say "Yes, this can cause false positives. But=20 > we can get those under control (or delegate sub-domains for third=20 > parties, or some other workaround like using DMARC to collect feedback=20 > on where the unsigned mail originates). The bottom line is we don't=20 > want anyone spoofing our domain." >=20 Then don't let people "spoof" your domain. You have another problem with sh= ared IPs that hasn't been brought into the discussion. By sharing IPs you a= re sharing reputation across customers. If one of those customers starts sp= ewing abusive mail then the other customers suffer as a consequence. I'd re= ally like to hear you explain to the other customers when their mail is bei= ng rejected because the shared IP is on a blocklist. DMARC doesn't help you= r customers in this case. > > If bigbank.com cannot control it's managers/employees and how they=20 > > send mail then that is an internal problem that bigbank needs to=20 > > address. There are plenty of other mechanisms for bigbank to control=20 > > what > it emits (in the case of spam). >=20 > True enough. But it happens with regularity. At a large company,=20 > people move on all the time. Groups change and people retire, change=20 > jobs, or otherwise move on. The people in charge of maintaining all=20 > this IT stuff do not keep pace with the scope of change. This is=20 > especially true in a large organization (it is one of our own challenges)= . >=20 I'm not sympathetic. My company has multiple divisions, brands and operatin= g units around the globe, 10s of thousands of employees and yet we seem to = be able to manage it. Other large organizations manage it as well. What I'm= hearing is "we are out of control and want to modify DMARC to account for = this".=20 > But even beyond that, it's not the only legitimate case we have to deal w= ith. > We have companies like real estate companies (e.g., Remax -- if they=20 > were a > customer) that have independent sales agents. The inbound mail is=20 > agent@remax.com. The independent agent gets the mail forwarded to=20 > their personal email account and then they send outbound mail through=20 > us agent@yahoo.com. Remax does not own yahoo.com, but this is a=20 > legitimate case where a user "spoofs" a legitimate domain that they do no= t own. >=20 Again, DMARC is not intended for organizations that do this. It's not a que= stion of "legitimate case of spoofing". It's a question of whether a domain= /brand owner wishes to prevent direct domain abuse using DMARC. The reason = that large (and small) mailbox providers - including your own - got on boar= d with DMARC and the private channel assertions that preceded it is because= it works. DMARC only works to the extent that mailbox providers are willin= g to buy into it. I'd also point out that domains with end users such as th= e example you use above are simply not good candidates for implementing DMA= RC policy. Ask John Levine to explain the mailing list issue with regard to= DMARC policy assertions. > Thus, shutting down this case is not going to work. The majority of=20 > the mail from "legitimately spoofed" senders is non-spam. But the=20 > cases of spoofing a domain maliciously is what I want to target. >=20 And this is only relevant to the extent that this legitimate mail is origin= ating from domains subject to direct domain abuse and which do not have unc= ontrolled end users sending mail. > > Perhaps MS should offer bigbank dedicated IPs - ESPs do this all the=20 > > time > for their customers. > > It may not be so critical for other customers. Sounds like a=20 > > business > opportunity to me. >=20 > This would solve one problem but introduces other: >=20 > a) We have plenty of small businesses that sign up for our service.=20 > They may all want their own IPs. Microsoft has plenty of IPs but we=20 > don't have an near- infinite amount (the ones Microsoft has, we share=20 > them with the rest of the company; they don't all belong to our division)= . >=20 Not all businesses (with domains) are candidates for having their own IPs o= r implementing DMARC. This includes most small businesses. > b) Even if we did give customers their own IPs, they each would get at=20 > least two IPs - one in two different data centers for redundancy. This=20 > reduces the available pool of IPs. >=20 There is this very new standard called IPv6. I hear this provides a couple = of extra IPs to the mix. Someone on this list even brought up NIST working = on requirements for IPv6 only mail sending hosts. I would argue that the ca= se you are putting forward is an unwillingness to address internal implemen= tation/business structure issues. > c) The networking challenge of maintaining IPs-to-customers mapping is=20 > painful. Running a service with as much redundancy, failover, cross-=20 > datacenter routing as ours is difficult and maintaining all these=20 > network mappings adds too much complexity. We can barely keep track of=20 > our own IPs. >=20 A lot of ESPs do this on some scale with much more limited resources. Other= large providers are dealing with the issue. > Thus, the cost/benefit tradeoff of giving everyone (or even some=20 > customers) their own IP skews heavier towards the costs compared the bene= fits. >=20 The other option is to propose to externalize those costs to everyone else. Mike From johnl@iecc.com Mon Apr 1 18:53:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA2B11E80CC for ; Mon, 1 Apr 2013 18:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_16=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1QOZAgqLUkn for ; Mon, 1 Apr 2013 18:53:43 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2641511E80A6 for ; Mon, 1 Apr 2013 18:53:43 -0700 (PDT) Received: (qmail 35164 invoked from network); 2 Apr 2013 01:53:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Apr 2013 01:53:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a3a26.xn--9vv.k1304; i=johnl@user.iecc.com; bh=yryyXlmU+JjOExoF7HDgXudynLgSBfCNx1a2rveyYPk=; b=gU5I80vwZv38dXUm+0nmsT3DNdcl3hDVwyw0eZWKeFeJspzFkKwfDB6JLHIwvZxByuzETH0m/nlLsCLrB2s4Bhhg90x4KrMf2f9JYtgH6bb40RpshTRpGWB22nBURjpY4+xPEqzWwtLDM5hDRQl11QfyFUtETlrLaXSYcuhC2lc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a3a26.xn--9vv.k1304; olt=johnl@user.iecc.com; bh=yryyXlmU+JjOExoF7HDgXudynLgSBfCNx1a2rveyYPk=; b=f54DmiCdfg7QDwd8GLeX2pwLMcDgOH6GKnh2mnol0PR+eoC8JEk5Vt7sYblKsnr7+9KzWtPO2WebK/U+2KhwGLCmDipcvFVw24RMkXXtzTfqTxWhY/bOHJTyJNbNaRtnN5zs6gG0Rr7TSKLO+AEUr+RT4a6/cjjIDi5YXIjvIRU= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Apr 2013 01:53:19 -0000 Message-ID: <20130402015319.6440.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 01:53:44 -0000 >> bigbank.com txt "v=spf1 +ip4:22.22.22.22 ?ip4:157.55.158.0/23 >> ?ip4:157.55.234.0/24 ?ip4:157.56.112.0/24 ~all" > >example.com ------------+ > | >BigBank.com ------------+----> Microsoft Forefront IPs ----> Internet > | >Learning.edu | > security@bigbank.com --+ > >Case 1 - Mail comes from 22.22.22.22 -> Forefront scans it Oh, no, I had in mind customers who send mail through Forefront, but also send some of their own mail directly from 22.22.22.22. If it all goes through Forefront, it all gets Forefront's ?ip SPF rules. >Case 2 - Mail comes from 1.2.3.4 (Learning.edu malicious spoof) -> Forefront scans it and it SPF fails -> Relays to Internet (e.g., >Hotmail) who scans it and it is Neutral > >But real mail from BigBank.com would have a DKIM header and so therefore it would DMARC pass at the Hotmail side. > >Is that right? Right. >But wouldn't it mean that a 3rd party who didn't validate DKIM or DMARC would always get SPF Neutral in the case of a legitimate message? Right. Since we know the same IP can emit both real and bogus messages and SPF can't tell the difference, what other result could you honestly provide? Is it really a good idea to return an SPF pass for a message that might be a phish? >> Or you can sign all your mail with DKIM, publish no SPF at all, and use DMARC p=reject. > >I've thought of that, too. I think that would be a good solution if DMARC compliance was more widespread than it is >From a security point of view, it's really the same as what you have now, since you can't count on the bounce address as an identifier nor SPF to tell you whether a message is authorized. >I've thought of that, too. But I heard ADSP was basically dead and superseded by DMARC. ADSP is kaput. No great loss. It seems to me that you have an opportunity here for some client behavior modification that can be applied incrementally. If you don't know what domains a client uses, you can't make any meaningful path authorization assertions. (I don't want to think about who gets the blame when you send those SPF approved phishes.) But when a client gives you their list of domains, you can then filter their mail to only allow those domains in their mailstream, and more important, filter all your other clients' mail to forbid them. Now you have your paths back under control, and you can publish SPF records for that client that provide pass results. That's a feature that adds customer value or whatever it's called these days. R's, John From johnl@iecc.com Mon Apr 1 18:57:10 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866FB21F8EC8 for ; Mon, 1 Apr 2013 18:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.885 X-Spam-Level: X-Spam-Status: No, score=-110.885 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+BBTn8uJTx1 for ; Mon, 1 Apr 2013 18:57:10 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A08A521F8EBE for ; Mon, 1 Apr 2013 18:57:09 -0700 (PDT) Received: (qmail 36228 invoked from network); 2 Apr 2013 01:57:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Apr 2013 01:57:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a3af5.xn--btvx9d.k1304; i=johnl@user.iecc.com; bh=v4LbGPuN0rzqV/vrYQC9k6tm2rG252xM3JOG//Ha+nI=; b=T2JcwzY9gcQtx4pRT/8jgtmunNaiD6wyuXOQUma1DS6kTdfH4IALBNApT1fzNbD1YJ38ooi/UoigMegmtA6IXasZpqlPzZAbSnx69On0XQ4UWdS0YJSi+taAHrti+UJ3E3idFMcp1ceRQC+Az9LkOSOZUkRKKIEsE8RS9gswVp8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a3af5.xn--btvx9d.k1304; olt=johnl@user.iecc.com; bh=v4LbGPuN0rzqV/vrYQC9k6tm2rG252xM3JOG//Ha+nI=; b=zfFlPHUFSgk6N75zIYeiNowCRBihtobBONL3oSmj9gFP8SuVf/HeODvxhXgkSd76ipYK+zG4/jKwgZg4/doQEl7BMTusa3vvMQIuep0UEBN82ldM6EoNp8QIzscOxVD8y50i5jXvm4MWaDyRQ5Ra/E/MSRrxREoz/SDKdtNpTIw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Apr 2013 01:56:46 -0000 Message-ID: <20130402015646.6502.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <07885B3D9573426085184C6B2CD2504C@fgsr.local> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: jgomez@seryrich.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 01:57:10 -0000 >The point remains: in what form or shape Terry's optional DMARC extension hinders DMARC's goals? As I've said several times already, it causes DMARC failures on valid mail, provoking complaints to the recipient mail system. Beyond that, as a general rule, the more complicated a spec is, the less likely it is to be implemented consistently and the less likely different implementations are to interoperate. As Russ Housely said as he finished his term as IETF chair last month, a standard is done not when there is nothing left to add, but when there is nothing left to take away. R's, John From jgomez@seryrich.com Mon Apr 1 19:14:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8318121E80B0 for ; Mon, 1 Apr 2013 19:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JH3emsEnfpg for ; Mon, 1 Apr 2013 19:14:59 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 97B3421E804A for ; Mon, 1 Apr 2013 19:14:58 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Apr 2013 04:14:56 +0200 Message-ID: From: "J. Gomez" To: References: <20130402015319.6440.qmail@joyce.lan> Date: Tue, 2 Apr 2013 04:16:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 02:14:59 -0000 On Tuesday, April 02, 2013 3:53 AM [GMT+1=3DCET], John Levine wrote: > Right. Since we know the same IP can emit both real and bogus > messages and SPF can't tell the difference, what other result could > you honestly provide? Is it really a good idea to return an SPF pass > for a message that might be a phish? Yes, it would be a good idea to return an SPF pass, if and only if a = standardized layer above SPF would require also a DKIM pass to build a = final result of PASS. Why? Because the probability of a trojanized AND spoofing client hosted = in the same sending IP address is close to zero, but not equal to zero. = To clear that marginal doubt, DKIM is needed. And to assert that policy = requirement to others unaware of the particularities of that = infraestructure, DMARC is need. So the idea is this: if DMARC is in a layer above SPF and DKIM, lets = plug in DMARC the holes anyone of those under it may have left open. Yes, things could have been born perfect at once, but here we are and = these issues we have. Why not patch them, if the solution is both within = reach and cheap? Regards, J. Gomez From jgomez@seryrich.com Mon Apr 1 19:21:29 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A26821E80E4 for ; Mon, 1 Apr 2013 19:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lK8DDdbgJBON for ; Mon, 1 Apr 2013 19:21:29 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id C15A821E80B0 for ; Mon, 1 Apr 2013 19:21:28 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Apr 2013 04:21:27 +0200 Message-ID: <42268ECB3A1E40458A319239C9E1F963@fgsr.local> From: "J. Gomez" To: References: <20130402015646.6502.qmail@joyce.lan> Date: Tue, 2 Apr 2013 04:22:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 02:21:29 -0000 On Tuesday, April 02, 2013 3:56 AM [GMT+1=3DCET], John Levine wrote: >> The point remains: in what form or shape Terry's optional DMARC >> extension hinders DMARC's goals?=20 >=20 > As I've said several times already, it causes DMARC failures on valid > mail, provoking complaints to the recipient mail system. Only if the sender has explicitly "opted in" into Terry's proposed = optional extension to DMARC. So there will be no innocent bystanders = hurt. Terry's idea, as I read it, is that his extension is non-default = behaviour to accomodate marginal cases. So you would have to explicitly = choose to shoot yourself in your feet to receive any potential pain. Regards, J. Gomez From MHammer@ag.com Mon Apr 1 19:22:34 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DA221E80E4 for ; Mon, 1 Apr 2013 19:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EOyi9Y4wDvb for ; Mon, 1 Apr 2013 19:22:33 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 79C5521E80B0 for ; Mon, 1 Apr 2013 19:22:33 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 1 Apr 2013 22:22:32 -0400 From: "MH Michael Hammer (5304)" To: Terry Zink , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: AQHOLyQDr9vuaJVnrUmomkiXMf3sBZjB9p9wgABk7gD//74yQIAAVFCA//+9roA= Date: Tue, 2 Apr 2013 02:22:31 +0000 Message-ID: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <515A02DB.2010309@gmail.com> <9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <3cc1dd69471d4f059fff49ecd3c6f45d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: <3cc1dd69471d4f059fff49ecd3c6f45d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 02:22:34 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Terry Zink > Sent: Monday, April 01, 2013 9:52 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally > require SPF and DKIM >=20 > Hi, Mike, thanks for your response. >=20 > > I'd really like to hear you explain to the other customers when their > > mail is being rejected because the shared IP is on a blocklist. DMARC > > doesn't help your customers in this case. >=20 > I'm not sure where this comment comes from, protecting and monitoring our > outbound IP reputation is something I have spent many years working on bu= t > is orthogonal to this discussion (you don't need one for the other, altho= ugh > they help). >=20 > Please let me know if you believe otherwise. The original case for a DMARC extension of requiring DKIM only was predicat= ed on one customer on shared IPs sending spam and another part of your orga= nization (Hotmail) having difficulties because DMARC will pass on either SP= F or DKIM. The issue of a sender on shared IPs emitting spam is certainly r= elevant to this discussion. Either spam is being emitted or it is not. Neut= ering (fixing) DMARC doesn't solve the wider problem of spam being emitted = even if it solves the internal DMARC issue for Forefront/Hotmail. >=20 >=20 > > Not all businesses (with domains) are candidates for having their own > > IPs or implementing DMARC. This includes most small businesses. >=20 > I disagree. I think that small businesses are great candidates for DMARC.= As > an industry we should help them move there. >=20 >=20 > > There is this very new standard called IPv6. I hear this provides a > > couple of extra IPs to the mix. Someone on this list even brought up > > NIST working on requirements for IPv6 only mail sending hosts. I would > > argue that the case you are putting forward is an unwillingness to addr= ess > internal implementation/business structure issues. >=20 > IPv6 adoption is still in its infancy. Are you really proposing that simp= ly giving > each sender its own IPv6 address is the solution, when there are many ema= il > receivers who don't receive any mail over IPv6 (e.g., Hotmail)? >=20 You can provide an IPv6 to IPv4 gateway..... You'll break SPF but if you do= it right you won't break DKIM. Implementing aligned DKIM and SPF in 2007 w= as a significant effort for us, yet we did it. > I agree that there are things that can be done in parallel. But at the sa= me > time, some of these implementations do not have critical mass. >=20 >=20 > >> c) The networking challenge of maintaining IPs-to-customers mapping > >> is painful. Running a service with as much redundancy, failover, > >> cross- datacenter routing as ours is difficult and maintaining all > >> these network mappings adds too much complexity. We can barely keep > >> track of our own IPs. > >> >=20 > > A lot of ESPs do this on some scale with much more limited resources. > > Other large providers are dealing with the issue. >=20 > Without knowing the implementation details of various ESPs, I don't think= it's > useful to say Company A does this and therefore so should Company Y. > Organizations have varying needs and have their own reasons for pursuing > the things they do. >=20 And organizations choose to implement standards or they choose not to. You = pointed to the difficulty level and I pointed out that others are managing = these things. I like to tell a joke about this space. Q: How many Psychiatr= ists does it take to change a light bulb? Answer: One, but the bulb has to= want to change. What I'm hearing is that in this case the bulb doesn't wan= t to change (for whatever reason). >=20 > >> Thus, the cost/benefit tradeoff of giving everyone (or even some > >> customers) their own IP skews heavier towards the costs compared the > benefits. > > > > The other option is to propose to externalize those costs to everyone e= lse. >=20 > I understand your point. My goal in this discussion is to bring the probl= em of > shared IP space and how to authenticate. DMARC seems like a natural place > to do it since it is still a new protocol. >=20 > -- Terry >=20 DMARC is not particularly new. The private implementations date back to the= 2007 timeframe. The goal of creating a public standard based on the succes= ses seen in the private channel implementations was intended to open it up = from a private club with limited membership to something that anyone could = implement. Trying to overload other design parameters to attempt to solve s= omething that DMARC intentionally did not try to solve is a dangerous path = to go down. There are lots of problems DMARC doesn't address. For example, DMARC doesn'= t address cousin domains, the display (friendly ) name issue or the use of = other character sets to present a look alike domain name. Shared IP space i= s shared IP space. Sharing IP space across organizations reduces the granul= arity and utility of SPF. If you don't want to use SPF then sign with DKIM.= You can still use DMARC if you are only using DKIM and not SPF. I use shar= ed IPs across domains but I DKIM sign those domains and each of the domains= has similar security implementations. So from my perspective it is possibl= e to do.... I've been doing it for years. Mike From jgomez@seryrich.com Mon Apr 1 19:43:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EE021E804A for ; Mon, 1 Apr 2013 19:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLfuOTyWwBlV for ; Mon, 1 Apr 2013 19:43:12 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 431A121E8108 for ; Mon, 1 Apr 2013 19:43:11 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 2 Apr 2013 04:43:09 +0200 Message-ID: From: "J. Gomez" To: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com><515A02DB.2010309@gmail.com><9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com><3cc1dd69471d4f059fff49ecd3c6f45d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Tue, 2 Apr 2013 04:44:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 02:43:14 -0000 On Tuesday, April 02, 2013 4:22 AM [GMT+1=3DCET], MH Michael Hammer = (5304) wrote: > DMARC is not particularly new. The private implementations date back > to the 2007 timeframe. The goal of creating a public standard based > on the successes seen in the private channel implementations was > intended to open it up from a private club with limited membership to > something that anyone could implement. So, you want the public to aknowledge a private practice as a public = standard, and at the same time you don't want input from the public but = blind adhesion, because, you know, it has been working fine in our = private club? > Trying to overload other > design parameters to attempt to solve something that DMARC > intentionally did not try to solve is a dangerous path to go down. =20 Terry's proposed extension is: 1. Optional, 2. Non-default, and 3. Not more relaxed but more strict. Where is the danger? You don't have the need?, well then go with the = more relaxed default. > I use shared IPs across domains > but I DKIM sign those domains and each of the domains has similar > security implementations. So from my perspective it is possible to > do.... I've been doing it for years. So what? Good for you. The world is wide. One size does not fit all, = yada yada... Again, is the proposed optional extension damaging to DMARC's goals? Are = DMARC's goals those of a private club, or those of the non-spoofing = email community at large? Regards, J. Gomez From sklist@kitterman.com Mon Apr 1 20:34:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1575721E8163 for ; Mon, 1 Apr 2013 20:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps3yP4lmKXsg for ; Mon, 1 Apr 2013 20:34:51 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F3FAB21E8156 for ; Mon, 1 Apr 2013 20:34:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3654720E40D5; Mon, 1 Apr 2013 23:34:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364873690; bh=Xshbovo9eqjqjGvyyOWBbGzKsGTFlRiLgCHpmC8zdTk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=N1xgMgMGneLwTT0ZuSPaqvZFk1FnzhzuadCJ17tO0cBAzvsced4f6zP34aV1BETke RF4pUQee0ejG7fvDagR+dK9Xr0bJL8a9VVoTl288JPhuTkLUM42MHTJw4bt20vYppP 89MIg5a9th86BaNypoHTjTM+VS82bqf1/K6FVoc4= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 1A3EA20E4090; Mon, 1 Apr 2013 23:34:49 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 01 Apr 2013 23:34:49 -0400 Message-ID: <3148207.XmBmmHESji@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 03:34:52 -0000 On Tuesday, April 02, 2013 04:44:27 AM J. Gomez wrote: > On Tuesday, April 02, 2013 4:22 AM [GMT+1=CET], MH Michael Hammer (5304) wrote: > > DMARC is not particularly new. The private implementations date back > > to the 2007 timeframe. The goal of creating a public standard based > > on the successes seen in the private channel implementations was > > intended to open it up from a private club with limited membership to > > something that anyone could implement. > > So, you want the public to aknowledge a private practice as a public > standard, and at the same time you don't want input from the public but > blind adhesion, because, you know, it has been working fine in our private > club? It was private in 2007. It's been public for quite some time. There is, in fact, already an open source, high quality C library and milter that supports DMARC: http://www.trusteddomain.org/opendmarc.html I'm running it in production (and I was not part of that private club) and I know others are too. This may be new to you, but there's an experience base built around the current spec and some momentum towards deployment. Considering that many of the largest mail providers in the world are among the implementers, it's more than just a small private club. > > Trying to overload other > > design parameters to attempt to solve something that DMARC > > intentionally did not try to solve is a dangerous path to go down. > > Terry's proposed extension is: > > 1. Optional, > 2. Non-default, and > 3. Not more relaxed but more strict. > > Where is the danger? You don't have the need?, well then go with the more > relaxed default. > > I use shared IPs across domains > > but I DKIM sign those domains and each of the domains has similar > > security implementations. So from my perspective it is possible to > > do.... I've been doing it for years. > > So what? Good for you. The world is wide. One size does not fit all, yada > yada... > > Again, is the proposed optional extension damaging to DMARC's goals? Are > DMARC's goals those of a private club, or those of the non-spoofing email > community at large? First, consider that DMARC itself is optional. Now you have an optional add on that receivers have to consider. By complicating the deployment decision making process, more choices and options slow things down. That doesn't mean they are always to be avoided, but they have a cost. Second, consider what the deployed receiver base of this option to an option is likely to be? It's zero now. What sender would rely on it when no receiver processes it? The other way around too. Getting past this chicken/egg problem is hard. The DMARC folks have spent years working on it. Third, if an extension like the one you propose has value, it can be added later. There's no need for it to be included in the initial round of discussions/standardization of DMARC. As long as the DMARC record structure is extensible to support new policy types (I haven't checked and I don't remember) then this can be done later. If you want to get this to work, focus on making sure the base protocol is extensible to do what you want and then work on developing interest and momentem around code and deployment to support it. If you want to change things, that's how to get it done. It's WAY harder than writing emails to IETF lists. Scott K From sm@resistor.net Mon Apr 1 20:51:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A51E21E8127 for ; Mon, 1 Apr 2013 20:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glNklroEvjuJ for ; Mon, 1 Apr 2013 20:51:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E5821E8119 for ; Mon, 1 Apr 2013 20:51:19 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r323pA5s007481; Mon, 1 Apr 2013 20:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364874675; bh=t6rqJX1xvH/j22WSJ4/1ngwem8VkMjOjiOBlkfcdT7A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jacqMOfOuFa6A6xTQLgfF5iRaq/z5K8GQNbmaPeYGu7GGZizgGOrXBTgk271d2xI9 EwVRBfC32WxFQciTgnqGrSYtpnHWK9r4AX3qq94ktYnnliFfbx3mafffQTNyTDWV1E WZfRSzfpY2+VjCumEraD1AeKY505uSFy+8FSW4RQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364874675; i=@resistor.net; bh=t6rqJX1xvH/j22WSJ4/1ngwem8VkMjOjiOBlkfcdT7A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DQGVxUT0g7GdOp1MLZFXP0MCwuy3XpMQuf/VO+vewbkgzTsJ8vKFpAQsBPqO+p34l OzeFWxnO+6th3eVw/muYXdLruc5licf4x1tksbMMFeXrjZbR54pSFfQJ2WKa2Qz0kf ImlUKMq6S7bc94C/vC1WPAz/NWw+pWNvAUUXn7XY= Message-Id: <6.2.5.6.2.20130401203905.0be09580@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 01 Apr 2013 20:46:17 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC working group charter proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 03:51:20 -0000 Hi Murray, At 22:26 31-03-2013, Murray S. Kucherawy wrote: >A first draft of a charter can be found linked from >http://wiki.tools.ietf.org/wg/appsawg/trac/wiki. I am picking on a specific point in the charter: "SPF (RFC4408) and DKIM (RFC6376) provide basic domain name authentication methods for email." There is an IETF working group working on an update to RFC 4408. Was that taken into consideration for the proposed charter? Regards, -sm From johnl@iecc.com Mon Apr 1 21:01:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0A821E8190 for ; Mon, 1 Apr 2013 21:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.916 X-Spam-Level: X-Spam-Status: No, score=-110.916 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBM+WvKRsyc7 for ; Mon, 1 Apr 2013 21:01:19 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D7EC221E8119 for ; Mon, 1 Apr 2013 21:01:18 -0700 (PDT) Received: (qmail 68821 invoked from network); 2 Apr 2013 04:01:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Apr 2013 04:01:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a5804.xn--i8sz2z.k1304; i=johnl@user.iecc.com; bh=C8Tn4Wy0PCGgQUekvnsPI5KVHD23W9+ihXXtzq+RdMI=; b=hlEd4GB5bvyDHysNGzqqJcqnYng+JKjJkSOuKbkbGZK5nZDeNPS5Jp/6a8HYcxHfIY5WTkvl0fVuG03UAyjleZ/VCbXwLpvuThzIuuHgKrLlIs2jzU8NXwiFp2vaHAUq6FV4GPAxAMPLITCzS/z2INXGJUgCr39hNA+KG4k2vU0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515a5804.xn--i8sz2z.k1304; olt=johnl@user.iecc.com; bh=C8Tn4Wy0PCGgQUekvnsPI5KVHD23W9+ihXXtzq+RdMI=; b=02VBqIYBA8CjB0Edat3ISbH49YZ05sf84rPNJ4yEsSWVYDrrCvdSdA0H/35KLt+BcGCEzowvVGMe8QUYS+nUmE+V2zmrZVg6EWeIH1R8nGN5UtW0ti/0WXr96LonApw1TZU06wOE2BRCEQ1La5EkOWL2n8VfEBH2jcdFxJX6WAA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 2 Apr 2013 04:00:46 -0000 Message-ID: <20130402040046.37252.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <6.2.5.6.2.20130401203905.0be09580@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sm@resistor.net Subject: Re: [dmarc-ietf] DMARC working group charter proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 04:01:19 -0000 > "SPF (RFC4408) and DKIM (RFC6376) provide basic domain name authentication > methods for email." I suppose it could mention spfbis, but at this point spfbis is close enough to done that I think we can say with high confidence that nothing it does will affect DMARC. From superuser@gmail.com Mon Apr 1 21:10:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23FE21E8193 for ; Mon, 1 Apr 2013 21:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTrsb11bMWb8 for ; Mon, 1 Apr 2013 21:10:39 -0700 (PDT) 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 F20BF21E8119 for ; Mon, 1 Apr 2013 21:10:38 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm11so2752740wib.5 for ; Mon, 01 Apr 2013 21:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=r1BPhM39JP7Ytxq89ChlVLxxeOf9qQu/alz79tLMjYQ=; b=UO9MxlJXF3jNEAOWSrSuOq+kuM9m7uBGb34vw0kJIqUt17tUzAR5pD41f1OYpylBzN rtLoOBf2Cu3h4zfmOsY8cUOmhCkJ2kjpjipVDduRzY+D3NOncb5ZPFUFUjOQ5RZzl0K0 CsgdG9aFrK4QWh9RBTMhOXPaMi4e7P8FtgRokybo8SQHVbEujmAqk74vfotwsujpFo/2 /0l9IvJRgGPstQpeln7roO0eXTRqiG6zaWC7SJsv2ahfwDQBVOFRb5xTh7xUaZr+OKEQ E+Vo91w1LkiMwNbZy18U+ijyNlWthDhqLi4gvx2AOYkFc4PzNriNpIwkB4UetSo3UGLs 5dUg== MIME-Version: 1.0 X-Received: by 10.180.94.39 with SMTP id cz7mr13169801wib.21.1364875838142; Mon, 01 Apr 2013 21:10:38 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Mon, 1 Apr 2013 21:10:38 -0700 (PDT) In-Reply-To: <20130402040046.37252.qmail@joyce.lan> References: <6.2.5.6.2.20130401203905.0be09580@resistor.net> <20130402040046.37252.qmail@joyce.lan> Date: Mon, 1 Apr 2013 21:10:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d04426de67ec0b904d958eb7e Cc: SM , dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC working group charter proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 04:10:39 -0000 --f46d04426de67ec0b904d958eb7e Content-Type: text/plain; charset=ISO-8859-1 That's basically what's expected, yes. At the time the charter was presented for public review, RFC4408 was the current specification for SPF. The documents this WG produces will certainly refer to the right thing when the time comes. -MSK On Mon, Apr 1, 2013 at 9:00 PM, John Levine wrote: > > "SPF (RFC4408) and DKIM (RFC6376) provide basic domain name > authentication > > methods for email." > > I suppose it could mention spfbis, but at this point spfbis is close > enough to done that I think we can say with high confidence that > nothing it does will affect DMARC. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f46d04426de67ec0b904d958eb7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That's basically what's expected, yes.=A0 At = the time the charter was presented for public review, RFC4408 was the curre= nt specification for SPF.=A0 The documents this WG produces will certainly = refer to the right thing when the time comes.

-MSK


On Mon, Apr 1, 2013 at 9:00 PM, John Levine &l= t;johnl@taugh.com&= gt; wrote:
> =A0 "SPF (RFC440= 8) and DKIM (RFC6376) provide basic domain name authentication
> =A0 =A0methods for email."

I suppose it could mention spfbis, but at this point spfbis is close<= br> enough to done that I think we can say with high confidence that
nothing it does will affect DMARC.

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

--f46d04426de67ec0b904d958eb7e-- From MHammer@ag.com Mon Apr 1 21:24:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863D821E81BF for ; Mon, 1 Apr 2013 21:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M0foSt7pG-u for ; Mon, 1 Apr 2013 21:24:15 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 91C1C21E81C9 for ; Mon, 1 Apr 2013 21:24:15 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Tue, 2 Apr 2013 00:24:14 -0400 From: "MH Michael Hammer (5304)" To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: AQHOL0v9UeR/7PM140unGGiG/fifB5jCSXow Date: Tue, 2 Apr 2013 04:24:14 +0000 Message-ID: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com><515A02DB.2010309@gmail.com><9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com><3cc1dd69471d4f059fff49ecd3c6f45d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 04:24:16 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of J. Gomez > Sent: Monday, April 01, 2013 10:44 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally > require SPF and DKIM >=20 > On Tuesday, April 02, 2013 4:22 AM [GMT+1=3DCET], MH Michael Hammer > (5304) wrote: > > DMARC is not particularly new. The private implementations date back > > to the 2007 timeframe. The goal of creating a public standard based on > > the successes seen in the private channel implementations was intended > > to open it up from a private club with limited membership to something > > that anyone could implement. >=20 > So, you want the public to aknowledge a private practice as a public stan= dard, > and at the same time you don't want input from the public but blind > adhesion, because, you know, it has been working fine in our private club= ? >=20 Not at all. What I'm saying is that DMARC is something that has been workin= g for some time - both in private channels AND as a public standard ( but n= ot an IETF standard). I'm not asking for blind adherence but that proposed = additions, extensions and changes should be looked at very carefully as to = whether they are generally useful or a corner case which are currently addr= essed in other ways. In this case I would argue that the proposed change is= intended to mitigate architectural and implementation choices that have lo= ng been known within the email authentication and reputation community to b= e problematical. Shared IPs =3D shared consequences for the entities shari= ng those IPs. If you don't want the shared consequences then don't publish = SPF and DKIM sign only. When it comes to entities emitting spam, the "we're= good people who oopsie, did a bad thing" is what I call the Jessica Rabbit= theory of responsibility - "I'm not bad, I'm just drawn that way."=20 > > Trying to overload other > > design parameters to attempt to solve something that DMARC > > intentionally did not try to solve is a dangerous path to go down. >=20 > Terry's proposed extension is: >=20 > 1. Optional, > 2. Non-default, and > 3. Not more relaxed but more strict. >=20 > Where is the danger? You don't have the need?, well then go with the more > relaxed default. >=20 For example, you are asking existing implementers (validators) to make chan= ges to their code base to accommodate this. The current mailbox coverage of= existing validators is 60%+. That is certainly a non-trivial amount of imp= lementation. You ignore the issue of whether validators feel the juice is w= orth the squeeze for this change. If you make this optional for validators = then senders (that implement this extension) will get inconsistent outcomes= across mailbox providers. One of the design parameters for DMARC was to mi= nimize this risk. Or are you arguing it should be optional for senders but = mandatory for validators? Getting mailbox providers to buy into DMARC and a= gree to things like reporting (for example) was non-trivial. Be careful of = the demands you put on them or you may find DMARC as dead as ADSP. If you want a DKIM pass only then the simple solution is to DKIM sign (DMAR= C aligned) and don't publish an SPF record. Done. You are DMARC compliant, = no architectural changes are required in the spec and all you have to do is= remove your SPF record(s). DMARC validators don't have to do a thing and y= our stated need is accommodated. > > I use shared IPs across domains > > but I DKIM sign those domains and each of the domains has similar > > security implementations. So from my perspective it is possible to > > do.... I've been doing it for years. >=20 > So what? Good for you. The world is wide. One size does not fit all, yada > yada... >=20 Is yada yada a technical term or simply your way of indicating you watch Se= infeld? There are lots of sizes of implementers that have addressed this is= sue. You obviously have no interest in existing working implementations (mu= ltiple alternatives have been offered by others as well as myself) in this = problem space so why would you expect people to give credence to something = which has no implementation track record? What I'm hearing is "Shiny new th= ing I want". These issues have been presented on at any number of venues in= cluding MAAWG, RSA, INTERACT, OTA and INTERACT to name a few. Shared IPs are choice. Open Relays are a choice. People make choices and those choices have tradeoffs. > Again, is the proposed optional extension damaging to DMARC's goals? Are > DMARC's goals those of a private club, or those of the non-spoofing email > community at large? >=20 I view it as damaging because it requires validators to work to accommodate= the change when the same (desired by you) outcome can be achieved without = requiring code changes. I view it s not fully baked because the individuals= supporting it have not presented data points based on real traffic as to a= ) the incremental cases and benefits vs additional overhead. For example, w= hat impact, if any, does this have on reporting? > Regards, >=20 > J. Gomez From dcrocker@gmail.com Mon Apr 1 21:33:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E1521F961C for ; Mon, 1 Apr 2013 21:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv63445E3JBF for ; Mon, 1 Apr 2013 21:33:37 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 11B0421F9619 for ; Mon, 1 Apr 2013 21:33:37 -0700 (PDT) Received: by mail-gh0-f172.google.com with SMTP id r19so4161ghr.3 for ; Mon, 01 Apr 2013 21:33:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6jnmfmpKeg7HIu5h6BVsv8VG750C1xEsrxj7NDim1js=; b=KLhW3P7WqUtUeaNb8sFHD+p+hwStxVEBquQIzPdCJ1jP5BUfo/B0UMem8uesIlOFyL gh2NSHsRfvxJS79nCm6qNOVNyvq8EZxJRxUMuISrMx3JZh/bpWiQgNwd8uzeipS6P4Fw xf7uX9BpXI/VubUJqfimtRcMLprC8AcXYDBmSzAg4Q/UC4zz870G2gGDbPQvLVrBRw73 Hb2R6tHf5BjLutpR5DfISBFwLypOKujR0gULR2Yc2VZ/PLbfOUWk95R7BjuM5qf4OPaT I8G/WaJSQZ/kh50YYH/ASAPaLT7Uep3kl8MdyonZI90r3ZxLpZKJ5kZWZ1qiVbQ7AE8+ xkOQ== X-Received: by 10.236.65.67 with SMTP id e43mr12707348yhd.125.1364877216616; Mon, 01 Apr 2013 21:33:36 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id x71sm61199yhg.17.2013.04.01.21.33.34 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Apr 2013 21:33:35 -0700 (PDT) Message-ID: <515A5F9D.7090108@gmail.com> Date: Mon, 01 Apr 2013 21:33:33 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: SM References: <6.2.5.6.2.20130401203905.0be09580@resistor.net> In-Reply-To: <6.2.5.6.2.20130401203905.0be09580@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] DMARC working group charter proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 04:33:38 -0000 On 4/1/2013 8:46 PM, SM wrote: > There is an IETF working group working on an update to RFC 4408. Was > that taken into consideration for the proposed charter? SM, What 'consideration' do you have in mind and how would it affect DMARC and its working group, one way or the other, besides merely changing the RFC number? d/ -- Dave Crocker bbiw.net From sm@resistor.net Mon Apr 1 21:59:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE4C21F981E for ; Mon, 1 Apr 2013 21:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oXB0iJ8Sh7O for ; Mon, 1 Apr 2013 21:59:21 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3835921F97CA for ; Mon, 1 Apr 2013 21:59:18 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r324x5rG016004; Mon, 1 Apr 2013 21:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364878751; bh=ihwWssDMALYoI8dfLSl9nEDT4wPYXJ74jKVabZC8lbk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZMXzL3NU9UF2oKc4C31XySQvtTzG6k3kBG7ahHDQhd5taxGQfGKRJZbswkn92Z2kp VMoHs/QHAUwBNMbWRGQ6idf5qlSyj8km/7k1iO/ALoAxC5y7QGhoCTFGs7mKCmEGZ4 bTZh3glXABvsK7y/7lhp3iozZ4xswHvWVcZTzEvA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364878751; i=@resistor.net; bh=ihwWssDMALYoI8dfLSl9nEDT4wPYXJ74jKVabZC8lbk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zikUeAjHv7s/QuFHKfEIIONgu47LjU1vo/R4hfQG6F0Wu/U+ggAYN3aPcpjEM7Svl ihi0Vc8SRKvekWdl+CQJ4UL2G3+xxGP7bKJazn39W5kqBet7uOeh4h2PQiYgTyOzYO RKzB1s/HKLw8DD2dU8tjdlHhrw4jSkSFHDmqz+js= Message-Id: <6.2.5.6.2.20130401215118.0c087e28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 01 Apr 2013 21:57:40 -0700 To: Dave Crocker From: SM In-Reply-To: <515A5F9D.7090108@gmail.com> References: <6.2.5.6.2.20130401203905.0be09580@resistor.net> <515A5F9D.7090108@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] DMARC working group charter proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 04:59:21 -0000 Hi Dave, At 21:33 01-04-2013, Dave Crocker wrote: >What 'consideration' do you have in mind and how would it affect >DMARC and its working group, one way or the other, besides merely >changing the RFC number? John Levine and Murray Kucherawy covered what I was thinking about when I mentioned "considerations". It is also about the proposed working group not having to go through a long discussion of whether to change the RFC number or not. Regards, -sm From superuser@gmail.com Mon Apr 1 22:50:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099D921F96EC for ; Mon, 1 Apr 2013 22:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG4i+6fMYBwB for ; Mon, 1 Apr 2013 22:50:13 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 87C6721F9434 for ; Mon, 1 Apr 2013 22:49:39 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id f12so45545wgh.34 for ; Mon, 01 Apr 2013 22:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xXkDCgdR2ah2TZfIxrB6NXT4kC/3DKv+dyKRE0W2KHo=; b=Mb4AjOJb6QDLY+xxX7CshgJkLcVhx3o8gRj8nvNd8kp4FhHGZHI1WEm9whYWuwRVc/ VOtfXCshZtdOhjniCcp5JDADEmAnAO5XogfUK2Fed73+aTJLrbCoYPEYxzF/Zf02t0BQ QNBDgb2YHRuvAtNcjgts89vY3rd90hPElfxZa5ugedWKUjhZ8HIf8GOVwiSCOJCSSm8p E+45bp8cRC0IkKF113p2VeURME2fwN7HXGBTIZkIHRBzu+MHzWkOQ6TK7w7DhB0zqziS ZhVl+2nNauNr97mt1VRoi8ruzHa1mhAq5GUKru7Dtog3M1Vf+//4DGFf+e7uv9Gi1g6d /PXg== MIME-Version: 1.0 X-Received: by 10.194.242.163 with SMTP id wr3mr19085710wjc.35.1364881778505; Mon, 01 Apr 2013 22:49:38 -0700 (PDT) Received: by 10.180.13.71 with HTTP; Mon, 1 Apr 2013 22:49:38 -0700 (PDT) In-Reply-To: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <515A02DB.2010309@gmail.com> <9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <3cc1dd69471d4f059fff49ecd3c6f45d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Mon, 1 Apr 2013 22:49:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=089e013d1da8917f6504d95a4d22 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 05:50:15 -0000 --089e013d1da8917f6504d95a4d22 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 1, 2013 at 7:44 PM, J. Gomez wrote: > So, you want the public to aknowledge a private practice as a public > standard, and at the same time you don't want input from the public but > blind adhesion, because, you know, it has been working fine in our private > club? > In contrast, you're expecting that any suggestion made in this more public venue automatically has to be accepted? But either way we're getting ahead of ourselves; there isn't even a working group yet. As has already been pointed out, DMARC hasn't been private for quite some time. The point here is indeed to subject the specification to even more open and rigorous review that it's already received. There's been a public (albeit external to the IETF) mailing list for a long while now. The fact that a proposed change doesn't receive favourable response doesn't mean it didn't get considered, does it? As for actual technical arguments, I find John's and Scott's points compelling. Neither DKIM nor SPF are useful defenses if you can't control the content they authorize or authenticate. In effect, in the attack scenario Terry provided, SPF is giving what the victim domain perceives as false positives. Sticking with that scenario, the solution appears to be to remove SPF from the equation by neutralizing its "pass" response when coming from those IP addresses. I keep coming back to a Venn Diagram showing SPF pass and DKIM pass plus their overlap, which is the DMARC pass space; if you don't want DMARC to pass for the case where SPF passed but DKIM failed, then DMARC pass is now logically equivalent to DKIM pass. To enact that, just turn off SPF and sign all your mail. On the flipside, if the victim domain's signing keys were compromised, one could generate spam signed as them from any IP address, rendering DKIM meaningless but SPF effective (probably). I don't find the argument that delegating DKIM is hard to be believable. If in Terry's application "require both" is an acceptable outcome, then his customer base was either prepared to delegate DKIM or do it themselves anyway. Where is the danger? You don't have the need?, well then go with the more > relaxed default. > I don't believe anyone's calling the proposal "dangerous", but the reasons for the resistance have already been laid out. > > > I use shared IPs across domains > > but I DKIM sign those domains and each of the domains has similar > > security implementations. So from my perspective it is possible to > > do.... I've been doing it for years. > > So what? Good for you. The world is wide. One size does not fit all, yada > yada... > That doesn't mean this is the right place for all solutions to all configurations, does it? > > Again, is the proposed optional extension damaging to DMARC's goals? Are > DMARC's goals those of a private club, or those of the non-spoofing email > community at large? > The latter, but don't conflate that goal with a requirement to be all-inclusive either. We couldn't alter DKIM to make it work seamlessly with all mailing list configurations, so we stopped trying. That doesn't mean DKIM had a private set of requirements; rather, it had realistic ones. -MSK --089e013d1da8917f6504d95a4d22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 1, 2013 at 7:44 PM, J. Gomez <jgomez@seryri= ch.com> wrote:
So, you want the public to aknowledge a priv= ate practice as a public standard, and at the same time you don't want = input from the public but blind adhesion, because, you know, it has been wo= rking fine in our private club?

In contrast, you're expecting that any= suggestion made in this more public venue automatically has to be accepted= ?=A0 But either way we're getting ahead of ourselves; there isn't e= ven a working group yet.

As has already been pointed out, DMARC hasn't been priva= te for quite some time.=A0 The point here is indeed to subject the specific= ation to even more open and rigorous review that it's already received.= =A0 There's been a public (albeit external to the IETF) mailing list fo= r a long while now.=A0 The fact that a proposed change doesn't receive = favourable response doesn't mean it didn't get considered, does it?=

As for actual technical arguments, I find John's and Scott= 9;s points compelling.=A0 Neither DKIM nor SPF are useful defenses if you c= an't control the content they authorize or authenticate.=A0 In effect, = in the attack scenario Terry provided, SPF is giving what the victim domain= perceives as false positives.=A0 Sticking with that scenario, the solution= appears to be to remove SPF from the equation by neutralizing its "pa= ss" response when coming from those IP addresses.=A0 I keep coming bac= k to a Venn Diagram showing SPF pass and DKIM pass plus their overlap, whic= h is the DMARC pass space; if you don't want DMARC to pass for the case= where SPF passed but DKIM failed, then DMARC pass is now logically equival= ent to DKIM pass.=A0 To enact that, just turn off SPF and sign all your mai= l.

On the flipside, if the victim domain's signing keys were compromis= ed, one could generate spam signed as them from any IP address, rendering D= KIM meaningless but SPF effective (probably).

I don't find the argument that delegating DKIM is h= ard to be believable.=A0 If in Terry's application "require both&q= uot; is an acceptable outcome, then his customer base was either prepared t= o delegate DKIM or do it themselves anyway.

Where is the danger? You don't have the need?, well then go with the mo= re relaxed default.

I don't believe= anyone's calling the proposal "dangerous", but the reasons f= or the resistance have already been laid out.
=A0

> I use shared IPs across domains
> but I DKIM sign those domains and each of the domains has similar
> security implementations. So from my perspective it is possible to
> do.... I've been doing it for years.

So what? Good for you. The world is wide. One size does not fit all, = yada yada...

That doesn't mean this= is the right place for all solutions to all configurations, does it?
=A0

Again, is the proposed optional extension damaging to DMARC's goals? Ar= e DMARC's goals those of a private club, or those of the non-spoofing e= mail community at large?

The latter, bu= t don't conflate that goal with a requirement to be all-inclusive eithe= r.=A0 We couldn't alter DKIM to make it work seamlessly with all mailin= g list configurations, so we stopped trying.=A0 That doesn't mean DKIM = had a private set of requirements; rather, it had realistic ones.

-MSK
--089e013d1da8917f6504d95a4d22-- From prvs=797119cd4=fmartin@linkedin.com Tue Apr 2 09:09:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9721F8C8C for ; Tue, 2 Apr 2013 09:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKYV3DPNz3cR for ; Tue, 2 Apr 2013 09:09:05 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6198121F8CA5 for ; Tue, 2 Apr 2013 09:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1364918945; x=1396454945; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=YOyX74oTZZ9tpGo/EtQtR8XnQ12k0C6HgwJ812rH8dI=; b=qTkKrIhXHUPzlpWTQWw1EAuEju/Sa1Ah6lfIZoZpbV1ciC1CtylSPY2Y +2EcCgE8b2MflTuqqN12aDEVl4neYe0dFtYVPq4oYnFI6RO9CFKoDiZNX Hmud/04iiwtBTZJjz8bGCrvh4EV7Pfk1b5rXM3y5VjRxjd5N0qPmf58Kb E=; X-IronPort-AV: E=Sophos;i="4.87,394,1363158000"; d="scan'208,217";a="43875164" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 2 Apr 2013 09:08:57 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Tue, 2 Apr 2013 09:08:57 -0700 From: Franck Martin To: "Murray S. Kucherawy" , John Levine Thread-Topic: [dmarc-ietf] DMARC working group charter proposal Thread-Index: AQHOL1Vb8TYTEaw2p0G2IQ+2NiRoZ5jCw/wAgAACwgCAAFNYAA== Date: Tue, 2 Apr 2013 16:08:56 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EA310D@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.254] Content-Type: multipart/alternative; boundary="_000_77426B543150464AA3F30DF1A91365DE52EA310DESV4MBX01linked_" MIME-Version: 1.0 Cc: SM , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC working group charter proposal X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 16:09:06 -0000 --_000_77426B543150464AA3F30DF1A91365DE52EA310DESV4MBX01linked_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2V2ZXJhbCBvZiB1cywgcGFydGljaXBhdGVkIGluIHRoZSBTUEZiaXMgd29ya2dyb3VwLCB3ZSBn b3QgY2xhcmlmaWNhdGlvbiBvbiBib3VuY2UgYW5kIFNQRiBhcyBubyBvbmUgd29ycmllcyBhYm91 dCBib3VuY2VzLi4uIDpQDQoNCkZyb206ICJNdXJyYXkgUy4gS3VjaGVyYXd5IiA8c3VwZXJ1c2Vy QGdtYWlsLmNvbTxtYWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNvbT4+DQpEYXRlOiBNb25kYXksIEFw cmlsIDEsIDIwMTMgOToxMCBQTQ0KVG86IEpvaG4gTGV2aW5lIDxqb2hubEB0YXVnaC5jb208bWFp bHRvOmpvaG5sQHRhdWdoLmNvbT4+DQpDYzogU00gPHNtQHJlc2lzdG9yLm5ldDxtYWlsdG86c21A cmVzaXN0b3IubmV0Pj4sICJkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0Zi5vcmc+IiA8 ZG1hcmNAaWV0Zi5vcmc8bWFpbHRvOmRtYXJjQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbZG1h cmMtaWV0Zl0gRE1BUkMgd29ya2luZyBncm91cCBjaGFydGVyIHByb3Bvc2FsDQoNClRoYXQncyBi YXNpY2FsbHkgd2hhdCdzIGV4cGVjdGVkLCB5ZXMuICBBdCB0aGUgdGltZSB0aGUgY2hhcnRlciB3 YXMgcHJlc2VudGVkIGZvciBwdWJsaWMgcmV2aWV3LCBSRkM0NDA4IHdhcyB0aGUgY3VycmVudCBz cGVjaWZpY2F0aW9uIGZvciBTUEYuICBUaGUgZG9jdW1lbnRzIHRoaXMgV0cgcHJvZHVjZXMgd2ls bCBjZXJ0YWlubHkgcmVmZXIgdG8gdGhlIHJpZ2h0IHRoaW5nIHdoZW4gdGhlIHRpbWUgY29tZXMu DQoNCi1NU0sNCg0KDQpPbiBNb24sIEFwciAxLCAyMDEzIGF0IDk6MDAgUE0sIEpvaG4gTGV2aW5l IDxqb2hubEB0YXVnaC5jb208bWFpbHRvOmpvaG5sQHRhdWdoLmNvbT4+IHdyb3RlOg0KPiAgICJT UEYgKFJGQzQ0MDgpIGFuZCBES0lNIChSRkM2Mzc2KSBwcm92aWRlIGJhc2ljIGRvbWFpbiBuYW1l IGF1dGhlbnRpY2F0aW9uDQo+ICAgIG1ldGhvZHMgZm9yIGVtYWlsLiINCg0KSSBzdXBwb3NlIGl0 IGNvdWxkIG1lbnRpb24gc3BmYmlzLCBidXQgYXQgdGhpcyBwb2ludCBzcGZiaXMgaXMgY2xvc2UN CmVub3VnaCB0byBkb25lIHRoYXQgSSB0aGluayB3ZSBjYW4gc2F5IHdpdGggaGlnaCBjb25maWRl bmNlIHRoYXQNCm5vdGhpbmcgaXQgZG9lcyB3aWxsIGFmZmVjdCBETUFSQy4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRtYXJjIG1haWxpbmcgbGlz dA0KZG1hcmNAaWV0Zi5vcmc8bWFpbHRvOmRtYXJjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYw0KDQo= --_000_77426B543150464AA3F30DF1A91365DE52EA310DESV4MBX01linked_ Content-Type: text/html; charset="utf-8" Content-ID: <5883660169A99A498338694D2DEA9383@linkedin.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+U2V2ZXJhbCBv ZiB1cywgcGFydGljaXBhdGVkIGluIHRoZSBTUEZiaXMgd29ya2dyb3VwLCB3ZSBnb3QgY2xhcmlm aWNhdGlvbiBvbiBib3VuY2UgYW5kIFNQRiBhcyBubyBvbmUgd29ycmllcyBhYm91dCBib3VuY2Vz Li4uIDpQPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0 OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u ZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5H LUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBz b2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90O011cnJheSBTLiBL dWNoZXJhd3kmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzdXBlcnVzZXJAZ21haWwuY29tIj5z dXBlcnVzZXJAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgQXByaWwgMSwgMjAxMyA5OjEwIFBNPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+Sm9obiBMZXZpbmUgJmx0Ozxh IGhyZWY9Im1haWx0bzpqb2hubEB0YXVnaC5jb20iPmpvaG5sQHRhdWdoLmNvbTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+U00gJmx0OzxhIGhy ZWY9Im1haWx0bzpzbUByZXNpc3Rvci5uZXQiPnNtQHJlc2lzdG9yLm5ldDwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5vcmciPmRtYXJjQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRtYXJjQGlldGYub3JnIj5kbWFyY0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5S ZTogW2RtYXJjLWlldGZdIERNQVJDIHdvcmtpbmcgZ3JvdXAgY2hhcnRlciBwcm9wb3NhbDxicj4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8ZGl2PlRoYXQncyBiYXNpY2FsbHkgd2hhdCdzIGV4cGVjdGVkLCB5ZXMuJm5ic3A7IEF0IHRo ZSB0aW1lIHRoZSBjaGFydGVyIHdhcyBwcmVzZW50ZWQgZm9yIHB1YmxpYyByZXZpZXcsIFJGQzQ0 MDggd2FzIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gZm9yIFNQRi4mbmJzcDsgVGhlIGRvY3Vt ZW50cyB0aGlzIFdHIHByb2R1Y2VzIHdpbGwgY2VydGFpbmx5IHJlZmVyIHRvIHRoZSByaWdodCB0 aGluZyB3aGVuIHRoZSB0aW1lIGNvbWVzLjxicj4NCjxicj4NCjwvZGl2Pg0KLU1TSzxicj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxicj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj5PbiBNb24sIEFwciAxLCAyMDEzIGF0IDk6MDAgUE0sIEpvaG4gTGV2aW5lIDxz cGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86am9obmxAdGF1Z2guY29tIiB0YXJn ZXQ9Il9ibGFuayI+am9obmxAdGF1Z2guY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2Jv cmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBjbGFzcz0i aW0iPiZndDsgJm5ic3A7ICZxdW90O1NQRiAoUkZDNDQwOCkgYW5kIERLSU0gKFJGQzYzNzYpIHBy b3ZpZGUgYmFzaWMgZG9tYWluIG5hbWUgYXV0aGVudGljYXRpb248YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDttZXRob2RzIGZvciBlbWFpbC4mcXVvdDs8YnI+DQo8YnI+DQo8L2Rpdj4NCkkgc3VwcG9z ZSBpdCBjb3VsZCBtZW50aW9uIHNwZmJpcywgYnV0IGF0IHRoaXMgcG9pbnQgc3BmYmlzIGlzIGNs b3NlPGJyPg0KZW5vdWdoIHRvIGRvbmUgdGhhdCBJIHRoaW5rIHdlIGNhbiBzYXkgd2l0aCBoaWdo IGNvbmZpZGVuY2UgdGhhdDxicj4NCm5vdGhpbmcgaXQgZG9lcyB3aWxsIGFmZmVjdCBETUFSQy48 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCmRtYXJjIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRm Lm9yZyI+ZG1hcmNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1hcmM8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_77426B543150464AA3F30DF1A91365DE52EA310DESV4MBX01linked_-- From tzink@exchange.microsoft.com Tue Apr 2 09:18:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA14B21F86E3 for ; Tue, 2 Apr 2013 09:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H902esnRCAcs for ; Tue, 2 Apr 2013 09:18:30 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.28]) by ietfa.amsl.com (Postfix) with ESMTP id EEEF521F86DE for ; Tue, 2 Apr 2013 09:18:29 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.670.5; Tue, 2 Apr 2013 16:18:28 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.123]) with mapi id 15.00.0670.000; Tue, 2 Apr 2013 16:18:28 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: AQHOL2X0wTz1NBkoXUCF8zORG9m6EJjDGmrQ Date: Tue, 2 Apr 2013 16:18:27 +0000 Message-ID: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <515A02DB.2010309@gmail.com> <9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <3cc1dd69471d4f059fff49ecd3c6f45d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.157.4] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 16:18:30 -0000 > The fact that a proposed change doesn't receive favourable response=20 > doesn't mean it didn't get considered, does it? While I don't really agree with the reasons for the unfavorable response, I= do acknowledge that this proposal has met with strong resistance. There's = probably a better way to solve this. For example, if an organization behind= a cloud-based service wants to prevent spoofing, it could say "The domain = example.com always DKIM signs its mail" and then any unsigned mail would be= rejected (or rerouted). This is a private ADSP. > If in Terry's application "require both" is an acceptable outcome,=20 > then his customer base was either prepared to delegate DKIM or do it=20 > themselves anyway. I did use myself and the company I work for as an example, but the scenario= extends to many cloud-based providers of email. A better forum may be a working-group session at MAAWG, or a set of Best-Pr= actices.=20 -- Terry From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of M= urray S. Kucherawy Sent: Monday, April 01, 2013 10:50 PM To: J. Gomez Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally req= uire SPF and DKIM On Mon, Apr 1, 2013 at 7:44 PM, J. Gomez wrote: So, you want the public to aknowledge a private practice as a public standa= rd, and at the same time you don't want input from the public but blind adh= esion, because, you know, it has been working fine in our private club? In contrast, you're expecting that any suggestion made in this more public = venue automatically has to be accepted?=A0 But either way we're getting ahe= ad of ourselves; there isn't even a working group yet. As has already been pointed out, DMARC hasn't been private for quite some t= ime.=A0 The point here is indeed to subject the specification to even more = open and rigorous review that it's already received.=A0 There's been a publ= ic (albeit external to the IETF) mailing list for a long while now.=A0 The = fact that a proposed change doesn't receive favourable response doesn't mea= n it didn't get considered, does it? As for actual technical arguments, I find John's and Scott's points compell= ing.=A0 Neither DKIM nor SPF are useful defenses if you can't control the c= ontent they authorize or authenticate.=A0 In effect, in the attack scenario= Terry provided, SPF is giving what the victim domain perceives as false po= sitives.=A0 Sticking with that scenario, the solution appears to be to remo= ve SPF from the equation by neutralizing its "pass" response when coming fr= om those IP addresses.=A0 I keep coming back to a Venn Diagram showing SPF = pass and DKIM pass plus their overlap, which is the DMARC pass space; if yo= u don't want DMARC to pass for the case where SPF passed but DKIM failed, t= hen DMARC pass is now logically equivalent to DKIM pass.=A0 To enact that, = just turn off SPF and sign all your mail. On the flipside, if the victim domain's signing keys were compromised, one = could generate spam signed as them from any IP address, rendering DKIM mean= ingless but SPF effective (probably). I don't find the argument that delegating DKIM is hard to be believable.=A0= If in Terry's application "require both" is an acceptable outcome, then hi= s customer base was either prepared to delegate DKIM or do it themselves an= yway. Where is the danger? You don't have the need?, well then go with the more r= elaxed default. I don't believe anyone's calling the proposal "dangerous", but the reasons = for the resistance have already been laid out. =A0 > I use shared IPs across domains > but I DKIM sign those domains and each of the domains has similar > security implementations. So from my perspective it is possible to > do.... I've been doing it for years. So what? Good for you. The world is wide. One size does not fit all, yada y= ada... That doesn't mean this is the right place for all solutions to all configur= ations, does it? =A0 Again, is the proposed optional extension damaging to DMARC's goals? Are DM= ARC's goals those of a private club, or those of the non-spoofing email com= munity at large? The latter, but don't conflate that goal with a requirement to be all-inclu= sive either.=A0 We couldn't alter DKIM to make it work seamlessly with all = mailing list configurations, so we stopped trying.=A0 That doesn't mean DKI= M had a private set of requirements; rather, it had realistic ones. -MSK From zwicky@yahoo-inc.com Tue Apr 2 10:54:26 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5101C21F8CD8 for ; Tue, 2 Apr 2013 10:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cacFgNCpxrEK for ; Tue, 2 Apr 2013 10:54:19 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id A197A21F8CC9 for ; Tue, 2 Apr 2013 10:54:17 -0700 (PDT) Received: from SP1-EX07CAS04.ds.corp.yahoo.com (sp1-ex07cas04.corp.sp1.yahoo.com [216.252.116.155]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r32HrjBZ053174 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 2 Apr 2013 10:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1364925227; bh=2CjtkS47F0wMwhdQqBy6ZvlIiwJJ+dvbD8Bd3K7I5Uk=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rtk32TEePjeT9/q974IxMeuOpWb/bSD1pDE/SiHbpqzcGou+YkEzO8MiREJ3/Fck9 NscA+09AVhF3xSwjPVxHjocThLWTK1NEaIXBiDae45UEvrmhqVkNRWXacxfBfjSe+5 T0r35HC3rMgjOzR5wnHuV7hsABSd3msxIB+j27/c= Received: from SP1-EX07VS01.ds.corp.yahoo.com ([216.252.116.136]) by SP1-EX07CAS04.ds.corp.yahoo.com ([216.252.116.158]) with mapi; Tue, 2 Apr 2013 10:53:45 -0700 From: Elizabeth Zwicky To: "J. Gomez" Date: Tue, 2 Apr 2013 10:53:44 -0700 Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM Thread-Index: Ac4vywTNn3Gu9GGiScm9jwnNORa1tw== Message-ID: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <80FFAE6594A84EB9BDC60EA75BC91597@fgsr.local> In-Reply-To: <80FFAE6594A84EB9BDC60EA75BC91597@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 925226007 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally requireSPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 17:54:26 -0000 On Apr 1, 2013, at 4:15 PM, J. Gomez wrote: > -- makes DMARC more resilient in case any of its underliying authenticati= ons mechanisms becomes compromised/broken/moot in the future. It's not clear to me that this is usefully true. Let us pretend that DKIM is broken -- you can forge a DKIM signature for an= ybody you like. Anybody who needed a DMARC 'both' option before is now out of luck -- DMARC= can always pass, so they are vulnerable to whatever problem they would hav= e been vulnerable to without it. Anybody who actually needed the current DMARC 'any' option is also out of l= uck, because they can't go to 'both'.=20 Only the tiny minority of people who can use 'both' but don't actually need= to remain protected, and the net result is that the standard is unusable. = There is some benefit, but it is not enough to be worth any significant cos= t, and adding a new option is a big implementation cost. Elizabeth= From zwicky@yahoo-inc.com Tue Apr 2 11:12:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D0D21F8D14 for ; Tue, 2 Apr 2013 11:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.598 X-Spam-Level: X-Spam-Status: No, score=-18.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpkjQIRbjyNg for ; Tue, 2 Apr 2013 11:12:47 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id 64CEA21F8D09 for ; Tue, 2 Apr 2013 11:12:47 -0700 (PDT) Received: from SP1-EX07CAS02.ds.corp.yahoo.com (sp1-ex07cas02.ds.corp.yahoo.com [216.252.116.138]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r32ICQKp005778 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Tue, 2 Apr 2013 11:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1364926347; bh=TX071Wl7S89bygm+RTtRcYf5dMmN1nVhclycvZnwgvU=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=isbAoTllWGczUbvJWeCXDERM6fGE6F/NdxZveij3JGOiZRRK2ZO4719mNd/wpeGlD avOms6qHaDz/whmw5fYaD9LNQkIS4/+Pqs7xbp13hNZ91Qr+2BGHv7BCpEXLRfK77Y 1AmfX6VX4vp1aFtV4Kg21I97599Ssi3J8B6wM6y4= Received: from SP1-EX07VS01.ds.corp.yahoo.com ([216.252.116.136]) by SP1-EX07CAS02.ds.corp.yahoo.com ([216.252.116.167]) with mapi; Tue, 2 Apr 2013 11:12:26 -0700 From: Elizabeth Zwicky To: "J. Gomez" Date: Tue, 2 Apr 2013 11:12:25 -0700 Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM Thread-Index: Ac4vzaDKZM/EssXmQ/6SYxGo3m/47A== Message-ID: <172A8DBA-4A64-42E7-87FD-BE185DC2977F@yahoo-inc.com> References: <77426B543150464AA3F30DF1A91365DE52EA0E87@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 926347003 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 02 Apr 2013 18:12:48 -0000 On Apr 1, 2013, at 5:53 PM, J. Gomez wrote: >=20 > Ok, DMARC has been devised by brand-companies (Facebook, Linkedin, Big-Ba= nk-X) and mailbox-providers (Hotmail, Yahoo, Gmail), I see that and I under= stand their needs to reliably exchange email policies. But there is more pe= ople in the email ecosystem, like for example cloud-services providers, who= also happen to do email. I note that Yahoo!, Google, and Microsoft are all, in fact, cloud-service p= roviders in some form. You can make the argument that Hotmail is not, it's= only other parts of Microsoft, but Gmail and Yahoo! Mail both are.=20 There are edge cases where a both option might be helpful -- I've talked to= an Amazon customer who said that he had a case where his client required S= PF to pass, which left him stuck configuring SPF so all of Amazon's cloud p= assed. This is a more compelling case than Terry's, since it can't be handl= ed just by SPF configuration. It still could be handled by enforcement with= in Amazon. The question is, "Which serves the community better, handling this within D= MARC or forcing cloud providers to handle it internally?" and that's not a = question where the answer is immediately clear. We know from private-channe= l experience that almost nobody uses this kind of option, and that people w= ho try to often discover belatedly that they don't consistently get a doubl= e-pass everywhere they care about and back off. So there is some reason to = believe that it is marginally useful and noticeably dangerous. If it's really cheap to implement, or it's more useful than previously beli= eved, because there's some large class of people who don't use private chan= nel but have a phishing problem, then maybe it's worth giving people more c= hances to get things wrong. But accidentally blocking mail is the main fail= ure mode of this kind of standard, so that's pretty intimidating. And not g= etting widespread, interoperable implementation is another big failure mode= , and anything that complicates implementation also risks that.=20 So there's a pretty high barrier to surmount in adding this kind of option.= =20 Elizabeth= From tim@eudaemon.net Tue Apr 2 23:04:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EEF21F8550 for ; Tue, 2 Apr 2013 23:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwB9RsR2xU9x for ; Tue, 2 Apr 2013 23:04:42 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id C88EF21F854E for ; Tue, 2 Apr 2013 23:04:42 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 27E6ECB46; Wed, 3 Apr 2013 02:05:19 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Draegen In-Reply-To: <3cc1dd69471d4f059fff49ecd3c6f45d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Wed, 3 Apr 2013 02:04:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55b1222360ab4215a09a54da800d261b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <515A02DB.2010309@gmail.com> <9b3745d8976d42df8fc9521e7f4c4b49@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <3cc1dd69471d4f059fff49ecd3c6f45d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> To: Terry Zink X-Mailer: Apple Mail (2.1503) Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 06:04:43 -0000 Hi Terry, I like your proposal, but see problems: - SPF and DKIM don't always work in production. By themselves, both SPF and DKIM sometimes fail to yield correct = results, even when they *should*. Be this because of transient DNS = errors, DKIM canonicalization errors (its a real thing, and "relaxed" = unintuitively breaks more), or bad luck, the error rate introduced by = requiring both SPF and DKIM to pass 100% of the time is just too high to = be useful. Keep in mind that this is not about Domain-A sending just to = Receiver-B; the problem space is every domain sending to every possible = receiver/stack/environment. - Requiring both DKIM and SPF to yield aligned domain identifiers = overshoots the goal. The Receiver side of the coin (the "receiving function" if = you'll allow me to talk about all and everything that processes incoming = email) needs a basic, reliable way to link a domain to a piece of = email.. when processing trillions of emails from across millions of = domains on top of thousands of software environments. Even if the = reality of imperfect implementations didn't matter (see #1), the = receiving function is hunting for an assertion of "this email really = does come from X domain". By requiring both DKIM and SPF to "pass", = you're asking the receiving function to consider an extra assertion of = "does this email really *really* come from X domain?". - Complexity is an adoption barrier. Because email is used everywhere by everyone all the time and = dwarfs everything else, trying to change it is really hard. The = installed base is "yes", everyone has their customized way to squeeze = it, Mars lost its water when it tried to upgrade its email. Any bell, = whistle, or tiny piece of extra functionality equates to a real-life = adoption barrier. If said bell, whistle, or tiny piece of extra = functionality *significantly* increases the ability to adopt DMARC = everywhere, then OK, let's all talk about it and do it. - DMARC cannot fix the shared IP problem. If a company: - is activity managing its security envelope, - determines that it needs DMARC, and - is using a service provider that allows any of its = clients to send email pretending to be any other client.. ..then the company needs to think in terms of risk management. = I won't break this down any further unless someone asks. - There is a work-around to address your proposal: What the company can do in this situation is: use a different = domain or a sub-domain for the traffic coming out of the service = provider, and require "strict" identifier alignment as needed. Problem = solved without changing DMARC. Lastly, I hope the above does not read like it contains any hostility. = The tone of email-related IETF lists are sometimes hard to modulate, so = I just want to be clear: I like your idea, but for the above reasons I = think it asks DMARC to do too much for too little (esp 'cause there's a = viable way to work-around your scenario). =3D- Tim From jgomez@seryrich.com Wed Apr 3 13:26:29 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D793821F8DEF for ; Wed, 3 Apr 2013 13:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_65=0.6, URIBL_GREY=0.25] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK99+RKK97o6 for ; Wed, 3 Apr 2013 13:26:29 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id D13F121F8D94 for ; Wed, 3 Apr 2013 13:26:28 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 3 Apr 2013 22:26:26 +0200 Message-ID: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> From: "J. Gomez" To: Date: Wed, 3 Apr 2013 22:27:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 20:26:30 -0000 Hello. I have this sample email which I got that would fail both SPF and DKIM = in the realm of DMARC, although it would pass both SPF and DKIM = "by-themselves". However as the RFC5322.From header is not aligned with = SPF nor DKIM, it would fail DMARC. This is legitimate marketing email from Symantec to which I am = subscribed, it's not spam. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Ds= ample email = begins=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Return-Path: = X-Original-To: username@example.com Delivered-To: username@example.com X-Greylist: delayed 903 seconds by postgrey-1.27 at mta.example.com; = Wed, 03 Apr 2013 16:24:22 CEST Received-SPF: pass (mail24.wdc01.mcdlv.net: 205.201.129.24 is = authorized to=20 use = 'bounce-mc.us1_1110737.1350597-username=3Dexample.com@mail24.wdc01.mcdlv.= net' in 'mfrom' identity=20 (mechanism 'ip4:205.201.129.24' matched)) receiver=3Dmta.example.com; = identity=3Dmfrom;=20 = envelope-from=3D"bounce-mc.us1_1110737.1350597-username=3Dexample.com@mai= l24.wdc01.mcdlv.net";=20 helo=3Dmail24.wdc01.mcdlv.net; client-ip=3D205.201.129.24 Received: from mail24.wdc01.mcdlv.net (mail24.wdc01.mcdlv.net = [205.201.129.24]) by mta.example.com (Postfix) with ESMTP id AB742DDC for ; Wed, 3 Apr 2013 16:24:22 +0200 (CEST) DKIM-Signature: v=3D1; a=3Drsa-sha1; c=3Drelaxed/relaxed; s=3Dk1; = d=3Dmail24.wdc01.mcdlv.net; = h=3DSubject:From:Reply-To:To:Date:Message-ID:List-Unsubscribe:Sender:Cont= ent-Type:MIME-Version; = i=3Dnoreply=3D3Dconnect.symantec.com@mail24.wdc01.mcdlv.net; bh=3D6IA6whsf6Mi46BRi22XWXWox/5E=3D; = b=3DNTAL+qICFA0yYELNcLO1prdSsCBvdnpAWsk1ldUZcowdg3hUO2bsmmq8Ozv2F1FRnN7lM= Bc+1jQ8 = +Tw8kcRt4/yD3mAsdXfQzvlgRIs55W1vJm7jn8SBhLcmK68PlAdB1jg6zWKMJVkv0M09rpC5l= 04x 7/wCUrnuL9EMVEb0P1k=3D DomainKey-Signature: a=3Drsa-sha1; c=3Dnofws; q=3Ddns; s=3Dk1; = d=3Dmail24.wdc01.mcdlv.net; = b=3Dl69UWJaIbsYh5rKEXj7xG9MYNKIyxh67fHRU5Rog9hGjqsc5jOI5sWyV/FA+U7e6XD6oT= pmJvLbc = pLVD1a0jbFybeN3Y98o8mkvntmQpQe0dpUb2ASXWkthAneLqFh/+GGh5UHa0lNi56heF+5zmU= T0P r7Ef+4hXZO4yBij7EQA=3D; Received: from (127.0.0.1) by mail24.wdc01.mcdlv.net (PowerMTA(TM) = v3.5r16) id hbgtpg0rhiou for ; Wed, 3 Apr 2013 = 14:09:15 +0000 (envelope-from = ) Subject: = =3D?utf-8?Q?News=3D20from=3D20the=3D20Symantec=3D20Connect=3D20Community?= =3D From: =3D?utf-8?Q?Symantec=3D20Connect?=3D = Reply-To: =3D?utf-8?Q?Symantec=3D20Connect?=3D = To: Date: Wed, 3 Apr 2013 14:09:15 +0000 Message-ID: = X-Mailer: MailChimp Mailer - **CID8bb792691bd8db17d31c** X-Campaign: mailchimpb7d514bd368b15a2ce69ce107.8bb792691b X-campaignid: mailchimpb7d514bd368b15a2ce69ce107.8bb792691b X-Report-Abuse: Please report abuse for this campaign here: = http://www.mailchimp.com/abuse/abuse.phtml?u=3Db7d514bd368b15a2ce69ce107&= id=3D8bb792691b&e=3Dd8db17d31c x-accounttype: pd List-Unsubscribe: = , = Sender: "Symantec Connect" = x-mcda: FALSE Content-Type: multipart/alternative; = boundary=3D"_----------=3D_MCPart_639961374" MIME-Version: 1.0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Ds= ample email = endns=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D I would like cases like this to be addressed in the BCP document for = DMARC, toghether with suggestions for alternative ways to send such an = email in a DMARC-compatible way. Regards, J. Gomez From prvs=798292818=fmartin@linkedin.com Wed Apr 3 13:45:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD6921F8EB4 for ; Wed, 3 Apr 2013 13:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGcm1GvxYe5i for ; Wed, 3 Apr 2013 13:45:29 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id B88AD21F8EA0 for ; Wed, 3 Apr 2013 13:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365021929; x=1396557929; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=UA45Kd41N/BwPlox13kp8o2jfT+ExCH0D8DB9pYzB2E=; b=l4yKIy2eUL1dJ3s77OHxlfQXUlfxXgw73xfIYmbqMengaE2Gk+nZAbtG U91W5bFcQynB/Suj/biYuKR4KGY5P0c96ptnBsKStYctKzi2WsP7tmcUz a8BWSGeIKP6ps9lChk2rIvgmf0gR39Yapwzh+mG5s92LDY4r8ydWWjytd o=; X-IronPort-AV: E=Sophos;i="4.87,403,1363158000"; d="scan'208";a="42935660" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Wed, 3 Apr 2013 13:45:23 -0700 From: Franck Martin To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] A case to be addressed in the BCP document for DMARC Thread-Index: AQHOMKmNT0czIjfchkaaO5cKf5PRM5jE9wCA Date: Wed, 3 Apr 2013 20:45:22 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> In-Reply-To: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.254] Content-Type: text/plain; charset="utf-8" Content-ID: <95086478F1EAFB4AB47F946B798FE4F7@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 20:45:30 -0000 WWVzLCBhbmQgSSBnb3QgdGhyb3VnaCB0aGUgc2FtZSBwcm9ibGVtcyB0byBnZXQgYWxsIG91ciB0 aGlyZCBwYXJ0aWVzIHRvDQphbGlnbiBpdCB3YXMgbm90IHRvbyBoYXJkIGJ1dCBpdCByZXF1aXJl ZCBzb21lIGZvY3VzLCBzb21lIGludm9sdmluZw0KZ2V0dGluZyB0aGVtIHRvIHN0YXJ0IHRvIERL SU0gc2lnbi4NCg0KVGhpcyBGQVEgaHR0cDovL3d3dy5kbWFyYy5vcmcvZmFxLmh0bWwjc18xNCBh bnN3ZXJzIGJyaWVmbHkgd2hhdCBoYXMgdG8gYmUNCmRvbmUgZm9yIGEgdGhpcmQgcGFydHkuIEkg ZG9uJ3Qga25vdyBvdGhlciBzb2x1dGlvbnMsIGJ1dCB0aGV5IGhhdmUgcHJvdmVuDQpzdWZmaWNp ZW50IGZvciBldmVyeW9uZSBJIGhhZCB0byB3b3JrIHdpdGguDQoNCkkgdGhpbmsgRE1BUkMgb2Zm ZXJzIGFuIG9wcG9ydHVuaXR5IHRvIGludmVudG9yeSBhbGwgdGhlIG1haWwgc3RyZWFtcyBhbg0K b3JnYW5pemF0aW9uIHVzZXMsIGFuZCB0byBnZXQgdGhlbSB0byBhIGNlcnRhaW4gY29ycG9yYXRl IGxldmVsIG9mDQpzdGFuZGFyZHMuIEl0IG1heSByZXF1aXJlcyB5b3UgdG8gd3JpdGUgbmV3IG9u IGJvYXJkaW5nIHJ1bGVzIGZvciB0aGlyZA0KcGFydGllcywgYW5kIGJlIGNhcGFibGUgdG8gc2F5 IHRvIGEgdmVuZG9yLCBhbmQgbW9yZSBpbXBvcnRhbnQgdG8geW91ciBvd24NCnBlb3BsZTogInNv cnJ5LCB5b3UgY2FuJ3QgY29tcGx5IHdpdGggb3VyIHNlY3VyaXR5IHJ1bGVzLCBzbyB3ZSBjYW4n dCBoYXZlDQp5b3UgYXMgYSB2ZW5kb3IgdW50aWwgeW91IGRvIi4gSSBndWVzcyBJIGhhdmUgYSBz bGlnaHQgYml0IG1vcmUgcG93ZXIgb24NCnZlbmRvcnMgdG8gb3BlbiB0aGlzIHJvYWQuLi4NCg0K U28gdGhpcyBzZWVtcyB0byBtZSBhIHByb2JsZW0gYXQgT1NJIGxheWVyIDkNCmh0dHA6Ly9lbi53 aWtpcGVkaWEub3JnL3dpa2kvTGF5ZXJfOA0KDQpJdCBpcyBpbXBvcnRhbnQgdG8gc2VlIHRoYXQg RE1BUkMgcmVsaWVzIGhlYXZpbHkgb24NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWt1Y2hlcmF3eS1kbWFyYy1iYXNlLTAwI3NlY3Rpb24tMy40IDEuDQoNCjEuICAgVGhlIFJGQzUz MjIuRnJvbSBkb21haW4gaXMgdGhlIGlkZW50aWZpZXIgdXNlZCBmb3IgYWxsIG1lc3NhZ2UNCiAg ICAgICAgdmFsaWRhdGlvbiBvcGVyYXRpb25zLCBhcyBpdCBpcyB0aGUgc2luZ2xlIGlkZW50aWZp ZXIgaW4gdGhlDQogICAgICAgIG1lc3NhZ2UgbGlrZWx5IHRvIGJlIHZpc2libGUgdG8gdGhlIHVz ZXIuDQoNCg0KSWYgdGhlcmUgaXMgbm8gYXV0aGVudGljYXRpb24gZ2x1ZSB0byBSRkM1MzIyLkZy b20gdGhlbiB5b3UgYWxsb3cgYW55b25lDQp0byBzZW5kIGZvciB5b3UuLi4NCg0KT24gNC8zLzEz IDE6MjcgUE0sICJKLiBHb21leiIgPGpnb21lekBzZXJ5cmljaC5jb20+IHdyb3RlOg0KDQo+SGVs bG8uDQo+DQo+SSBoYXZlIHRoaXMgc2FtcGxlIGVtYWlsIHdoaWNoIEkgZ290IHRoYXQgd291bGQg ZmFpbCBib3RoIFNQRiBhbmQgREtJTSBpbg0KPnRoZSByZWFsbSBvZiBETUFSQywgYWx0aG91Z2gg aXQgd291bGQgcGFzcyBib3RoIFNQRiBhbmQgREtJTQ0KPiJieS10aGVtc2VsdmVzIi4gSG93ZXZl ciBhcyB0aGUgUkZDNTMyMi5Gcm9tIGhlYWRlciBpcyBub3QgYWxpZ25lZCB3aXRoDQo+U1BGIG5v ciBES0lNLCBpdCB3b3VsZCBmYWlsIERNQVJDLg0KPg0KPlRoaXMgaXMgbGVnaXRpbWF0ZSBtYXJr ZXRpbmcgZW1haWwgZnJvbSBTeW1hbnRlYyB0byB3aGljaCBJIGFtDQo+c3Vic2NyaWJlZCwgaXQn cyBub3Qgc3BhbS4NCj4NCg0K From tzink@exchange.microsoft.com Wed Apr 3 14:11:34 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F25221F8F6F for ; Wed, 3 Apr 2013 14:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pyb3RUEIbDJ for ; Wed, 3 Apr 2013 14:11:33 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2083E21F8F56 for ; Wed, 3 Apr 2013 14:11:33 -0700 (PDT) Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) with Microsoft SMTP Server (TLS) id 15.0.670.5; Wed, 3 Apr 2013 21:11:29 +0000 Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.4.18]) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.4.18]) with mapi id 15.00.0670.000; Wed, 3 Apr 2013 21:11:29 +0000 From: Terry Zink To: Franck Martin , "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] A case to be addressed in the BCP document for DMARC Thread-Index: AQHOMKmJYXHKHa0HREWO6P9UMi3e2pjE9v4AgAAGi5A= Date: Wed, 3 Apr 2013 21:11:28 +0000 Message-ID: <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> References: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.157.4] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUSR01MB601; H:BLUSR01MB601.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 21:11:34 -0000 I don't think any of the options DMARC FAQ are satisfactory: > A.Integrate externally: The third party sender uses its own mail > servers to send your emails=20 > 1. Delegate a sub domain so they can put their own DKIM record and > SPF record in the DNS.=20 > 2. Give the third party a DKIM private key to sign the emails and=20 > publish the public key in your DNS and/or add their sending IP,=20 > maybe via a SPF include, to your SPF record.=20 This is probably the most realistic workaround. But it makes diagnosis diff= icult to see who is actually sending the messages. For example, suppose Big= Bank.com outsources its email to BigEmailers.com and the setup is as above,= and the message looks as below: SMTP Mail From: communications@email.BigBank.com 5322 From: communications.email.BigBank.com Neither of those lets the receiver know that the mail actually came from Bi= gEmailers.com. You also have to manage private keys both within your own or= ganization and with a 3rd party. Who knows how reliable they are? On the ot= her hand: SMTP Mail From: BigBank@BigEmailers.com 5322 From: communications.email.BigBank.com This makes it easier to see who is the originator of the email. But it also= fails DMARC. > B. Integrate internally: Get the third party sender to relay all your ema= ils via=20 > your mail server. Many large organizations would strongly push back at this, and rightly so. = It's a security risk to allow someone else to send mail through your own ha= rdware and network (unless that is your business model). > C. Do not integrate and tell them not to spoof This is not workable, either. As a consumer, I would be confused if mail fr= om BigBank@BigEmailers.com arrived in my inbox, claiming to be from BigBank= . I'd think it was a phish. BigBank wants the 5322 From to be BigBank.com. Thus, in my view, the sending-mail-on-behalf-of-another is problematic for = DMARC and each workaround has its own constraints which may not be satisfac= tory to many senders and brands. -- Terry -----Original Message----- From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of F= ranck Martin Sent: Wednesday, April 03, 2013 1:45 PM To: J. Gomez; dmarc@ietf.org Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DM= ARC Yes, and I got through the same problems to get all our third parties to al= ign it was not too hard but it required some focus, some involving getting = them to start to DKIM sign. This FAQ http://www.dmarc.org/faq.html#s_14 answers briefly what has to be = done for a third party. I don't know other solutions, but they have proven = sufficient for everyone I had to work with. I think DMARC offers an opportunity to inventory all the mail streams an or= ganization uses, and to get them to a certain corporate level of standards.= It may requires you to write new on boarding rules for third parties, and = be capable to say to a vendor, and more important to your own people: "sorry, you can't comply with our security rules, so we can't have = you as a vendor until you do". I guess I have a slight bit more power on ve= ndors to open this road... So this seems to me a problem at OSI layer 9 http://en.wikipedia.org/wiki/Layer_8 It is important to see that DMARC relies heavily on http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-3.4 1. 1. The RFC5322.From domain is the identifier used for all message validation operations, as it is the single identifier in the message likely to be visible to the user. If there is no authentication glue to RFC5322.From then you allow anyone to= send for you... On 4/3/13 1:27 PM, "J. Gomez" wrote: >Hello. > >I have this sample email which I got that would fail both SPF and DKIM=20 >in the realm of DMARC, although it would pass both SPF and DKIM=20 >"by-themselves". However as the RFC5322.From header is not aligned with=20 >SPF nor DKIM, it would fail DMARC. > >This is legitimate marketing email from Symantec to which I am=20 >subscribed, it's not spam. > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From tzink@exchange.microsoft.com Wed Apr 3 14:12:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3EC21F8FBE for ; Wed, 3 Apr 2013 14:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPAud9CNeyEm for ; Wed, 3 Apr 2013 14:12:51 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3F28821F8FB8 for ; Wed, 3 Apr 2013 14:12:51 -0700 (PDT) Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) by BLUSR01MB603.namsdf01.sdf.exchangelabs.com (10.255.124.168) with Microsoft SMTP Server (TLS) id 15.0.670.5; Wed, 3 Apr 2013 21:12:50 +0000 Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.4.18]) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.4.18]) with mapi id 15.00.0670.000; Wed, 3 Apr 2013 21:12:49 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] A case to be addressed in the BCP document for DMARC Thread-Index: AQHOMKmJYXHKHa0HREWO6P9UMi3e2pjE9v4AgAAGi5CAAAD04A== Date: Wed, 3 Apr 2013 21:12:48 +0000 Message-ID: References: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> In-Reply-To: <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.157.4] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUSR01MB603; H:BLUSR01MB601.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 21:12:52 -0000 To clarify my point, these workarounds work, but the tradeoffs may not be w= orth it. -- Terry -----Original Message----- From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of T= erry Zink Sent: Wednesday, April 03, 2013 2:11 PM To: Franck Martin; J. Gomez; dmarc@ietf.org Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DM= ARC I don't think any of the options DMARC FAQ are satisfactory: > A.Integrate externally: The third party sender uses its own mail=20 > servers to send your emails > 1. Delegate a sub domain so they can put their own DKIM record and > SPF record in the DNS.=20 > 2. Give the third party a DKIM private key to sign the emails and=20 > publish the public key in your DNS and/or add their sending IP,=20 > maybe via a SPF include, to your SPF record.=20 This is probably the most realistic workaround. But it makes diagnosis diff= icult to see who is actually sending the messages. For example, suppose Big= Bank.com outsources its email to BigEmailers.com and the setup is as above,= and the message looks as below: SMTP Mail From: communications@email.BigBank.com 5322 From: communications.email.BigBank.com Neither of those lets the receiver know that the mail actually came from Bi= gEmailers.com. You also have to manage private keys both within your own or= ganization and with a 3rd party. Who knows how reliable they are? On the ot= her hand: SMTP Mail From: BigBank@BigEmailers.com 5322 From: communications.email.BigBank.com This makes it easier to see who is the originator of the email. But it also= fails DMARC. > B. Integrate internally: Get the third party sender to relay all your=20 > emails via your mail server. Many large organizations would strongly push back at this, and rightly so. = It's a security risk to allow someone else to send mail through your own ha= rdware and network (unless that is your business model). > C. Do not integrate and tell them not to spoof This is not workable, either. As a consumer, I would be confused if mail fr= om BigBank@BigEmailers.com arrived in my inbox, claiming to be from BigBank= . I'd think it was a phish. BigBank wants the 5322 From to be BigBank.com. Thus, in my view, the sending-mail-on-behalf-of-another is problematic for = DMARC and each workaround has its own constraints which may not be satisfac= tory to many senders and brands. -- Terry -----Original Message----- From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of F= ranck Martin Sent: Wednesday, April 03, 2013 1:45 PM To: J. Gomez; dmarc@ietf.org Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DM= ARC Yes, and I got through the same problems to get all our third parties to al= ign it was not too hard but it required some focus, some involving getting = them to start to DKIM sign. This FAQ http://www.dmarc.org/faq.html#s_14 answers briefly what has to be = done for a third party. I don't know other solutions, but they have proven = sufficient for everyone I had to work with. I think DMARC offers an opportunity to inventory all the mail streams an or= ganization uses, and to get them to a certain corporate level of standards.= It may requires you to write new on boarding rules for third parties, and = be capable to say to a vendor, and more important to your own people: "sorry, you can't comply with our security rules, so we can't have = you as a vendor until you do". I guess I have a slight bit more power on ve= ndors to open this road... So this seems to me a problem at OSI layer 9 http://en.wikipedia.org/wiki/Layer_8 It is important to see that DMARC relies heavily on http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-3.4 1. 1. The RFC5322.From domain is the identifier used for all message validation operations, as it is the single identifier in the message likely to be visible to the user. If there is no authentication glue to RFC5322.From then you allow anyone to= send for you... On 4/3/13 1:27 PM, "J. Gomez" wrote: >Hello. > >I have this sample email which I got that would fail both SPF and DKIM=20 >in the realm of DMARC, although it would pass both SPF and DKIM=20 >"by-themselves". However as the RFC5322.From header is not aligned with=20 >SPF nor DKIM, it would fail DMARC. > >This is legitimate marketing email from Symantec to which I am=20 >subscribed, it's not spam. > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From R.E.Sonneveld@sonnection.nl Wed Apr 3 14:38:00 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A431221F9027 for ; Wed, 3 Apr 2013 14:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVOIvTqgzJU9 for ; Wed, 3 Apr 2013 14:38:00 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id D092F21F9025 for ; Wed, 3 Apr 2013 14:37:59 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 0E2E98C1306; Wed, 3 Apr 2013 23:37:54 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id DE7F58C0605; Wed, 3 Apr 2013 23:37:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 9C8A91230B3; Wed, 3 Apr 2013 23:37:53 +0200 (CEST) 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 1VQi45nH96nM; Wed, 3 Apr 2013 23:37:42 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 08290123039; Wed, 3 Apr 2013 23:37:42 +0200 (CEST) Message-ID: <515CA125.6020901@sonnection.nl> Date: Wed, 03 Apr 2013 23:37:41 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Terry Zink References: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> In-Reply-To: <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Franck Martin , "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 21:38:00 -0000 Hi, Terry, On 04/03/2013 11:11 PM, Terry Zink wrote: > I don't think any of the options DMARC FAQ are satisfactory: > >> A.Integrate externally: The third party sender uses its own mail >> servers to send your emails >> 1. Delegate a sub domain so they can put their own DKIM record and >> SPF record in the DNS. >> 2. Give the third party a DKIM private key to sign the emails and >> publish the public key in your DNS and/or add their sending IP, >> maybe via a SPF include, to your SPF record. > This is probably the most realistic workaround. But it makes diagnosis difficult to see who is actually sending the messages. For example, suppose BigBank.com outsources its email to BigEmailers.com and the setup is as above, and the message looks as below: > > SMTP Mail From: communications@email.BigBank.com > 5322 From: communications.email.BigBank.com > > Neither of those lets the receiver know that the mail actually came from BigEmailers.com. Well, that depends on what you define as 'came from'. The d= payload of a DKIM signature refers to the owner of the domain that is 'claiming some responsibility for the message by signing it', see paragraph 2.5 of http://tools.ietf.org/html/rfc6376. Furthermore, there is the difference between the Sender of a message and the Author of it. In your example BigEmailers.com might be the sender, but BigBank can still take the responsibility for submitting the message to the e-mail ecosystem (sending it via the mailers of BigEmailers.com). > You also have to manage private keys both within your own organization and with a 3rd party. Who knows how reliable they are? Many organizations have delegated their DNS administration to their provider or another 3rd party, which means the trust model of DKIM and SPF has its own weaknesses as well. That doesn't mean DKIM and SPF cannot be used. Likewise, we cannot say DMARC cannot be used in this scenario, but it is important to keep in mind these weaknesses, make a risk analysis and decide whether to use these technologies (or not) and whether to delegate DNS and/or signing to 3rd parties (or not). /rolf From tzink@exchange.microsoft.com Wed Apr 3 14:41:17 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41ECF21F9023 for ; Wed, 3 Apr 2013 14:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.732 X-Spam-Level: X-Spam-Status: No, score=-102.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWg4AkZl3Ae6 for ; Wed, 3 Apr 2013 14:41:16 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF7721F9003 for ; Wed, 3 Apr 2013 14:41:16 -0700 (PDT) Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) by BLUSR01MB602.namsdf01.sdf.exchangelabs.com (10.255.124.167) with Microsoft SMTP Server (TLS) id 15.0.670.5; Wed, 3 Apr 2013 21:41:14 +0000 Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.4.18]) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.4.18]) with mapi id 15.00.0670.000; Wed, 3 Apr 2013 21:41:13 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] A case to be addressed in the BCP document for DMARC Thread-Index: AQHOMKmJYXHKHa0HREWO6P9UMi3e2pjE9v4AgAAGi5CAAAgTgIAAAGGA Date: Wed, 3 Apr 2013 21:41:13 +0000 Message-ID: <4338c2e81acd4978a682467244a6d5bb@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> References: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> <515CA125.6020901@sonnection.nl> In-Reply-To: <515CA125.6020901@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.157.4] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUSR01MB602; H:BLUSR01MB601.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 21:41:17 -0000 > Furthermore, there is the difference between the Sender of a message and = the Author of=20 > it. In your example BigEmailers.com might be the sender, but BigBank can = still take the=20 > responsibility for submitting the message to the e-mail ecosystem (sendin= g it via the=20 > mailers of BigEmailers.com). True. > Likewise, we cannot say DMARC cannot be used in this scenario, but it is = important=20 > to keep in mind these weaknesses, make a risk analysis and decide whether= to use these=20 > technologies (or not) and whether to delegate DNS and/or signing to 3rd p= arties (or not). Correct, this is a better way to put it. -- Terry -----Original Message----- From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl]=20 Sent: Wednesday, April 03, 2013 2:38 PM To: Terry Zink Cc: Franck Martin; J. Gomez; dmarc@ietf.org Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DM= ARC Hi, Terry, On 04/03/2013 11:11 PM, Terry Zink wrote: > I don't think any of the options DMARC FAQ are satisfactory: > >> A.Integrate externally: The third party sender uses its own mail=20 >> servers to send your emails >> 1. Delegate a sub domain so they can put their own DKIM record and >> SPF record in the DNS. >> 2. Give the third party a DKIM private key to sign the emails and >> publish the public key in your DNS and/or add their sending IP, >> maybe via a SPF include, to your SPF record. > This is probably the most realistic workaround. But it makes diagnosis di= fficult to see who is actually sending the messages. For example, suppose B= igBank.com outsources its email to BigEmailers.com and the setup is as abov= e, and the message looks as below: > > SMTP Mail From: communications@email.BigBank.com > 5322 From: communications.email.BigBank.com > > Neither of those lets the receiver know that the mail actually came from = BigEmailers.com. Well, that depends on what you define as 'came from'. The d=3D payload of a= DKIM signature refers to the owner of the domain that is 'claiming some re= sponsibility for the message by signing it', see paragraph 2.5 of http://to= ols.ietf.org/html/rfc6376. Furthermore, there is the difference between the= Sender of a message and the Author of it. In your example BigEmailers.com = might be the sender, but BigBank can still take the responsibility for subm= itting the message to the e-mail ecosystem (sending it via the mailers of B= igEmailers.com). > You also have to manage private keys both within your own organization an= d with a 3rd party. Who knows how reliable they are? Many organizations have delegated their DNS administration to their provide= r or another 3rd party, which means the trust model of DKIM and SPF has its= own weaknesses as well. That doesn't mean DKIM and SPF cannot be used. Lik= ewise, we cannot say DMARC cannot be used in this scenario, but it is impor= tant to keep in mind these weaknesses, make a risk analysis and decide whet= her to use these technologies (or not) and whether to delegate DNS and/or s= igning to 3rd parties (or not). /rolf From prvs=798292818=fmartin@linkedin.com Wed Apr 3 14:47:50 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF7C21F9039 for ; Wed, 3 Apr 2013 14:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.655 X-Spam-Level: X-Spam-Status: No, score=-5.655 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, GB_ABOUTYOU=0.5, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-e5ix5EWMtK for ; Wed, 3 Apr 2013 14:47:49 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6F81521F9033 for ; Wed, 3 Apr 2013 14:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365025669; x=1396561669; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=3sfy7WSq9aXk0lUeKm0SvOFNGLiW4jjBXKK1FY/QY4s=; b=IPmQ8hazlwO79IONggJLpSj1+EhcaPMd+1CrL5yqiUnBaHSj9Di75FBQ c37JsY4pL63qasymGRdiK0xDyqmkM0aE/D33OFBuyE9GOlxWIq21/NAZX krvHfxlaH3rJ6UJIHrW7UBDaRdySUznyBrj/gcCBsn1OUlUuet4R1IyLU g=; X-IronPort-AV: E=Sophos;i="4.87,403,1363158000"; d="scan'208";a="44073692" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Wed, 3 Apr 2013 14:47:43 -0700 From: Franck Martin To: Terry Zink , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] A case to be addressed in the BCP document for DMARC Thread-Index: AQHOMKmNT0czIjfchkaaO5cKf5PRM5jE9wCAgAB8ogCAAABfAP//lGgA Date: Wed, 3 Apr 2013 21:47:43 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EB083C@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.254] Content-Type: text/plain; charset="utf-8" Content-ID: <3B4B8E19ACF25E4A8849B267B3539EF7@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 21:47:50 -0000 DQoNCk9uIDQvMy8xMyAyOjEyIFBNLCAiVGVycnkgWmluayIgPHR6aW5rQGV4Y2hhbmdlLm1pY3Jv c29mdC5jb20+IHdyb3RlOg0KDQo+VG8gY2xhcmlmeSBteSBwb2ludCwgdGhlc2Ugd29ya2Fyb3Vu ZHMgd29yaywgYnV0IHRoZSB0cmFkZW9mZnMgbWF5IG5vdCBiZQ0KPndvcnRoIGl0Lg0KPg0KPi0t IFRlcnJ5DQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBkbWFyYy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mDQo+VGVycnkgWmluaw0KPlNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDMsIDIwMTMgMjoxMSBQ TQ0KPlRvOiBGcmFuY2sgTWFydGluOyBKLiBHb21lejsgZG1hcmNAaWV0Zi5vcmcNCj5TdWJqZWN0 OiBSZTogW2RtYXJjLWlldGZdIEEgY2FzZSB0byBiZSBhZGRyZXNzZWQgaW4gdGhlIEJDUCBkb2N1 bWVudCBmb3INCj5ETUFSQw0KPg0KPkkgZG9uJ3QgdGhpbmsgYW55IG9mIHRoZSBvcHRpb25zIERN QVJDIEZBUSBhcmUgc2F0aXNmYWN0b3J5Og0KPg0KPj4gQS5JbnRlZ3JhdGUgZXh0ZXJuYWxseTog VGhlIHRoaXJkIHBhcnR5IHNlbmRlciB1c2VzIGl0cyBvd24gbWFpbA0KPj4gc2VydmVycyB0byBz ZW5kIHlvdXIgZW1haWxzDQo+PiAgIDEuIERlbGVnYXRlIGEgc3ViIGRvbWFpbiBzbyB0aGV5IGNh biBwdXQgdGhlaXIgb3duIERLSU0gcmVjb3JkIGFuZA0KPj4gICAgICBTUEYgcmVjb3JkIGluIHRo ZSBETlMuDQo+PiAgIDIuIEdpdmUgdGhlIHRoaXJkIHBhcnR5IGEgREtJTSBwcml2YXRlIGtleSB0 byBzaWduIHRoZSBlbWFpbHMgYW5kDQo+PiAgICAgIHB1Ymxpc2ggdGhlIHB1YmxpYyBrZXkgaW4g eW91ciBETlMgYW5kL29yIGFkZCB0aGVpciBzZW5kaW5nIElQLA0KPj4gICAgICBtYXliZSB2aWEg YSBTUEYgaW5jbHVkZSwgdG8geW91ciBTUEYgcmVjb3JkLg0KPg0KPlRoaXMgaXMgcHJvYmFibHkg dGhlIG1vc3QgcmVhbGlzdGljIHdvcmthcm91bmQuIEJ1dCBpdCBtYWtlcyBkaWFnbm9zaXMNCj5k aWZmaWN1bHQgdG8gc2VlIHdobyBpcyBhY3R1YWxseSBzZW5kaW5nIHRoZSBtZXNzYWdlcy4gRm9y IGV4YW1wbGUsDQo+c3VwcG9zZSBCaWdCYW5rLmNvbSBvdXRzb3VyY2VzIGl0cyBlbWFpbCB0byBC aWdFbWFpbGVycy5jb20gYW5kIHRoZSBzZXR1cA0KPmlzIGFzIGFib3ZlLCBhbmQgdGhlIG1lc3Nh Z2UgbG9va3MgYXMgYmVsb3c6DQo+DQo+U01UUCBNYWlsIEZyb206IGNvbW11bmljYXRpb25zQGVt YWlsLkJpZ0JhbmsuY29tDQo+NTMyMiBGcm9tOiBjb21tdW5pY2F0aW9ucy5lbWFpbC5CaWdCYW5r LmNvbQ0KDQpUaGUgc2VuZGluZyBJUCBhbmQgcmVjZWl2ZWQgaGVhZGVycyBhbmQgbWVzc2FnZSBp ZCwgd2lsbCB0ZWxsIHlvdSB3aG8gc2VudA0KdGhlIGVtYWlsLCBidXQgaXMgaXQgaW1wb3J0YW50 IChzZWUgbGF0ZXIpPw0KDQo+DQo+TmVpdGhlciBvZiB0aG9zZSBsZXRzIHRoZSByZWNlaXZlciBr bm93IHRoYXQgdGhlIG1haWwgYWN0dWFsbHkgY2FtZSBmcm9tDQo+QmlnRW1haWxlcnMuY29tLiBZ b3UgYWxzbyBoYXZlIHRvIG1hbmFnZSBwcml2YXRlIGtleXMgYm90aCB3aXRoaW4geW91cg0KPm93 biBvcmdhbml6YXRpb24gYW5kIHdpdGggYSAzcmQgcGFydHkuIFdobyBrbm93cyBob3cgcmVsaWFi bGUgdGhleSBhcmU/DQo+T24gdGhlIG90aGVyIGhhbmQ6DQo+DQo+U01UUCBNYWlsIEZyb206IEJp Z0JhbmtAQmlnRW1haWxlcnMuY29tDQo+NTMyMiBGcm9tOiBjb21tdW5pY2F0aW9ucy5lbWFpbC5C aWdCYW5rLmNvbQ0KPg0KPlRoaXMgbWFrZXMgaXQgZWFzaWVyIHRvIHNlZSB3aG8gaXMgdGhlIG9y aWdpbmF0b3Igb2YgdGhlIGVtYWlsLiBCdXQgaXQNCj5hbHNvIGZhaWxzIERNQVJDLg0KDQpCaWdC YW5rIGlzIHRoZSBvbmUgY29udHJhY3RpbmcgYmlnZW1haWxlcnMsIEkgZmluZCB0aGVtIHJlc3Bv bnNpYmxlIGZvcg0KdGhlIGVtYWlsIHRoZXkgc2VuZCByYXRoZXIgdGhhbiBiaWdlbWFpbGVycy4g V2hlbiB5b3UgbG9kZ2UgYSBjb21wbGFpbiB0bw0KYmlnZW1haWxlcnMgdGhlIHJlYWN0aW9uIHdp bGwgYmUgdG8gY29tcGxhaW4gdG8gYmlnYmFuay4gSWYgeW91IGNhbid0DQpjb250cm9sIGEgdmVu ZG9yLCBvciB1cGhlbGQgdGhlbSB0byB5b3VyIHN0YW5kYXJkcyBkb24ndCBjb250cmFjdCB0aGVt LiBTbw0KSSBwcmVmZXIgdG8gY29tcGxhaW4gdG8gYmlnIGJhbmsgZGlyZWN0bHkgYmVjYXVzZSB0 aGV5IGRvIGNhcmUgYWJvdXQgdGhlaXINCmVtYWlscy4NCg0KDQo+DQo+PiBCLiBJbnRlZ3JhdGUg aW50ZXJuYWxseTogR2V0IHRoZSB0aGlyZCBwYXJ0eSBzZW5kZXIgdG8gcmVsYXkgYWxsIHlvdXIN Cj4+IGVtYWlscyB2aWEgeW91ciBtYWlsIHNlcnZlci4NCj4NCj5NYW55IGxhcmdlIG9yZ2FuaXph dGlvbnMgd291bGQgc3Ryb25nbHkgcHVzaCBiYWNrIGF0IHRoaXMsIGFuZCByaWdodGx5DQo+c28u IEl0J3MgYSBzZWN1cml0eSByaXNrIHRvIGFsbG93IHNvbWVvbmUgZWxzZSB0byBzZW5kIG1haWwg dGhyb3VnaCB5b3VyDQo+b3duIGhhcmR3YXJlIGFuZCBuZXR3b3JrICh1bmxlc3MgdGhhdCBpcyB5 b3VyIGJ1c2luZXNzIG1vZGVsKS4NCj4NCg0KSXQgaXMgdGhlaXIgY2hvaWNlLCBidXQgYWxzbyBt YW55IGxhcmdlIG9yZ2FuaXphdGlvbnMgZG8gaXQgdG9vLiBBbmQgdGhpcw0KaXMgdGhlIGJ1c2lu ZXNzIG1vZGVsIG9mIHNlbmRncmlkIGFuZCBtZXNzYWdlYnVzLCBqdXN0IHRvIGNpdGUgYSBmZXcg dGhhdA0KY29tZXMgdG8gbWluZC4NCg0KPg0KPj4gQy4gRG8gbm90IGludGVncmF0ZSBhbmQgdGVs bCB0aGVtIG5vdCB0byBzcG9vZg0KPg0KPlRoaXMgaXMgbm90IHdvcmthYmxlLCBlaXRoZXIuIEFz IGEgY29uc3VtZXIsIEkgd291bGQgYmUgY29uZnVzZWQgaWYgbWFpbA0KPmZyb20gQmlnQmFua0BC aWdFbWFpbGVycy5jb20gYXJyaXZlZCBpbiBteSBpbmJveCwgY2xhaW1pbmcgdG8gYmUgZnJvbQ0K PkJpZ0JhbmsuIEknZCB0aGluayBpdCB3YXMgYSBwaGlzaC4gQmlnQmFuayB3YW50cyB0aGUgNTMy MiBGcm9tIHRvIGJlDQo+QmlnQmFuay5jb20uDQoNCkl0IGRlcGVuZHMgd2hhdCB5b3VyIHVzZSBj YXNlIGlzLCBpZiBpdCBpcyB0byBzZW5kIGEgc3VydmV5IGZyb20NCnN1cnZleW1vbmtleSwgSSBn dWVzcyB0aGlzIHdvdWxkIGJlIGZpbmUsIGFuZCB0aGV5IGNvdWxkIGhhdmUgYSBkbWFyYw0KcmVj b3JkIHdpdGggcD1yZWplY3QgdG9vLi4uDQoNCj4NCj4NCj5UaHVzLCBpbiBteSB2aWV3LCB0aGUg c2VuZGluZy1tYWlsLW9uLWJlaGFsZi1vZi1hbm90aGVyIGlzIHByb2JsZW1hdGljDQo+Zm9yIERN QVJDIGFuZCBlYWNoIHdvcmthcm91bmQgaGFzIGl0cyBvd24gY29uc3RyYWludHMgd2hpY2ggbWF5 IG5vdCBiZQ0KPnNhdGlzZmFjdG9yeSB0byBtYW55IHNlbmRlcnMgYW5kIGJyYW5kcy4NCj4NCg0K U3VyZSwgaXQgaXMgbm90IHRvIGJlIHRha2VuIGxpZ2h0bHksIGl0IGlzIGFib3V0IHlvdXIgcmVw dXRhdGlvbiBhbmQgeW91DQpkb24ndCB3YW50IHRvIGJlIGFzc29jaWF0ZWQgd2l0aCBhbnlvbmUg dGhhdCBjYW5ub3QgdXBoZWxkIHlvdXIgc3RhbmRhcmRzLg0KSSBkb24ndCBjb25zaWRlciBhbnkg YXMgYSB3b3JrYXJvdW5kLCBkZWZpbmUgeW91ciB1c2UgY2FzZXMsIGFzc2VzcyB5b3VyDQpzZWN1 cml0eSByaXNrcyBhbmQgbWFrZSB5b3VyIGNob2ljZXMgd2lzZWx5Lg0KDQo= From jgomez@seryrich.com Wed Apr 3 15:00:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A85621F907E for ; Wed, 3 Apr 2013 15:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[AWL=-1.600, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, NORMAL_HTTP_TO_IP=0.001, URIBL_GREY=0.25] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWxSqg70VgZp for ; Wed, 3 Apr 2013 15:00:06 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 1805521F9079 for ; Wed, 3 Apr 2013 15:00:06 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 4 Apr 2013 00:00:04 +0200 Message-ID: From: "J. Gomez" To: References: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> Date: Thu, 4 Apr 2013 00:01:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 22:00:07 -0000 On Wednesday, April 03, 2013 11:11 PM [GMT+1=3DCET], Terry Zink wrote: > I don't think any of the options DMARC FAQ are satisfactory: >=20 >> A.Integrate externally: The third party sender uses its own mail >> servers to send your emails >> 1. Delegate a sub domain so they can put their own DKIM record and >> SPF record in the DNS. >> 2. Give the third party a DKIM private key to sign the emails and >> publish the public key in your DNS and/or add their sending IP, >> maybe via a SPF include, to your SPF record. >=20 > This is probably the most realistic workaround. But it makes > diagnosis difficult to see who is actually sending the messages. For > example, suppose BigBank.com outsources its email to BigEmailers.com > and the setup is as above, and the message looks as below: =20 >=20 > SMTP Mail From: communications@email.BigBank.com > 5322 From: communications.email.BigBank.com >=20 > Neither of those lets the receiver know that the mail actually came > from BigEmailers.com. Well, I don't think in your example the receiver would mind that the = "material" sender, BigEmailers.com, was transparent to him, as the = receiver only knows and only cares for BigBank.com, who is the "branded" = sender that he is interested to hear about. So as long as what the = receiver sees in his MUA, "From: news@BigBank.com", is authentic, then = all is good. Option 2 above I regard and cumbersome, error prone, and ugly. However, option 1 above seems to me as the way to go, and in my opinion = the industry SHOULD standardize on it. I have received an email (to which I am subscribed, it's not spam) which = I think illustrates perfectly the use of option 1 above: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Demail with delegated subdomain = begins=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Return-Path: X-Original-To: username@example.com Delivered-To: username@example.com Received-SPF: pass (news.foromtb.com: Sender is authorized to use = 'boletin@news.foromtb.com' in 'mfrom' identity=20 (mechanism 'include:spf-a.emailvision.net' matched)) = receiver=3Dmta.example.com; identity=3Dmfrom;=20 envelope-from=3D"boletin@news.foromtb.com"; = helo=3Dlithium-thfi.ccemails.com; client-ip=3D81.92.114.35 Received: from lithium-thfi.ccemails.com (lithium-thfi.ccemails.com = [81.92.114.35]) by mta.example.com (Postfix) with ESMTP id 5EC10C6A for ; Tue, 2 Apr 2013 10:46:34 +0200 (CEST) DKIM-Signature: v=3D1; a=3Drsa-sha1; c=3Drelaxed/relaxed; s=3Demv; = d=3Dnews.foromtb.com; = h=3DDate:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:Li= st-Unsubscribe; i=3Dboletin@news.foromtb.com; bh=3DaGJl9CDQjnYr4CUovQNBDurhsmE=3D; = b=3DxRKeHeiQtBFOg5wmUfIbIJ0GvBQH5mgZNnXm5L6bhyulecHl9qH5n6jNP8YZ2hHiT0Uaf= dw5/VYD = cKh2xtMqX4kF8+jiXQItC0CEO9Mg5ljrcmMlRAQk3NMvxYQB8a046tXMs65onDR+BH0Di2hZW= X/f EqT5vJjImOnxiXM3j1A=3D Received: by lithium-thfi.ccemails.com id hbades167582 for = ; Tue, 2 Apr 2013 10:46:33 +0200 (envelope-from = ) Date: Tue, 2 Apr 2013 10:46:33 +0200 (CEST) From: Boletin ForoMTB Reply-To: Boletin ForoMTB To: Username in ForoMTB Message-ID: <2.1.2.1101041001.477108.7584587300@news.foromtb.com> Subject: = =3D?iso-8859-15?Q?Tres_a=3DF1os_pedaleando_juntos_con_Retto_tienen_premio= ?=3D MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=3D4771087584587300 X-EMV-Platform: p2ccc.campaigncommander.com$ X-EMV-CampagneId: 477108$ X-EMV-MemberId: 7584587300$ List-Unsubscribe: = , = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3Demail with delegated subdomain = ends=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here, the domain owner, "foromtb.com", is running naked regarding SPF, = etc: $ host -t txt _dmarc.foromtb.com. Host _dmarc.foromtb.com. not found: 3(NXDOMAIN) $ host -t txt foromtb.com. foromtb.com has no TXT record $ host -t mx foromtb.com. foromtb.com mail is handled by 0 mail.foromtb.com. foromtb.com mail is handled by 10 www.foromtb.com. However, they have outsourced their email marketing operations to = EMV2.com by means of giving them control of their subdomain = "news.foromtb.com", which EMV2 has clothed up handsomely in SPF, DKIM = and DMARC, together with proper reverse DNS, etc.: $ host -t txt news.foromtb.com. news.foromtb.com descriptive text "v=3Dspf1 = include:spf-a.emailvision.net include:spf-b.emailvision.net = include:spf-c.emailvision.net -all" news.foromtb.com descriptive text "spf2.0/pra = include:senderid-a.emailvision.net include:senderid-b.emailvision.net = include:senderid-c.emailvision.net -all" $ host -t txt _dmarc.news.foromtb.com. _dmarc.news.foromtb.com descriptive text "v=3DDMARC1\; p=3Dnone\; = rua=3Demv.dmarc.rua@emailvision.com\; rf=3Dafrf\; pct=3D100\;" $ host -t mx news.foromtb.com. =20 news.foromtb.com mail is handled by 10 smtp1.emv2.com. news.foromtb.com mail is handled by 20 smtp2.emv2.com. $ host 81.92.114.35 35.114.92.81.in-addr.arpa domain name pointer = lithium-thfi.ccemails.com. $ host lithium-thfi.ccemails.com lithium-thfi.ccemails.com has address 81.92.114.35 lithium-thfi.ccemails.com mail is handled by 10 smtp1.emv2.com. lithium-thfi.ccemails.com mail is handled by 20 smtp2.emv2.com. This approach in my opinion is clean and non convoluted, for (1) the = "branded" sender, (2) the "material" sender, and (3) the final = recipient. Note the perfect alignment of the RFC5322.From header with = both SPF and DKIM, and that only in the "Reply-To:" header is the domain = owner's main domain used. Plus, it passed (1) SPF by its own, (2) DKIM by its own, and (3) DMARC = itself. I could not dream of a more perfect execution than this! Regards, J. Gomez From johnl@iecc.com Wed Apr 3 15:12:58 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B35C21F90F4 for ; Wed, 3 Apr 2013 15:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.963 X-Spam-Level: X-Spam-Status: No, score=-110.963 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld8jfX1r8l9A for ; Wed, 3 Apr 2013 15:12:57 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5CC21F90E0 for ; Wed, 3 Apr 2013 15:12:57 -0700 (PDT) Received: (qmail 45004 invoked from network); 3 Apr 2013 22:12:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Apr 2013 22:12:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515ca968.xn--btvx9d.k1304; i=johnl@user.iecc.com; bh=TdxhdJofEM4o3QR8rqEO/1uz0G50HF3dgfSumYdz1b8=; b=OO1y94mWCt0KE7xLrkMkEed6tLo//HNe+HjIi3DmThzjrB6jn0vQLONtuwc5hMT/2Fe8LIK597GTRobHdS2+R7ZIHVLPAbdOh3WLFzDT5uZM/0PEo7lHdsN6daJ/pls75IOC8wVEFHvALVrb3sSCV9XTTTzK2SO3Q3BRqH71ooc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515ca968.xn--btvx9d.k1304; olt=johnl@user.iecc.com; bh=TdxhdJofEM4o3QR8rqEO/1uz0G50HF3dgfSumYdz1b8=; b=hRSTOBqVxHhNjPUW9Dn+ymcxRtzZv4X/okMt2rLbJbd7LG1z5r5ZiUHWlA4Z2MoBe/Nu2mb7NZwiBn4Z2Z5X4Y0HU1K/UKCzaU9kQeF5H1CT4tPy5zA9ukQR5kcRXEX9iItJ1LLQGQCkDMxrmhWhua4t8Is0lRC6NPAJj52Hp8U= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Apr 2013 22:12:34 -0000 Message-ID: <20130403221234.15518.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: jgomez@seryrich.com Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 22:12:58 -0000 >I have this sample email which I got that would fail both SPF and DKIM in the realm of DMARC, although it >would pass both SPF and DKIM "by-themselves". However as the RFC5322.From header is not aligned with SPF nor >DKIM, it would fail DMARC. > >This is legitimate marketing email from Symantec to which I am subscribed, it's not spam. It was sent on Symantec's behalf by Mailchimp, an ESP in the US. The return address is at one of Mailchimp's domains, presumably so they can more easily do the bounce handling and analytics. This is a very common setup at ESPs. I know people at Mailchimp, they're quite sophisticated, and I have no doubt that if Symantec told them they were worried about phishing and wanted to mail with a restricive DMARC policy, Mailchimp would adjust the mail stream to make it happen. Do you have reason to believe otherwise? I don't have deep insight into the motivations of the people who designed DMARC, but I am quite sure that allowing every mailer in the world to keep mailing with no change whatsoever to their existing cruddy practices was not on the list. You might want to review the list archives at dmarc.org where a lot of these issues have come up before. R's, John From prvs=798292818=fmartin@linkedin.com Wed Apr 3 15:22:10 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111E321F9049 for ; Wed, 3 Apr 2013 15:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.351 X-Spam-Level: X-Spam-Status: No, score=-4.351 tagged_above=-999 required=5 tests=[AWL=-1.631, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, IP_NOT_FRIENDLY=0.334, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, URIBL_GREY=0.25] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zcA0M5UGr7W for ; Wed, 3 Apr 2013 15:22:06 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 15EBF21F8FDB for ; Wed, 3 Apr 2013 15:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365027725; x=1396563725; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=fVfFyW9SU5HeNgZqnNunrB1rmwqXIhqbV/gxFAc9Dhk=; b=ks1kdmKaB56bI5ajjxoGk/ntSUkdRVJjIpnmM++F0I2IfBKaFSU+h1XF qqfjgkuFhGbebet300/Inhagw6f4RM//MvIyuBxeh9NRbM6bLNjmRiOtm 0YZ+chXSlkZ1xqpaTE9ZGC2yNvO0btGnrW9jraZMHG2el0sJ6bF8kf4tC M=; X-IronPort-AV: E=Sophos;i="4.87,403,1363158000"; d="scan'208";a="44077119" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 3 Apr 2013 15:21:59 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Wed, 3 Apr 2013 15:22:00 -0700 From: Franck Martin To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] A case to be addressed in the BCP document for DMARC Thread-Index: AQHOMLmoc62dyXOiB061anp+PHtFJw== Date: Wed, 3 Apr 2013 22:21:59 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EB094B@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 22:22:10 -0000 VG8gYmUgbm90ZWQ6DQpGcm9tOiBCb2xldGluIEZvcm9NVEIgPGJvbGV0aW5AZm9yb210Yi5jb20+ DQoNCndpdGggbm8gcmVwbHktdG86IHdvdWxkIGhhdmUgYmVlbiBmaW5lIHdpdGggRE1BUkMgaW4g cmVsYXhlZCBtb2RlICh3aGljaA0KaXMgdGhlIHJlY29yZCB0aGV5IHB1Ymxpc2hlZCkuDQoNCk9u IDQvMy8xMyAzOjAxIFBNLCAiSi4gR29tZXoiIDxqZ29tZXpAc2VyeXJpY2guY29tPiB3cm90ZToN Cg0KPk9uIFdlZG5lc2RheSwgQXByaWwgMDMsIDIwMTMgMTE6MTEgUE0gW0dNVCsxPUNFVF0sIFRl cnJ5IFppbmsgd3JvdGU6DQo+DQo+PiBJIGRvbid0IHRoaW5rIGFueSBvZiB0aGUgb3B0aW9ucyBE TUFSQyBGQVEgYXJlIHNhdGlzZmFjdG9yeToNCj4+IA0KPj4+IEEuSW50ZWdyYXRlIGV4dGVybmFs bHk6IFRoZSB0aGlyZCBwYXJ0eSBzZW5kZXIgdXNlcyBpdHMgb3duIG1haWwNCj4+PiBzZXJ2ZXJz IHRvIHNlbmQgeW91ciBlbWFpbHMNCj4+PiAgIDEuIERlbGVnYXRlIGEgc3ViIGRvbWFpbiBzbyB0 aGV5IGNhbiBwdXQgdGhlaXIgb3duIERLSU0gcmVjb3JkIGFuZA0KPj4+ICAgICAgU1BGIHJlY29y ZCBpbiB0aGUgRE5TLg0KPj4+ICAgMi4gR2l2ZSB0aGUgdGhpcmQgcGFydHkgYSBES0lNIHByaXZh dGUga2V5IHRvIHNpZ24gdGhlIGVtYWlscyBhbmQNCj4+PiAgICAgIHB1Ymxpc2ggdGhlIHB1Ymxp YyBrZXkgaW4geW91ciBETlMgYW5kL29yIGFkZCB0aGVpciBzZW5kaW5nIElQLA0KPj4+ICAgICAg bWF5YmUgdmlhIGEgU1BGIGluY2x1ZGUsIHRvIHlvdXIgU1BGIHJlY29yZC4NCj4+IA0KPj4gVGhp cyBpcyBwcm9iYWJseSB0aGUgbW9zdCByZWFsaXN0aWMgd29ya2Fyb3VuZC4gQnV0IGl0IG1ha2Vz DQo+PiBkaWFnbm9zaXMgZGlmZmljdWx0IHRvIHNlZSB3aG8gaXMgYWN0dWFsbHkgc2VuZGluZyB0 aGUgbWVzc2FnZXMuIEZvcg0KPj4gZXhhbXBsZSwgc3VwcG9zZSBCaWdCYW5rLmNvbSBvdXRzb3Vy Y2VzIGl0cyBlbWFpbCB0byBCaWdFbWFpbGVycy5jb20NCj4+IGFuZCB0aGUgc2V0dXAgaXMgYXMg YWJvdmUsIGFuZCB0aGUgbWVzc2FnZSBsb29rcyBhcyBiZWxvdzoNCj4+IA0KPj4gU01UUCBNYWls IEZyb206IGNvbW11bmljYXRpb25zQGVtYWlsLkJpZ0JhbmsuY29tDQo+PiA1MzIyIEZyb206IGNv bW11bmljYXRpb25zLmVtYWlsLkJpZ0JhbmsuY29tDQo+PiANCj4+IE5laXRoZXIgb2YgdGhvc2Ug bGV0cyB0aGUgcmVjZWl2ZXIga25vdyB0aGF0IHRoZSBtYWlsIGFjdHVhbGx5IGNhbWUNCj4+IGZy b20gQmlnRW1haWxlcnMuY29tLg0KPg0KPldlbGwsIEkgZG9uJ3QgdGhpbmsgaW4geW91ciBleGFt cGxlIHRoZSByZWNlaXZlciB3b3VsZCBtaW5kIHRoYXQgdGhlDQo+Im1hdGVyaWFsIiBzZW5kZXIs IEJpZ0VtYWlsZXJzLmNvbSwgd2FzIHRyYW5zcGFyZW50IHRvIGhpbSwgYXMgdGhlDQo+cmVjZWl2 ZXIgb25seSBrbm93cyBhbmQgb25seSBjYXJlcyBmb3IgQmlnQmFuay5jb20sIHdobyBpcyB0aGUg ImJyYW5kZWQiDQo+c2VuZGVyIHRoYXQgaGUgaXMgaW50ZXJlc3RlZCB0byBoZWFyIGFib3V0LiBT byBhcyBsb25nIGFzIHdoYXQgdGhlDQo+cmVjZWl2ZXIgc2VlcyBpbiBoaXMgTVVBLCAiRnJvbTog bmV3c0BCaWdCYW5rLmNvbSIsIGlzIGF1dGhlbnRpYywgdGhlbg0KPmFsbCBpcyBnb29kLg0KPg0K Pk9wdGlvbiAyIGFib3ZlIEkgcmVnYXJkIGFuZCBjdW1iZXJzb21lLCBlcnJvciBwcm9uZSwgYW5k IHVnbHkuDQo+DQo+SG93ZXZlciwgb3B0aW9uIDEgYWJvdmUgc2VlbXMgdG8gbWUgYXMgdGhlIHdh eSB0byBnbywgYW5kIGluIG15IG9waW5pb24NCj50aGUgaW5kdXN0cnkgU0hPVUxEIHN0YW5kYXJk aXplIG9uIGl0Lg0KPg0KPkkgaGF2ZSByZWNlaXZlZCBhbiBlbWFpbCAodG8gd2hpY2ggSSBhbSBz dWJzY3JpYmVkLCBpdCdzIG5vdCBzcGFtKSB3aGljaA0KPkkgdGhpbmsgaWxsdXN0cmF0ZXMgcGVy ZmVjdGx5IHRoZSB1c2Ugb2Ygb3B0aW9uIDEgYWJvdmU6DQo+DQo+DQo+PT09PT09PT09PT09PT09 PT09PT09PT09PT1lbWFpbCB3aXRoIGRlbGVnYXRlZCBzdWJkb21haW4NCj5iZWdpbnM9PT09PT09 PT09PT09PT0NCj4gUmV0dXJuLVBhdGg6IDxib2xldGluQG5ld3MuZm9yb210Yi5jb20+DQo+IFgt T3JpZ2luYWwtVG86IHVzZXJuYW1lQGV4YW1wbGUuY29tDQo+IERlbGl2ZXJlZC1UbzogdXNlcm5h bWVAZXhhbXBsZS5jb20NCj4gUmVjZWl2ZWQtU1BGOiBwYXNzIChuZXdzLmZvcm9tdGIuY29tOiBT ZW5kZXIgaXMgYXV0aG9yaXplZCB0byB1c2UNCj4nYm9sZXRpbkBuZXdzLmZvcm9tdGIuY29tJyBp biAnbWZyb20nIGlkZW50aXR5DQo+ICAobWVjaGFuaXNtICdpbmNsdWRlOnNwZi1hLmVtYWlsdmlz aW9uLm5ldCcgbWF0Y2hlZCkpDQo+cmVjZWl2ZXI9bXRhLmV4YW1wbGUuY29tOyBpZGVudGl0eT1t ZnJvbTsNCj4gIGVudmVsb3BlLWZyb209ImJvbGV0aW5AbmV3cy5mb3JvbXRiLmNvbSI7DQo+aGVs bz1saXRoaXVtLXRoZmkuY2NlbWFpbHMuY29tOyBjbGllbnQtaXA9ODEuOTIuMTE0LjM1DQo+IFJl Y2VpdmVkOiBmcm9tIGxpdGhpdW0tdGhmaS5jY2VtYWlscy5jb20gKGxpdGhpdW0tdGhmaS5jY2Vt YWlscy5jb20NCj5bODEuOTIuMTE0LjM1XSkNCj4gIGJ5IG10YS5leGFtcGxlLmNvbSAoUG9zdGZp eCkgd2l0aCBFU01UUCBpZCA1RUMxMEM2QQ0KPiAgZm9yIDx1c2VybmFtZUBleGFtcGxlLmNvbT47 IFR1ZSwgIDIgQXByIDIwMTMgMTA6NDY6MzQgKzAyMDAgKENFU1QpDQo+IERLSU0tU2lnbmF0dXJl OiB2PTE7IGE9cnNhLXNoYTE7IGM9cmVsYXhlZC9yZWxheGVkOyBzPWVtdjsNCj5kPW5ld3MuZm9y b210Yi5jb207DQo+ICANCj5oPURhdGU6RnJvbTpSZXBseS1UbzpUbzpNZXNzYWdlLUlEOlN1Ympl Y3Q6TUlNRS1WZXJzaW9uOkNvbnRlbnQtVHlwZTpMaXN0LQ0KPlVuc3Vic2NyaWJlOyBpPWJvbGV0 aW5AbmV3cy5mb3JvbXRiLmNvbTsNCj4gIGJoPWFHSmw5Q0RRam5ZcjRDVW92UU5CRHVyaHNtRT07 DQo+ICANCj5iPXhSS2VIZWlRdEJGT2c1d21VZkliSUowR3ZCUUg1bWdaTm5YbTVMNmJoeXVsZWNI bDlxSDVuNmpOUDhZWjJoSGlUMFVhZmR3NQ0KPi9WWUQNCj4gICAgDQo+Y0toMnh0TXFYNGtGOCtq aVhRSXRDMENFTzlNZzVsanJjbU1sUkFRazNOTXZ4WVFCOGEwNDZ0WE1zNjVvbkRSK0JIMERpMmha V1gNCj4vZg0KPiAgICBFcVQ1dkpqSW1PbnhpWE0zajFBPQ0KPiBSZWNlaXZlZDogYnkgbGl0aGl1 bS10aGZpLmNjZW1haWxzLmNvbSBpZCBoYmFkZXMxNjc1ODIgZm9yDQo+PHVzZXJuYW1lQGV4YW1w bGUuY29tPjsgVHVlLCAyIEFwciAyMDEzIDEwOjQ2OjMzICswMjAwIChlbnZlbG9wZS1mcm9tDQo+ PGJvbGV0aW5AbmV3cy5mb3JvbXRiLmNvbT4pDQo+IERhdGU6IFR1ZSwgMiBBcHIgMjAxMyAxMDo0 NjozMyArMDIwMCAoQ0VTVCkNCj4gRnJvbTogQm9sZXRpbiBGb3JvTVRCIDxib2xldGluQG5ld3Mu Zm9yb210Yi5jb20+DQo+IFJlcGx5LVRvOiBCb2xldGluIEZvcm9NVEIgPGJvbGV0aW5AZm9yb210 Yi5jb20+DQo+IFRvOiBVc2VybmFtZSBpbiBGb3JvTVRCIDx1c2VybmFtZUBleGFtcGxlLmNvbT4N Cj4gTWVzc2FnZS1JRDogPDIuMS4yLjExMDEwNDEwMDEuNDc3MTA4Ljc1ODQ1ODczMDBAbmV3cy5m b3JvbXRiLmNvbT4NCj4gU3ViamVjdDogDQo+PT9pc28tODg1OS0xNT9RP1RyZXNfYT1GMW9zX3Bl ZGFsZWFuZG9fanVudG9zX2Nvbl9SZXR0b190aWVuZW5fcHJlbWlvPz0NCj4gTUlNRS1WZXJzaW9u OiAxLjANCj4gQ29udGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7IGJvdW5kYXJ5PTQ3 NzEwODc1ODQ1ODczMDANCj4gWC1FTVYtUGxhdGZvcm06IHAyY2NjLmNhbXBhaWduY29tbWFuZGVy LmNvbSQNCj4gWC1FTVYtQ2FtcGFnbmVJZDogNDc3MTA4JA0KPiBYLUVNVi1NZW1iZXJJZDogNzU4 NDU4NzMwMCQNCj4gTGlzdC1VbnN1YnNjcmliZToNCj48aHR0cDovL3AydHJjLmVtdjIuY29tL0hE P2E9RU5YN0NxamlucV9MOFNBOU1LSkluRTduR0h4S0xFWFd5X2NTdEdiNWx3OFcwYg0KPkJoT0c1 bXBxVnNqZV9IaGREUVNsSHg+LA0KPjxtYWlsdG86dW5zdWJzY3JpYmVAbmV3cy5mb3JvbXRiLmNv bT9zdWJqZWN0PXVuc3Vic2NyaWJlLTItRU5YN0NxamlucV9MOFNBDQo+OU1LSkluRTduR0h4S0xF WFd5X2NTdEdiNWx3OFcwYkJoT0c1bXBxVnNqZV9IaGREUVNsSHg+DQo+PT09PT09PT09PT09PT09 PT09PT09PT09PT1lbWFpbCB3aXRoIGRlbGVnYXRlZCBzdWJkb21haW4NCj5lbmRzPT09PT09PT09 PT09PT09DQo+DQo+DQo+SGVyZSwgdGhlIGRvbWFpbiBvd25lciwgImZvcm9tdGIuY29tIiwgaXMg cnVubmluZyBuYWtlZCByZWdhcmRpbmcgU1BGLA0KPmV0YzoNCj4NCj4gJCBob3N0IC10IHR4dCBf ZG1hcmMuZm9yb210Yi5jb20uDQo+IEhvc3QgX2RtYXJjLmZvcm9tdGIuY29tLiBub3QgZm91bmQ6 IDMoTlhET01BSU4pDQo+DQo+ICQgaG9zdCAtdCB0eHQgZm9yb210Yi5jb20uDQo+IGZvcm9tdGIu Y29tIGhhcyBubyBUWFQgcmVjb3JkDQo+DQo+ICQgaG9zdCAtdCBteCBmb3JvbXRiLmNvbS4NCj4g Zm9yb210Yi5jb20gbWFpbCBpcyBoYW5kbGVkIGJ5IDAgbWFpbC5mb3JvbXRiLmNvbS4NCj4gZm9y b210Yi5jb20gbWFpbCBpcyBoYW5kbGVkIGJ5IDEwIHd3dy5mb3JvbXRiLmNvbS4NCj4NCj5Ib3dl dmVyLCB0aGV5IGhhdmUgb3V0c291cmNlZCB0aGVpciBlbWFpbCBtYXJrZXRpbmcgb3BlcmF0aW9u cyB0bw0KPkVNVjIuY29tIGJ5IG1lYW5zIG9mIGdpdmluZyB0aGVtIGNvbnRyb2wgb2YgdGhlaXIg c3ViZG9tYWluDQo+Im5ld3MuZm9yb210Yi5jb20iLCB3aGljaCBFTVYyIGhhcyBjbG90aGVkIHVw IGhhbmRzb21lbHkgaW4gU1BGLCBES0lNIGFuZA0KPkRNQVJDLCB0b2dldGhlciB3aXRoIHByb3Bl ciByZXZlcnNlIEROUywgZXRjLjoNCj4NCj4gJCBob3N0IC10IHR4dCBuZXdzLmZvcm9tdGIuY29t Lg0KPiBuZXdzLmZvcm9tdGIuY29tIGRlc2NyaXB0aXZlIHRleHQgInY9c3BmMSBpbmNsdWRlOnNw Zi1hLmVtYWlsdmlzaW9uLm5ldA0KPmluY2x1ZGU6c3BmLWIuZW1haWx2aXNpb24ubmV0IGluY2x1 ZGU6c3BmLWMuZW1haWx2aXNpb24ubmV0IC1hbGwiDQo+IG5ld3MuZm9yb210Yi5jb20gZGVzY3Jp cHRpdmUgdGV4dCAic3BmMi4wL3ByYQ0KPmluY2x1ZGU6c2VuZGVyaWQtYS5lbWFpbHZpc2lvbi5u ZXQgaW5jbHVkZTpzZW5kZXJpZC1iLmVtYWlsdmlzaW9uLm5ldA0KPmluY2x1ZGU6c2VuZGVyaWQt Yy5lbWFpbHZpc2lvbi5uZXQgLWFsbCINCj4NCj4gJCBob3N0IC10IHR4dCBfZG1hcmMubmV3cy5m b3JvbXRiLmNvbS4NCj4gX2RtYXJjLm5ld3MuZm9yb210Yi5jb20gZGVzY3JpcHRpdmUgdGV4dCAi dj1ETUFSQzFcOyBwPW5vbmVcOw0KPnJ1YT1lbXYuZG1hcmMucnVhQGVtYWlsdmlzaW9uLmNvbVw7 IHJmPWFmcmZcOyBwY3Q9MTAwXDsiDQo+DQo+ICQgaG9zdCAtdCBteCBuZXdzLmZvcm9tdGIuY29t Lg0KPiBuZXdzLmZvcm9tdGIuY29tIG1haWwgaXMgaGFuZGxlZCBieSAxMCBzbXRwMS5lbXYyLmNv bS4NCj4gbmV3cy5mb3JvbXRiLmNvbSBtYWlsIGlzIGhhbmRsZWQgYnkgMjAgc210cDIuZW12Mi5j b20uDQo+DQo+ICQgaG9zdCA4MS45Mi4xMTQuMzUNCj4gMzUuMTE0LjkyLjgxLmluLWFkZHIuYXJw YSBkb21haW4gbmFtZSBwb2ludGVyIGxpdGhpdW0tdGhmaS5jY2VtYWlscy5jb20uDQo+DQo+ICQg aG9zdCBsaXRoaXVtLXRoZmkuY2NlbWFpbHMuY29tDQo+IGxpdGhpdW0tdGhmaS5jY2VtYWlscy5j b20gaGFzIGFkZHJlc3MgODEuOTIuMTE0LjM1DQo+IGxpdGhpdW0tdGhmaS5jY2VtYWlscy5jb20g bWFpbCBpcyBoYW5kbGVkIGJ5IDEwIHNtdHAxLmVtdjIuY29tLg0KPiBsaXRoaXVtLXRoZmkuY2Nl bWFpbHMuY29tIG1haWwgaXMgaGFuZGxlZCBieSAyMCBzbXRwMi5lbXYyLmNvbS4NCj4NCj4NCj5U aGlzIGFwcHJvYWNoIGluIG15IG9waW5pb24gaXMgY2xlYW4gYW5kIG5vbiBjb252b2x1dGVkLCBm b3IgKDEpIHRoZQ0KPiJicmFuZGVkIiBzZW5kZXIsICgyKSB0aGUgIm1hdGVyaWFsIiBzZW5kZXIs IGFuZCAoMykgdGhlIGZpbmFsIHJlY2lwaWVudC4NCj5Ob3RlIHRoZSBwZXJmZWN0IGFsaWdubWVu dCBvZiB0aGUgUkZDNTMyMi5Gcm9tIGhlYWRlciB3aXRoIGJvdGggU1BGIGFuZA0KPkRLSU0sIGFu ZCB0aGF0IG9ubHkgaW4gdGhlICJSZXBseS1UbzoiIGhlYWRlciBpcyB0aGUgZG9tYWluIG93bmVy J3MgbWFpbg0KPmRvbWFpbiB1c2VkLg0KPg0KPlBsdXMsIGl0IHBhc3NlZCAoMSkgU1BGIGJ5IGl0 cyBvd24sICgyKSBES0lNIGJ5IGl0cyBvd24sIGFuZCAoMykgRE1BUkMNCj5pdHNlbGYuIEkgY291 bGQgbm90IGRyZWFtIG9mIGEgbW9yZSBwZXJmZWN0IGV4ZWN1dGlvbiB0aGFuIHRoaXMhDQo+DQo+ UmVnYXJkcywNCj4NCj5KLiBHb21leg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ZG1hcmMgbWFpbGluZyBsaXN0DQo+ZG1hcmNAaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjDQoNCg== From johnl@iecc.com Wed Apr 3 15:30:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92DC21F9052 for ; Wed, 3 Apr 2013 15:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.981 X-Spam-Level: X-Spam-Status: No, score=-110.981 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bw-Gh6UNElW for ; Wed, 3 Apr 2013 15:30:40 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1A21F902A for ; Wed, 3 Apr 2013 15:30:39 -0700 (PDT) Received: (qmail 50137 invoked from network); 3 Apr 2013 22:30:40 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Apr 2013 22:30:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515cad8f.xn--9vv.k1304; i=johnl@user.iecc.com; bh=426uQas5+RBV5Aia+T+9inIU9teQfwg2dAQJjM6ag20=; b=FJRTM5JHBJs62QOVaqSyJKzwzDIv9++yRHnGI0A8j+X8hWz8za7cyIWvgRXZTmuf6JUqC7v0Qz6DNssGi8PKPVtHZHB6STwkNtfChlu+5P5ZJg1zhWOvcqsje8/C/Rx5kg0BTAf21fbeIDfWZxD/8y4svWXQ0eguDwiaUv3ocaw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515cad8f.xn--9vv.k1304; olt=johnl@user.iecc.com; bh=426uQas5+RBV5Aia+T+9inIU9teQfwg2dAQJjM6ag20=; b=xqjjLX2uSPTbBWNxn9eTnWi0e16yyS7cWJbJmZJFrohUNeb13luegGnuPlR3Q0noHQSgvTK8VqKSZB9ih/c4VktR0F6qo7jVutS0nbvh7JXWK28aF3mvOWbCWlSxXW9kx8jJB0sd/WNU1DEGe7PVhViO2E8KvZBB29bJPBZC3uI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Apr 2013 22:30:16 -0000 Message-ID: <20130403223016.15561.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] outsourcing strategies, was A case to be addressed X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 22:30:41 -0000 >SMTP Mail From: communications@email.BigBank.com >5322 From: communications.email.BigBank.com > >Neither of those lets the receiver know that the mail actually came from BigEmailers.com. You also have to >manage private keys both within your own organization and with a 3rd party. Who knows how reliable they are? Apparently reliable enough, since it's a very common way for big companies to configure their ESP mail including the DKIM signatures. If the ESP turns out to be corrupt or incompetent, the company always has the option of removing the DNS delegation for email.bigbank.com, installing poison records to make all the SPF and DMARC fail, and using a different DNS name at their new ESP. I know that Forefront has a lot of big corporate customers, but it is my impression that you're mostly doing individual mail, exactly the kind that DMARC has the most trouble with due to forward to gmail, mailing lists and the like. We could round up some more people from the ESPs and bulk mailers that DMARC matches best and see what kinds of configurations they expect would be hard and what would be easy. R's, John From steven.m.jones@gmail.com Wed Apr 3 16:15:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38F921F8F0A for ; Wed, 3 Apr 2013 16:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ea9HGEbotL64 for ; Wed, 3 Apr 2013 16:15:29 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 718EB21F8F05 for ; Wed, 3 Apr 2013 16:15:29 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c10so2410338ieb.31 for ; Wed, 03 Apr 2013 16:15:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=A68ssN3ES14q506vAlsYZcM7g73MpEVuB7I+CyiarGc=; b=REIT4tMY9//8QWtOXTZAgkR2EHiKLrF3u/puZwLKlBcbuLEPtbHn9KdPVE/tCu4DzB wQWsPVIVBTjBXO7YGDnb7l3cQGLVvarS31IyIjXpSMhbcauYCzBbUFwtsXmefURSCGM3 cAjGsgiGS1/4xrUWS7Rq9JKbOgjVwiqHDKZwPi+/fJKtLUiQIo2Twrn3QH+lPp9T7oPi FTtQEh0JyiSmugqqzqCW0dGk5Xpk8GwhaerxPrA/lpoLYU6e/9/SoDKSKtA0ukayj+bf qoOLC0eHWHlenijgZ0MkXRhrmsXhhKCqjBLlX7jpx6yM4JhaKARFI2Ift8prB+d6hq7C RbEQ== MIME-Version: 1.0 X-Received: by 10.50.20.7 with SMTP id j7mr8608354ige.10.1365030929020; Wed, 03 Apr 2013 16:15:29 -0700 (PDT) Received: by 10.50.156.168 with HTTP; Wed, 3 Apr 2013 16:15:28 -0700 (PDT) In-Reply-To: <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> References: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> Date: Wed, 3 Apr 2013 16:15:28 -0700 Message-ID: From: Steve Jones To: Terry Zink Content-Type: multipart/alternative; boundary=047d7bd75bb8a1c07d04d97d0756 Cc: Franck Martin , "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 23:15:30 -0000 --047d7bd75bb8a1c07d04d97d0756 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 3, 2013 at 2:11 PM, Terry Zink wrote: > I don't think any of the options DMARC FAQ are satisfactory: > > > A.Integrate externally: The third party sender uses its own mail > > servers to send your emails > > 1. Delegate a sub domain so they can put their own DKIM record and > > SPF record in the DNS. > > 2. Give the third party a DKIM private key to sign the emails and > > publish the public key in your DNS and/or add their sending IP, > > maybe via a SPF include, to your SPF record. > > This is probably the most realistic workaround. The use of a sub-domain per product and/or 3rd party vendor, and providing them with signing keys, is the preferred model for my employer (BofA). It takes work, it may cost more, but having our customers compromised costs us too. > But it makes diagnosis difficult to see who is actually sending the > messages. For example, suppose BigBank.com outsources its email to > BigEmailers.com and the setup is as above, and the message looks as below: > > SMTP Mail From: communications@email.BigBank.com > 5322 From: communications.email.BigBank.com > > Neither of those lets the receiver know that the mail actually came from > BigEmailers.com. What does "actually came from" mean? If you want something provable in any way, 5321.MFROM is useless because it isn't signed. If you just mean for troubleshooting, why you have IP address data, reverse lookups, and asserted hostnames in logs and headers - and you're parsing all that or you wouldn't have the 5322.From available. You certainly have the "last hop" data available as state when you're handling the inbound connection... So I have all that information available, but you need to see the 3rd party identified in the 5321.MFROM in order to tell where it came from? I don't get it. Or is your "receiver" not the ISP/IT staff or the software they operate? Sidenote: Are you deliberately omitting an "@" in both of your 5322.From examples? Or is there a notational convention I've misplaced? > You also have to manage private keys both within your own organization and > with a 3rd party. Who knows how reliable they are? We have revised contract terms to specify how 3rd parties must perform in these areas. If they want our business, they'll meet the standards. And we audit all of our vendors periodically. Initially we got all kinds of pushback from ESPs who were happy with their existing business models and didn't want to make changes. We got absurd proposal prices - basically to buy them entire new infrastructures - or flat refusals. From those who wanted our business, we got a timeline or roadmap that led to compliance... I don't expect the average small business to go through all that. But it is my hope that as we require more responsible practices at the top of the ESP market, they filter down through the middle to the bottom of the market, and small businesses and their customers will benefit too. > > > B. Integrate internally: Get the third party sender to relay all your > emails via > > your mail server. > > Many large organizations would strongly push back at this, and rightly so. > It's a security risk to allow someone else to send mail through your own > hardware and network (unless that is your business model). > Then again, we may require it. Consider the case where a CRM platform like SalesForce is sending out messages on your behalf, from regulated employees - financial advisors, portfolio managers, etc. You're not only dealing with sensitive traffic with considerable potential losses in the event of successful phishing, you're usually under legal obligation to archive all such traffic. But aside from that specific example, we've spec'd several cases where we would do this for email originating at partner firms to make sure the authentication is done right. Again sub-domains are useful to segment traffic, allow for different policies, and help prevent a "mishap" at the partner from resulting in email masquerading as an address/domain that we haven't authorized them to use. If they do spew badness with the authorized sub-domain, we can disable relaying and push policies to block all of that traffic as soon as it's detected - without impacting the rest of our mailstreams. Thus, in my view, the sending-mail-on-behalf-of-another is problematic for > DMARC and each workaround has its own constraints which may not be > satisfactory to many senders and brands. > There are trade-offs, to be sure. And not every existing practice is going to continue to work, anymore than it's acceptable now, as it was ten years ago, for a random employee to go out with a credit card and hire a marketing firm to register a domain and send out an email marketing campaign using one of our brands. (Usually with each URL and tag in the message using a different domain from all the others...) --S. --047d7bd75bb8a1c07d04d97d0756 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0O= n Wed, Apr 3, 2013 at 2:11 PM, Terry Zink <tzink@exchange.micro= soft.com> wrote:
I don't think any of = the options DMARC FAQ are satisfactory:

> A.Integrate externally: The third party sender uses its own mail
> servers to send your emails
> =A0 1. Delegate a sub domain so they can put their own DKIM record and=
> =A0 =A0 =A0SPF record in the DNS.
> =A0 2. Give the third party a DKIM private key to sign the emails and<= br> > =A0 =A0 =A0publish the public key in your DNS and/or add their sending= IP,
> =A0 =A0 =A0maybe via a SPF include, to your SPF record.

This is probably the most realistic workaround.

The use of a sub-domain per product and/or 3rd party vendor, and prov= iding them with signing keys, is the preferred model for my employer (BofA)= . It takes work, it may cost more, but having our customers compromised cos= ts us too.

=A0
B= ut it makes diagnosis difficult to see who is actually sending the messages= . For example, suppose BigBank.com outsources its email to BigEmailers.com = and the setup is as above, and the message looks as below:

SMTP Mail From: communi= cations@email.BigBank.com
5322 From: communications.email.BigBank.com

Neither of those lets the receiver know that the mail actually came from Bi= gEmailers.com.

What does "actually came fro= m" mean? If you want something provable in any way, 5321.MFROM is usel= ess because it isn't signed.

If you just mean for troubleshooting, why you have IP addres= s data, reverse lookups, and asserted hostnames in logs and headers - and y= ou're parsing all that or you wouldn't have the 5322.From available= . You certainly have the "last hop" data available as state when = you're handling the inbound connection... So I have all that informatio= n available, but you need to see the 3rd party identified in the 5321.MFROM= in order to tell where it came from?

I don't get it. Or is your "receiver" not the ISP/IT staf= f or the software they operate?

Sidenote: Are you deliberately omitting an "@" in both of = your 5322.From examples? Or is there a notational convention I've mispl= aced?


=A0
You also have to manage private keys both within your own organ= ization and with a 3rd party. Who knows how reliable they are?

We have revised contract terms to specify how 3rd parti= es must perform in these areas. If they want our business, they'll meet= the standards. And we audit all of our vendors periodically.

Initially we got all kinds of pushback from ESPs who were happy with t= heir existing business models and didn't want to make changes. We got a= bsurd proposal prices - basically to buy them entire new infrastructures - = or flat refusals. From those who wanted our business, we got a timeline or = roadmap that led to compliance...

I don't expect the average small business to go through = all that. But it is my hope that as we require more responsible practices a= t the top of the ESP market, they filter down through the middle to the bot= tom of the market, and small businesses and their customers will benefit to= o.

=A0

> B. Integrate internally: Get the third party sender to relay all your = emails via
> your mail server.

Many large organizations would strongly push back at this, and rightly so. = It's a security risk to allow someone else to send mail through your ow= n hardware and network (unless that is your business model).

Then again, we may require it. Consider the case where = a CRM platform like SalesForce is sending out messages on your behalf, from= regulated employees - financial advisors, portfolio managers, etc. You'= ;re not only dealing with sensitive traffic with considerable potential los= ses in the event of successful phishing, you're usually under legal obl= igation to archive all such traffic.

But aside from that specific example, we've spec'd s= everal cases where we would do this for email originating at partner firms = to make sure the authentication is done right. Again sub-domains are useful= to segment traffic, allow for different policies, and help prevent a "= ;mishap" at the partner from resulting in email masquerading as an add= ress/domain that we haven't authorized them to use. If they do spew bad= ness with the authorized sub-domain, we can disable relaying and push polic= ies to block all of that traffic as soon as it's detected - without imp= acting the rest of our mailstreams.


Thus, in my view, the sending-mail-on-behalf-of-another is problematic for = DMARC and each workaround has its own constraints which may not be satisfac= tory to many senders and brands.

There = are trade-offs, to be sure. And not every existing practice is going to con= tinue to work, anymore than it's acceptable now, as it was ten years ag= o, for a random employee to go out with a credit card and hire a marketing = firm to register a domain and send out an email marketing campaign using on= e of our brands. (Usually with each URL and <img> tag in the message = using a different domain from all the others...)

--S.
--047d7bd75bb8a1c07d04d97d0756-- From steven.m.jones@gmail.com Wed Apr 3 16:35:03 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75AD21F8D90 for ; Wed, 3 Apr 2013 16:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYEKNmbPDv+U for ; Wed, 3 Apr 2013 16:35:03 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3F62721F8BEB for ; Wed, 3 Apr 2013 16:35:03 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id bn7so2352611ieb.23 for ; Wed, 03 Apr 2013 16:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=e5/hQh0/3ttaj+6vPwEei/n2X2uF1p+ADoP3PGQ6/mA=; b=WjjkT9QWJc6uvVOb2WmjvyCQoYEw1PUsSwj6XMA3RmahRqhgXu5VDE0sJUehoodcIE kyNvvkB6YgUhBqtZqv44O8nMSXjaQeszzzXrSD+s2ic1e5eWPNW583X/8L4H4o4wlLJ0 NutLLNhH3TFl80eQaFx+cfHUR1DW7Wv9PpHW1SFBg7Oj+0dnIbSgU84kV3Fd8eQpyMrP Ymk2Hyyqk1zwAIqGsl8rZuipiWMmO4grgQdb2NslJRF1GY5R95QEVrph3hvk5wxYnxkp cEFXvgt2wZL+fRCRz1hizvM90bBORH/JDrhnOsWKPUnNTio7r4nG+c3T2BCQ6Z5mzSmw 1UrQ== MIME-Version: 1.0 X-Received: by 10.43.4.74 with SMTP id ob10mr2092658icb.28.1365032102930; Wed, 03 Apr 2013 16:35:02 -0700 (PDT) Received: by 10.50.156.168 with HTTP; Wed, 3 Apr 2013 16:35:02 -0700 (PDT) In-Reply-To: References: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> Date: Wed, 3 Apr 2013 16:35:02 -0700 Message-ID: From: Steve Jones To: Terry Zink Content-Type: multipart/alternative; boundary=bcaec5158d879a30ad04d97d4d4e Cc: Franck Martin , "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 03 Apr 2013 23:35:03 -0000 --bcaec5158d879a30ad04d97d4d4e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 3, 2013 at 4:15 PM, Steve Jones wrote: > > What does "actually came from" mean? If you want something provable in any > way, 5321.MFROM is useless because it isn't signed. > Sorry, that second sentence is as puzzling as anything I'm asking about... Please disregard. --S. --bcaec5158d879a30ad04d97d4d4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0O= n Wed, Apr 3, 2013 at 4:15 PM, Steve Jones <steven.m.jones@gmail.co= m> wrote:
=

What does "actually c= ame from" mean? If you want something provable in any way, 5321.MFROM = is useless because it isn't signed.

Sorry, that second= sentence is as puzzling as anything I'm asking about... Please disrega= rd.

--S.


--bcaec5158d879a30ad04d97d4d4e-- From tzink@exchange.microsoft.com Wed Apr 3 17:03:17 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C318A21F852A for ; Wed, 3 Apr 2013 17:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVQv44DwqMfn for ; Wed, 3 Apr 2013 17:03:15 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.90]) by ietfa.amsl.com (Postfix) with ESMTP id 737E521F8526 for ; Wed, 3 Apr 2013 17:03:15 -0700 (PDT) Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) by BLUSR01MB603.namsdf01.sdf.exchangelabs.com (10.255.124.168) with Microsoft SMTP Server (TLS) id 15.0.670.5; Thu, 4 Apr 2013 00:03:12 +0000 Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.4.18]) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.4.18]) with mapi id 15.00.0670.000; Thu, 4 Apr 2013 00:03:11 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] A case to be addressed in the BCP document for DMARC Thread-Index: AQHOMKmJYXHKHa0HREWO6P9UMi3e2pjE9v4AgAAGi5CAACNlAIAADEXQ Date: Thu, 4 Apr 2013 00:03:10 +0000 Message-ID: References: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:e0:200d:f194:3b13:e610:d144] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUSR01MB603; H:BLUSR01MB601.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 04 Apr 2013 00:03:17 -0000 > The use of a sub-domain per product and/or 3rd party vendor, and providin= g them=20 > with signing keys, is the preferred model for my employer (BofA). It take= s work, > it may cost more, but having our customers compromised costs us too. If it works for BofA, that's a good sign that it would work for other brand= s, too. > Sidenote: Are you deliberately omitting an "@" in both of your 5322.From = examples?=20 > Or is there a notational convention I've misplaced? First time was a typo. Second time was copy-and-paste of that typo. Also, I just discovered that there is a MAAWG video and pdf series on DMARC= and third-parties are covered in section 6. It goes into the pros and cons= of various options: http://www.maawg.org/activities/training/dmarc-training-series I withdraw my previous objections to option A. Move along, move along. -- Terry -----Original Message----- From: Steve Jones [mailto:steven.m.jones@gmail.com]=20 Sent: Wednesday, April 03, 2013 4:15 PM To: Terry Zink Cc: Franck Martin; J. Gomez; dmarc@ietf.org Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DM= ARC =A0On Wed, Apr 3, 2013 at 2:11 PM, Terry Zink wrote: I don't think any of the options DMARC FAQ are satisfactory: > A.Integrate externally: The third party sender uses its own mail=20 > servers to send your emails > =A0 1. Delegate a sub domain so they can put their own DKIM record and > =A0 =A0 =A0SPF record in the DNS. > =A0 2. Give the third party a DKIM private key to sign the emails and > =A0 =A0 =A0publish the public key in your DNS and/or add their sending IP= , > =A0 =A0 =A0maybe via a SPF include, to your SPF record. This is probably the most realistic workaround.=20 The use of a sub-domain per product and/or 3rd party vendor, and providing = them with signing keys, is the preferred model for my employer (BofA). It t= akes work, it may cost more, but having our customers compromised costs us = too. =A0 But it makes diagnosis difficult to see who is actually sending the message= s. For example, suppose BigBank.com outsources its email to BigEmailers.com= and the setup is as above, and the message looks as below: SMTP Mail From: communications@email.BigBank.com 5322 From: communications.email.BigBank.com Neither of those lets the receiver know that the mail actually came from Bi= gEmailers.com. What does "actually came from" mean? If you want something provable in any = way, 5321.MFROM is useless because it isn't signed. If you just mean for troubleshooting, why you have IP address data, reverse= lookups, and asserted hostnames in logs and headers - and you're parsing a= ll that or you wouldn't have the 5322.From available. You certainly have th= e "last hop" data available as state when you're handling the inbound conne= ction... So I have all that information available, but you need to see the = 3rd party identified in the 5321.MFROM in order to tell where it came from? I don't get it. Or is your "receiver" not the ISP/IT staff or the software = they operate? Sidenote: Are you deliberately omitting an "@" in both of your 5322.From ex= amples? Or is there a notational convention I've misplaced? =A0 You also have to manage private keys both within your own organization and = with a 3rd party. Who knows how reliable they are?=20 We have revised contract terms to specify how 3rd parties must perform in t= hese areas. If they want our business, they'll meet the standards. And we a= udit all of our vendors periodically. Initially we got all kinds of pushback from ESPs who were happy with their = existing business models and didn't want to make changes. We got absurd pro= posal prices - basically to buy them entire new infrastructures - or flat r= efusals. From those who wanted our business, we got a timeline or roadmap t= hat led to compliance... I don't expect the average small business to go through all that. But it is= my hope that as we require more responsible practices at the top of the ES= P market, they filter down through the middle to the bottom of the market, = and small businesses and their customers will benefit too. =A0 > B. Integrate internally: Get the third party sender to relay all your=20 > emails via your mail server. Many large organizations would strongly push back at this, and rightly so. = It's a security risk to allow someone else to send mail through your own ha= rdware and network (unless that is your business model). Then again, we may require it. Consider the case where a CRM platform like = SalesForce is sending out messages on your behalf, from regulated employees= - financial advisors, portfolio managers, etc. You're not only dealing wit= h sensitive traffic with considerable potential losses in the event of succ= essful phishing, you're usually under legal obligation to archive all such = traffic. But aside from that specific example, we've spec'd several cases where we w= ould do this for email originating at partner firms to make sure the authen= tication is done right. Again sub-domains are useful to segment traffic, al= low for different policies, and help prevent a "mishap" at the partner from= resulting in email masquerading as an address/domain that we haven't autho= rized them to use. If they do spew badness with the authorized sub-domain, = we can disable relaying and push policies to block all of that traffic as s= oon as it's detected - without impacting the rest of our mailstreams. Thus, in my view, the sending-mail-on-behalf-of-another is problematic for = DMARC and each workaround has its own constraints which may not be satisfac= tory to many senders and brands. There are trade-offs, to be sure. And not every existing practice is going = to continue to work, anymore than it's acceptable now, as it was ten years = ago, for a random employee to go out with a credit card and hire a marketin= g firm to register a domain and send out an email marketing campaign using = one of our brands. (Usually with each URL and tag in the message usin= g a different domain from all the others...) --S. From tzink@exchange.microsoft.com Thu Apr 4 09:14:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E0E21F95FB for ; Thu, 4 Apr 2013 09:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZe7NE9cOHuF for ; Thu, 4 Apr 2013 09:14:44 -0700 (PDT) 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 519D121F942D for ; Thu, 4 Apr 2013 09:14:40 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.675.1; Thu, 4 Apr 2013 16:14:37 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.109]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.109]) with mapi id 15.00.0675.000; Thu, 4 Apr 2013 16:14:37 +0000 From: Terry Zink To: Terry Zink , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] A case to be addressed in the BCP document for DMARC Thread-Index: AQHOMKmJYXHKHa0HREWO6P9UMi3e2pjE9v4AgAAGi5CAAAD04IABPuzQ Date: Thu, 4 Apr 2013 16:14:36 +0000 Message-ID: <7bf458bdc3934cbab4b676cc3d967523@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <471DAE327D3E4AE2A5DAB89BFA618A43@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EB06CE@ESV4-MBX01.linkedin.biz> <30dc5cbfd17b4fd39e57ce69c9a7486b@BLUSR01MB601.namsdf01.sdf.exchangelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.93.132] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DMARC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 04 Apr 2013 16:14:45 -0000 Hmm, the timing of this message makes it seem like I have reservations abou= t the various options.=20 I don't; this mail just arrived late. -- Terry -----Original Message----- From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of T= erry Zink Sent: Wednesday, April 03, 2013 2:13 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DM= ARC To clarify my point, these workarounds work, but the tradeoffs may not be w= orth it. -- Terry -----Original Message----- From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of T= erry Zink Sent: Wednesday, April 03, 2013 2:11 PM To: Franck Martin; J. Gomez; dmarc@ietf.org Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DM= ARC I don't think any of the options DMARC FAQ are satisfactory: > A.Integrate externally: The third party sender uses its own mail=20 > servers to send your emails > 1. Delegate a sub domain so they can put their own DKIM record and > SPF record in the DNS.=20 > 2. Give the third party a DKIM private key to sign the emails and=20 > publish the public key in your DNS and/or add their sending IP,=20 > maybe via a SPF include, to your SPF record.=20 This is probably the most realistic workaround. But it makes diagnosis diff= icult to see who is actually sending the messages. For example, suppose Big= Bank.com outsources its email to BigEmailers.com and the setup is as above,= and the message looks as below: SMTP Mail From: communications@email.BigBank.com 5322 From: communications.email.BigBank.com Neither of those lets the receiver know that the mail actually came from Bi= gEmailers.com. You also have to manage private keys both within your own or= ganization and with a 3rd party. Who knows how reliable they are? On the ot= her hand: SMTP Mail From: BigBank@BigEmailers.com 5322 From: communications.email.BigBank.com This makes it easier to see who is the originator of the email. But it also= fails DMARC. > B. Integrate internally: Get the third party sender to relay all your=20 > emails via your mail server. Many large organizations would strongly push back at this, and rightly so. = It's a security risk to allow someone else to send mail through your own ha= rdware and network (unless that is your business model). > C. Do not integrate and tell them not to spoof This is not workable, either. As a consumer, I would be confused if mail fr= om BigBank@BigEmailers.com arrived in my inbox, claiming to be from BigBank= . I'd think it was a phish. BigBank wants the 5322 From to be BigBank.com. Thus, in my view, the sending-mail-on-behalf-of-another is problematic for = DMARC and each workaround has its own constraints which may not be satisfac= tory to many senders and brands. -- Terry -----Original Message----- From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of F= ranck Martin Sent: Wednesday, April 03, 2013 1:45 PM To: J. Gomez; dmarc@ietf.org Subject: Re: [dmarc-ietf] A case to be addressed in the BCP document for DM= ARC Yes, and I got through the same problems to get all our third parties to al= ign it was not too hard but it required some focus, some involving getting = them to start to DKIM sign. This FAQ http://www.dmarc.org/faq.html#s_14 answers briefly what has to be = done for a third party. I don't know other solutions, but they have proven = sufficient for everyone I had to work with. I think DMARC offers an opportunity to inventory all the mail streams an or= ganization uses, and to get them to a certain corporate level of standards.= It may requires you to write new on boarding rules for third parties, and = be capable to say to a vendor, and more important to your own people: "sorry, you can't comply with our security rules, so we can't have = you as a vendor until you do". I guess I have a slight bit more power on ve= ndors to open this road... So this seems to me a problem at OSI layer 9 http://en.wikipedia.org/wiki/Layer_8 It is important to see that DMARC relies heavily on http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-3.4 1. 1. The RFC5322.From domain is the identifier used for all message validation operations, as it is the single identifier in the message likely to be visible to the user. If there is no authentication glue to RFC5322.From then you allow anyone to= send for you... On 4/3/13 1:27 PM, "J. Gomez" wrote: >Hello. > >I have this sample email which I got that would fail both SPF and DKIM=20 >in the realm of DMARC, although it would pass both SPF and DKIM=20 >"by-themselves". However as the RFC5322.From header is not aligned with=20 >SPF nor DKIM, it would fail DMARC. > >This is legitimate marketing email from Symantec to which I am=20 >subscribed, it's not spam. > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From vesely@tana.it Fri Apr 5 10:14:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B637C21F9852 for ; Fri, 5 Apr 2013 10:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.519 X-Spam-Level: X-Spam-Status: No, score=-3.519 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_48=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cdL-MNcJKU5 for ; Fri, 5 Apr 2013 10:14:42 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 52CE721F984F for ; Fri, 5 Apr 2013 10:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365182080; bh=UTdrckDK19pQMGOL+I+2ZF4p/LJNyYYhnZWFUA+Fqfo=; l=2857; h=Date:From:To:References:In-Reply-To; b=ru8ox0+xvtk7m+eHPgJ9Tg4Fzc3XM2Fjq0RMRBpLttGYyD0hNaqA2gWmvI5PKUEPN SLeYUUkGWlpbLj3Nxs5sm5swv+nl2Ggq3R3fyrW80zoK7+dG3KvnphPai2RUNNn/F1 9VeJ0voe6vRYr9wZRQLqrAn0CD+p6OlN3xtQwM0o= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 05 Apr 2013 19:14:40 +0200 id 00000000005DC03F.00000000515F0680.00005925 Message-ID: <515F0680.9010203@tana.it> Date: Fri, 05 Apr 2013 19:14:40 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130403223016.15561.qmail@joyce.lan> In-Reply-To: <20130403223016.15561.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 05 Apr 2013 17:14:43 -0000 Hi On Thu 04/Apr/2013 00:30:16 +0200 John Levine wrote: >>SMTP Mail From: communications@email.BigBank.com >>5322 From: communications.email.BigBank.com >> >>Neither of those lets the receiver know that the mail actually came from BigEmailers.com. You also have to >>manage private keys both within your own organization and with a 3rd party. Who knows how reliable they are? > > Apparently reliable enough, since it's a very common way for big > companies to configure their ESP mail including the DKIM signatures. > If the ESP turns out to be corrupt or incompetent, the company always > has the option of removing the DNS delegation for email.bigbank.com, > installing poison records to make all the SPF and DMARC fail, and > using a different DNS name at their new ESP. I couldn't help thinking back to when you wrote: In the physical world, banks have marble counters, vaults with heavy steel doors, and other physical objects that are hard to fake. A building that looks like a bank probably is a bank. http://www.circleid.com/posts/fight_phishing_with_branding/ All of that marble and heavy steel was built by external service providers who contracted those jobs. Even surveillance is outsourced. The only reason for not delegating BigBank.com altogether would be if they want web and mail to be handled by different providers. IMHO getting persuaded to outsource email to competent providers, lest be accused of insufficient protection against phishing, is the only way that banks can catch up. > I know that Forefront has a lot of big corporate customers, but it is > my impression that you're mostly doing individual mail, exactly the > kind that DMARC has the most trouble with due to forward to gmail, > mailing lists and the like. Newbie's question (be patient): As I'm new to DMARC, perhaps I may ask why cannot a list manager or similar operator change the From: slightly? For this message, that would be: IN: From: Alessandro Vesely OUT: From: Alessandro Vesely (sent by ietf.org) Where the domain-like token in the trailing comment, if authenticated, is to be used for alignment instead of the author domain. That would stop everyone from getting DMARC feedback that don't pertain to them, while still being visible in the MUA. Note that some MUA already attempts a similar merging of header.from and smtp.mailfrom by displaying "on behalf of". In addition, such change would most probably break any original DKIM signature, thereby clarifying that any claim of some responsibility was taken over. BTW: Why messages in this list are not signed? > We could round up some more people from the ESPs and bulk mailers > that DMARC matches best and see what kinds of configurations they > expect would be hard and what would be easy. From prvs=800a5e35e=fmartin@linkedin.com Fri Apr 5 10:49:12 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD43A21F9764 for ; Fri, 5 Apr 2013 10:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF4wYiEnPXZJ for ; Fri, 5 Apr 2013 10:49:12 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 04CAA21F973D for ; Fri, 5 Apr 2013 10:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365184146; x=1396720146; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=aUbEFopfxAhlksWhiBxJNcm6c1obVh/Zm4/E9PeH6iA=; b=n3ZPjiXl8PpsaZetRuYp9puH8aCTcknzNktAA7wtBUAMqAnMKvzstgy3 R0Y8J63i0GCGqQb8VgoV2G3bA4t5AqvH7XhqPylyNFu9G/3LW0mey4AHB F899hP/Is3vQF+wB7998sTSRMf1Sxe982yYH1fhZYEW+zc+QKjxPHateF U=; X-IronPort-AV: E=Sophos;i="4.87,416,1363158000"; d="scan'208";a="44321785" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Fri, 5 Apr 2013 10:48:59 -0700 From: Franck Martin To: Alessandro Vesely , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] outsourcing strategies, and a newbie's question Thread-Index: AQHOMiEXTf7Bov2X20CELZ8dTRNRo5jH53AA Date: Fri, 5 Apr 2013 17:48:59 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EB992A@ESV4-MBX01.linkedin.biz> In-Reply-To: <515F0680.9010203@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 05 Apr 2013 17:49:13 -0000 DQoNCk9uIDQvNS8xMyAxMDoxNCBBTSwgIkFsZXNzYW5kcm8gVmVzZWx5IiA8dmVzZWx5QHRhbmEu aXQ+IHdyb3RlOg0KDQo+SGkNCj4NCj5PbiBUaHUgMDQvQXByLzIwMTMgMDA6MzA6MTYgKzAyMDAg Sm9obiBMZXZpbmUgd3JvdGU6DQo+Pj5TTVRQIE1haWwgRnJvbTogY29tbXVuaWNhdGlvbnNAZW1h aWwuQmlnQmFuay5jb20NCj4+PjUzMjIgRnJvbTogY29tbXVuaWNhdGlvbnMuZW1haWwuQmlnQmFu ay5jb20NCj4+Pg0KPj4+TmVpdGhlciBvZiB0aG9zZSBsZXRzIHRoZSByZWNlaXZlciBrbm93IHRo YXQgdGhlIG1haWwgYWN0dWFsbHkgY2FtZQ0KPj4+ZnJvbSBCaWdFbWFpbGVycy5jb20uIFlvdSBh bHNvIGhhdmUgdG8NCj4+Pm1hbmFnZSBwcml2YXRlIGtleXMgYm90aCB3aXRoaW4geW91ciBvd24g b3JnYW5pemF0aW9uIGFuZCB3aXRoIGEgM3JkDQo+Pj5wYXJ0eS4gV2hvIGtub3dzIGhvdyByZWxp YWJsZSB0aGV5IGFyZT8NCj4+IA0KPj4gQXBwYXJlbnRseSByZWxpYWJsZSBlbm91Z2gsIHNpbmNl IGl0J3MgYSB2ZXJ5IGNvbW1vbiB3YXkgZm9yIGJpZw0KPj4gY29tcGFuaWVzIHRvIGNvbmZpZ3Vy ZSB0aGVpciBFU1AgbWFpbCBpbmNsdWRpbmcgdGhlIERLSU0gc2lnbmF0dXJlcy4NCj4+IElmIHRo ZSBFU1AgdHVybnMgb3V0IHRvIGJlIGNvcnJ1cHQgb3IgaW5jb21wZXRlbnQsIHRoZSBjb21wYW55 IGFsd2F5cw0KPj4gaGFzIHRoZSBvcHRpb24gb2YgcmVtb3ZpbmcgdGhlIEROUyBkZWxlZ2F0aW9u IGZvciBlbWFpbC5iaWdiYW5rLmNvbSwNCj4+IGluc3RhbGxpbmcgcG9pc29uIHJlY29yZHMgdG8g bWFrZSBhbGwgdGhlIFNQRiBhbmQgRE1BUkMgZmFpbCwgYW5kDQo+PiB1c2luZyBhIGRpZmZlcmVu dCBETlMgbmFtZSBhdCB0aGVpciBuZXcgRVNQLg0KPg0KPkkgY291bGRuJ3QgaGVscCB0aGlua2lu ZyBiYWNrIHRvIHdoZW4geW91IHdyb3RlOg0KPg0KPiAgIEluIHRoZSBwaHlzaWNhbCB3b3JsZCwg YmFua3MgaGF2ZSBtYXJibGUgY291bnRlcnMsIHZhdWx0cyB3aXRoDQo+ICAgaGVhdnkgc3RlZWwg ZG9vcnMsIGFuZCBvdGhlciBwaHlzaWNhbCBvYmplY3RzIHRoYXQgYXJlIGhhcmQgdG8NCj4gICBm YWtlLiBBIGJ1aWxkaW5nIHRoYXQgbG9va3MgbGlrZSBhIGJhbmsgcHJvYmFibHkgaXMgYSBiYW5r Lg0KPiAgICAgIGh0dHA6Ly93d3cuY2lyY2xlaWQuY29tL3Bvc3RzL2ZpZ2h0X3BoaXNoaW5nX3dp dGhfYnJhbmRpbmcvDQo+DQo+QWxsIG9mIHRoYXQgbWFyYmxlIGFuZCBoZWF2eSBzdGVlbCB3YXMg YnVpbHQgYnkgZXh0ZXJuYWwgc2VydmljZQ0KPnByb3ZpZGVycyB3aG8gY29udHJhY3RlZCB0aG9z ZSBqb2JzLiAgRXZlbiBzdXJ2ZWlsbGFuY2UgaXMgb3V0c291cmNlZC4NCj4gVGhlIG9ubHkgcmVh c29uIGZvciBub3QgZGVsZWdhdGluZyBCaWdCYW5rLmNvbSBhbHRvZ2V0aGVyIHdvdWxkIGJlIGlm DQo+dGhleSB3YW50IHdlYiBhbmQgbWFpbCB0byBiZSBoYW5kbGVkIGJ5IGRpZmZlcmVudCBwcm92 aWRlcnMuICBJTUhPDQo+Z2V0dGluZyBwZXJzdWFkZWQgdG8gb3V0c291cmNlIGVtYWlsIHRvIGNv bXBldGVudCBwcm92aWRlcnMsIGxlc3QgYmUNCj5hY2N1c2VkIG9mIGluc3VmZmljaWVudCBwcm90 ZWN0aW9uIGFnYWluc3QgcGhpc2hpbmcsIGlzIHRoZSBvbmx5IHdheQ0KPnRoYXQgYmFua3MgY2Fu IGNhdGNoIHVwLg0KPg0KPj4gSSBrbm93IHRoYXQgRm9yZWZyb250IGhhcyBhIGxvdCBvZiBiaWcg Y29ycG9yYXRlIGN1c3RvbWVycywgYnV0IGl0IGlzDQo+PiBteSBpbXByZXNzaW9uIHRoYXQgeW91 J3JlIG1vc3RseSBkb2luZyBpbmRpdmlkdWFsIG1haWwsIGV4YWN0bHkgdGhlDQo+PiBraW5kIHRo YXQgRE1BUkMgaGFzIHRoZSBtb3N0IHRyb3VibGUgd2l0aCBkdWUgdG8gZm9yd2FyZCB0byBnbWFp bCwNCj4+IG1haWxpbmcgbGlzdHMgYW5kIHRoZSBsaWtlLg0KPg0KPk5ld2JpZSdzIHF1ZXN0aW9u IChiZSBwYXRpZW50KTogIEFzIEknbSBuZXcgdG8gRE1BUkMsIHBlcmhhcHMgSSBtYXkNCj5hc2sg d2h5IGNhbm5vdCBhIGxpc3QgbWFuYWdlciBvciBzaW1pbGFyIG9wZXJhdG9yIGNoYW5nZSB0aGUg RnJvbToNCj5zbGlnaHRseT8gIEZvciB0aGlzIG1lc3NhZ2UsIHRoYXQgd291bGQgYmU6DQo+DQo+ SU46DQo+ICAgRnJvbTogQWxlc3NhbmRybyBWZXNlbHkgPHZlc2VseUB0YW5hLml0Pg0KPg0KPk9V VDoNCj4gICBGcm9tOiBBbGVzc2FuZHJvIFZlc2VseSA8dmVzZWx5QHRhbmEuaXQ+IChzZW50IGJ5 IGlldGYub3JnKQ0KPg0KDQpXaGF0IHlvdSBkZXNjcmliZSBpZiBJJ20gbm90IG1pc3Rha2VuLCBp cyBub3QgYSB2YWxpZCBlbWFpbCBzeW50YXggKG9yDQpkZXByZWNhdGVkIG9uZSksIGJ1dCB3aGF0 IHlvdXIgTVVBIHByZXNlbnQgeW91IHdpdGguDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM1MzIyI3NlY3Rpb24tMy40IG1haWxib3ggc3ludGF4DQoNClRoZSB1c2Ugb2YgdGhlIFNlbmRl cjogaGVhZGVyIGZvciBETUFSQyBhcyBhbiBpZGVudGlmaWVyIHdhcyBub3QgYWRvcHRlZA0KYmVj YXVzZSBpdCBjb3VsZCBiZSBlYXNpbHkgYWJ1c2VkIChjZiBzeXN0ZW1zIGxpa2Ugc2VuZCB0aGlz IGFydGljbGUgdG8gYQ0KZnJpZW5kKSBhbmQgbm90IGFsbCBNVUFzIGRpc3BsYXkgaXQgdG8gdGhl IHVzZXIgKG9yIGluIGEgbWVhbmluZ2Z1bCB3YXkpLg0KDQpIb3dldmVyLCBhbmQgdGhhdCdzIGFu b3RoZXIgdG9waWMgeW91ciBjb3VsZCBkbzoNCkZyb206ICJBbGVzc2FuZHJvIFZlc2VseSAodmlh IElFVEYpIiA8ZG1hcmNAaWV0Zi5vcmc+DQoNClJlcGx5IHRvOiAiRE1BUkMgTGlzdCIgPGRtYXJj QGlldGYub3JnPg0KDQoNCm9yDQoNCkZyb206ICJBbGVzc2FuZHJvIFZlc2VseSAodmlhIElFVEYp IiA8ZG1hcmNAaWV0Zi5vcmc+DQpSZXBseSB0bzogIkRNQVJDIExpc3QiIDxkbWFyY0BpZXRmLm9y Zz4sICJBbGVzc2FuZHJvIFZlc2VseSINCjx2ZXNlbHlAdGFuYS5pdD4NCg0KTm90ZSBJIGFsc28g ZG8gbm90IHdhbnQgdG8gZW5jb3VyYWdlIHBlb3BsZSB0byBwdXQgYW55dGhpbmcgdGhhdCBsb29r cw0KbGlrZSBhbiBlbWFpbCBhZGRyZXNzIG9yIGRvbWFpbiBpbiB0aGUgZnJpZW5kbHkgRnJvbSBw YXJ0Lg0KDQo= From johnl@taugh.com Fri Apr 5 11:08:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B5B21F984E for ; Fri, 5 Apr 2013 11:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MT9UL6NyhIdM for ; Fri, 5 Apr 2013 11:08:59 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B3B7621F9844 for ; Fri, 5 Apr 2013 11:08:58 -0700 (PDT) Received: (qmail 35192 invoked from network); 5 Apr 2013 18:08:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=8977.515f1339.k1304; bh=xJ76cZLhZF5XjA0V6nVGbh0XqPITYI1tx44xOz6DfPs=; b=JY9eDTJvFnd1FqBy4YDX3/sHfg+msqqKplXo9sUBHGmI+rN/XviJWxSX4uUdj//9o1rjcs7Kkh+E4WsdMXYM/GQFQ0Z3Zb/NWe+wgXB8t8oHzs1X4XkMBXFbtZN+t0l1Vuir1skX08FVhErhYytgWiOTVsZQBSs+IHlD842UZig= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:vbr-info:user-agent:cleverness; s=8977.515f1339.k1304; bh=xJ76cZLhZF5XjA0V6nVGbh0XqPITYI1tx44xOz6DfPs=; b=AOdW1GtipZdZtbKzKWMZ/suoP/u4lx9RGNCbeg6hxlIl4bIZZjGWrGs3ZsN/M2UUXlvLk1a8dsDEvsxps97ahc/GZDbIrq5HlH65P74kS9SzAF+ijQI25cXpFMzrDE51XcvmDwQc9bAlGF2hGHtCEcnuD+UHDO0UwQBLBR7/hOo= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 5 Apr 2013 18:08:35 -0000 Date: 5 Apr 2013 14:08:56 -0400 Message-ID: From: "John R Levine" To: "Alessandro Vesely" In-Reply-To: <515F0680.9010203@tana.it> References: <20130403223016.15561.qmail@joyce.lan> <515F0680.9010203@tana.it> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-2124793943-1365185337=:29920" Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 05 Apr 2013 18:08:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-2124793943-1365185337=:29920 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > BTW: Why messages in this list are not signed? Beats me. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-2124793943-1365185337=:29920 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDA1MTgwODU2WjAjBgkqhkiG 9w0BCQQxFgQU9yEA1R460uIeFajW+pBch7XiKJ4weQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAUq6ogJeUimus aAf3cw5N3hOX3HCzMgpOTPnWc/Be3BYJxpNJlAWBIMHzZr5K0yvq9o7E3hGD IuCM++OcR+lmCpNLPbtBJjrN6T3XS3MSgpbJEsxsmzn4COExgBWFwUfZlrU5 oLQLL8mvWDiwa5oeXAWYDE2Ks0m7rcPUwnCPRgqhQY6YBPJRsP11pmvofd+0 MXuf7AIMydvwszmKmHmQDhV4Q0aXvoTHkxrKDzyYNCCreysooC+bDJ8GHKwM i2GiU8PTFuKteSgmi3kHhWD0ZI4mQvE4e4SNfZoQTrOovFqWyi597HNZIBFb hHc1Op3fyvhf35ZwupHWIW9M8B/o7g== --3825401791-2124793943-1365185337=:29920-- From johnl@iecc.com Fri Apr 5 11:11:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CE921F9855 for ; Fri, 5 Apr 2013 11:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.997 X-Spam-Level: X-Spam-Status: No, score=-110.997 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9y7QMteCn9D for ; Fri, 5 Apr 2013 11:11:43 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 603F721F9844 for ; Fri, 5 Apr 2013 11:11:43 -0700 (PDT) Received: (qmail 35902 invoked from network); 5 Apr 2013 18:11:43 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 5 Apr 2013 18:11:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515f13de.xn--btvx9d.k1304; i=johnl@user.iecc.com; bh=3hjp8LcADdpXgWF3F9LuUJ7M1xb6RwOLbVXmIr35Nss=; b=CdJLe4FDI1LCL0bdQmpdxxMsheEgWliKin6f50eQqiWhgr6KqCudG64LNcyibDcw1Uiy66OX92y5xx9bwNR+XYRGHs8wN5EAr1/tmhGkJTKvAAR202CC2kZ/m0Hr5a3rcofh3DG1gQw1d9oQ1K7Dkuz2YSr/O/dG06S9T1hREgw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=515f13de.xn--btvx9d.k1304; olt=johnl@user.iecc.com; bh=3hjp8LcADdpXgWF3F9LuUJ7M1xb6RwOLbVXmIr35Nss=; b=mCFJP5ytWxSBDerLqMZ7NlhRJf/YQ6XZgtIJATeOutkhyt9MezDV2ft2LHYWswbDSoydHY2WrS8ztcqBK45Y8SKfpyBC2b0iTBWXqws6yNgRkF2miXkIiNrvCnjT0CxH+x1/0WjkSSvxgAJ3SZTk+kgxF3MKU346J/PoZXn2X/U= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 5 Apr 2013 18:11:20 -0000 Message-ID: <20130405181120.30162.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EB992A@ESV4-MBX01.linkedin.biz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: fmartin@linkedin.com Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 05 Apr 2013 18:11:44 -0000 >>Newbie's question (be patient): As I'm new to DMARC, perhaps I may >>ask why cannot a list manager or similar operator change the From: >>slightly? For the umpteenth time, because they have no incentive to do so. If DMARC is going to be successful, it has to work with the existing mail system. For the most part it does. The mailing list arguments are a tempest in a teapot and only arise because a few people wilfully publish inappropriate DMARC records. R's, John From vesely@tana.it Fri Apr 5 11:15:12 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27CAD21F9898 for ; Fri, 5 Apr 2013 11:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zrau-uXfSFIR for ; Fri, 5 Apr 2013 11:15:11 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40121F9896 for ; Fri, 5 Apr 2013 11:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365185694; bh=8oFeUd/aHzgg0Vcl8+lxYRRExBywUkc4bAwNB57U564=; l=1639; h=Date:From:To:References:In-Reply-To; b=g1dQVMUvFFXhUBRu4trgC3oJKZsVzGVX93Vx+ZCAlAaNNTGykwAQEVoBKpE4t4f29 P+Oan5o0XJENcbXbnmkMpjyYGa8a6nvF96kJTVqEec/QHWlJ8GushQSQkASbwtJkBT Af8NKIdlDBzO8eCeHPD3TrwhHNz5QKjOEE6JD18w= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 05 Apr 2013 20:14:54 +0200 id 00000000005DC045.00000000515F149E.00007257 Message-ID: <515F149E.3040900@tana.it> Date: Fri, 05 Apr 2013 20:14:54 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <77426B543150464AA3F30DF1A91365DE52EB992A@ESV4-MBX01.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EB992A@ESV4-MBX01.linkedin.biz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 05 Apr 2013 18:15:12 -0000 On Fri 05/Apr/2013 19:48:59 +0200 Franck Martin wrote: > On 4/5/13 10:14 AM, "Alessandro Vesely" wrote: >> >>Newbie's question (be patient): As I'm new to DMARC, perhaps I may >>ask why cannot a list manager or similar operator change the From: >>slightly? For this message, that would be: >> >>IN: >> From: Alessandro Vesely >> >>OUT: >> From: Alessandro Vesely (sent by ietf.org) > > What you describe if I'm not mistaken, is not a valid email syntax (or > deprecated one), but what your MUA present you with. > http://tools.ietf.org/html/rfc5322#section-3.4 mailbox syntax The trailing comment is the CFWS there. > The use of the Sender: header for DMARC as an identifier was not adopted > because it could be easily abused (cf systems like send this article to a > friend) and not all MUAs display it to the user (or in a meaningful way). Yup, for visibility. > However, and that's another topic your could do: > From: "Alessandro Vesely (via IETF)" > > Reply to: "DMARC List" > > > or > > From: "Alessandro Vesely (via IETF)" > Reply to: "DMARC List" , "Alessandro Vesely" > These were discussed various times, e.g. http://mipassoc.org/pipermail/dkim-dev/2009-September/000202.html > Note I also do not want to encourage people to put anything that looks > like an email address or domain in the friendly From part. Yeah, Thunderbird chokes a bit on that, placing a comma before the comment and displaying it as if it were an additional sender... From prvs=800a5e35e=fmartin@linkedin.com Fri Apr 5 11:58:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B611121F96C4 for ; Fri, 5 Apr 2013 11:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.937 X-Spam-Level: X-Spam-Status: No, score=-5.937 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA-R8VsAEnIM for ; Fri, 5 Apr 2013 11:58:47 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0E77D21F8F08 for ; Fri, 5 Apr 2013 11:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365188326; x=1396724326; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=o40Ds9XB6jlt/EatH80WNyBaBKpyCl/1SCiL9RdL5bE=; b=IzYh62/WzhoUCtk3J+5OKqUR83/ess1QPmJO7PN6si1aDdNaS6Vq+/fl rtWTgmso9MvnsLr5MyFtqLx/o6uV4bGTvwTnLM43GjTtM9ktCx1FNZxVe L74DDaMpMjiMLhbOdlSzn3T2kA9Cb9qzokA6FBDiKT6j80e0MwVj9v0bh 0=; X-IronPort-AV: E=Sophos;i="4.87,416,1363158000"; d="scan'208";a="43129424" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Fri, 5 Apr 2013 11:58:40 -0700 From: Franck Martin To: Alessandro Vesely , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] a newbie's question Thread-Index: AQHOMimHGgvh3Ggjt0OTMJFwSFGCH5jH+tMA Date: Fri, 5 Apr 2013 18:58:39 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EBA6E3@ESV4-MBX01.linkedin.biz> In-Reply-To: <515F149E.3040900@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="utf-8" Content-ID: <684B1341EEF4664E9C09A0A993056860@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 05 Apr 2013 18:58:47 -0000 DQoNCk9uIDQvNS8xMyAxMToxNCBBTSwgIkFsZXNzYW5kcm8gVmVzZWx5IiA8dmVzZWx5QHRhbmEu aXQ+IHdyb3RlOg0KDQo+T24gRnJpIDA1L0Fwci8yMDEzIDE5OjQ4OjU5ICswMjAwIEZyYW5jayBN YXJ0aW4gd3JvdGU6DQo+PiBPbiA0LzUvMTMgMTA6MTQgQU0sICJBbGVzc2FuZHJvIFZlc2VseSIg PHZlc2VseUB0YW5hLml0PiB3cm90ZToNCj4+Pg0KPj4+TmV3YmllJ3MgcXVlc3Rpb24gKGJlIHBh dGllbnQpOiAgQXMgSSdtIG5ldyB0byBETUFSQywgcGVyaGFwcyBJIG1heQ0KPj4+YXNrIHdoeSBj YW5ub3QgYSBsaXN0IG1hbmFnZXIgb3Igc2ltaWxhciBvcGVyYXRvciBjaGFuZ2UgdGhlIEZyb206 DQo+Pj5zbGlnaHRseT8gIEZvciB0aGlzIG1lc3NhZ2UsIHRoYXQgd291bGQgYmU6DQo+Pj4NCj4+ PklOOg0KPj4+ICAgRnJvbTogQWxlc3NhbmRybyBWZXNlbHkgPHZlc2VseUB0YW5hLml0Pg0KPj4+ DQo+Pj5PVVQ6DQo+Pj4gICBGcm9tOiBBbGVzc2FuZHJvIFZlc2VseSA8dmVzZWx5QHRhbmEuaXQ+ IChzZW50IGJ5IGlldGYub3JnKQ0KPj4gDQo+PiBXaGF0IHlvdSBkZXNjcmliZSBpZiBJJ20gbm90 IG1pc3Rha2VuLCBpcyBub3QgYSB2YWxpZCBlbWFpbCBzeW50YXggKG9yDQo+PiBkZXByZWNhdGVk IG9uZSksIGJ1dCB3aGF0IHlvdXIgTVVBIHByZXNlbnQgeW91IHdpdGguDQo+PiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1MzIyI3NlY3Rpb24tMy40IG1haWxib3ggc3ludGF4DQo+DQo+ VGhlIHRyYWlsaW5nIGNvbW1lbnQgaXMgdGhlIENGV1MgdGhlcmUuDQoNCkFoLCBBQk5GIGlzIHJl YWxseSBvYnNjdXJlIHRvIG1lLi4uIEkgd29yayBiZXR0ZXIgd2l0aCBleGFtcGxlcyBhbmQgSSBo YXZlDQpuZXZlciBzZWVuIHlvdXIgZXhhbXBsZSBpbiB1c2UuLi4gU29ycnkgZm9yIHRoYXQuDQoN Cg== From vesely@tana.it Sat Apr 6 03:40:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F61021F8D05 for ; Sat, 6 Apr 2013 03:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.419 X-Spam-Level: X-Spam-Status: No, score=-4.419 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eySc5LexMscI for ; Sat, 6 Apr 2013 03:40:36 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 73FCD21F8C26 for ; Sat, 6 Apr 2013 03:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365244833; bh=QsRRTSUGOOc09CUMTHEdL7fQb+66sHdaTAnJnA29QkE=; l=968; h=Date:From:To:References:In-Reply-To; b=puZEjO8nza+4USBQfY84/pOjKXRAWKe0pDlu5FyQ2SY2MMnrYi9ZHqVLqc2v4865+ /qdGxGXO4Tixcl2oJCzRr+2ggfgUNbirvDqt6ijeQ8GrZCNQf/BFHYFNyMZkHsB7ag 9/m3nfElCw/AK1f4i7nZNCQJhKisn2+EnoB8iRcs= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sat, 06 Apr 2013 12:40:33 +0200 id 00000000005DC039.00000000515FFBA1.00004A8C Message-ID: <515FFBA1.8000208@tana.it> Date: Sat, 06 Apr 2013 12:40:33 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130405181120.30162.qmail@joyce.lan> In-Reply-To: <20130405181120.30162.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Apr 2013 10:40:37 -0000 On Fri 05/Apr/2013 20:11:20 +0200 John Levine wrote: >>>Newbie's question (be patient): As I'm new to DMARC, perhaps I may >>>ask why cannot a list manager or similar operator change the From: >>>slightly? > > For the umpteenth time, because they have no incentive to do so. Thank you for your patience. Perhaps, DMARC consideration for such slight change (and let me underline _slight_) could be enough of an incentive for some mailing lists. For sure, we cannot expect that all of them suddenly change, considering that many don't even sign. > If DMARC is going to be successful, it has to work with the existing > mail system. For the most part it does. > > The mailing list arguments are a tempest in a teapot and only arise > because a few people wilfully publish inappropriate DMARC records. Right, but isn't that the same weakness as ADSP? Both protocols seem to be good at anti-phishing, but then they work for transactional mail only. From johnl@iecc.com Sat Apr 6 09:50:05 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411E521F8E96 for ; Sat, 6 Apr 2013 09:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.01 X-Spam-Level: X-Spam-Status: No, score=-111.01 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzVLdOx8cZ-N for ; Sat, 6 Apr 2013 09:50:04 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4550A21F8E66 for ; Sat, 6 Apr 2013 09:50:03 -0700 (PDT) Received: (qmail 67657 invoked from network); 6 Apr 2013 16:50:03 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Apr 2013 16:50:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5160523a.xn--i8sz2z.k1304; i=johnl@user.iecc.com; bh=mV0+c/jAnKEZLyMmoOmCJrVOz7W2CowaHxKK51upF+A=; b=h5WZmUjwR6G1/dDkQsMbUYjT0kGOwj4wEkKUC/+ER+s0/fkIdmjiwnP4/Ga9GjGgQ8U/bEIP8tQOyl6HxeHpxRjSDMFbQ/9j5cNqumeTgj0Wug8b/8ofQQXpizNoczRBlTNh2nFil8ZbnsVUM852lHMGeWfbec0ypNleGrhMZp8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5160523a.xn--i8sz2z.k1304; olt=johnl@user.iecc.com; bh=mV0+c/jAnKEZLyMmoOmCJrVOz7W2CowaHxKK51upF+A=; b=RqMHWgdkiCIU0HibOOaWY2jjnf1pxHdTW9TDyY7NVgvx/R03p/iwhZJtv4LCJK7u4tphyjPcfGI0dKTYOQ9vCREkpzmxzsuaicx4mbjx5+gigGTmfG7rxxfMBlHY1vm0ROqDW2Gfz4EiAK2VttQ0Tokg1S2UQtTgqCxSZrU/biI= Date: 6 Apr 2013 16:49:40 -0000 Message-ID: <20130406164940.43055.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <515FFBA1.8000208@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Apr 2013 16:50:05 -0000 >> The mailing list arguments are a tempest in a teapot and only arise >> because a few people wilfully publish inappropriate DMARC records. > >Right, but isn't that the same weakness as ADSP? Both protocols seem >to be good at anti-phishing, but then they work for transactional mail >only. DMARC and ADSP share many of the same issues, most notably that it is incredibly difficult to explain to people that a stricter policy is not necessarily "more secure" and that if your published policy does not match your real mailing practices, you will cause problems both for yourself and for recipient systems who (unwisely) believe what you say. From prvs=801fbfcc5=fmartin@linkedin.com Sat Apr 6 13:54:03 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8C21F8618 for ; Sat, 6 Apr 2013 13:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.974 X-Spam-Level: X-Spam-Status: No, score=-5.974 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIN7WK8LvcWn for ; Sat, 6 Apr 2013 13:54:02 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id EC76821F84CD for ; Sat, 6 Apr 2013 13:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365281636; x=1396817636; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=PgBOJjitp2MSGhD0/4A59C+NTi308ElMfqvwxHD2D44=; b=dNQNjB+mEAJ98NJ4dHnE8r8E6xrvy/ChnNBrENXQfPyWrCoz4NKVVDk5 p5CY65aHle/3+/NVjQUp/C1XskhQjPQY2ye2iTzoEA75XOWnrnknYtZOH 5KiQBAeabKe/g7xBsXBHXkHz1qGlWmuADcJCGDWLBzIugrmqGslzt5SQt A=; X-IronPort-AV: E=Sophos;i="4.87,421,1363158000"; d="scan'208";a="44411599" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Sat, 6 Apr 2013 13:53:50 -0700 From: Franck Martin To: Alessandro Vesely , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] not about outsourcing strategies, and a newbie's question Thread-Index: AQHOMrM0Ox+ucrlBNkOkBe6MGAJTlpjJrEiA Date: Sat, 6 Apr 2013 20:53:50 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EC14B3@ESV4-MBX01.linkedin.biz> In-Reply-To: <515FFBA1.8000208@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.251] Content-Type: text/plain; charset="utf-8" Content-ID: <0437C1A1C097E646BF2003F1E78A7ADF@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Apr 2013 20:54:03 -0000 DQpPbiA0LzYvMTMgMzo0MCBBTSwgIkFsZXNzYW5kcm8gVmVzZWx5IiA8dmVzZWx5QHRhbmEuaXQ+ IHdyb3RlOg0KDQo+T24gRnJpIDA1L0Fwci8yMDEzIDIwOjExOjIwICswMjAwIEpvaG4gTGV2aW5l IHdyb3RlOg0KPj4+Pk5ld2JpZSdzIHF1ZXN0aW9uIChiZSBwYXRpZW50KTogIEFzIEknbSBuZXcg dG8gRE1BUkMsIHBlcmhhcHMgSSBtYXkNCj4+Pj5hc2sgd2h5IGNhbm5vdCBhIGxpc3QgbWFuYWdl ciBvciBzaW1pbGFyIG9wZXJhdG9yIGNoYW5nZSB0aGUgRnJvbToNCj4+Pj5zbGlnaHRseT8NCj4+ IA0KPj4gRm9yIHRoZSB1bXB0ZWVudGggdGltZSwgYmVjYXVzZSB0aGV5IGhhdmUgbm8gaW5jZW50 aXZlIHRvIGRvIHNvLg0KPg0KPlRoYW5rIHlvdSBmb3IgeW91ciBwYXRpZW5jZS4gIFBlcmhhcHMs IERNQVJDIGNvbnNpZGVyYXRpb24gZm9yIHN1Y2gNCj5zbGlnaHQgY2hhbmdlIChhbmQgbGV0IG1l IHVuZGVybGluZSBfc2xpZ2h0XykgY291bGQgYmUgZW5vdWdoIG9mIGFuDQo+aW5jZW50aXZlIGZv ciBzb21lIG1haWxpbmcgbGlzdHMuICBGb3Igc3VyZSwgd2UgY2Fubm90IGV4cGVjdCB0aGF0IGFs bA0KPm9mIHRoZW0gc3VkZGVubHkgY2hhbmdlLCBjb25zaWRlcmluZyB0aGF0IG1hbnkgZG9uJ3Qg ZXZlbiBzaWduLg0KDQpXaGF0IERNQVJDIHN0aWxsIHN1ZmZlcnMgZnJvbSBpcyB0b29scy4gVGhl IGNvbW11bml0eSBoYXMgYmVlbiB3b3JraW5nIG9uDQpzb21lLiBZb3Uga25vdyB0aGUgc2F5aW5n IHBlb3BsZSBzY3JhdGNoIHRoZWlyIG93biBpdGNoLiBvcGVuZG1hcmMgaXMNCnJlbGVhc2VkLCBj YW4gYmUgdXNlZCBpbiBwcm9kdWN0aW9uLCBidXQgaXQgaXMganVzdCBub3cgdGhhdCB5b3UgaGF2 ZSBhDQpwYWNrYWdlIHRvIGluc3RhbGwgaXQgcmVsYXRpdmVseSBlYXNpbHkgb24gVWJ1bnR1LiBJ IGhhdmUgaGVhcmQgb2YgUlBNcywNCmJ1dCBvcGVuZG1hcmMgaXMgc3RpbGwgaGFyZCB0byBpbnN0 YWxsLiBJdCB3aWxsIGNvbWUgd2hlbiBpdCBpcyBzaGlwcGVkIGJ5DQpkZWZhdWx0IGluIGxpbnV4 IGRpc3RybyByZWxlYXNlcy4NCg0KU2FtZSBmb3IgbWFpbGluZyBsaXN0cywgdGhlIGlzc3VlIGlz IG5vdCBuZXcNCihodHRwOi8vd2lraS5saXN0Lm9yZy9kaXNwbGF5L0RFVi9ES0lNKSwgYnV0IHRo ZSBwZW9wbGUgaW52b2x2ZWQgaW4NCmRldmVsb3Bpbmcgc2F5IG1haWxtYW4sIGFyZSBmb2N1c2lu ZyBvbiBzb21lIG90aGVyIG1vcmUgaW1wb3J0YW50IHBhcnRzLA0KbGlrZSByZWxlYXNpbmcgMy4w LiBTbyB1bnRpbCB0aGVyZSBhcmUgb3B0aW9ucyBhdmFpbGFibGUsIGluIGEgbWFpbGluZw0KbGlz dCBzb2Z0d2FyZSwgd2Ugd29uJ3Qga25vdyBpZiBvcGVyYXRvcnMgd291bGQgbWFrZSB0aGlzIGNo YW5nZSBvciBub3QsDQphdCB0aGUgbW9tZW50IHRoZXkgY2Fubm90LiBHcmFudGVkIHRoZXJlIGlz IG5vIGluY2VudGl2ZSwgYnV0IGlzIGl0DQpiZWNhdXNlIGxpa2Ugd2hlbiBJIHRhbGsgdG8gdGhp cmQgcGFydGllcyBtYWlsZXJzIHdobyB3b3VsZCBsaWtlIHRvIGRvDQpidXNpbmVzcyB3aXRoIHVz LCB0aGV5IG1vc3RseSBoYXZlIG5ldmVyIGhlYXJkIG9mIERNQVJDPw0KDQpUaGVyZSBpcyBhIHBh dGNoIGZvciBtYWlsbWFuIDIuMSwgeW91IGNhbiB0cnkgaXQNCmh0dHBzOi8vY29kZS5sYXVuY2hw YWQubmV0L35tbG0tYXV0aG9yL21haWxtYW4vMi4xLWF1dGhvcg0KDQpJIGhhdmUgbm90IGhhZCB0 aGUgdGltZSB0byBwdXNoIGl0IGludG8gMy4wLCB2b2x1bnRlZXJzPw0KDQo+DQo+PiBJZiBETUFS QyBpcyBnb2luZyB0byBiZSBzdWNjZXNzZnVsLCBpdCBoYXMgdG8gd29yayB3aXRoIHRoZSBleGlz dGluZw0KPj4gbWFpbCBzeXN0ZW0uICBGb3IgdGhlIG1vc3QgcGFydCBpdCBkb2VzLg0KPj4gDQo+ PiBUaGUgbWFpbGluZyBsaXN0IGFyZ3VtZW50cyBhcmUgYSB0ZW1wZXN0IGluIGEgdGVhcG90IGFu ZCBvbmx5IGFyaXNlDQo+PiBiZWNhdXNlIGEgZmV3IHBlb3BsZSB3aWxmdWxseSBwdWJsaXNoIGlu YXBwcm9wcmlhdGUgRE1BUkMgcmVjb3Jkcy4NCj4NCj5SaWdodCwgYnV0IGlzbid0IHRoYXQgdGhl IHNhbWUgd2Vha25lc3MgYXMgQURTUD8gIEJvdGggcHJvdG9jb2xzIHNlZW0NCj50byBiZSBnb29k IGF0IGFudGktcGhpc2hpbmcsIGJ1dCB0aGVuIHRoZXkgd29yayBmb3IgdHJhbnNhY3Rpb25hbCBt YWlsDQo+b25seS4NCg0KRXZlbiB3aXRoIHRyYW5zYWN0aW9uYWwgZW1haWxzIHRoZXJlIGFyZSBp c3N1ZXM6DQpodHRwOi8vd3d3Lml0LmNvcm5lbGwuZWR1L3NlcnZpY2VzL2NtYWlsL2hvd3RvL3Nw b29mLmNmbQ0KVGhpcyBzcGVjaWZpYyBwcm9ibGVtIGhhcyBub3QgeWV0IGJlZW4gYWRkcmVzc2Vk LCBpdCBpcyBxdWl0ZSB0eXBpY2FsIGluDQpkb3QgZWR1IG9yZ2FuaXphdGlvbnMsIGJ1dCBJIGhh dmUgc2VlbiBwZW9wbGUgYmVpbmcgbW9yZSBhbmQgbW9yZSBtaW5kZnVsDQphYm91dCBpdCwgYmVj YXVzZSBub3cgaXQgaXMgbm90IGFueW1vcmUgb25lIG9kZCB1c2VyLCBhbmQgSSBoYXZlIHNlZW4N CnN5c3RlbSBjaGFuZ2VzIHRvIGF2b2lkIHRoYXQgZm9yd2FyZGluZyBicmVha3MgREtJTS4NCg0K SSBjYW5ub3QgZmluZCBhbnkgYXJ0aWNsZSBkZXNjcmliaW5nIGNvbmRpdGlvbnMgd2hlbiBFeGNo YW5nZSBicmVhay9kb24ndA0KYnJlYWsgREtJTSB3aGVuIGZvcndhcmRpbmcuLi4gSWYgc29tZW9u ZSBoYXMgYSBwb2ludGVyPw0KDQo= From johnl@iecc.com Sat Apr 6 14:34:56 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A9421F892D for ; Sat, 6 Apr 2013 14:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.422 X-Spam-Level: X-Spam-Status: No, score=-110.422 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feUlnJfMUUZG for ; Sat, 6 Apr 2013 14:34:56 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EBA9C21F8867 for ; Sat, 6 Apr 2013 14:34:55 -0700 (PDT) Received: (qmail 59340 invoked from network); 6 Apr 2013 21:34:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Apr 2013 21:34:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516094ff.xn--i8sz2z.k1304; i=johnl@user.iecc.com; bh=oLDWh+Kqgq+pfV70W7kjanmHr75A5Rw5cdp1uGLJ03A=; b=ldPLxjToUOIxlwWimROqtBIyTXClt6hKDOjvPneur6Yl5bBXMTxD6MgvsaAuWEDtGDqLmTvPMjuZvQcuTMXosts3I2nJTrzGqK3b/+76e1z6M6KPI3jVYflrVvNkcKJZxY7CcYF6spH41zUYT4GG5HXv0KvkoL+6H0YG/MrbnBI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516094ff.xn--i8sz2z.k1304; olt=johnl@user.iecc.com; bh=oLDWh+Kqgq+pfV70W7kjanmHr75A5Rw5cdp1uGLJ03A=; b=fSJFbdUE4F8ucd5LP5F0R8Oy66ZivEWfJNXHJyHmyfmetzwR727jb0b6QirY98+PSSC2eJllNpeyR3Rd/Of4ooImDeV2sEkO9m4+/hAEZ5vsf9JPzWUA1QAZv06s/deFzXKRvkNdsXdSgiumg71owyBXhxBClw6zb+SDWyxapVQ= Date: 6 Apr 2013 21:34:32 -0000 Message-ID: <20130406213432.74072.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EC14B3@ESV4-MBX01.linkedin.biz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: fmartin@linkedin.com Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Apr 2013 21:34:57 -0000 >Authentication-Results: iecc.com / 1; spf=pass spf.mailfrom=dmarc-bounces@ietf.org spf.helo=mail.ietf.org; >dkim=fail (bad signature) header.d=linkedin.com header.b="dNQNjB+m"; dmarc=fail.reject >header.from=linkedin.com >What DMARC still suffers from is tools. Well, that, and some serious education for mail system operators about what is or isn't appropriate in their DMARC assertions. If I actually implemented DMARC according to the spec, Linkedin's incorrect policy assertions would bounce me off the list. They know this and refuse to fix it, or even to admit the problems they're causing. It isn't a big problem now, since the overall adoption of DMARC is still relatively low, but it could be a significant problem in the future if it's widely used. >Same for mailing lists, the issue is not new >(http://wiki.list.org/display/DEV/DKIM), but the people involved in >developing say mailman, are focusing on some other more important parts, For the zillionth time, there is no chance whatsoever that Mailman and other open source list managers will change to work around DMARC's limitations. I wish people would stop wasting time by claiming otherwise. (The most they would plausibly do is a simple hack to prevent damage to the rest of their users by refusing mail from senders with policies other than p=none, which is easy to do with a shim between the incoming MDA and the list manager.) List software didn't change for SPF, they didn't change for DKIM ADSP, and they're not going to change for DMARC. This is not a bug or flaw in mailing lists, it's a limitation in DMARC that we have to be sure to document as clearly as possible and see if we can somehow persuade people to publish accurate policy statements. R's, John From prvs=801fbfcc5=fmartin@linkedin.com Sat Apr 6 14:53:26 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B24121F8867 for ; Sat, 6 Apr 2013 14:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.403 X-Spam-Level: X-Spam-Status: No, score=-5.403 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3ZjQfjBxBSe for ; Sat, 6 Apr 2013 14:53:04 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id B4AB321F869C for ; Sat, 6 Apr 2013 14:53:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365285184; x=1396821184; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=R7cJncuRrjQf/GUbAAlYp5XTEZ4k54hdUk6zLLwrbrQ=; b=0F0xWmW2CXmb7JAl+KM6I3QWogS21NjPrXd1YU4Uvjv72oqZ7reVz3v1 Iewa9uYGg1RVXz5kbpmlkKF5ZxPAOB8b/1fN5lmD3+j+/of6+kkMvQWRL npFd1t8s07n8ojBXX3a+mbSI5Py9lu6Nb+GNkcuj4gSKPoN176CzDjNFn w=; X-IronPort-AV: E=Sophos;i="4.87,421,1363158000"; d="scan'208";a="43199124" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Sat, 6 Apr 2013 14:52:58 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Sat, 6 Apr 2013 14:52:58 -0700 From: Franck Martin To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] not about outsourcing strategies, and a newbie's question Thread-Index: AQHOMrM0Ox+ucrlBNkOkBe6MGAJTlpjJrEiAgACAtwD//4/KgA== Date: Sat, 6 Apr 2013 21:52:55 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EC1788@ESV4-MBX01.linkedin.biz> In-Reply-To: <20130406213432.74072.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: text/plain; charset="utf-8" Content-ID: <19EFDD4B68984D44B53129AA80A97855@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Apr 2013 21:53:26 -0000 QnV0IHlvdSBnb3QgdGhpcyBlbWFpbCwgSSBkb24ndCBzZWUgd2hlcmUgaXMgdGhlIHByb2JsZW0u IDpQDQoNCkkgdGhpbmsgd2Ugd2lsbCBhZ3JlZSB0byBkaXNhZ3JlZS4NCg0KT24gNC82LzEzIDI6 MzQgUE0sICJKb2huIExldmluZSIgPGpvaG5sQHRhdWdoLmNvbT4gd3JvdGU6DQoNCj4+QXV0aGVu dGljYXRpb24tUmVzdWx0czogaWVjYy5jb20gLyAxOyBzcGY9cGFzcw0KPj5zcGYubWFpbGZyb209 ZG1hcmMtYm91bmNlc0BpZXRmLm9yZyBzcGYuaGVsbz1tYWlsLmlldGYub3JnOw0KPj5ka2ltPWZh aWwgKGJhZCBzaWduYXR1cmUpIGhlYWRlci5kPWxpbmtlZGluLmNvbSBoZWFkZXIuYj0iZE5RTmpC K20iOw0KPj5kbWFyYz1mYWlsLnJlamVjdA0KPj5oZWFkZXIuZnJvbT1saW5rZWRpbi5jb20NCj4N Cj4+V2hhdCBETUFSQyBzdGlsbCBzdWZmZXJzIGZyb20gaXMgdG9vbHMuDQo+DQo+V2VsbCwgdGhh dCwgYW5kIHNvbWUgc2VyaW91cyBlZHVjYXRpb24gZm9yIG1haWwgc3lzdGVtIG9wZXJhdG9ycyBh Ym91dA0KPndoYXQgaXMgb3IgaXNuJ3QgYXBwcm9wcmlhdGUgaW4gdGhlaXIgRE1BUkMgYXNzZXJ0 aW9ucy4NCj4NCj5JZiBJIGFjdHVhbGx5IGltcGxlbWVudGVkIERNQVJDIGFjY29yZGluZyB0byB0 aGUgc3BlYywgTGlua2VkaW4ncw0KPmluY29ycmVjdCBwb2xpY3kgYXNzZXJ0aW9ucyB3b3VsZCBi b3VuY2UgbWUgb2ZmIHRoZSBsaXN0LiAgVGhleSBrbm93DQo+dGhpcyBhbmQgcmVmdXNlIHRvIGZp eCBpdCwgb3IgZXZlbiB0byBhZG1pdCB0aGUgcHJvYmxlbXMgdGhleSdyZQ0KPmNhdXNpbmcuICBJ dCBpc24ndCBhIGJpZyBwcm9ibGVtIG5vdywgc2luY2UgdGhlIG92ZXJhbGwgYWRvcHRpb24gb2YN Cj5ETUFSQyBpcyBzdGlsbCByZWxhdGl2ZWx5IGxvdywgYnV0IGl0IGNvdWxkIGJlIGEgc2lnbmlm aWNhbnQgcHJvYmxlbQ0KPmluIHRoZSBmdXR1cmUgaWYgaXQncyB3aWRlbHkgdXNlZC4NCj4NCj4+ U2FtZSBmb3IgbWFpbGluZyBsaXN0cywgdGhlIGlzc3VlIGlzIG5vdCBuZXcNCj4+KGh0dHA6Ly93 aWtpLmxpc3Qub3JnL2Rpc3BsYXkvREVWL0RLSU0pLCBidXQgdGhlIHBlb3BsZSBpbnZvbHZlZCBp bg0KPj5kZXZlbG9waW5nIHNheSBtYWlsbWFuLCBhcmUgZm9jdXNpbmcgb24gc29tZSBvdGhlciBt b3JlIGltcG9ydGFudCBwYXJ0cywNCj4NCj5Gb3IgdGhlIHppbGxpb250aCB0aW1lLCB0aGVyZSBp cyBubyBjaGFuY2Ugd2hhdHNvZXZlciB0aGF0IE1haWxtYW4gYW5kDQo+b3RoZXIgb3BlbiBzb3Vy Y2UgbGlzdCBtYW5hZ2VycyB3aWxsIGNoYW5nZSB0byB3b3JrIGFyb3VuZCBETUFSQydzDQo+bGlt aXRhdGlvbnMuICBJIHdpc2ggcGVvcGxlIHdvdWxkIHN0b3Agd2FzdGluZyB0aW1lIGJ5IGNsYWlt aW5nDQo+b3RoZXJ3aXNlLiAgKFRoZSBtb3N0IHRoZXkgd291bGQgcGxhdXNpYmx5IGRvIGlzIGEg c2ltcGxlIGhhY2sgdG8NCj5wcmV2ZW50IGRhbWFnZSB0byB0aGUgcmVzdCBvZiB0aGVpciB1c2Vy cyBieSByZWZ1c2luZyBtYWlsIGZyb20NCj5zZW5kZXJzIHdpdGggcG9saWNpZXMgb3RoZXIgdGhh biBwPW5vbmUsIHdoaWNoIGlzIGVhc3kgdG8gZG8gd2l0aCBhDQo+c2hpbSBiZXR3ZWVuIHRoZSBp bmNvbWluZyBNREEgYW5kIHRoZSBsaXN0IG1hbmFnZXIuKQ0KPg0KPkxpc3Qgc29mdHdhcmUgZGlk bid0IGNoYW5nZSBmb3IgU1BGLCB0aGV5IGRpZG4ndCBjaGFuZ2UgZm9yIERLSU0gQURTUCwNCj5h bmQgdGhleSdyZSBub3QgZ29pbmcgdG8gY2hhbmdlIGZvciBETUFSQy4gIFRoaXMgaXMgbm90IGEg YnVnIG9yIGZsYXcNCj5pbiBtYWlsaW5nIGxpc3RzLCBpdCdzIGEgbGltaXRhdGlvbiBpbiBETUFS QyB0aGF0IHdlIGhhdmUgdG8gYmUgc3VyZQ0KPnRvIGRvY3VtZW50IGFzIGNsZWFybHkgYXMgcG9z c2libGUgYW5kIHNlZSBpZiB3ZSBjYW4gc29tZWhvdyBwZXJzdWFkZQ0KPnBlb3BsZSB0byBwdWJs aXNoIGFjY3VyYXRlIHBvbGljeSBzdGF0ZW1lbnRzLg0KDQo= From johnl@iecc.com Sat Apr 6 15:24:22 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E2E21F84EF for ; Sat, 6 Apr 2013 15:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.997 X-Spam-Level: X-Spam-Status: No, score=-110.997 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93BTU1CmXQyY for ; Sat, 6 Apr 2013 15:24:22 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B61F821F84D6 for ; Sat, 6 Apr 2013 15:24:21 -0700 (PDT) Received: (qmail 72274 invoked from network); 6 Apr 2013 22:24:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 6 Apr 2013 22:24:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5160a095.xn--yuvv84g.k1304; i=johnl@user.iecc.com; bh=B6hxDQamC0pgrxtTteSQ1vvC4i+ZgRcDFlo4VO4APNU=; b=G+onTTCm/pjWx1pJtFKUBBpsHKXIyqX9l2leB499IWFmq/FqQAxhmh1vs0l8FALUvx4NNte5hQBXQfU6IBW/DzqgZWaKwIxuXH+h2pli5z27Cc2AcSh2zZndEOZp/1RsemP7uvOY9K+38fUn5AMPDa/WDtUzJxx2sUsgHMqvmWc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5160a095.xn--yuvv84g.k1304; olt=johnl@user.iecc.com; bh=B6hxDQamC0pgrxtTteSQ1vvC4i+ZgRcDFlo4VO4APNU=; b=pVs4Q3za7Sf0ytCgABNALI0odza5JRvgRrCHSqR9li6pzk3BWG4nJkUQUGuzA9/eiJ4xsgPvXFQBO/rZk53y6un7hEh+IAfEU6h/GK80qEE5EfMoq7qaFoiJzPHAydceAcAHInZGqqNglOkiHIrwCnqxsSYnWnTjOVOsshs8Qa0= Date: 6 Apr 2013 22:23:58 -0000 Message-ID: <20130406222358.82898.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EC1788@ESV4-MBX01.linkedin.biz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: fmartin@linkedin.com Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Apr 2013 22:24:22 -0000 >>If I actually implemented DMARC according to the spec, Linkedin's >>incorrect policy assertions would bounce me off the list. They know >>this and refuse to fix it, or even to admit the problems they're >>causing. It isn't a big problem now, since the overall adoption of >>DMARC is still relatively low, but it could be a significant problem >>in the future if it's widely used. >But you got this email, I don't see where is the problem. :P Sigh. My point exactly. R's, John From jgomez@seryrich.com Sat Apr 6 16:25:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D55921F8DCF for ; Sat, 6 Apr 2013 16:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85nBBJiqTfAI for ; Sat, 6 Apr 2013 16:25:06 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id A2BBD21F8700 for ; Sat, 6 Apr 2013 16:25:04 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 7 Apr 2013 01:25:02 +0200 Message-ID: <3BA3E5A21E4A4DA880384707233C4FE1@fgsr.local> From: "J. Gomez" To: References: <20130405181120.30162.qmail@joyce.lan> Date: Sun, 7 Apr 2013 01:26:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Apr 2013 23:25:06 -0000 On Friday, April 05, 2013 8:11 PM [GMT+1=3DCET], John Levine wrote: > > > Newbie's question (be patient): As I'm new to DMARC, perhaps I > > > may ask why cannot a list manager or similar operator change the > > > From: slightly? >=20 > For the umpteenth time, because they have no incentive to do so. >=20 > If DMARC is going to be successful, it has to work with the existing > mail system. For the most part it does. >=20 > The mailing list arguments are a tempest in a teapot and only arise > because a few people wilfully publish inappropriate DMARC records. If DMARC is going to be successful, it will be so when you can implement = "p=3Dreject", which is not compatible with the current state of the art = in mailing list software and common behaviour. If you cannot, as a sender, annouce "p=3Dreject" for DMARC, then DMARC = is not going to help you much as a sender, except for its reporting = capabilities. Regards, J. Gomez From jgomez@seryrich.com Sat Apr 6 16:45:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4A521F8D8E for ; Sat, 6 Apr 2013 16:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTaDGVvMEHsl for ; Sat, 6 Apr 2013 16:45:20 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 3279921F8AF0 for ; Sat, 6 Apr 2013 16:45:20 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 7 Apr 2013 01:45:18 +0200 Message-ID: From: "J. Gomez" To: References: <77426B543150464AA3F30DF1A91365DE52EC14B3@ESV4-MBX01.linkedin.biz> Date: Sun, 7 Apr 2013 01:46:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 06 Apr 2013 23:45:21 -0000 On Saturday, April 06, 2013 10:53 PM [GMT+1=3DCET], Franck Martin wrote: > I cannot find any article describing conditions when Exchange > break/don't break DKIM when forwarding... If someone has a pointer? Microsoft Exchange most definetly breaks DKIM (*) in already received = email messages. Microsoft Exchange stores the received messages in it's = own proprietary TNEF format, wich you can only access through MAPI, = which prety much means only through Outlook. If you access the messages = in an Exchange mailbox through POP3 or IMAP, you get a "translation" = on-the-fly of the body of the message done by Exchange from its internal = TNEF format to "whatever" (**) (***). (*) That happens for sure when a message lands in an Exchange mailbox. = But I can not say about a pure forwarding scenario where the forwarded = message does not land into a Exchange mailbox. (**) "Whatever" by default is "BestBodyFormat", which means Exchange = will present you with an aproximation to the orginal content of the = message when it serves the message to you through POP3 or IMAP. See: = http://esupport.lenovo.com/mss/mss.pl?doctype=3Dkb&docid=3DOTQ0MTUz https://groups.google.com/forum/?fromgroups=3D#!topic/WAGIT/D16Yygt4xmo http://forums.mozillazine.org/viewtopic.php?f=3D39&t=3D628678 (***) This "translation" is a modification of the message and therefore = obviously breaks the DKIM signature. Regards,=20 J. Gomez From jgomez@seryrich.com Sat Apr 6 17:03:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B8821F8B96 for ; Sat, 6 Apr 2013 17:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2NCvoGifa9a for ; Sat, 6 Apr 2013 17:03:01 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 1896C21F8B64 for ; Sat, 6 Apr 2013 17:03:01 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 7 Apr 2013 02:02:59 +0200 Message-ID: <4ED3405772FA4FA3B3E8CFA8D720D72D@fgsr.local> From: "J. Gomez" To: References: <20130406213432.74072.qmail@joyce.lan> Date: Sun, 7 Apr 2013 02:04:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 00:03:02 -0000 On Saturday, April 06, 2013 11:34 PM [GMT+1=3DCET], John Levine wrote: > For the zillionth time, there is no chance whatsoever that Mailman and > other open source list managers will change to work around DMARC's > limitations. I wish people would stop wasting time by claiming > otherwise. Is this assetion based on the comtemplation of some magic cristal ball = for the future? If the major mailbox providers (Hotmail, Gmail, Yahoo, AOL, etc.) = implement DMARC to the tee, mailing list software will either change to = be compatible with DMARC or die. I bet that if the major mailbox providers implement DMARC to the tee, = mailing list software will change to become compatible with DMARC. The other option is DMARC does not gain traction, and/or it is = implemented in the real world with receivers ignoring the "p=3Dreject" = policy, which would mean DMARC would become mostly useless. For example, mailing list software could change the RFC5322.From header = from: From: John Smith to become: =20 From: Mailman on behalf of John Smith and then the organizational domain foo.com would sign with DKIM the = outgoing message forwarded to the list's subscribers and relay it = through a "foo.com" SPF-authorized smarthost. That would make that = mailing list message fully DMARC compatible. Will mailing list sofware go through all this trouble? Nobody knows, but = if DMARC becomes an industry standard, it may well be the case. Regards, J. Gomez From johnl@iecc.com Sat Apr 6 18:06:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4608A21F87C5 for ; Sat, 6 Apr 2013 18:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.008 X-Spam-Level: X-Spam-Status: No, score=-111.008 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zghF3Nabz9CL for ; Sat, 6 Apr 2013 18:06:13 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABAD21F86C9 for ; Sat, 6 Apr 2013 18:06:13 -0700 (PDT) Received: (qmail 9143 invoked from network); 7 Apr 2013 01:06:12 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Apr 2013 01:06:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5160c684.xn--30v786c.k1304; i=johnl@user.iecc.com; bh=b9+uycELgYiDvJkwLc/2qo3vgn8P6WDVGQ0J3uuQ7Tk=; b=IiC3Lil4/5GMNuj1iY7unIh0oHIBFFs9q6NU4yYwTU64xhcykONMBtMJOHVMmj6+ip0tDhpFEPngoyJFQ4NVDMWZA3O9kA0Cf1pc5HE9eobQIQQX0S0Gi5dL46kEHvvubto3n7kobdMejLUSYnFtIBqmB9loCyOz/GyllAsi/C8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5160c684.xn--30v786c.k1304; olt=johnl@user.iecc.com; bh=b9+uycELgYiDvJkwLc/2qo3vgn8P6WDVGQ0J3uuQ7Tk=; b=se+j7YKk+ow5ENmMJhlllTeiUtNCFKtzJ7PKzpKL0uZezvol+Pkk49m2E1Dhujx5s0mlcBrzngs1LtxY9KYPecFwVL9iMiXZFhZpQa5a+InYyyKaIcIJLPYDgfzUWj0WvMmS7okjtppYwM4cJAq8Bo40gQQpKcF11kxPM6RYa90= Date: 7 Apr 2013 01:05:48 -0000 Message-ID: <20130407010548.38641.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <4ED3405772FA4FA3B3E8CFA8D720D72D@fgsr.local> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: jgomez@seryrich.com Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 01:06:14 -0000 >> For the zillionth time, there is no chance whatsoever that Mailman and >> other open source list managers will change to work around DMARC's >> limitations. I wish people would stop wasting time by claiming >> otherwise. > >Is this assetion based on the comtemplation of some magic cristal ball for the future? No, it's based on having run mailing lists for several decades, switching among too many list management packages. I run about 100 lists, of which about 30 have an interesting amount of traffic. Just for reference, have you ever run a mailing list? How many list management systems are you familiar with? R's, John From superuser@gmail.com Sun Apr 7 10:29:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D64021F8B08 for ; Sun, 7 Apr 2013 10:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAtBnTm5Kh71 for ; Sun, 7 Apr 2013 10:29:18 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB3121F8916 for ; Sun, 7 Apr 2013 10:29:18 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b12so5025335wgh.6 for ; Sun, 07 Apr 2013 10:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=S8sFUP9sInZiL7gSZqnaR56YXKrVlNvv4TQdjCwaRUM=; b=ryn1jmaZiIgqAIqsUcYs+Yyjex6qblOMK+vgdC7S/9Usa4K1GBn6zzYr3ieDtG61Zs HOmJgFKz/VJWca/+nF/YE2v/Cda7NgY5/5N5uN4F6u/Jdn6VT+eLpg2rlgjQpT7kcFqE 69i3NntHrrg37JetypD+IWbL2G6ZLWksb4DoE0lgWZv7qJ9938mnHN+dZiB6y+pzAAYi YVGt4hN5R789KLvDfebyN7yZVCCViPOALsyYElsEOdTCgNzlSEmMMJR26ANNY42fg5Lv xoCaWayq/MGDOvcbdyDpPHpJgyiFSsvLASjTMhw7zLtDspjG0HjS67SwyOEJXD5Sk1xq qvWQ== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr27133246wjb.17.1365355757586; Sun, 07 Apr 2013 10:29:17 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sun, 7 Apr 2013 10:29:17 -0700 (PDT) In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EC14B3@ESV4-MBX01.linkedin.biz> References: <515FFBA1.8000208@tana.it> <77426B543150464AA3F30DF1A91365DE52EC14B3@ESV4-MBX01.linkedin.biz> Date: Sun, 7 Apr 2013 10:29:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=047d7b5d8cffec4e3704d9c8a8b0 Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 17:29:20 -0000 --047d7b5d8cffec4e3704d9c8a8b0 Content-Type: text/plain; charset=ISO-8859-1 This is the first I've heard someone say OpenDMARC is hard to install. So far the feedback has been the opposite. I invite you to the opendmarc-users list to describe your experience and suggest ways to improve it. On Sat, Apr 6, 2013 at 1:53 PM, Franck Martin wrote: > > On 4/6/13 3:40 AM, "Alessandro Vesely" wrote: > > >On Fri 05/Apr/2013 20:11:20 +0200 John Levine wrote: > >>>>Newbie's question (be patient): As I'm new to DMARC, perhaps I may > >>>>ask why cannot a list manager or similar operator change the From: > >>>>slightly? > >> > >> For the umpteenth time, because they have no incentive to do so. > > > >Thank you for your patience. Perhaps, DMARC consideration for such > >slight change (and let me underline _slight_) could be enough of an > >incentive for some mailing lists. For sure, we cannot expect that all > >of them suddenly change, considering that many don't even sign. > > What DMARC still suffers from is tools. The community has been working on > some. You know the saying people scratch their own itch. opendmarc is > released, can be used in production, but it is just now that you have a > package to install it relatively easily on Ubuntu. I have heard of RPMs, > but opendmarc is still hard to install. It will come when it is shipped by > default in linux distro releases. > > Same for mailing lists, the issue is not new > (http://wiki.list.org/display/DEV/DKIM), but the people involved in > developing say mailman, are focusing on some other more important parts, > like releasing 3.0. So until there are options available, in a mailing > list software, we won't know if operators would make this change or not, > at the moment they cannot. Granted there is no incentive, but is it > because like when I talk to third parties mailers who would like to do > business with us, they mostly have never heard of DMARC? > > There is a patch for mailman 2.1, you can try it > https://code.launchpad.net/~mlm-author/mailman/2.1-author > > I have not had the time to push it into 3.0, volunteers? > > > > >> If DMARC is going to be successful, it has to work with the existing > >> mail system. For the most part it does. > >> > >> The mailing list arguments are a tempest in a teapot and only arise > >> because a few people wilfully publish inappropriate DMARC records. > > > >Right, but isn't that the same weakness as ADSP? Both protocols seem > >to be good at anti-phishing, but then they work for transactional mail > >only. > > Even with transactional emails there are issues: > http://www.it.cornell.edu/services/cmail/howto/spoof.cfm > This specific problem has not yet been addressed, it is quite typical in > dot edu organizations, but I have seen people being more and more mindful > about it, because now it is not anymore one odd user, and I have seen > system changes to avoid that forwarding breaks DKIM. > > I cannot find any article describing conditions when Exchange break/don't > break DKIM when forwarding... If someone has a pointer? > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7b5d8cffec4e3704d9c8a8b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is the first I've heard someone say OpenDMARC is = hard to install.=A0 So far the feedback has been the opposite.

I inv= ite you to the opendmarc-users list to describe your experience and suggest= ways to improve it.


On Sat,= Apr 6, 2013 at 1:53 PM, Franck Martin <fmartin@linkedin.com> wrote:

On 4/6/13 3:40 AM, "Alessandro Vesely" <vesely@tana.it> wrote:

>On Fri 05/Apr/2013 20:11:20 +0200 John Levine wrote:
>>>>Newbie's question (be patient): =A0As I'm new to DM= ARC, perhaps I may
>>>>ask why cannot a list manager or similar operator change th= e From:
>>>>slightly?
>>
>> For the umpteenth time, because they have no incentive to do so. >
>Thank you for your patience. =A0Perhaps, DMARC consideration for such >slight change (and let me underline _slight_) could be enough of an
>incentive for some mailing lists. =A0For sure, we cannot expect that al= l
>of them suddenly change, considering that many don't even sign.

What DMARC still suffers from is tools. The community has been workin= g on
some. You know the saying people scratch their own itch. opendmarc is
released, can be used in production, but it is just now that you have a
package to install it relatively easily on Ubuntu. I have heard of RPMs, but opendmarc is still hard to install. It will come when it is shipped by<= br> default in linux distro releases.

Same for mailing lists, the issue is not new
(http:/= /wiki.list.org/display/DEV/DKIM), but the people involved in
developing say mailman, are focusing on some other more important parts, like releasing 3.0. So until there are options available, in a mailing
list software, we won't know if operators would make this change or not= ,
at the moment they cannot. Granted there is no incentive, but is it
because like when I talk to third parties mailers who would like to do
business with us, they mostly have never heard of DMARC?

There is a patch for mailman 2.1, you can try it
https://code.launchpad.net/~mlm-author/mailman/2.1-author<= br>
I have not had the time to push it into 3.0, volunteers?

>
>> If DMARC is going to be successful, it has to work with the existi= ng
>> mail system. =A0For the most part it does.
>>
>> The mailing list arguments are a tempest in a teapot and only aris= e
>> because a few people wilfully publish inappropriate DMARC records.=
>
>Right, but isn't that the same weakness as ADSP? =A0Both protocols = seem
>to be good at anti-phishing, but then they work for transactional mail<= br> >only.

Even with transactional emails there are issues:
http://www.it.cornell.edu/services/cmail/howto/spoof.cfm This specific problem has not yet been addressed, it is quite typical in dot edu organizations, but I have seen people being more and more mindful about it, because now it is not anymore one odd user, and I have seen
system changes to avoid that forwarding breaks DKIM.

I cannot find any article describing conditions when Exchange break/don'= ;t
break DKIM when forwarding... If someone has a pointer?

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

--047d7b5d8cffec4e3704d9c8a8b0-- From prvs=802a6e817=fmartin@linkedin.com Sun Apr 7 11:10:32 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D9621F86AF for ; Sun, 7 Apr 2013 11:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44IGPrrpiNYJ for ; Sun, 7 Apr 2013 11:10:31 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 966EE21F8518 for ; Sun, 7 Apr 2013 11:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365358231; x=1396894231; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=G0VjTNEyRQgQP1IhbsYWSwCisbJdnMtBL3xYals1X9E=; b=t5aqri7xNMX5KF0cFH5nSVQ+Jus0k4CFuBlOmur2Gfi62tWjDJWJguz0 J6dyBz3dqMf5cBcuXKQBK+s0jor5YcLrJMOGx7TbiFGiDavU3RdPdkkk1 mawdlF9ytB0BfOnH22j41pmSen2kxPjyVaTWrWgkia1Pin+Pd4YWWz6wE U=; X-IronPort-AV: E=Sophos;i="4.87,424,1363158000"; d="scan'208,217";a="43231148" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Sun, 7 Apr 2013 11:10:24 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Sun, 7 Apr 2013 11:10:24 -0700 From: Franck Martin To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] not about outsourcing strategies, and a newbie's question Thread-Index: AQHOMrM0Ox+ucrlBNkOkBe6MGAJTlpjJrEiAgAHOhoD//5YkAA== Date: Sun, 7 Apr 2013 18:10:23 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EC8C69@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/alternative; boundary="_000_77426B543150464AA3F30DF1A91365DE52EC8C69ESV4MBX01linked_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 18:10:32 -0000 --_000_77426B543150464AA3F30DF1A91365DE52EC8C69ESV4MBX01linked_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9uJ3QgdGFrZSBpdCBwZXJzb25hbGx5LCBub3QgZXZlcnlvbmUgaXMgYSB0ZWNobm9sb2dpc3Qg YW5kIGNhbiBjb21waWxlL2luc3RhbGwgYSB0YXJiYWxsLCB1bnRpbCB0aGVyZSBhcmUgUlBNcyAo dGhlcmUgYXJlIGRlYnMsIEkgaGF2ZSBub3Qgc2VlbiBhbnkgUlBNcyB5ZXQpIGFuZCBpdCBpcyBp bmNsdWRlZCBpbiBsaW51eCBkaXN0cmlidXRpb25zLCBvcGVuRE1BUkMgd2lsbCByZW1haW4gImhh cmQgdG8gaW5zdGFsbCIuDQoNCmh0dHA6Ly93d3cucnBtZmluZC5uZXQvbGludXgvcnBtMmh0bWwv c2VhcmNoLnBocD9xdWVyeT1vcGVuZG1hcmMmc3VibWl0PVNlYXJjaCsuLi4NCmh0dHA6Ly9wYWNr YWdlcy51YnVudHUuY29tL3NlYXJjaD9rZXl3b3Jkcz1vcGVuZG1hcmMNCg0KVGhpcyBpcyBteSBw b2ludCBhbmQgSSBzdGljayB0byBpdC4NCg0KSSBpbnZpdGUgeW91IHRvIG1lZXQgcGVvcGxlIG91 dHNpZGUgdGVjaG5vbG9naXN0IGNpcmNsZXMgYW5kIHNlZSB3aGF0IHRoZSByZWFsIHdvcmxkIGlz IGFib3V0IDpQDQoNCkZyb206ICJNdXJyYXkgUy4gS3VjaGVyYXd5IiA8c3VwZXJ1c2VyQGdtYWls LmNvbTxtYWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNvbT4+DQpEYXRlOiBTdW5kYXksIEFwcmlsIDcs IDIwMTMgMTA6MjkgQU0NClRvOiBGcmFuY2sgTWFydGluIDxmbWFydGluQGxpbmtlZGluLmNvbTxt YWlsdG86Zm1hcnRpbkBsaW5rZWRpbi5jb20+Pg0KQ2M6IEFsZXNzYW5kcm8gVmVzZWx5IDx2ZXNl bHlAdGFuYS5pdDxtYWlsdG86dmVzZWx5QHRhbmEuaXQ+PiwgImRtYXJjQGlldGYub3JnPG1haWx0 bzpkbWFyY0BpZXRmLm9yZz4iIDxkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBub3QgYWJvdXQgb3V0c291cmNpbmcgc3RyYXRl Z2llcywgYW5kIGEgbmV3YmllJ3MgcXVlc3Rpb24NCg0KVGhpcyBpcyB0aGUgZmlyc3QgSSd2ZSBo ZWFyZCBzb21lb25lIHNheSBPcGVuRE1BUkMgaXMgaGFyZCB0byBpbnN0YWxsLiAgU28gZmFyIHRo ZSBmZWVkYmFjayBoYXMgYmVlbiB0aGUgb3Bwb3NpdGUuDQoNCkkgaW52aXRlIHlvdSB0byB0aGUg b3BlbmRtYXJjLXVzZXJzIGxpc3QgdG8gZGVzY3JpYmUgeW91ciBleHBlcmllbmNlIGFuZCBzdWdn ZXN0IHdheXMgdG8gaW1wcm92ZSBpdC4NCg0KDQo= --_000_77426B543150464AA3F30DF1A91365DE52EC8C69ESV4MBX01linked_ Content-Type: text/html; charset="utf-8" Content-ID: <9CCBCACB9250EE4DA62D27F7F46D5068@linkedin.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+RG9uJ3QgdGFr ZSBpdCBwZXJzb25hbGx5LCBub3QgZXZlcnlvbmUgaXMgYSB0ZWNobm9sb2dpc3QgYW5kIGNhbiBj b21waWxlL2luc3RhbGwgYSB0YXJiYWxsLCB1bnRpbCB0aGVyZSBhcmUgUlBNcyAodGhlcmUgYXJl IGRlYnMsIEkgaGF2ZSBub3Qgc2VlbiBhbnkgUlBNcyB5ZXQpIGFuZCBpdCBpcyBpbmNsdWRlZCBp biBsaW51eCBkaXN0cmlidXRpb25zLCBvcGVuRE1BUkMgd2lsbCByZW1haW4gJnF1b3Q7aGFyZCB0 byBpbnN0YWxsJnF1b3Q7LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGEgaHJlZj0i aHR0cDovL3d3dy5ycG1maW5kLm5ldC9saW51eC9ycG0yaHRtbC9zZWFyY2gucGhwP3F1ZXJ5PW9w ZW5kbWFyYyZhbXA7c3VibWl0PVNlYXJjaCYjNDM7Ij5odHRwOi8vd3d3LnJwbWZpbmQubmV0L2xp bnV4L3JwbTJodG1sL3NlYXJjaC5waHA/cXVlcnk9b3BlbmRtYXJjJmFtcDtzdWJtaXQ9U2VhcmNo JiM0Mzs8L2E+Li4uPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHA6Ly9wYWNrYWdlcy51YnVudHUu Y29tL3NlYXJjaD9rZXl3b3Jkcz1vcGVuZG1hcmMiPmh0dHA6Ly9wYWNrYWdlcy51YnVudHUuY29t L3NlYXJjaD9rZXl3b3Jkcz1vcGVuZG1hcmM8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5UaGlzIGlzIG15IHBvaW50IGFuZCBJIHN0aWNrIHRvIGl0LjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+SSBpbnZpdGUgeW91IHRvIG1lZXQgcGVvcGxlIG91dHNpZGUgdGVjaG5v bG9naXN0IGNpcmNsZXMgYW5kIHNlZSB3aGF0IHRoZSByZWFsIHdvcmxkIGlzIGFib3V0IDpQPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFs aWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVS LUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBp bjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9S REVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90O011cnJheSBTLiBLdWNoZXJhd3km cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzdXBlcnVzZXJAZ21haWwuY29tIj5zdXBlcnVzZXJA Z21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0 ZTogPC9zcGFuPlN1bmRheSwgQXByaWwgNywgMjAxMyAxMDoyOSBBTTxicj4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkZyYW5jayBNYXJ0aW4gJmx0OzxhIGhyZWY9 Im1haWx0bzpmbWFydGluQGxpbmtlZGluLmNvbSI+Zm1hcnRpbkBsaW5rZWRpbi5jb208L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPkFsZXNzYW5k cm8gVmVzZWx5ICZsdDs8YSBocmVmPSJtYWlsdG86dmVzZWx5QHRhbmEuaXQiPnZlc2VseUB0YW5h Lml0PC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRmLm9yZyI+ZG1hcmNA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZG1hcmNAaWV0Zi5vcmciPmRt YXJjQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+ U3ViamVjdDogPC9zcGFuPlJlOiBbZG1hcmMtaWV0Zl0gbm90IGFib3V0IG91dHNvdXJjaW5nIHN0 cmF0ZWdpZXMsIGFuZCBhIG5ld2JpZSdzIHF1ZXN0aW9uPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5UaGlzIGlzIHRoZSBmaXJzdCBJ J3ZlIGhlYXJkIHNvbWVvbmUgc2F5IE9wZW5ETUFSQyBpcyBoYXJkIHRvIGluc3RhbGwuJm5ic3A7 IFNvIGZhciB0aGUgZmVlZGJhY2sgaGFzIGJlZW4gdGhlIG9wcG9zaXRlLjxicj4NCjxicj4NCkkg aW52aXRlIHlvdSB0byB0aGUgb3BlbmRtYXJjLXVzZXJzIGxpc3QgdG8gZGVzY3JpYmUgeW91ciBl eHBlcmllbmNlIGFuZCBzdWdnZXN0IHdheXMgdG8gaW1wcm92ZSBpdC48YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_77426B543150464AA3F30DF1A91365DE52EC8C69ESV4MBX01linked_-- From superuser@gmail.com Sun Apr 7 11:37:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB30D21F8615 for ; Sun, 7 Apr 2013 11:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JChwj3pRWDkM for ; Sun, 7 Apr 2013 11:37:43 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 823DB21F85DC for ; Sun, 7 Apr 2013 11:37:42 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so5263500wgh.5 for ; Sun, 07 Apr 2013 11:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3wAhw0bbIvrNy1cLf4l3yF7aMGK9CE0Tz0twU9xqDoE=; b=AFF2wG9oYjq2F3RPm0Yo5f6DHOnM88wVF250rZGWcnYdPHlM1BNj0DAZfF/m5lo3CX rXoUEObtSCQgaINs8UJFOUMUsRca8hskDjL/dORPbASa+2zzYSs/v1dNO1h5ZEUDrfSD VcffAjmIprMBky3dlDmDsvww9YmcAVUwdGOZfx4u65wsMFfjYsXtEceNStCvG5kBEPV/ Cpa1KkSyb1vSWncIjmA33cWouDfmwlxAuxQTuoAmHGy149Odj8cD0rMul9xgVN2TQAmj JoU3/G4Ex2CewxjpqqDeTiPzRL+vJOUGC0NjjT5da3h1SrWzw/VYlg961ekRwWubTZ7H pMNQ== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr8662082wib.32.1365359861583; Sun, 07 Apr 2013 11:37:41 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sun, 7 Apr 2013 11:37:41 -0700 (PDT) In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EC8C69@ESV4-MBX01.linkedin.biz> References: <77426B543150464AA3F30DF1A91365DE52EC8C69@ESV4-MBX01.linkedin.biz> Date: Sun, 7 Apr 2013 11:37:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d044306aa8a570d04d9c99d6a Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 18:37:43 -0000 --f46d044306aa8a570d04d9c99d6a Content-Type: text/plain; charset=ISO-8859-1 I don't find it particularly helpful to answer "How can we improve?" with antagonism. But since you said it so nicely, a Google search revealed these: https://github.com/stevejenkins/OpenDMARC-Fedora http://packages.debian.org/search?keywords=opendmarc http://packages.ubuntu.com/quantal-backports/mail/opendmarc So they're out there if you're willing to look for them. -MSK On Sun, Apr 7, 2013 at 11:10 AM, Franck Martin wrote: > Don't take it personally, not everyone is a technologist and can > compile/install a tarball, until there are RPMs (there are debs, I have not > seen any RPMs yet) and it is included in linux distributions, openDMARC > will remain "hard to install". > > > http://www.rpmfind.net/linux/rpm2html/search.php?query=opendmarc&submit=Search+ > ... > http://packages.ubuntu.com/search?keywords=opendmarc > > This is my point and I stick to it. > > I invite you to meet people outside technologist circles and see what > the real world is about :P > > From: "Murray S. Kucherawy" > Date: Sunday, April 7, 2013 10:29 AM > To: Franck Martin > Cc: Alessandro Vesely , "dmarc@ietf.org" > Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a > newbie's question > > This is the first I've heard someone say OpenDMARC is hard to install. > So far the feedback has been the opposite. > > I invite you to the opendmarc-users list to describe your experience and > suggest ways to improve it. > > > --f46d044306aa8a570d04d9c99d6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't find it particularly helpful to= answer "How can we improve?" with antagonism.

But s= ince you said it so nicely, a Google search revealed these:

https://github.com/st= evejenkins/OpenDMARC-Fedora
http://p= ackages.debian.org/search?keywords=3Dopendmarc
http://packages.ubuntu.c= om/quantal-backports/mail/opendmarc

So they're out there if you're willing to look for them.<= br>
-MSK


On Sun, Apr 7, 2013 at 11:10 AM, Franck Martin <fmartin@l= inkedin.com> wrote:
Don't take it personally, not everyone is a technologist and can c= ompile/install a tarball, until there are RPMs (there are debs, I have not = seen any RPMs yet) and it is included in linux distributions, openDMARC wil= l remain "hard to install".


--f46d044306aa8a570d04d9c99d6a-- From johnl@iecc.com Sun Apr 7 12:00:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5CF21F8D33 for ; Sun, 7 Apr 2013 12:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.028 X-Spam-Level: X-Spam-Status: No, score=-111.028 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtS3LfcUT3lB for ; Sun, 7 Apr 2013 12:00:12 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0627721F8D52 for ; Sun, 7 Apr 2013 12:00:11 -0700 (PDT) Received: (qmail 66545 invoked from network); 7 Apr 2013 19:00:11 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Apr 2013 19:00:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5161c23a.xn--3zv.k1304; i=johnl@user.iecc.com; bh=MEV46mUBFNh+xH00JS/3BfiDTVFLhDR9/6VuJeDBhtY=; b=Ka7atY18hH1DP9vD+ErN7wS/iVstSdcdB28vPwyPx8HyfjuyMmXV0JElu0RiNzJFAnF0o9s4Eo9OEVc6YJ+DgGUcXa6D7P5tNjkDWqZS4by4EEacK3V66vqJgoXoNNDuyWuiBQuetHrL9BmhUMgoifz+31JPsRWsUx+sw+eraDo= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5161c23a.xn--3zv.k1304; olt=johnl@user.iecc.com; bh=MEV46mUBFNh+xH00JS/3BfiDTVFLhDR9/6VuJeDBhtY=; b=meW1rrU4NkapR10YDCD2J3jE9XKt4MbznzpZf5v4kS1MGI2zze2R6AIvxfomCx2XS0IP6fTpBoqywLr+WQBuxEN+5+ee20nyM1GqJCpZsHp0jzIaaDz1YrGULDkLfKBQJJGpmu0QPYimqc1dDWpksFphMgx2piu+fy2c9EH3cM8= Date: 7 Apr 2013 18:59:48 -0000 Message-ID: <20130407185948.76912.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 19:00:15 -0000 >This is the first I've heard someone say OpenDMARC is hard to install. So >far the feedback has been the opposite. The documentation is a bit sparse for the reporting part, and it would be nice to have a cheat sheet for the libraries. From prvs=802a6e817=fmartin@linkedin.com Sun Apr 7 12:05:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1B821F8A51 for ; Sun, 7 Apr 2013 12:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.996 X-Spam-Level: X-Spam-Status: No, score=-5.996 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZjCeFIg0VRJ for ; Sun, 7 Apr 2013 12:05:01 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 87F1621F863B for ; Sun, 7 Apr 2013 12:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365361500; x=1396897500; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=1K73kRBmDyxHEgHDsmUJ0g+SJ3vUWmNtel+sn+tW4KY=; b=svg3vGqXrAMJhnuo/RNdimpu9lbrYGrZLE4W6Z8eBR3Sa8g8ZvVDp0+R f46+Dl6vePBkXPWhaWxoMCYxmgRp2VMJbwu7F6KaVIp5G4i4PfFoAisPj E/7AQ6fGpY39G7jZHlaKQRfXu8si56jSUEJuK2ZnvAIx5lWaol+PvApYf U=; X-IronPort-AV: E=Sophos;i="4.87,424,1363158000"; d="scan'208,217";a="43232761" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Sun, 7 Apr 2013 12:04:54 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Sun, 7 Apr 2013 12:04:54 -0700 From: Franck Martin To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] not about outsourcing strategies, and a newbie's question Thread-Index: AQHOMrM0Ox+ucrlBNkOkBe6MGAJTlpjJrEiAgAHOhoD//5YkAIAAfPiA//+SPIA= Date: Sun, 7 Apr 2013 19:04:53 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EC8F81@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: multipart/alternative; boundary="_000_77426B543150464AA3F30DF1A91365DE52EC8F81ESV4MBX01linked_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 19:05:02 -0000 --_000_77426B543150464AA3F30DF1A91365DE52EC8F81ESV4MBX01linked_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzYWlkIEkgaGF2ZSBzZWVuIGRlYnMgYW5kIHRoZXkgYXJlIHBhcnQgb2YgdWJ1bnR1IGFuZCBJ IGhhdmUgcHV0IHRoZSBsaW5rIHRvIHRoZW0sIEkgaGF2ZSBub3QgeWV0IHNlZW4gYSBycG0geWV0 LCB3aGF0IHlvdSBwb2ludCB0byBpcyBhIHNwZWMgZmlsZSB0aGF0IGFsbG93cyB0byBjcmVhdGUg YSBycG0uIEl0IGlzIG5vdCBhIFJQTS4NCg0KVGhlcmUgaXMgYSBzb3VyY2UgUlBNIGF0IGh0dHA6 Ly9zdGV2ZWouZmVkb3JhcGVvcGxlLm9yZy9PcGVuRE1BUkMvDQoNCktlZXAgdGhlIGdvb2Qgd29y aywgdGhlIHJwbSB3aWxsIGV2ZW50dWFsbHkgYXBwZWFyIG9uIGZlZG9yYSBvciBvdGhlciBkaXN0 cm8uIEl0IGlzIGp1c3QgYSBxdWVzdGlvbiBvZiB0aW1lIGFuZCBlbmNvdXJhZ2VtZW50cywgYW5k IGxvb2tzIGxpa2UgU3RldmUgSmVua2lucyBpcyBhYm91dCB0byBicmVhayBpdCBvbiBGZWRvcmEu DQoNCkZyb206ICJNdXJyYXkgUy4gS3VjaGVyYXd5IiA8c3VwZXJ1c2VyQGdtYWlsLmNvbTxtYWls dG86c3VwZXJ1c2VyQGdtYWlsLmNvbT4+DQpEYXRlOiBTdW5kYXksIEFwcmlsIDcsIDIwMTMgMTE6 MzcgQU0NClRvOiBGcmFuY2sgTWFydGluIDxmbWFydGluQGxpbmtlZGluLmNvbTxtYWlsdG86Zm1h cnRpbkBsaW5rZWRpbi5jb20+Pg0KQ2M6IEFsZXNzYW5kcm8gVmVzZWx5IDx2ZXNlbHlAdGFuYS5p dDxtYWlsdG86dmVzZWx5QHRhbmEuaXQ+PiwgImRtYXJjQGlldGYub3JnPG1haWx0bzpkbWFyY0Bp ZXRmLm9yZz4iIDxkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1hcmNAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFtkbWFyYy1pZXRmXSBub3QgYWJvdXQgb3V0c291cmNpbmcgc3RyYXRlZ2llcywgYW5k IGEgbmV3YmllJ3MgcXVlc3Rpb24NCg0KSSBkb24ndCBmaW5kIGl0IHBhcnRpY3VsYXJseSBoZWxw ZnVsIHRvIGFuc3dlciAiSG93IGNhbiB3ZSBpbXByb3ZlPyIgd2l0aCBhbnRhZ29uaXNtLg0KDQpC dXQgc2luY2UgeW91IHNhaWQgaXQgc28gbmljZWx5LCBhIEdvb2dsZSBzZWFyY2ggcmV2ZWFsZWQg dGhlc2U6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9zdGV2ZWplbmtpbnMvT3BlbkRNQVJDLUZlZG9y YQ0KaHR0cDovL3BhY2thZ2VzLmRlYmlhbi5vcmcvc2VhcmNoP2tleXdvcmRzPW9wZW5kbWFyYw0K aHR0cDovL3BhY2thZ2VzLnVidW50dS5jb20vcXVhbnRhbC1iYWNrcG9ydHMvbWFpbC9vcGVuZG1h cmMNCg0KU28gdGhleSdyZSBvdXQgdGhlcmUgaWYgeW91J3JlIHdpbGxpbmcgdG8gbG9vayBmb3Ig dGhlbS4NCg0KLU1TSw0KDQoNCk9uIFN1biwgQXByIDcsIDIwMTMgYXQgMTE6MTAgQU0sIEZyYW5j ayBNYXJ0aW4gPGZtYXJ0aW5AbGlua2VkaW4uY29tPG1haWx0bzpmbWFydGluQGxpbmtlZGluLmNv bT4+IHdyb3RlOg0KRG9uJ3QgdGFrZSBpdCBwZXJzb25hbGx5LCBub3QgZXZlcnlvbmUgaXMgYSB0 ZWNobm9sb2dpc3QgYW5kIGNhbiBjb21waWxlL2luc3RhbGwgYSB0YXJiYWxsLCB1bnRpbCB0aGVy ZSBhcmUgUlBNcyAodGhlcmUgYXJlIGRlYnMsIEkgaGF2ZSBub3Qgc2VlbiBhbnkgUlBNcyB5ZXQp IGFuZCBpdCBpcyBpbmNsdWRlZCBpbiBsaW51eCBkaXN0cmlidXRpb25zLCBvcGVuRE1BUkMgd2ls bCByZW1haW4gImhhcmQgdG8gaW5zdGFsbCIuDQoNCmh0dHA6Ly93d3cucnBtZmluZC5uZXQvbGlu dXgvcnBtMmh0bWwvc2VhcmNoLnBocD9xdWVyeT1vcGVuZG1hcmMmc3VibWl0PVNlYXJjaCsuLi4N Cmh0dHA6Ly9wYWNrYWdlcy51YnVudHUuY29tL3NlYXJjaD9rZXl3b3Jkcz1vcGVuZG1hcmMNCg0K VGhpcyBpcyBteSBwb2ludCBhbmQgSSBzdGljayB0byBpdC4NCg0KSSBpbnZpdGUgeW91IHRvIG1l ZXQgcGVvcGxlIG91dHNpZGUgdGVjaG5vbG9naXN0IGNpcmNsZXMgYW5kIHNlZSB3aGF0IHRoZSBy ZWFsIHdvcmxkIGlzIGFib3V0IDpQDQoNCkZyb206ICJNdXJyYXkgUy4gS3VjaGVyYXd5IiA8c3Vw ZXJ1c2VyQGdtYWlsLmNvbTxtYWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNvbT4+DQpEYXRlOiBTdW5k YXksIEFwcmlsIDcsIDIwMTMgMTA6MjkgQU0NClRvOiBGcmFuY2sgTWFydGluIDxmbWFydGluQGxp bmtlZGluLmNvbTxtYWlsdG86Zm1hcnRpbkBsaW5rZWRpbi5jb20+Pg0KQ2M6IEFsZXNzYW5kcm8g VmVzZWx5IDx2ZXNlbHlAdGFuYS5pdDxtYWlsdG86dmVzZWx5QHRhbmEuaXQ+PiwgImRtYXJjQGll dGYub3JnPG1haWx0bzpkbWFyY0BpZXRmLm9yZz4iIDxkbWFyY0BpZXRmLm9yZzxtYWlsdG86ZG1h cmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBub3QgYWJvdXQgb3V0c291 cmNpbmcgc3RyYXRlZ2llcywgYW5kIGEgbmV3YmllJ3MgcXVlc3Rpb24NCg0KVGhpcyBpcyB0aGUg Zmlyc3QgSSd2ZSBoZWFyZCBzb21lb25lIHNheSBPcGVuRE1BUkMgaXMgaGFyZCB0byBpbnN0YWxs LiAgU28gZmFyIHRoZSBmZWVkYmFjayBoYXMgYmVlbiB0aGUgb3Bwb3NpdGUuDQoNCkkgaW52aXRl IHlvdSB0byB0aGUgb3BlbmRtYXJjLXVzZXJzIGxpc3QgdG8gZGVzY3JpYmUgeW91ciBleHBlcmll bmNlIGFuZCBzdWdnZXN0IHdheXMgdG8gaW1wcm92ZSBpdC4NCg0KDQoNCg== --_000_77426B543150464AA3F30DF1A91365DE52EC8F81ESV4MBX01linked_ Content-Type: text/html; charset="utf-8" Content-ID: <3406331715C0D94DB3FEBEE27B03B6FE@linkedin.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXY+SSBzYWlkIEkg aGF2ZSBzZWVuIGRlYnMgYW5kIHRoZXkgYXJlIHBhcnQgb2YgdWJ1bnR1IGFuZCBJIGhhdmUgcHV0 IHRoZSBsaW5rIHRvIHRoZW0sIEkgaGF2ZSBub3QgeWV0IHNlZW4gYSBycG0geWV0LCB3aGF0IHlv dSBwb2ludCB0byBpcyBhIHNwZWMgZmlsZSB0aGF0IGFsbG93cyB0byBjcmVhdGUgYSBycG0uIEl0 IGlzIG5vdCBhIFJQTS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXJlIGlzIGEg c291cmNlIFJQTSBhdCBodHRwOi8vc3RldmVqLmZlZG9yYXBlb3BsZS5vcmcvT3BlbkRNQVJDLzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+S2VlcCB0aGUgZ29vZCB3b3JrLCB0aGUgcnBt IHdpbGwgZXZlbnR1YWxseSBhcHBlYXIgb24gZmVkb3JhIG9yIG90aGVyIGRpc3Ryby4gSXQgaXMg anVzdCBhIHF1ZXN0aW9uIG9mIHRpbWUgYW5kIGVuY291cmFnZW1lbnRzLCBhbmQgbG9va3MgbGlr ZSBTdGV2ZSBKZW5raW5zIGlzIGFib3V0IHRvIGJyZWFrIGl0IG9uIEZlZG9yYS48L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVm dDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDog bWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURE SU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklH SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7TXVycmF5IFMuIEt1Y2hlcmF3eSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb20iPnN1cGVydXNlckBnbWFpbC5j b208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3Nw YW4+U3VuZGF5LCBBcHJpbCA3LCAyMDEzIDExOjM3IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+RnJhbmNrIE1hcnRpbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmZtYXJ0aW5AbGlua2VkaW4uY29tIj5mbWFydGluQGxpbmtlZGluLmNvbTwvYT4mZ3Q7PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+QWxlc3NhbmRybyBWZXNl bHkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZXNlbHlAdGFuYS5pdCI+dmVzZWx5QHRhbmEuaXQ8L2E+ Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRtYXJjQGlldGYub3JnIj5kbWFyY0BpZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRmLm9yZyI+ZG1hcmNAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0 OiA8L3NwYW4+UmU6IFtkbWFyYy1pZXRmXSBub3QgYWJvdXQgb3V0c291cmNpbmcgc3RyYXRlZ2ll cywgYW5kIGEgbmV3YmllJ3MgcXVlc3Rpb248YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2PkkgZG9u J3QgZmluZCBpdCBwYXJ0aWN1bGFybHkgaGVscGZ1bCB0byBhbnN3ZXIgJnF1b3Q7SG93IGNhbiB3 ZSBpbXByb3ZlPyZxdW90OyB3aXRoIGFudGFnb25pc20uPGJyPg0KPGJyPg0KPC9kaXY+DQpCdXQg c2luY2UgeW91IHNhaWQgaXQgc28gbmljZWx5LCBhIEdvb2dsZSBzZWFyY2ggcmV2ZWFsZWQgdGhl c2U6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3N0ZXZlamVua2lucy9P cGVuRE1BUkMtRmVkb3JhIj5odHRwczovL2dpdGh1Yi5jb20vc3RldmVqZW5raW5zL09wZW5ETUFS Qy1GZWRvcmE8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cDovL3BhY2thZ2VzLmRlYmlhbi5vcmcvc2Vh cmNoP2tleXdvcmRzPW9wZW5kbWFyYyI+aHR0cDovL3BhY2thZ2VzLmRlYmlhbi5vcmcvc2VhcmNo P2tleXdvcmRzPW9wZW5kbWFyYzwvYT48YnI+DQo8YSBocmVmPSJodHRwOi8vcGFja2FnZXMudWJ1 bnR1LmNvbS9xdWFudGFsLWJhY2twb3J0cy9tYWlsL29wZW5kbWFyYyI+aHR0cDovL3BhY2thZ2Vz LnVidW50dS5jb20vcXVhbnRhbC1iYWNrcG9ydHMvbWFpbC9vcGVuZG1hcmM8L2E+PGJyPg0KPGJy Pg0KPC9kaXY+DQpTbyB0aGV5J3JlIG91dCB0aGVyZSBpZiB5b3UncmUgd2lsbGluZyB0byBsb29r IGZvciB0aGVtLjxicj4NCjxicj4NCjwvZGl2Pg0KLU1TSzxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZXh0cmEiPjxicj4NCjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBT dW4sIEFwciA3LCAyMDEzIGF0IDExOjEwIEFNLCBGcmFuY2sgTWFydGluIDxzcGFuIGRpcj0ibHRy Ij4NCiZsdDs8YSBocmVmPSJtYWlsdG86Zm1hcnRpbkBsaW5rZWRpbi5jb20iIHRhcmdldD0iX2Js YW5rIj5mbWFydGluQGxpbmtlZGluLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8Ymxv Y2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3Jk ZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9ImZv bnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjt3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2PkRvbid0IHRha2UgaXQgcGVyc29uYWxseSwgbm90IGV2ZXJ5b25lIGlz IGEgdGVjaG5vbG9naXN0IGFuZCBjYW4gY29tcGlsZS9pbnN0YWxsIGEgdGFyYmFsbCwgdW50aWwg dGhlcmUgYXJlIFJQTXMgKHRoZXJlIGFyZSBkZWJzLCBJIGhhdmUgbm90IHNlZW4gYW55IFJQTXMg eWV0KSBhbmQgaXQgaXMgaW5jbHVkZWQgaW4gbGludXggZGlzdHJpYnV0aW9ucywgb3BlbkRNQVJD IHdpbGwgcmVtYWluICZxdW90O2hhcmQgdG8gaW5zdGFsbCZxdW90Oy48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHA6Ly93d3cucnBtZmluZC5uZXQvbGludXgvcnBt Mmh0bWwvc2VhcmNoLnBocD9xdWVyeT1vcGVuZG1hcmMmYW1wO3N1Ym1pdD1TZWFyY2gmIzQzOyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cucnBtZmluZC5uZXQvbGludXgvcnBtMmh0bWwvc2Vh cmNoLnBocD9xdWVyeT1vcGVuZG1hcmMmYW1wO3N1Ym1pdD1TZWFyY2gmIzQzOzwvYT4uLi48L2Rp dj4NCjxkaXY+PGEgaHJlZj0iaHR0cDovL3BhY2thZ2VzLnVidW50dS5jb20vc2VhcmNoP2tleXdv cmRzPW9wZW5kbWFyYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9wYWNrYWdlcy51YnVudHUuY29t L3NlYXJjaD9rZXl3b3Jkcz1vcGVuZG1hcmM8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj5UaGlzIGlzIG15IHBvaW50IGFuZCBJIHN0aWNrIHRvIGl0LjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+SSBpbnZpdGUgeW91IHRvIG1lZXQgcGVvcGxlIG91dHNpZGUgdGVjaG5v bG9naXN0IGNpcmNsZXMgYW5kIHNlZSB3aGF0IHRoZSByZWFsIHdvcmxkIGlzIGFib3V0IDpQPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXItcmlnaHQ6 bWVkaXVtIG5vbmU7cGFkZGluZy1yaWdodDowaW47cGFkZGluZy1sZWZ0OjBpbjtwYWRkaW5nLXRv cDozcHQ7dGV4dC1hbGlnbjpsZWZ0O2ZvbnQtc2l6ZToxMXB0O2JvcmRlci1ib3R0b206bWVkaXVt IG5vbmU7Zm9udC1mYW1pbHk6Q2FsaWJyaTtib3JkZXItdG9wOiNiNWM0ZGYgMXB0IHNvbGlkO3Bh ZGRpbmctYm90dG9tOjBpbjtib3JkZXItbGVmdDptZWRpdW0gbm9uZSI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90O011cnJheSBTLiBLdWNoZXJhd3km cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzdXBlcnVzZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+c3VwZXJ1c2VyQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5TdW5kYXksIEFwcmlsIDcsIDIwMTMgMTA6MjkgQU08 YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj5GcmFuY2sgTWFy dGluICZsdDs8YSBocmVmPSJtYWlsdG86Zm1hcnRpbkBsaW5rZWRpbi5jb20iIHRhcmdldD0iX2Js YW5rIj5mbWFydGluQGxpbmtlZGluLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+QWxlc3NhbmRybyBWZXNlbHkgJmx0OzxhIGhyZWY9Im1h aWx0bzp2ZXNlbHlAdGFuYS5pdCIgdGFyZ2V0PSJfYmxhbmsiPnZlc2VseUB0YW5hLml0PC9hPiZn dDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpkbWFyY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmRtYXJjQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRtYXJjQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1hcmNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtkbWFyYy1pZXRmXSBu b3QgYWJvdXQgb3V0c291cmNpbmcgc3RyYXRlZ2llcywgYW5kIGEgbmV3YmllJ3MgcXVlc3Rpb248 YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImltIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXYgZGlyPSJsdHIiPlRoaXMgaXMgdGhlIGZpcnN0IEkndmUgaGVhcmQgc29tZW9u ZSBzYXkgT3BlbkRNQVJDIGlzIGhhcmQgdG8gaW5zdGFsbC4mbmJzcDsgU28gZmFyIHRoZSBmZWVk YmFjayBoYXMgYmVlbiB0aGUgb3Bwb3NpdGUuPGJyPg0KPGJyPg0KSSBpbnZpdGUgeW91IHRvIHRo ZSBvcGVuZG1hcmMtdXNlcnMgbGlzdCB0byBkZXNjcmliZSB5b3VyIGV4cGVyaWVuY2UgYW5kIHN1 Z2dlc3Qgd2F5cyB0byBpbXByb3ZlIGl0Ljxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxf ZXh0cmEiPjxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFu PjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_77426B543150464AA3F30DF1A91365DE52EC8F81ESV4MBX01linked_-- From jgomez@seryrich.com Sun Apr 7 13:19:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F4821F8E5A for ; Sun, 7 Apr 2013 13:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdI6NyLPS7DB for ; Sun, 7 Apr 2013 13:19:29 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAC921F8ACE for ; Sun, 7 Apr 2013 13:19:28 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 7 Apr 2013 22:19:25 +0200 Message-ID: <1CBBDC25A6754A1B9348CF0A3D785C12@fgsr.local> From: "J. Gomez" To: References: <20130407010548.38641.qmail@joyce.lan> Date: Sun, 7 Apr 2013 22:20:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 20:19:30 -0000 On Sunday, April 07, 2013 3:05 AM [GMT+1=3DCET], John Levine wrote: > > > For the zillionth time, there is no chance whatsoever that > > > Mailman and other open source list managers will change to work > > > around DMARC's limitations. I wish people would stop wasting time > > > by claiming otherwise. > >=20 > > Is this assetion based on the comtemplation of some magic cristal > > ball for the future?=20 >=20 > No, it's based on having run mailing lists for several decades, > switching among too many list management packages. I run about 100 > lists, of which about 30 have an interesting amount of traffic. >=20 > Just for reference, have you ever run a mailing list? How many list > management systems are you familiar with? Argument from authority ( = http://en.wikipedia.org/wiki/Argument_from_authority ) while warranted, = is not of special value to predict the future. Mailman already has an option to become DMARC-compatible. If that option = would become the default configuration for "Mailman out-of-the-box", = then all would be fine. The option is in General Options -> anonymous_list, set to Yes. This = puts the mailing list address in the RFC5322.From header in the emails = the mailing list software forwards to its subscribers. Do you see any = problem in that option? With time, things do change. Several decades is about time for a change. Regards, J. Gomez From superuser@gmail.com Sun Apr 7 13:27:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3664421F8ECB for ; Sun, 7 Apr 2013 13:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvdsHOaP2-s6 for ; Sun, 7 Apr 2013 13:27:19 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1D73621F8D52 for ; Sun, 7 Apr 2013 13:27:18 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k13so3167357wgh.3 for ; Sun, 07 Apr 2013 13:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mlgV/vNW3wZRextZv02s3sNX+OHRwJqeY59W9Cbbaag=; b=CyHbjkyCMlOjzjLtRHJl7W5ZzfGmJOiohW3HVcSbND6lOQyeBIT9wwbc6qnsrMsLfx f0dBJDW+4gaHI7wyv5vlDywiTKyPk9CSpkuHtjAzg3O3feTUHkP+Gjv6TjCSZMqRLhow oPLNYDv0OKaXUQhRN90GwpagkVuzX61HNU/Bh87NXNADmPj3ZdMNLcUwHJmfdfH6HRGN DsRrm0193bg2Jmmmm/YyB986HeZ+Be40PuV81IvJSa+HlX9GVoDPcSfXGc0N6yur89Bj 1xY8k0GR+/dQ1rfDnyi8btMp1kqcv2j3npUE5ZavTfgxG7d6ZEiZ+Fp2BvfPUKTzVf3U chRA== MIME-Version: 1.0 X-Received: by 10.180.149.227 with SMTP id ud3mr14212636wib.0.1365366438258; Sun, 07 Apr 2013 13:27:18 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sun, 7 Apr 2013 13:27:17 -0700 (PDT) In-Reply-To: <20130407185948.76912.qmail@joyce.lan> References: <20130407185948.76912.qmail@joyce.lan> Date: Sun, 7 Apr 2013 13:27:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a11c384788a6db004d9cb259f Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 20:27:20 -0000 --001a11c384788a6db004d9cb259f Content-Type: text/plain; charset=ISO-8859-1 Thanks for the suggestions. I've opened tracker items to deal with both of those doc points in the next release. People with feedback about that particular project should avail themselves of the ticket system on SourceForge or the mailing lists for the project hosted at trusteddomain.org. -MSK On Sun, Apr 7, 2013 at 11:59 AM, John Levine wrote: > >This is the first I've heard someone say OpenDMARC is hard to install. So > >far the feedback has been the opposite. > > The documentation is a bit sparse for the reporting part, and it would > be nice to have a cheat sheet for the libraries. > > --001a11c384788a6db004d9cb259f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, Apr 7, 2013 at 11:59 AM, John Levine &= lt;johnl@taugh.com= > wrote:
>This is the first I= 9;ve heard someone say OpenDMARC is hard to install. =A0So
>far the feedback has been the opposite.

The documentation is a bit sparse for the reporting part, and it woul= d
be nice to have a cheat sheet for the libraries.


--001a11c384788a6db004d9cb259f-- From superuser@gmail.com Sun Apr 7 13:38:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E82521F8F06 for ; Sun, 7 Apr 2013 13:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVMvM1K9vfp8 for ; Sun, 7 Apr 2013 13:38:06 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0C55621F8EEB for ; Sun, 7 Apr 2013 13:38:05 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id l18so5073275wgh.1 for ; Sun, 07 Apr 2013 13:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bPR0KghP+6xVzKv1Az6hU7yZbZwJ/AUrSQqJwtrePuk=; b=1C6rp28qBg01HzUXFxZQfh8NInxF6bvnu5prQiZQotbL48qFULioZ/jUlqqmFUebIX Yl6ttCSOD0gMCLIU08YolYBTf/ChIS6Ac6qEDIZ8gqoln/9wJ+JqhB5e/XmHIbGdd9lH 7sxtiSpQv5pxNSrIpkCzraI7C7uaYqy4UCD0HhNwQ9iCz/YhZDud+KrhwzF2KfwTo2KD IYf9R9MQszqvG2NfAQJZbe2P6iV8sHu32Z/KNo+PX/+QaoCUTbCpA314pipOBtuTTn11 SaEhWGOEFdYzxcZKZlLokitrz75rBshMkwpXwW+DXchKDbIUTL5c4DUyGmKCLKYto3OO Re4w== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr27629363wjb.17.1365367085250; Sun, 07 Apr 2013 13:38:05 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sun, 7 Apr 2013 13:38:05 -0700 (PDT) In-Reply-To: <1CBBDC25A6754A1B9348CF0A3D785C12@fgsr.local> References: <20130407010548.38641.qmail@joyce.lan> <1CBBDC25A6754A1B9348CF0A3D785C12@fgsr.local> Date: Sun, 7 Apr 2013 13:38:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7b5d8cff1abccf04d9cb4c68 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 20:38:07 -0000 --047d7b5d8cff1abccf04d9cb4c68 Content-Type: text/plain; charset=ISO-8859-1 The issue isn't so much whether Mailman has an option to support it, but rather what corners of the deployed email infrastructure are going to be unable or unwilling to comply for whatever reason. New or well-maintained deployments can benefit, but anything upon which a lot of people depend that doesn't enjoy such attention and flexibility will become a pain point. I don't think it's a winning strategy to decide that the people who would be thus affected will just have to suffer. To be more specific: What about sites that don't run Mailman? There are some pretty big and busy lists out there that run the original Majordomo. On Sun, Apr 7, 2013 at 1:20 PM, J. Gomez wrote: > On Sunday, April 07, 2013 3:05 AM [GMT+1=CET], John Levine wrote: > > > > > For the zillionth time, there is no chance whatsoever that > > > > Mailman and other open source list managers will change to work > > > > around DMARC's limitations. I wish people would stop wasting time > > > > by claiming otherwise. > > > > > > Is this assetion based on the comtemplation of some magic cristal > > > ball for the future? > > > > No, it's based on having run mailing lists for several decades, > > switching among too many list management packages. I run about 100 > > lists, of which about 30 have an interesting amount of traffic. > > > > Just for reference, have you ever run a mailing list? How many list > > management systems are you familiar with? > > Argument from authority ( > http://en.wikipedia.org/wiki/Argument_from_authority ) while warranted, > is not of special value to predict the future. > > Mailman already has an option to become DMARC-compatible. If that option > would become the default configuration for "Mailman out-of-the-box", then > all would be fine. > > The option is in General Options -> anonymous_list, set to Yes. This puts > the mailing list address in the RFC5322.From header in the emails the > mailing list software forwards to its subscribers. Do you see any problem > in that option? > > With time, things do change. Several decades is about time for a change. > > Regards, > > J. Gomez > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7b5d8cff1abccf04d9cb4c68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The issue isn't so much whether Mailman has an option = to support it, but rather what corners of the deployed email infrastructure= are going to be unable or unwilling to comply for whatever reason.=A0 New = or well-maintained deployments can benefit, but anything upon which a lot o= f people depend that doesn't enjoy such attention and flexibility will = become a pain point.=A0 I don't think it's a winning strategy to de= cide that the people who would be thus affected will just have to suffer.
To be more specific: What about sites that don't run Mailman?=A0 Th= ere are some pretty big and busy lists out there that run the original Majo= rdomo.



On Sun, Apr 7, 2013 at 1:20 PM, J. Gomez <jgomez@seryrich.com> wrote:
On Sunday, April 07, 2013 3:05 AM [GMT+1=3DCET], John Lev= ine wrote:

> > > For the zillionth time, there is no chance whatsoever that > > > Mailman and other open source list managers will change to w= ork
> > > around DMARC's limitations. I wish people would stop was= ting time
> > > by claiming otherwise.
> >
> > Is this assetion based on the comtemplation of some magic cristal=
> > ball for the future?
>
> No, it's based on having run mailing lists for several decades, > switching among too many list management packages. =A0I run about 100<= br> > lists, of which about 30 have an interesting amount of traffic.
>
> Just for reference, have you ever run a mailing list? =A0How many list=
> management systems are you familiar with?

Argument from authority ( http://en.wikipedia.org/wiki/Argume= nt_from_authority ) while warranted, is not of special value to predict= the future.

Mailman already has an option to become DMARC-compatible. If that option wo= uld become the default configuration for "Mailman out-of-the-box"= , then all would be fine.

The option is in General Options -> anonymous_list, set to Yes. This put= s the mailing list address in the RFC5322.From header in the emails the mai= ling list software forwards to its subscribers. Do you see any problem in t= hat option?

With time, things do change. Several decades is about time for a change.
Regards,

J. Gomez

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

--047d7b5d8cff1abccf04d9cb4c68-- From superuser@gmail.com Sun Apr 7 13:40:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D65921F8EFE for ; Sun, 7 Apr 2013 13:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqMBTGQ1j5B8 for ; Sun, 7 Apr 2013 13:40:01 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE5221F8503 for ; Sun, 7 Apr 2013 13:40:01 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u12so4070568wey.5 for ; Sun, 07 Apr 2013 13:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=le+RNMSMrw6HAb+TZ3C6KlNExtjFrDbUYU+ONvoYHFg=; b=IDKxPcrGFBCunuLanxRy4ky8SELXWmk4tirMfFLGS6AVdMo3wrgYLV56qcG2hkGl0f 5HI8mqMWV1Nvz9w/xCXuyDckUGPG+AhFqfwqmgnPvCYosaDlNpW7W/KV71eRGGGrlKhl W8SibnpCe5WumKxVg8okcE2T5hi8UMdYvnxhllbQFqF1t7sAsRQhAkmELpJS8HWOMIRX n561pVHlbvsPToCcPoSmIzOY9uyIIxdDoeaqEkGILBzf6f/FedEH+DZ30sq4b5BkDS52 C7Y/OOnoCr22nFkrfhaqgymsL28vhY94z1tODBxKvsyA34+4NIn2jxJnPlr/PMaQl9Ok rPkQ== MIME-Version: 1.0 X-Received: by 10.180.74.67 with SMTP id r3mr9064684wiv.14.1365367200377; Sun, 07 Apr 2013 13:40:00 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sun, 7 Apr 2013 13:40:00 -0700 (PDT) In-Reply-To: <3BA3E5A21E4A4DA880384707233C4FE1@fgsr.local> References: <20130405181120.30162.qmail@joyce.lan> <3BA3E5A21E4A4DA880384707233C4FE1@fgsr.local> Date: Sun, 7 Apr 2013 13:40:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d0438914df7740704d9cb52c8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 20:40:02 -0000 --f46d0438914df7740704d9cb52c8 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 6, 2013 at 4:26 PM, J. Gomez wrote: > If DMARC is going to be successful, it will be so when you can implement > "p=reject", which is not compatible with the current state of the art in > mailing list software and common behaviour. > > If you cannot, as a sender, annouce "p=reject" for DMARC, then DMARC is > not going to help you much as a sender, except for its reporting > capabilities. > > > We have already heard from some senders for whom "p=none" plus reporting is already extremely attractive. Let's not decide it's a failure just because "p=reject" has a more limited use case than some people would like. --f46d0438914df7740704d9cb52c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 6, 2013 at 4:26 PM, J. Gomez <jgomez@seryri= ch.com> wrote:
If DMARC is going to be successful, it will = be so when you can implement "p=3Dreject", which is not compatibl= e with the current state of the art in mailing list software and common beh= aviour.

If you cannot, as a sender, annouce "p=3Dreject" for DMARC, then = DMARC is not going to help you much as a sender, except for its reporting c= apabilities.



We have already heard from some se= nders for whom "p=3Dnone" plus reporting is already extremely att= ractive.=A0 Let's not decide it's a failure just because "p=3D= reject" has a more limited use case than some people would like.

--f46d0438914df7740704d9cb52c8-- From superuser@gmail.com Sun Apr 7 13:45:54 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A178121F8F08 for ; Sun, 7 Apr 2013 13:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZyYf5E98fDE for ; Sun, 7 Apr 2013 13:45:53 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 76F0621F8916 for ; Sun, 7 Apr 2013 13:45:53 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k13so3169731wgh.5 for ; Sun, 07 Apr 2013 13:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ag7hx45I5+lgidFS+WodJk2uHSB1kKv7sJiEKmXDcsA=; b=EDmC/IbFe3temWixn6M3ZjnYDguoGMLBce0NCUw9NK5hHQo02r2lvEzYzlZgVEX7VZ anCBVcjGeIegZvehufs0RUaL8WaZ6+/NKcV19m52ExY3AZ1CfHZJBsSMtFZjGpI5Y+L0 +1sAH/aBtRFdU07vCiegnqcTRxl76GzmirniLLejUgBu3DXvjUQoS0bUVLA4oma83wOZ buwiop92GaKXi6jJdP+gflJql+xghJmfLCeZwARbcVVtv4cSLTwyb/OdDkQvQrocztEP OtOCk0EYwhvIuP29LbFRiCklIbp6flCQaz/6ep09c+nSTqbSK9lkRzLLLBljeyegavGx FQpw== MIME-Version: 1.0 X-Received: by 10.180.101.41 with SMTP id fd9mr8996438wib.20.1365367552643; Sun, 07 Apr 2013 13:45:52 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sun, 7 Apr 2013 13:45:52 -0700 (PDT) In-Reply-To: <4ED3405772FA4FA3B3E8CFA8D720D72D@fgsr.local> References: <20130406213432.74072.qmail@joyce.lan> <4ED3405772FA4FA3B3E8CFA8D720D72D@fgsr.local> Date: Sun, 7 Apr 2013 13:45:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d041826c2f69c0004d9cb6726 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 20:45:54 -0000 --f46d041826c2f69c0004d9cb6726 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 6, 2013 at 5:04 PM, J. Gomez wrote: > If the major mailbox providers (Hotmail, Gmail, Yahoo, AOL, etc.) > implement DMARC to the tee, mailing list software will either change to be > compatible with DMARC or die. > I think this logic presupposes that all sent mail will at some point in the future be covered by DMARC "p=reject" policies. It's already been stated that "p=reject" is not intended to be used by all senders. Perhaps the draft needs to be more assertive about this point. Suppose we make it clear that "p=reject" is only for transactional mail, or marketing mail from addresses that don't have users; user mail comes from another domain or a subdomain that's not guarded by DMARC. It seems unlikely transactional mail would even transit lists (would you subscribe to get your bank statements via a list? or marketing mail?), so DMARC doesn't need to interact with lists at all. > I bet that if the major mailbox providers implement DMARC to the tee, > mailing list software will change to become compatible with DMARC. > I think several have, and I don't think list servers are feeling this pressure. Maybe I just don't have all the information yet. > The other option is DMARC does not gain traction, and/or it is implemented > in the real world with receivers ignoring the "p=reject" policy, which > would mean DMARC would become mostly useless. > I think that's also a pretty long jump logic-wise. The traction is already there, and "p=reject" is already being honoured in at least some places. The sky doesn't appear to be falling so far. Will mailing list sofware go through all this trouble? Nobody knows, but if > DMARC becomes an industry standard, it may well be the case. > As you've observed, at least one implementation has the option. As you've also observed, time will tell whether it becomes necessary to default it "on". We ran through this debate with ADSP years ago. The solutions then are the same as the solutions now, as far as I can tell. -MSK --f46d041826c2f69c0004d9cb6726 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 6, 2013 at 5:04 PM, J. Gomez <jgomez@seryri= ch.com> wrote:
If the major mailbox providers (Hotmail, Gma= il, Yahoo, AOL, etc.) implement DMARC to the tee, mailing list software wil= l either change to be compatible with DMARC or die.

I think this logic presupposes that all se= nt mail will at some point in the future be covered by DMARC "p=3Dreje= ct" policies.=A0 It's already been stated that "p=3Dreject&qu= ot; is not intended to be used by all senders.=A0 Perhaps the draft needs t= o be more assertive about this point.

Suppose we make it clear that "p=3Dreject" is only= for transactional mail, or marketing mail from addresses that don't ha= ve users; user mail comes from another domain or a subdomain that's not= guarded by DMARC.=A0 It seems unlikely transactional mail would even trans= it lists (would you subscribe to get your bank statements via a list?=A0 or= marketing mail?), so DMARC doesn't need to interact with lists at all.=
=A0
I bet that if the major mailbox providers implement DMARC to the tee, maili= ng list software will change to become compatible with DMARC.

I think several have, and I don't think list ser= vers are feeling this pressure.=A0 Maybe I just don't have all the info= rmation yet.
=A0
The other option is DMARC does not gain traction, and/or it is implemented = in the real world with receivers ignoring the "p=3Dreject" policy= , which would mean DMARC would become mostly useless.

I think that's also a pretty long jump logic-wise.=A0 Th= e traction is already there, and "p=3Dreject" is already being ho= noured in at least some places.=A0 The sky doesn't appear to be falling= so far.

Will mailing list sofware go through all this trouble? Nobody knows, but if= DMARC becomes an industry standard, it may well be the case.

As you've observed, at least one implementation = has the option.=A0 As you've also observed, time will tell whether it b= ecomes necessary to default it "on".

We ran through this debate with ADSP years ago.=A0 The solut= ions then are the same as the solutions now, as far as I can tell.

-MSK
--f46d041826c2f69c0004d9cb6726-- From prvs=802a6e817=fmartin@linkedin.com Sun Apr 7 14:33:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B199521F850F for ; Sun, 7 Apr 2013 14:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWfI5tJ-fRNx for ; Sun, 7 Apr 2013 14:33:43 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id BA3D521F8F2A for ; Sun, 7 Apr 2013 14:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365370423; x=1396906423; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=QJ9iuEfgKQQyYrKtC126+P3uwAKUk6LL/C0GY6vI7L4=; b=wK4ZQ3d3wgy3RgihfhRYla70LQVj/iT+Lx3DnKkNcz595EpnElxMYCj9 W4n1VbjiNMT+4jrJoFRtOrskbNh2/3GO8oBALgvhyNbFdy+t+1K3g9fYu wg9XiCVhw8Mjgb6QZpUdag2MrS0pEQhtcs9vwGjzK19lZWjz45o5OxYYg 0=; X-IronPort-AV: E=Sophos;i="4.87,427,1363158000"; d="scan'208";a="44457906" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Sun, 7 Apr 2013 14:33:36 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Sun, 7 Apr 2013 14:33:36 -0700 From: Franck Martin To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] not about outsourcing strategies, and a newbie's question Thread-Index: AQHOM9eP6bBrjBr/IEa3LAvhuGoAqw== Date: Sun, 7 Apr 2013 21:33:35 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EC9F7D@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="utf-8" Content-ID: <65EFF3D936B1EB46979EEAD008BE241A@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 21:33:44 -0000 VGhhbmtzLCBiZXN0IGV4cGxhbmF0aW9uIG9uIHRoaXMgc3ViamVjdCBJIGhhdmUgc2VlbiBzbyBm YXIuDQoNCk9uIDQvNi8xMyA0OjQ2IFBNLCAiSi4gR29tZXoiIDxqZ29tZXpAc2VyeXJpY2guY29t PiB3cm90ZToNCg0KPk9uIFNhdHVyZGF5LCBBcHJpbCAwNiwgMjAxMyAxMDo1MyBQTSBbR01UKzE9 Q0VUXSwgRnJhbmNrIE1hcnRpbiB3cm90ZToNCj4+IEkgY2Fubm90IGZpbmQgYW55IGFydGljbGUg ZGVzY3JpYmluZyBjb25kaXRpb25zIHdoZW4gRXhjaGFuZ2UNCj4+IGJyZWFrL2Rvbid0IGJyZWFr IERLSU0gd2hlbiBmb3J3YXJkaW5nLi4uIElmIHNvbWVvbmUgaGFzIGEgcG9pbnRlcj8NCj4NCj5N aWNyb3NvZnQgRXhjaGFuZ2UgbW9zdCBkZWZpbmV0bHkgYnJlYWtzIERLSU0gKCopIGluIGFscmVh ZHkgcmVjZWl2ZWQNCj5lbWFpbCBtZXNzYWdlcy4gTWljcm9zb2Z0IEV4Y2hhbmdlIHN0b3JlcyB0 aGUgcmVjZWl2ZWQgbWVzc2FnZXMgaW4gaXQncw0KPm93biBwcm9wcmlldGFyeSBUTkVGIGZvcm1h dCwgd2ljaCB5b3UgY2FuIG9ubHkgYWNjZXNzIHRocm91Z2ggTUFQSSwgd2hpY2gNCj5wcmV0eSBt dWNoIG1lYW5zIG9ubHkgdGhyb3VnaCBPdXRsb29rLiBJZiB5b3UgYWNjZXNzIHRoZSBtZXNzYWdl cyBpbiBhbg0KPkV4Y2hhbmdlIG1haWxib3ggdGhyb3VnaCBQT1AzIG9yIElNQVAsIHlvdSBnZXQg YSAidHJhbnNsYXRpb24iIG9uLXRoZS1mbHkNCj5vZiB0aGUgYm9keSBvZiB0aGUgbWVzc2FnZSBk b25lIGJ5IEV4Y2hhbmdlIGZyb20gaXRzIGludGVybmFsIFRORUYgZm9ybWF0DQo+dG8gIndoYXRl dmVyIiAoKiopICgqKiopLg0KPg0KPg0KPigqKSBUaGF0IGhhcHBlbnMgZm9yIHN1cmUgd2hlbiBh IG1lc3NhZ2UgbGFuZHMgaW4gYW4gRXhjaGFuZ2UgbWFpbGJveC4NCj5CdXQgSSBjYW4gbm90IHNh eSBhYm91dCBhIHB1cmUgZm9yd2FyZGluZyBzY2VuYXJpbyB3aGVyZSB0aGUgZm9yd2FyZGVkDQo+ bWVzc2FnZSBkb2VzIG5vdCBsYW5kIGludG8gYSBFeGNoYW5nZSBtYWlsYm94Lg0KPg0KPigqKikg IldoYXRldmVyIiBieSBkZWZhdWx0IGlzICJCZXN0Qm9keUZvcm1hdCIsIHdoaWNoIG1lYW5zIEV4 Y2hhbmdlIHdpbGwNCj5wcmVzZW50IHlvdSB3aXRoIGFuIGFwcm94aW1hdGlvbiB0byB0aGUgb3Jn aW5hbCBjb250ZW50IG9mIHRoZSBtZXNzYWdlDQo+d2hlbiBpdCBzZXJ2ZXMgdGhlIG1lc3NhZ2Ug dG8geW91IHRocm91Z2ggUE9QMyBvciBJTUFQLiBTZWU6DQo+aHR0cDovL2VzdXBwb3J0Lmxlbm92 by5jb20vbXNzL21zcy5wbD9kb2N0eXBlPWtiJmRvY2lkPU9UUTBNVFV6DQo+aHR0cHM6Ly9ncm91 cHMuZ29vZ2xlLmNvbS9mb3J1bS8/ZnJvbWdyb3Vwcz0jIXRvcGljL1dBR0lUL0QxNll5Z3Q0eG1v DQo+aHR0cDovL2ZvcnVtcy5tb3ppbGxhemluZS5vcmcvdmlld3RvcGljLnBocD9mPTM5JnQ9NjI4 Njc4DQo+DQo+KCoqKikgVGhpcyAidHJhbnNsYXRpb24iIGlzIGEgbW9kaWZpY2F0aW9uIG9mIHRo ZSBtZXNzYWdlIGFuZCB0aGVyZWZvcmUNCj5vYnZpb3VzbHkgYnJlYWtzIHRoZSBES0lNIHNpZ25h dHVyZS4NCj4NCj5SZWdhcmRzLCANCj4NCj5KLiBHb21leg0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ZG1hcmMgbWFpbGluZyBsaXN0DQo+ZG1h cmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJj DQoNCg== From johnl@iecc.com Sun Apr 7 14:53:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F9D21F8526 for ; Sun, 7 Apr 2013 14:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.736 X-Spam-Level: X-Spam-Status: No, score=-110.736 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_16=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yBrHXxIPa1T for ; Sun, 7 Apr 2013 14:53:44 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D63C921F8523 for ; Sun, 7 Apr 2013 14:53:43 -0700 (PDT) Received: (qmail 13340 invoked from network); 7 Apr 2013 21:53:43 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Apr 2013 21:53:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5161eae6.xn--yuvv84g.k1304; i=johnl@user.iecc.com; bh=B2U0NBN//0PErpIooCFv4r1UkeIpVMz0J9i5yVvZuDA=; b=dbe9Iq24ojV8j0WgBNPuqF5Uo6/LGhs9OE54G29+4cicA2ifVTZilDf5/OQE+BylS4M+xtSeNJ4k0hrO5nMEwyDpQsveVmDAtXh2/tM8jpKKcILpCyzgWQHuvJ2FViA4wBi1det1oCFH8PaZCDsMRYn0I5LBsXWBvu3ezuVwp50= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5161eae6.xn--yuvv84g.k1304; olt=johnl@user.iecc.com; bh=B2U0NBN//0PErpIooCFv4r1UkeIpVMz0J9i5yVvZuDA=; b=usaq+2iyCdxmjZ5G+84PIflygArh+ofJXRaVQmMAgNdn4xQu1szzB24PxAibhib98HTbLECnnBvz/b03Gss16QhcOFkcby1MQ2T3Gx7ccMbPU3Gu+A2S45ZdNHG32zRxQ3nmHW1pCmXzqAL8XVSFRcmB2qcjR0t+v8jcs6oUzbI= Date: 7 Apr 2013 21:53:20 -0000 Message-ID: <20130407215320.78859.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 21:53:44 -0000 >The issue isn't so much whether Mailman has an option to support it, but >rather what corners of the deployed email infrastructure are going to be >unable or unwilling to comply for whatever reason. Unwilling is the key point. Mailman has had the anonymous_list option for a long time, but nobody uses it because the stuff that regular lists do like adding subject tags is useful. That won't change, and it's not because the people who run mailing lists are stupid or ignorant. As I said before, and should be apparent to people who are familiar with mailing list operation, this shouldn't be a big deal in practice so long as senders understand why they have to publish DMARC policies that reflect their actual practices, and not incorrectly say p=reject because they wrongly imagine it to be "more secure". R's, John From jgomez@seryrich.com Sun Apr 7 15:22:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D68221F8F06 for ; Sun, 7 Apr 2013 15:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ77wYv03cIm for ; Sun, 7 Apr 2013 15:22:07 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id A163F21F8EDF for ; Sun, 7 Apr 2013 15:22:06 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Apr 2013 00:22:05 +0200 Message-ID: From: "J. Gomez" To: References: <20130407215320.78859.qmail@joyce.lan> Date: Mon, 8 Apr 2013 00:23:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 07 Apr 2013 22:22:07 -0000 On Sunday, April 07, 2013 11:53 PM [GMT+1=3DCET], John Levine wrote: > > The issue isn't so much whether Mailman has an option to support > > it, but rather what corners of the deployed email infrastructure > > are going to be unable or unwilling to comply for whatever reason. >=20 > As I said before, and should be apparent to people who are familiar > with mailing list operation, this shouldn't be a big deal in practice > so long as senders understand why they have to publish DMARC policies > that reflect their actual practices, and not incorrectly say = p=3Dreject > because they wrongly imagine it to be "more secure". My guess is that "p=3Dreject" will become in wider and wider use as = years past after DMARC is born to the public email ecosystem, just as = "-all" is becoming in wider and wider use as years are passing after SPF = was born to the public email ecosystem. It's the natural thing to do: = "Oh, look, a hammer! Hmm, I guess what it will do to this spam nail = problem..." You are right that "p=3Dreject" will not reflect faithfully the real = practice of many Organizational Domains, but nonetheless many = Organizational Domains will set "p=3Dreject" anyways, it's such a = promising hammer... Reject, J. Gomez From vesely@tana.it Mon Apr 8 01:53:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42521F8EB2 for ; Mon, 8 Apr 2013 01:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.519 X-Spam-Level: X-Spam-Status: No, score=-4.519 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWRNe4XNACZy for ; Mon, 8 Apr 2013 01:53:38 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 33DA921F8DEF for ; Mon, 8 Apr 2013 01:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365411216; bh=ILp2HNsX8XyhvLhtyaxVpqKNZ/8bDCfAA5lFE+6DRRc=; l=1549; h=Date:From:To:References:In-Reply-To; b=DXfw5l/9ZQiNuZnxHXCfD2vV6pt1aK+AurXaUTkWbhxX+s/4U+y7H6yZ44c4dvh6Z btGQUjNDC9arvFzR1668Ps4gseVfOKTUaGc9J4Upj64gwdjoKp7eV2Gul2YddJuEPJ bs3bKFAgJKF0qV0VXlF+S1s0lWzutExXneZgnMMA= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 08 Apr 2013 10:53:36 +0200 id 00000000005DC042.0000000051628590.00007A3C Message-ID: <51628590.5050703@tana.it> Date: Mon, 08 Apr 2013 10:53:36 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130405181120.30162.qmail@joyce.lan> <3BA3E5A21E4A4DA880384707233C4FE1@fgsr.local> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 08:53:39 -0000 On Sun 07/Apr/2013 22:40:00 +0200 Murray S. Kucherawy wrote: > On Sat, Apr 6, 2013 at 4:26 PM, J. Gomez wrote: > >> If you cannot, as a sender, announce "p=reject" for DMARC, then >> DMARC is not going to help you much as a sender, except for its >> reporting capabilities. > > We have already heard from some senders for whom "p=none" plus > reporting is already extremely attractive. Let's not decide it's a > failure just because "p=reject" has a more limited use case than > some people would like. It is definitely extremely attractive and useful! Yet there are some points where reports can be improved. And one of them is mailing lists: Some reports have a "mailing_list" entry in the "reason and disposition" column. Now, one can reckon that feedback never hurts, or rather that it is fairly interesting to evaluate which mail sites turn out to be the targets chosen by the subscribers of a given list. However, I don't think that's what DMARC reports are for. That extra information is not only distracting for the recipient, but also a leakage from the reporter. For senders, it is difficult and questionable to limit an email domain to transactional mail only. A company would need to force users to hide behind external free-mail accounts, obscuring their own brand. Or they could set up subdomains, calling upon the public to discriminate between the secure and the insecure ones. Not an alluring prospect. IMHO DMARC had better handle mailing lists properly, if at all possible. From sweet@secondlook.com Mon Apr 8 08:32:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAEC21F8CF0 for ; Mon, 8 Apr 2013 08:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.679 X-Spam-Level: * X-Spam-Status: No, score=1.679 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45MZo1mk7qJm for ; Mon, 8 Apr 2013 08:32:35 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id CCAF521F9593 for ; Mon, 8 Apr 2013 08:32:34 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id p13so3823948vbe.7 for ; Mon, 08 Apr 2013 08:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=KLLj3aiUhsgvPC9KLPt5x8fsxDoFo1JeqXoUJUyoANM=; b=R3GcsAIpiNpkW6ThTHkHTT1qKHEYXxjjANqcsyhSsAbRah843IXuS+rnQl+cjPpOgb DmsegI6vTybESnk9grxPYI11fHjDpma+didQlYJGY5s1QZJyP4qOcp/X/BC2YrWd9wsh WbvUeBts45vZtMWAdKSiCUk8cjN/U7jGwD6ow= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:content-type:x-gm-message-state; bh=KLLj3aiUhsgvPC9KLPt5x8fsxDoFo1JeqXoUJUyoANM=; b=PwaKch0088l4/k0BHOt1N5PNCEG5Qu5/ggaJYawZlqj0JPxwTTWqq3k1pk/OgQaNNs o4je5WeC+3KBy7PZMK6VZ67DCWWNkn5AUrMz061+4pEhX6MvmOGTRgNp7YX9Hq+CB1Gw gV2kzPQqSt8tZ5viJ13ZSs40OtjeID34VjSMp7aJ1JwGvRrnihAepUgJsMaYMsCPqjvi JjZ1FiTL1rnWMfo7PbG5FuhtEeE4BY0+VlnETSwRKt3w2RU5YUw4w7B3DphgyZknDuwN IqbzpgoFQ0xepH8naiGnwC7rL7cxbnPlomLKPjd+oPEv9mZvyxZ6uejZs7jl3OVPBBpE Oa4Q== X-Received: by 10.220.9.3 with SMTP id j3mr16179666vcj.56.1365435154128; Mon, 08 Apr 2013 08:32:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.84.72 with HTTP; Mon, 8 Apr 2013 08:32:13 -0700 (PDT) X-Originating-IP: [70.36.144.2] In-Reply-To: References: <20130406213432.74072.qmail@joyce.lan> <4ED3405772FA4FA3B3E8CFA8D720D72D@fgsr.local> From: John Sweet Date: Mon, 8 Apr 2013 08:32:13 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn0FjxDyYBs+LW3X0Aoi5/xD/NvJ7ve/4IjQbNMaA9BZDaPY1jpJyjYcUd3eW2PhJoVshJQ Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 15:32:36 -0000 On Sun, Apr 7, 2013 at 1:45 PM, Murray S. Kucherawy wrote: > I think this logic presupposes that all sent mail will at some point in the > future be covered by DMARC "p=reject" policies. It's already been stated > that "p=reject" is not intended to be used by all senders. Perhaps the > draft needs to be more assertive about this point. > > Suppose we make it clear that "p=reject" is only for transactional mail, or > marketing mail from addresses that don't have users; user mail comes from > another domain or a subdomain that's not guarded by DMARC. I'd agree with that. At a DMARC talk recently, someone (maybe you, maybe Paul Midgen) said that right from the outset: it's not for all your mail. It might even have been on the first slide. For addresses that do have users, I can see the value of a permanent p=none policy, for monitoring. An organization may need to enforce an email usage policy, but be unable to back it up with an SPF -all or DMARC p=reject. Reporting makes it possible to track and mitigate taboo usage. The only issue might be spam filters assigning any DMARC failure a score, making it more likely a mailing list digest will end up in someone's spam folder. But we pretty much already live in that world (wrt SPF and DKIM), and I'd expect the filters to evolve over time. J From prvs=803f2c92d=fmartin@linkedin.com Mon Apr 8 09:22:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7684321F93B4 for ; Mon, 8 Apr 2013 09:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.735 X-Spam-Level: X-Spam-Status: No, score=-5.735 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8McNAsbFWrZ for ; Mon, 8 Apr 2013 09:22:37 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id CDABE21F8556 for ; Mon, 8 Apr 2013 09:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365438157; x=1396974157; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=9dgIMVuvZPYMnFh2efPhvBbZM4/pNvIFsrH53a0zGxU=; b=n/Ad17uazp6JRxYQODQY3JqKma+uyula/B2uLz5vAVSdXOI8YH6J4AYS /6blAEwa07kbZEFgAYt0QjlP+GQXCmiUUAFDG9yJ6qmst31WzzVuKS0FL lZQvt5OnJgUOmwtby6W4KqmJ7ZzCrzkuK0mIIyVQei1Bz8xNI2cdT/X6R c=; X-IronPort-AV: E=Sophos;i="4.87,432,1363158000"; d="scan'208";a="44543850" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 8 Apr 2013 09:22:29 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Mon, 8 Apr 2013 09:22:29 -0700 From: Franck Martin To: Alessandro Vesely , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] not about outsourcing strategies, and a newbie's question Thread-Index: AQHONDaXLwl0GKv090GafOlHVeKS05jMghyA Date: Mon, 8 Apr 2013 16:22:29 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52ECF36D@ESV4-MBX01.linkedin.biz> In-Reply-To: <51628590.5050703@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: text/plain; charset="utf-8" Content-ID: <4E5C01C70FFFBA4D8CCDFD41743ED6B5@linkedin.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 16:22:39 -0000 DQoNCk9uIDQvOC8xMyAxOjUzIEFNLCAiQWxlc3NhbmRybyBWZXNlbHkiIDx2ZXNlbHlAdGFuYS5p dD4gd3JvdGU6DQoNCj4NCj5Gb3Igc2VuZGVycywgaXQgaXMgZGlmZmljdWx0IGFuZCBxdWVzdGlv bmFibGUgdG8gbGltaXQgYW4gZW1haWwgZG9tYWluDQo+dG8gdHJhbnNhY3Rpb25hbCBtYWlsIG9u bHkuICBBIGNvbXBhbnkgd291bGQgbmVlZCB0byBmb3JjZSB1c2VycyB0bw0KPmhpZGUgYmVoaW5k IGV4dGVybmFsIGZyZWUtbWFpbCBhY2NvdW50cywgb2JzY3VyaW5nIHRoZWlyIG93biBicmFuZC4N Cj5PciB0aGV5IGNvdWxkIHNldCB1cCBzdWJkb21haW5zLCBjYWxsaW5nIHVwb24gdGhlIHB1Ymxp YyB0bw0KPmRpc2NyaW1pbmF0ZSBiZXR3ZWVuIHRoZSBzZWN1cmUgYW5kIHRoZSBpbnNlY3VyZSBv bmVzLiAgTm90IGFuDQo+YWxsdXJpbmcgcHJvc3BlY3QuDQoNCnNwbGl0dGluZyB0aGUgZW1haWwg ZG9tYWluIGludG8gdGhlIGJyYW5kIG5hbWUgYW5kIHRoZSBicmFuZCBuYW1lIC1pbmMgaGFzDQpi ZWVuIGRvbmUgYnkgc29tZSwgYnV0IHNvbWUgb3RoZXJzIGRvIG5vdCBsaWtlIGl0LiBTYXkgeW91 IGludGVyYWN0IHdpdGgNCmN1c3RvbWVycywgeW91IHdhbnQgdG8gZW1haWwgZnJvbSB0aGUgYnJh bmQgZG9tYWluIG5vdCB0aGUgY29ycG9yYXRlDQpkb21haW4sIGl0IGNyZWF0ZXMgY29uZnVzaW9u IGZvciB0aGUgc2VuZGVyIHRvby4NCg0KPg0KPklNSE8gRE1BUkMgaGFkIGJldHRlciBoYW5kbGUg bWFpbGluZyBsaXN0cyBwcm9wZXJseSwgaWYgYXQgYWxsIHBvc3NpYmxlLg0KDQpCZXNpZGVzIHNv bWUgd2lkZWx5IHVzZWQgTVRBcyBicmVha2luZyBES0lNIHNpZ25hdHVyZXMgd2hlbiBmb3J3YXJk aW5nLA0KdGhlIG9ubHkgb3RoZXIgcHJvYmxlbSBpcyBtYWlsaW5nIGxpc3RzIGFzIHlvdSBwb2lu dC4gVGhlcmUgaXMgYW4NCmFsdGVybmF0aXZlIHRvIHRoaXMgcHJvYmxlbSBpcyB0byByZXF1aXJl cyBlbXBsb3llZXMgb2YgYnJhbmRzIHRvIHVzZSBhDQpwZXJzb25hbCBlbWFpbCBhZGRyZXNzIHRv IGpvaW4gbWFpbGluZyBsaXN0cy4gSXQgc2VydmVzIHR3byBwdXJwb3Nlcy4NCjEpIHA9cmVqZWN0 IGNhbiBiZSBhcHBsaWVkLCBhbmQgdG9vIGJhZCBpZiB0aGUgZW1wbG95ZWUgZGlkIG5vdCBmb2xs b3cNCmNvbXBhbnkgcG9saWN5IGFuZCBkb24ndCBoYXZlIGhpcy9oZXIgZW1haWwgZGVsaXZlcmVk LA0KMikgb25lIG1heSB0aGluayBiZWNhdXNlIHRoZSBwZXJzb24gdXNlIGFuIGVtYWlsIGFkZHJl c3MgdXNpbmcgdGhlIGJyYW5kDQpkb21haW4gaXMgYSBzcG9rZXNwZXJzb24gZm9yIHNheSBjb21w YW55LiBPYmxpZ2luZyBwZW9wbGUgdG8gdXNlIGENCnBlcnNvbmFsIGVtYWlsIGFkZHJlc3MsIGlu IHNvbWUgbGFyZ2UgY29tcGFuaWVzLCBjb3VsZCBhbGlnbiB3aXRoDQpyZXN0cmljdGlvbnMgb24g cHVibGljIHNwZWFraW5nIG9mIGVtcGxveWVlcw0KDQo= From johnl@iecc.com Mon Apr 8 12:11:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C30821F94AF for ; Mon, 8 Apr 2013 12:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.73 X-Spam-Level: X-Spam-Status: No, score=-110.73 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_16=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fi-zdhNf4Ip for ; Mon, 8 Apr 2013 12:11:34 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2A821F89C3 for ; Mon, 8 Apr 2013 12:11:33 -0700 (PDT) Received: (qmail 47826 invoked from network); 8 Apr 2013 19:11:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 8 Apr 2013 19:11:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51631663.xn--30v786c.k1304; i=johnl@user.iecc.com; bh=MZULZTUbIetPZT9qBUlBmh4e55og8XNhIBv9AUMd7uI=; b=fVabTo0Hw1xoNPxms513OLGvS8Z9To48rXBNjmutzW1qi7cdH5MbSQK3TGkPITb9MML4OixMNZFaw6GTRHCmj81mvlAmKCbtY2l6Xl6NJD3kxT41Z3W3z+zrdWvUzm9cxOmJF74GmkUqfwiRzbXj19r0nUpzBRzqmt7AUlgdfBg= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51631663.xn--30v786c.k1304; olt=johnl@user.iecc.com; bh=MZULZTUbIetPZT9qBUlBmh4e55og8XNhIBv9AUMd7uI=; b=gKFBEu6ilQzy4gsQX9OO5xYnoixDCTH1nDl3oLGXX5RlSl3cUP6bGnG9i++7Z9Jn8jloTrZkHeO1CnqcdeVlXlSKByWd9VKUhwSDG1iFKrq6FECdrG2c7hZdbh2xV+lu3bvZY53Oy6vTxErg3OwH1qN20qno0/CHMHWhU0nVUfA= Date: 8 Apr 2013 19:11:09 -0000 Message-ID: <20130408191109.85674.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <51628590.5050703@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 19:11:35 -0000 >For senders, it is difficult and questionable to limit an email domain >to transactional mail only. That's simply untrue. Lots of companies use one domain for transactions and another for individual mail. Ask Paypal if you don't believe me. To look at it another way, if it's not worth your effort to change your mail setup to separate the transactions that merit p=reject from the live users who don't, it's not worth the effort for the rest of the world to change their mail setup to work around you, either. R's, John From jgomez@seryrich.com Mon Apr 8 12:31:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DA021F93C4 for ; Mon, 8 Apr 2013 12:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNAXOajQEXLg for ; Mon, 8 Apr 2013 12:31:39 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 95BA021F89D3 for ; Mon, 8 Apr 2013 12:31:38 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Apr 2013 21:31:36 +0200 Message-ID: <27D29611D193440E84A46318009E58F5@fgsr.local> From: "J. Gomez" To: References: <20130408191109.85674.qmail@joyce.lan> Date: Mon, 8 Apr 2013 21:32:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 19:31:39 -0000 On Monday, April 08, 2013 9:11 PM [GMT+1=3DCET], John Levine wrote: > > For senders, it is difficult and questionable to limit an email > > domain to transactional mail only. >=20 > That's simply untrue. Lots of companies use one domain for > transactions and another for individual mail. Ask Paypal if you don't > believe me. So if you are not Paypal-size or if you don't have Paypal-equivalent = technical resources, but you still care about making your brand = resilient to spoofing, tough luck!, no DMARC for you. Anyway, I bet p=3Dreject will get more and more adopted with the years, = and I sure hope your whitelisting file is on a big enough filesystem... Regards, J. Gomez From jgomez@seryrich.com Mon Apr 8 12:39:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3263121F85F5 for ; Mon, 8 Apr 2013 12:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.314 X-Spam-Level: X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iec0rUEOKLEa for ; Mon, 8 Apr 2013 12:39:08 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 6138A21F85A1 for ; Mon, 8 Apr 2013 12:39:08 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Apr 2013 21:39:06 +0200 Message-ID: <02541BC6C3C34926B487E8B87F138E17@fgsr.local> From: "J. Gomez" To: References: <20130406213432.74072.qmail@joyce.lan><4ED3405772FA4FA3B3E8CFA8D720D72D@fgsr.local> Date: Mon, 8 Apr 2013 21:40:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 19:39:09 -0000 On Monday, April 08, 2013 5:32 PM [GMT+1=3DCET], John Sweet wrote: > The only issue might be spam filters assigning any DMARC failure a > score, making it more likely a mailing list digest will end up in > someone's spam folder. But we pretty much already live in that world > (wrt SPF and DKIM), and I'd expect the filters to evolve over time. Well, this list's posts (and many other lists') get to my inbox with a = nice "received-spf: Pass" header, so I don't get how SPF hurts mailing = list's posts. Sender-ID with PRA does have problems with mailing lists, = but not SPF itself, which is fine. Regards, J. Gomez From jgomez@seryrich.com Mon Apr 8 12:43:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6BE21F85ED for ; Mon, 8 Apr 2013 12:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kioHWP6EpiWu for ; Mon, 8 Apr 2013 12:43:08 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 5C74021F85EB for ; Mon, 8 Apr 2013 12:43:08 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Apr 2013 21:43:07 +0200 Message-ID: From: "J. Gomez" To: References: <20130405181120.30162.qmail@joyce.lan><3BA3E5A21E4A4DA880384707233C4FE1@fgsr.local> <51628590.5050703@tana.it> Date: Mon, 8 Apr 2013 21:44:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 19:43:09 -0000 On Monday, April 08, 2013 10:53 AM [GMT+1=3DCET], Alessandro Vesely = wrote: > IMHO DMARC had better handle mailing lists properly, if at all > possible. It seems not to be possible with the currently defined scope for the = DMARC proposed standard. Which is the same as saying there is no will to = make it possible, i.e. there is no will to broaden DMARC's scope to = provide for mailing lists. Regards, J. Gomez From superuser@gmail.com Mon Apr 8 13:42:41 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197A121F9156 for ; Mon, 8 Apr 2013 13:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34M6aPckuRAN for ; Mon, 8 Apr 2013 13:42:40 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 66A7E21F907E for ; Mon, 8 Apr 2013 13:42:40 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id k13so4189534wgh.3 for ; Mon, 08 Apr 2013 13:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AJ5CiKzKP2UqSEJrlFc0dkH6KuXrNxFW1+5u8DFBBfQ=; b=fc9NeYxFQ63UqA45gmQj6uKQoOHCqmfQya6cE8VB/ZhnEN2VPYde2Z5ayccjg3MWwI HfdiUVXoTsEZ23PeEbDBEgPvAGOFa6LCkuANIM3ZD6qFGFDkxY3E1+EjaICGYaHitdrq cKlIJJaqlDfmmVeSz9VpDk4zF/dzN4sF/6VFuaOc69nQFN837uuo3ux3nTyP8O/KVOYM Jt9EzOlXz0/1kQkAFkdzPbHfFnGy46+L5gza6z82uGmS/iQq0fAtDsT8fOQUV037fvHd vVVEmydh/tHBLp9ZoXU1GpRmPTNIZMqPTgvA4athVRqy7Orc7WH78+RPtOhwc967P8WN cSQw== MIME-Version: 1.0 X-Received: by 10.180.74.67 with SMTP id r3mr15305904wiv.14.1365453759376; Mon, 08 Apr 2013 13:42:39 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 8 Apr 2013 13:42:38 -0700 (PDT) In-Reply-To: <27D29611D193440E84A46318009E58F5@fgsr.local> References: <20130408191109.85674.qmail@joyce.lan> <27D29611D193440E84A46318009E58F5@fgsr.local> Date: Mon, 8 Apr 2013 13:42:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d0438914d48f43504d9df7a31 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 20:42:41 -0000 --f46d0438914d48f43504d9df7a31 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 8, 2013 at 12:32 PM, J. Gomez wrote: > So if you are not Paypal-size or if you don't have Paypal-equivalent > technical resources, but you still care about making your brand resilient > to spoofing, tough luck!, no DMARC for you. > Why is use of two subdomains for different mail streams from the same common parent domain such a high-cost endeavour? I do it with my own private domain, and I'm one person with one computer. -MSK --f46d0438914d48f43504d9df7a31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 8, 2013 at 12:32 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
So if you are not Paypal-size or if you don&= #39;t have Paypal-equivalent technical resources, but you still care about = making your brand resilient to spoofing, tough luck!, no DMARC for you.

Why is use of two subdomains for different= mail streams from the same common parent domain such a high-cost endeavour= ?=A0 I do it with my own private domain, and I'm one person with one co= mputer.

-MSK
--f46d0438914d48f43504d9df7a31-- From jgomez@seryrich.com Mon Apr 8 14:00:55 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFAE21F8A52 for ; Mon, 8 Apr 2013 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmNeLuYGP0+U for ; Mon, 8 Apr 2013 14:00:55 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 96E1121F89DB for ; Mon, 8 Apr 2013 14:00:54 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 8 Apr 2013 23:00:52 +0200 Message-ID: From: "J. Gomez" To: References: <20130408191109.85674.qmail@joyce.lan><27D29611D193440E84A46318009E58F5@fgsr.local> Date: Mon, 8 Apr 2013 23:01:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 21:00:55 -0000 > Why is use of two subdomains for different mail streams from the same > common parent domain such a high-cost endeavour? I do it with my own > private domain, and I'm one person with one computer. =20 You are not an example about low-cost technological endeavours. Your are = an author of several published RFC's. It's one thing to create a subdomain for outsourcing the email marketing = operations (key word there being "outsourcing") to a third party with = the in-house required expertise. It's another thing to take on yourself = the convoluted approach of running two domains, one for your mailing = users and another for your branded presence in the intertubes. I bet we all in this list can do it easily. But the world is big and = wide, and many people who will end up tasked with managing medium-sized = business' email will not take a convoluted route at all, AND they will = publish a "p=3Dreject" DMARC policy as big as a cathedral. Pain will = ensue. And then nobody will take "p=3Dreject" as seriously as it is = intended, with the final effect of watering down DMARC effectiveness in = the real world --which is big, wide and hard to tame--. Regards, J. Gomez From superuser@gmail.com Mon Apr 8 14:17:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FC121F901A for ; Mon, 8 Apr 2013 14:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBuonwE4lLAE for ; Mon, 8 Apr 2013 14:17:38 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 025E021F8F9D for ; Mon, 8 Apr 2013 14:17:36 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id o45so4880313wer.22 for ; Mon, 08 Apr 2013 14:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=r+dTYvZHsvSkRd22kBT5JWO/WgBBDCC8/sD/bMDf1mg=; b=taPf7sj2iXmLQFII1TdsR5sBYAS4kRRKT0LCEG4n7RddY4vAgn7qEy0Te9EWOVNdEO IfbJR2eKOyLEPEsIhwvq6ko8MFLzL9lf7N52OE49FINGMbQiJpwa2eaRIGddqJFVWCNW RyKgbLhpMBLcvEAjXXmykyuKpcaSeDsIq/yjCiGaz1B3Eh5ya/J4exnS4CUvEErubG/j jP74apRN2aXuFXVtcZSIh3rgILMh635sXDr8cPaOW7oJ+NmHgIYv0QWQnqO+CXDHSRHU dXonBijE48Bxbi8EfEvUxwQnDoUcSWJsnUGmG6G8PJBXBFlVkNr88TPCcl2l4ztSuVHf pdqA== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr15342816wib.32.1365455856136; Mon, 08 Apr 2013 14:17:36 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 8 Apr 2013 14:17:35 -0700 (PDT) In-Reply-To: References: <20130408191109.85674.qmail@joyce.lan> <27D29611D193440E84A46318009E58F5@fgsr.local> Date: Mon, 8 Apr 2013 14:17:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d044306aa42f86204d9dff719 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 08 Apr 2013 21:17:39 -0000 --f46d044306aa42f86204d9dff719 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 8, 2013 at 2:01 PM, J. Gomez wrote: > You are not an example about low-cost technological endeavours. Your are > an author of several published RFC's. > I wasn't aware those were mutually exclusive. > > It's one thing to create a subdomain for outsourcing the email marketing > operations (key word there being "outsourcing") to a third party with the > in-house required expertise. It's another thing to take on yourself the > convoluted approach of running two domains, one for your mailing users and > another for your branded presence in the intertubes. > There are existence proofs available as counterexamples. Very large ones, in fact. > > I bet we all in this list can do it easily. But the world is big and wide, > and many people who will end up tasked with managing medium-sized business' > email will not take a convoluted route at all, AND they will publish a > "p=reject" DMARC policy as big as a cathedral. Pain will ensue. And then > nobody will take "p=reject" as seriously as it is intended, with the final > effect of watering down DMARC effectiveness in the real world --which is > big, wide and hard to tame--. > > ...which brings us back to "This tool is not for everyone." I think this topic has been beaten to death now, so I won't carry on the thread absent new information. -MSK --f46d044306aa42f86204d9dff719 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 8, 2013 at 2:01 PM, J. Gomez <jgomez@seryri= ch.com> wrote:
You are not an example about low-cost techno= logical endeavours. Your are an author of several published RFC's.
<= /blockquote>

I wasn't aware those were mutually exclusive.
= =A0

It's one thing to create a subdomain for outsourcing the email marketin= g operations (key word there being "outsourcing") to a third part= y with the in-house required expertise. It's another thing to take on y= ourself the convoluted approach of running two domains, one for your mailin= g users and another for your branded presence in the intertubes.

There are existence proofs available as co= unterexamples.=A0 Very large ones, in fact.

=A0

I bet we all in this list can do it easily. But the world is big and wide, = and many people who will end up tasked with managing medium-sized business&= #39; email will not take a convoluted route at all, AND they will publish a= "p=3Dreject" DMARC policy as big as a cathedral. Pain will ensue= . And then nobody will take "p=3Dreject" as seriously as it is in= tended, with the final effect of watering down DMARC effectiveness in the r= eal world --which is big, wide and hard to tame--.
=A0

...which brings us back to "This tool is not fo= r everyone."

I think this topi= c has been beaten to death now, so I won't carry on the thread absent n= ew information.

-MSK
--f46d044306aa42f86204d9dff719-- From vesely@tana.it Tue Apr 9 08:32:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C9421F878F for ; Tue, 9 Apr 2013 08:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hA5VUAcl2goj for ; Tue, 9 Apr 2013 08:32:13 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8A53921F8771 for ; Tue, 9 Apr 2013 08:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365521528; bh=raYParhqBSTEjlf3lGQUwcX2zD7yOhPZkLMz3UXtCKs=; l=1233; h=Date:From:To:References:In-Reply-To; b=L3dG54CBpxn9GMUlOYEgJKusZVKrdZhOnyDdyiLyssYRwmjt7FJ7y2/c3rpgvwRTy pXCT7F4+U0t9+7+LuTqFgy1lUW11lMtp4vdAxkJ3h8jppg3qlbNEiuImzH6KlvmJ9d 453fhylXPRJPvNOV8GRsWLqbiBdw4QqEF8vIItbU= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 09 Apr 2013 17:32:08 +0200 id 00000000005DC044.0000000051643478.0000465A Message-ID: <51643478.7060705@tana.it> Date: Tue, 09 Apr 2013 17:32:08 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130408191109.85674.qmail@joyce.lan> In-Reply-To: <20130408191109.85674.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 Apr 2013 15:32:14 -0000 On Mon 08/Apr/2013 21:11:09 +0200 John Levine wrote: > > To look at it another way, if it's not worth your effort to change > your mail setup to separate the transactions that merit p=reject from > the live users who don't, it's not worth the effort for the rest of > the world to change their mail setup to work around you, either. It's not so much who does the effort as how to automate it. There is no method (yet) whereby a receiver can ascertain that a message really belongs to a mailing list. Therefore it is savvy of phished domains to preventively reserve their domain name for transactional mail. However, when a receiver /knows/ who operates a given message stream, why does it still send DMARC reports to the wrong destinations, especially in case the "sender" is paypal-inc.com or another domain specifically designed to participate to mailing lists? As an identifier, belonging to a mailing list is paramountly visible to users, for it is often associated to a specific destination folder and a subject tag. Recognizing mailing lists, even if not (yet) comprehensively, would adjust the balance between SPF and DKIM, resulting in a better overall cohesion of these protocols. Is this silly? From johnl@iecc.com Tue Apr 9 09:44:57 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AD621F90A9 for ; Tue, 9 Apr 2013 09:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_14=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsCMx-oAVRyl for ; Tue, 9 Apr 2013 09:44:56 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF0D21F903B for ; Tue, 9 Apr 2013 09:44:55 -0700 (PDT) Received: (qmail 21856 invoked from network); 9 Apr 2013 16:44:55 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Apr 2013 16:44:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51644586.xn--btvx9d.k1304; i=johnl@user.iecc.com; bh=h+YtOfFS5h8b3HrH2kfC3FQcCC7IwCvaNm3o6Pc9xAo=; b=oZYD/Cv+XKldT/3CIMtQD6hmM5hzePR66e2kyI/4BNvkHa1QoJ+mW73zzFGC5yiw85MfqSo92oftfFRLQx1S2JlPM80okAmDfZwIQ+VnKhja0zbmguscGCpIXU/WiQU1XrSLY8vt1zaC7kaUhSc6ljyAzzHh1htU7mw/VeVMhhM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51644586.xn--btvx9d.k1304; olt=johnl@user.iecc.com; bh=h+YtOfFS5h8b3HrH2kfC3FQcCC7IwCvaNm3o6Pc9xAo=; b=EM+dO9h71y8ag/Ev7TNpg7780eM3IKQAiIvB2mAovA+rAe3rK7IwtqFgpso1xU8AiWFvkKFm3EJMqiGuOmbaiKnLhaRhhMVuJ4RYWQty6lnaXPOSpi+pJSMNHxAb6peo61h495Wq7g0vDcJJKA/9SQGR0F7qFkA5o9MN4s3w/Gk= Date: 9 Apr 2013 16:44:32 -0000 Message-ID: <20130409164432.68830.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <51643478.7060705@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 Apr 2013 16:44:57 -0000 >There is no method (yet) whereby a receiver can ascertain that a >message really belongs to a mailing list. Of course there is. The list can use DKIM and SPF just like anyone or anything else. It's not hard, my lists all do it. There is no magic way to mechanically determine that a domain is a "real" mailing list but that's in FUSSP territory. > However, when a receiver /knows/ who operates a >given message stream, why does it still send DMARC reports to the >wrong destinations, especially in case the "sender" is paypal-inc.com >or another domain specifically designed to participate to mailing lists? Sorry, this makes no sense at all. I know of no case where reports from mailing list mail go to the wrong destination. The DMARC record for paypal-inc.com says p=none and asks for reports. There's nothing wrong with that, my DMARC records all say the same thing. R's, John From sm@resistor.net Tue Apr 9 15:45:08 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0593321F973B for ; Tue, 9 Apr 2013 15:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf2W5qYZqom9 for ; Tue, 9 Apr 2013 15:45:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D60F021F973A for ; Tue, 9 Apr 2013 15:45:06 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r39Mix7h006402; Tue, 9 Apr 2013 15:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365547505; bh=G1muPsp5bhJ6HeQ4bqYGnd1fMsqJ979ePRxlsmp0nCo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=J/fR1dqr7kBJS5P6+yCH7nLjx5sbMH74kJjsQQ2azFxnLmPu2s3nzoDF91ouMIWBA 5MDCXj9bicOUFVFHApS/M5JUUAB9AQYZtJzK8E1Kacp/aLie97F1zR1gSQ5Hr6rBa/ qZqonOCUIbsQx1jhbEFVhIzAUGlddMDGXo1sUTj8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1365547505; i=@resistor.net; bh=G1muPsp5bhJ6HeQ4bqYGnd1fMsqJ979ePRxlsmp0nCo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=eFu/3Pw68Y0yzCWvS7WOyHnL7DtVdDyw2zur8F4/KcJHjlO50xCb4kVNDW7B1xIo/ Ggb/8tnLJVW493P7S4TbpnFS+nFs0k/Fp5hcw4pSIndy8CI2sx5DgtSLqsVTksWxAE Ec7iZ1WmKP143NYPp49RKT9ZBx1iK81r/OXmwB60= Message-Id: <6.2.5.6.2.20130409153425.0c5d89f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 09 Apr 2013 15:40:53 -0700 To: "J. Gomez" From: SM In-Reply-To: <1CBBDC25A6754A1B9348CF0A3D785C12@fgsr.local> References: <20130407010548.38641.qmail@joyce.lan> <1CBBDC25A6754A1B9348CF0A3D785C12@fgsr.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 Apr 2013 22:45:08 -0000 At 13:20 07-04-2013, J. Gomez wrote: >The option is in General Options -> anonymous_list, set to Yes. This >puts the mailing list address in the RFC5322.From header in the >emails the mailing list software forwards to its subscribers. Do you >see any problem in that option? I saw someone trying that once. It led to a denial of service and several complaints. I believe that it may be possible to object to such a requirement in an IETF specification. Regards, -sm From prvs=80483a580=fmartin@linkedin.com Tue Apr 9 16:03:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F14621F989A for ; Tue, 9 Apr 2013 16:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FywDIOvC88uv for ; Tue, 9 Apr 2013 16:03:44 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id AE65821F978F for ; Tue, 9 Apr 2013 16:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365548624; x=1397084624; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gR59NRZBmJO0q2DQ1ff0Ud7di3WaFrPaWCD37Hq+4MU=; b=oDy5ucx47rb5m1u2V9N3sVvexW2ZSFlBg7WyhCn01Aq8PLXwLjTUTJaq Ay961yKks2sYstfidIGeu+yKhcCRoyOb3NxoDOeV9ugCn+Q3g2LIgL3Oe 1OVs7eRLgBsY6kUnsn/qEHsQKvzvYP1VqOy2hrefx79+SJ04/KAj5ZbGl 4=; X-IronPort-AV: E=Sophos;i="4.87,441,1363158000"; d="scan'208";a="44726196" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Tue, 9 Apr 2013 16:03:37 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 16:03:37 -0700 From: Franck Martin To: SM Thread-Topic: [dmarc-ietf] not about outsourcing strategies, and a newbie's question Thread-Index: AQHONXPwW88p3yXYOESLFl+gC45hh5jO92SA Date: Tue, 9 Apr 2013 23:03:37 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EDD1DC@ESV4-MBX01.linkedin.biz> References: <20130407010548.38641.qmail@joyce.lan> <1CBBDC25A6754A1B9348CF0A3D785C12@fgsr.local> <6.2.5.6.2.20130409153425.0c5d89f8@resistor.net> In-Reply-To: <6.2.5.6.2.20130409153425.0c5d89f8@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <1FC25B3821C2854EB5C23148191160A1@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "J. Gomez" Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 09 Apr 2013 23:03:45 -0000 On Apr 9, 2013, at 3:40 PM, SM wrote: > At 13:20 07-04-2013, J. Gomez wrote: >> The option is in General Options -> anonymous_list, set to Yes. This put= s the mailing list address in the RFC5322.From header in the emails the mai= ling list software forwards to its subscribers. Do you see any problem in t= hat option? >=20 > I saw someone trying that once. It led to a denial of service and severa= l complaints. I believe that it may be possible to object to such a requir= ement in an IETF specification. >=20 The anonymous option strips a lot of things from the original email, it is = a bit drastic as you won't know who posted to the list. From vesely@tana.it Wed Apr 10 01:34:56 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30F921F905C for ; Wed, 10 Apr 2013 01:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_14=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijznXAYQLWyv for ; Wed, 10 Apr 2013 01:34:55 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C0FBD21F9058 for ; Wed, 10 Apr 2013 01:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365582892; bh=WtP7cvzjiMeIYXIu4A4ui9I7cy/bvb3KELhzCsIEYAE=; l=2286; h=Date:From:To:References:In-Reply-To; b=xajxwQ3ZDECR+mqPBbgpTxLuCIcMFxh9wLN8kDGFWa3Lje18TPkv4tUXgUaAqyePd lwiZf5Kb8POYFpFXk3J6Uc3lY8TzZbwyZ/zJoYoPFiW/I1SL856ILgQ757UHmvC5h9 JNxSIo466mTve85Jxtslu4FNTQGRTxGaBaqheZAA= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 10 Apr 2013 10:34:52 +0200 id 00000000005DC039.000000005165242C.000044F4 Message-ID: <5165242C.2030007@tana.it> Date: Wed, 10 Apr 2013 10:34:52 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130409164432.68830.qmail@joyce.lan> In-Reply-To: <20130409164432.68830.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 08:34:56 -0000 On Tue 09/Apr/2013 18:44:32 +0200 John Levine wrote: >> There is no method (yet) whereby a receiver can ascertain that a >> message really belongs to a mailing list. > > Of course there is. The list can use DKIM and SPF just like anyone > or anything else. It's not hard, my lists all do it. Yup, if spf=pass and smtp.mailfrom matches the List-Post: domain, then the message is from a mailing list or a fake thereof. > There is no magic way to mechanically determine that a domain is a > "real" mailing list but that's in FUSSP territory. Well, if the recipient repeatedly sent messages to the List-Post: address in the past, we can conclude it is authentic. Such criterion would miss the very first messages after subscription, but after all we do the same when manually setting the destination folder, don't we? >> when a receiver /knows/ who operates a given message stream, why >> does it still send DMARC reports to the wrong destinations, >> especially in case the "sender" is paypal-inc.com or another >> domain specifically designed to participate to mailing lists? > > Sorry, this makes no sense at all. I know of no case where > reports from mailing list mail go to the wrong destination. The > DMARC record for paypal-inc.com says p=none and asks for reports. > There's nothing wrong with that, my DMARC records all say the same > thing. The MLM is unable to publish a DMARC record for its list. Reports go to its subscribers instead. Just because I subscribed to your list I suddenly have more rights than you to know how it goes. Isn't that wrong? Consider the alternative: OLD 1. The RFC5322.From domain is the identifier used for all message validation operations, as it is the single identifier in the message likely to be visible to the user. NEW 1. Either the RFC5322.From or the RFC2369.List-Post domains are the identifiers used for all message validation operations, as they are the single identifiers in the message whose upshot is paramountly visible to the user. We can specify mailing list recognition to be as stringent as needed, tunable, and possibly deploying VBR, DNSWL, and triple opt-in. We know we'll never be able to catch all list messages, but could do the right thing when we see one. From dcrocker@gmail.com Wed Apr 10 07:03:38 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE1E21F977B for ; Wed, 10 Apr 2013 07:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBoZrsLzseR7 for ; Wed, 10 Apr 2013 07:03:38 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0A79021F97C8 for ; Wed, 10 Apr 2013 07:03:37 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id d42so209206qca.1 for ; Wed, 10 Apr 2013 07:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yDRjdnYX9wpujdz/FQm4Lro2ESyhuaadJV7u3RgGB2g=; b=R9hMw1EIZyocLjw3ctZiErFcQNiI83hRFsAF58ISuAUAJ1dSz+DZoqHyCYZj5MSzke HzxKn5Xmon0qxNe24dYMlA7COvE+sh3XRekIqld6e4XkQXTMvCVeIXs6E5cY13X1mKoz f/4tA0/aowDKtwNDVPH3xNEZw2EEADcgSjc4mt5I+hDjxHX11hJbyigrX+2SQF6imQQr pMCs+xVuqJLvPK6xDHQUBrB3YMY3YJZlz5UShdsVqTpiOoNesfNuUFwYnOfXV2g4FRDd oyprquMRhzz2Tx9dCcLDqbBOmmJTeW4yb5tBbhdcEwap5sBZC1g6AMTSGoah8A29tXmA HtcQ== X-Received: by 10.49.25.202 with SMTP id e10mr2555653qeg.49.1365602617494; Wed, 10 Apr 2013 07:03:37 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id i4sm829882qai.5.2013.04.10.07.03.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Apr 2013 07:03:36 -0700 (PDT) Message-ID: <51657132.4000604@gmail.com> Date: Wed, 10 Apr 2013 07:03:30 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Levine References: <20130409164432.68830.qmail@joyce.lan> In-Reply-To: <20130409164432.68830.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org, vesely@tana.it Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 14:03:39 -0000 On 4/9/2013 9:44 AM, John Levine wrote: >> There is no method (yet) whereby a receiver can ascertain that a >> message really belongs to a mailing list. > > Of course there is. The list can use DKIM and SPF just like anyone or > anything else. It's not hard, my lists all do it. There is no magic John, your response isn't just wrong, it dangerous. There is nothing in the semantics of DKIM or SPF that can provide validation of list origination. For example, DKIM merely asserts that the domain owner specified in d= has 'some' responsibility for the message; no statement about the validity of any content, nevermind membership or ownership of a list. SPF's semantics are a bit different, but no more relevant to validating list membership or origination. There might be a value-add layer of convention, processing, or the like, that could permit such validation, but neither of these mechanisms do it on their own, and there are no standards for it. And forgive me, but that added layer actually qualifies as magic, in the absence of formal standards to achieve it, since it's a receive-side heuristic. d/ -- Dave Crocker bbiw.net From prvs=805103602=fmartin@linkedin.com Wed Apr 10 10:07:11 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCF221F8BBC for ; Wed, 10 Apr 2013 10:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oagrGkiyqoRc for ; Wed, 10 Apr 2013 10:07:11 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 05D8C21F8BBA for ; Wed, 10 Apr 2013 10:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365613630; x=1397149630; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=m30ISvw49WXeiR0FQqLbwHFl4M3Bzw9sCshz9tCk8VM=; b=VeMrY4dltFfTAoc3zY1oljsnokfMxskif2R4Nghj+Gpo53iIWmu13oIY mTtF+tCznTfqxLI7HgXGv0Ux/RReJLpC3VPr2LJ3mZdQlhnVmMgRFGRt6 n2KMCwmx8BDyrTz1Ye5+p6BsMc9GYCPcF55DRGiv7mWLB+S1qxI6cunlj 4=; X-IronPort-AV: E=Sophos;i="4.87,449,1363158000"; d="scan'208";a="43567159" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Wed, 10 Apr 2013 10:07:02 -0700 From: Franck Martin To: Alessandro Vesely Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHONcZUoCodz3RnZ0iFbS64dw4anJjQJXQA Date: Wed, 10 Apr 2013 17:07:02 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> In-Reply-To: <5165242C.2030007@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <92FC15E4B8578440AC7A3E6FBF8D5141@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 17:07:11 -0000 On Apr 10, 2013, at 1:34 AM, Alessandro Vesely wrote: > On Tue 09/Apr/2013 18:44:32 +0200 John Levine wrote: >>> There is no method (yet) whereby a receiver can ascertain that a=20 >=20 > The MLM is unable to publish a DMARC record for its list. Reports go > to its subscribers instead. Just because I subscribed to your list I > suddenly have more rights than you to know how it goes. Isn't that > wrong? Consider the alternative: >=20 > OLD > 1. The RFC5322.From domain is the identifier used for all message > validation operations, as it is the single identifier in the > message likely to be visible to the user. >=20 > NEW > 1. Either the RFC5322.From or the RFC2369.List-Post domains are > the identifiers used for all message validation operations, as > they are the single identifiers in the message whose upshot is > paramountly visible to the user. >=20 > We can specify mailing list recognition to be as stringent as needed, > tunable, and possibly deploying VBR, DNSWL, and triple opt-in. We > know we'll never be able to catch all list messages, but could do the > right thing when we see one. 1) Why List-Post and not List-Id or another List-Header? 2) The trouble with list-x is that it is not exposed to the end user in any= way by any MUA (well may be some but I doubt it). From superuser@gmail.com Wed Apr 10 11:00:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA83221F8F58 for ; Wed, 10 Apr 2013 11:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYLJcuNL87q7 for ; Wed, 10 Apr 2013 11:00:19 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 07A6D21F8F6F for ; Wed, 10 Apr 2013 11:00:18 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id y10so780930wgg.26 for ; Wed, 10 Apr 2013 11:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UBx25cE+eh8MAqU3dKQaKX1ZMGfrfJ/voPZIXR4Fnco=; b=jn6B1CnEhBMvnCUV0zHpkDn/36xxrqxp1DIn2oPN2R5RaUQFhe5GUUPF/KI2quXaam pLvwhmh8s2UzCTExs655z4EIS9PBsPgMYJnQNKqo/FCVbgfPlq+rzFhNBzQ3r4DucdbS qw5xS5WZLUScln+s4OzFpT3sQcVciQbIsCrJZWfRwpwJXD7pIDrGwg9hnKooeLRRHaci PD1Z77r3ODfu/SYssvNvbvaKfbiHq9qknPH5ET3qjLjUkV1DpuoOkDsPCpULX+OHh8ET u85VTVgI8Bbn6XFoQP38yxOKT4+/duZYaq0fnIfda0LNoti0fzHR724Thy8+d5KlZSkU qHmQ== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr5389921wjb.17.1365616818156; Wed, 10 Apr 2013 11:00:18 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 10 Apr 2013 11:00:17 -0700 (PDT) In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> Date: Wed, 10 Apr 2013 11:00:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=047d7b5d8cff58801f04da0571d1 Cc: "" , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 18:00:19 -0000 --047d7b5d8cff58801f04da0571d1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 10, 2013 at 10:07 AM, Franck Martin wrote: > > NEW > > 1. Either the RFC5322.From or the RFC2369.List-Post domains are > > the identifiers used for all message validation operations, as > > they are the single identifiers in the message whose upshot is > > paramountly visible to the user. > > > > We can specify mailing list recognition to be as stringent as needed, > > tunable, and possibly deploying VBR, DNSWL, and triple opt-in. We > > know we'll never be able to catch all list messages, but could do the > > right thing when we see one. > > 1) Why List-Post and not List-Id or another List-Header? > None of them are suitable. If we were to do this, I can craft a message with a From: of security@paypal.com that will pass DMARC via the List-* header field containing whatever domain I want. > > 2) The trouble with list-x is that it is not exposed to the end user in > any way by any MUA (well may be some but I doubt it). > > Right. -MSK --047d7b5d8cff58801f04da0571d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 10, 2013 at 10:07 AM, Franck Martin <fmar= tin@linkedin.com> wrote:
> NEW
> 1. =A0 Either the RFC5322.From or the RFC2369.List-Post domains are > =A0 =A0 =A0the identifiers used for all message validation operations,= as
> =A0 =A0 =A0they are the single identifiers in the message whose upshot= is
> =A0 =A0 =A0paramountly visible to the user.
>
> We can specify mailing list recognition to be as stringent as needed,<= br> > tunable, and possibly deploying VBR, DNSWL, and triple opt-in. =A0We > know we'll never be able to catch all list messages, but could do = the
> right thing when we see one.

1) Why List-Post and not List-Id or another List-Header?

None of them are suitable.=A0 If we were to do this= , I can craft a message with a From: of security@paypal.com that will pass DMARC via the List-* header fiel= d containing whatever domain I want.
=A0

2) The trouble with list-x is that it is not exposed to the end user in any= way by any MUA (well may be some but I doubt it).


Right.<= br> =A0
-MSK
--047d7b5d8cff58801f04da0571d1-- From dcrocker@gmail.com Wed Apr 10 11:04:12 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0928621F8F05 for ; Wed, 10 Apr 2013 11:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bofFRc2oMoxO for ; Wed, 10 Apr 2013 11:04:11 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4C421F8F03 for ; Wed, 10 Apr 2013 11:04:11 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id d10so321026qca.23 for ; Wed, 10 Apr 2013 11:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YwhoU8L9BTrSZ7buwbNqQYt5vpYE8GqnrFo80aOH2t0=; b=hbwfgxpnGW3V4x79YNgqIU9nSEM97HJYreAVc4aKGnEpFW6r4CrVS9ZhX9Wr2jeb/s HsiLmLnF9ukY29g/QSwgTrhY/TgTJxbwNoDdu6aA9WrBK1qKYydSani0Hgj6CR/jh33X Um/XpO0KvGgNUhi6rdf8rgPtmkOtt3NAUWkcPg1Je3gxKDvY8tm0oTCg2z9H4uHSYvhR HN6NEGAouUrtGo3lj9FKl34htGGe4gSWeOdDHjLivLj0wgAETUlzIP5LTWUvFGECMdyj 2LbVlw3nSBbgJk78mUHxnXJeeNO0IoTTTOmlDItwG4alECUbh7PdWFs6WYXkGg3DsiOv VmoA== X-Received: by 10.229.73.72 with SMTP id p8mr1200709qcj.69.1365617050815; Wed, 10 Apr 2013 11:04:10 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id ku2sm1387171qeb.4.2013.04.10.11.04.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Apr 2013 11:04:10 -0700 (PDT) Message-ID: <5165A993.50208@gmail.com> Date: Wed, 10 Apr 2013 11:04:03 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Franck Martin , "" , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 18:04:12 -0000 On 4/10/2013 11:00 AM, Murray S. Kucherawy wrote: > 2) The trouble with list-x is that it is not exposed to the end user in > any way by any MUA (well may be some but I doubt it) So? What's the usage that you (or whoever) envision here, that is concerned with end-user behavior, and why should/will it work? (If I missed that premise in the thread, apologies; but it's worth reviewing carefully.) d/ -- Dave Crocker bbiw.net From superuser@gmail.com Wed Apr 10 11:17:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF5121F8C30 for ; Wed, 10 Apr 2013 11:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q32aFfqeF6WS for ; Wed, 10 Apr 2013 11:17:14 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 39D8821F8C1E for ; Wed, 10 Apr 2013 11:17:14 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id d7so597436wer.12 for ; Wed, 10 Apr 2013 11:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EjHA/Zv9FcWDgmeIN1Dh7d/W3o2diSfl015M6zeI88I=; b=y1+XjwzzxHEyjE9KSsIvG/LouKtkNCON2zoU9pQypMI0PTthNKaCPdbMIgdjqHN0I3 pEODfeeWeUPXjEro0Fi9dxi3bFxGF9j2cuJrDoWnxx3GQeRpH6/xTWhAvX0gcJdayhWM GdNdfqZdB4m4Hsddf96H3z1/UUOwTWvw+JstUw3JtmwRyV4UfOUesN8W0lnJdVfIvefF dOxAV/XTGYglVx8VCBBlPxMgW3K2chHPDN5ow20KNVS3LpHgjPWm/yKFpQ5wVHC3rzBk +sDZYhEMYx1OEDPnYQMNBHns25dx3uoJ/hCoXZPZgt182bTLXAEJl9ySdUOFG1rcVo9v g+lA== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr6970979wib.32.1365617833394; Wed, 10 Apr 2013 11:17:13 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 10 Apr 2013 11:17:13 -0700 (PDT) In-Reply-To: <5165A993.50208@gmail.com> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> Date: Wed, 10 Apr 2013 11:17:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=f46d044306aadbc90004da05ad30 Cc: Franck Martin , "" , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 18:17:15 -0000 --f46d044306aadbc90004da05ad30 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 10, 2013 at 11:04 AM, Dave Crocker wrote: > On 4/10/2013 11:00 AM, Murray S. Kucherawy wrote: > >> 2) The trouble with list-x is that it is not exposed to the end user in >> any way by any MUA (well may be some but I doubt it) >> > > So? > > What's the usage that you (or whoever) envision here, that is concerned > with end-user behavior, and why should/will it work? > > (If I missed that premise in the thread, apologies; but it's worth > reviewing carefully.) > > Unless I'm mistaken, Alessandro proposed solving the lists problem by having DMARC authenticate an identifier from the List-* header field set rather than only the From: field. The issue, as was discussed back in the ADSP days, is that you're then deciding this message passes based on an identifier the end user will never see. So I could craft a message with: From: security@paypal.com List-Something: myaddress@phish-r-us.example ...and then arrange that the message passes DKIM and SPF for phish-r-us.example, and put a DMARC policy up for that domain which will also pass. The end user sees "security@paypal.com" in their inbox, possibly even with a gold star next to it, and would likely not be shown the List-Something field. Better yet, PayPal isn't notified of the problem because no DMARC report request applies here. -MSK --f46d044306aadbc90004da05ad30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 10, 2013 at 11:04 AM, Dave Crocker <dcrock= er@gmail.com> wrote:
On 4/10/2013 11:00 AM, Mur= ray S. Kucherawy wrote:
2) The trouble with list-x is that it is not exposed to the end user in
any way by any MUA (well may be some but I doubt it)

So?

What's the usage that you (or whoever) envision here, that is concerned= with end-user behavior, and why should/will it work?

(If I missed that premise in the thread, apologies; but it's worth revi= ewing carefully.)


Unless I'm mistaken, Alessandro proposed= solving the lists problem by having DMARC authenticate an identifier from = the List-* header field set rather than only the From: field.=A0 The issue,= as was discussed back in the ADSP days, is that you're then deciding t= his message passes based on an identifier the end user will never see.=A0 S= o I could craft a message with:

From: security@paypal.com
List-Something: myaddress@phish-r-us.example

= ...and then arrange that the message passes DKIM and SPF for phish-r-us.exa= mple, and put a DMARC policy up for that domain which will also pass.=A0 Th= e end user sees "security@paypa= l.com" in their inbox, possibly even with a gold star next to it, = and would likely not be shown the List-Something field.

Better yet, PayPal isn't notified of the problem because no DMARC r= eport request applies here.

-MSK

--f46d044306aadbc90004da05ad30-- From jgomez@seryrich.com Wed Apr 10 11:59:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089F021F8B35 for ; Wed, 10 Apr 2013 11:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIqFTGRazzkk for ; Wed, 10 Apr 2013 11:59:13 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id C681C21F8B25 for ; Wed, 10 Apr 2013 11:59:12 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Apr 2013 20:59:10 +0200 Message-ID: From: "J. Gomez" To: References: <20130407010548.38641.qmail@joyce.lan> <1CBBDC25A6754A1B9348CF0A3D785C12@fgsr.local> <6.2.5.6.2.20130409153425.0c5d89f8@resistor.net> <77426B543150464AA3F30DF1A91365DE52EDD1DC@ESV4-MBX01.linkedin.biz> Date: Wed, 10 Apr 2013 21:00:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] not about outsourcing strategies, and a newbie's question X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 18:59:14 -0000 On Wednesday, April 10, 2013 1:03 AM [GMT+1=3DCET], Franck Martin wrote: > On Apr 9, 2013, at 3:40 PM, SM wrote: >=20 > > At 13:20 07-04-2013, J. Gomez wrote: > > > The option is in General Options -> anonymous_list, set to Yes. > > > This puts the mailing list address in the RFC5322.From header in > > > the emails the mailing list software forwards to its subscribers. > > > Do you see any problem in that option? =20 > >=20 > > I saw someone trying that once. It led to a denial of service and > > several complaints. I believe that it may be possible to object to > > such a requirement in an IETF specification. =20 > >=20 >=20 > The anonymous option strips a lot of things from the original email, > it is a bit drastic as you won't know who posted to the list.=20 You can know who posted to the list if the poster added a signature at = the bottom of the email body. You further could know who posted, if the mailing list software (Mailman = in this case) would had replaced the orginal email address in the = RFC5322.From header with the mailing list email address but had left the = descriptive portion of the RFC5322.From header mostly untouched, like = thus: From: "John Smith" would become: From: "Mailman from John Smith" This can already be achieved with some custom filters in the MTA, but if = the majority of mailing list sofware were to provide for that option be = set in a non convoluted way, then the mailing list problem of DMARC = would be almost a non-issue. Regards, J. Gomez From jgomez@seryrich.com Wed Apr 10 13:30:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A75E21F92C1 for ; Wed, 10 Apr 2013 13:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQz2NAO25Atp for ; Wed, 10 Apr 2013 13:30:29 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 58C9121F9357 for ; Wed, 10 Apr 2013 13:30:28 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Apr 2013 22:30:27 +0200 Message-ID: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> From: "J. Gomez" To: Date: Wed, 10 Apr 2013 22:31:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 20:30:30 -0000 I think there is minor contradiction in the draft specification of = DMARC, https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D1 Requirement #8 reads: Senders should be able to specify a percentage of their messages =20 to which their policies should be applied, with the rest =20 unaffected, in order to experiment and to understand and =20 minimize deployment risk. And the first paragraph in section 7.1 reads: If the "pct" tag is present in a policy record, application of policy =20 is done on a selective basis. The stated percentage of messages that =20 fail the DMARC test MUST be subjected to whatever policy is selected =20 by the "p" or "sp" tag (if present). Those that are not thus =20 selected MUST instead be subjected to the next policy lower in terms =20 of severity. I think Requirement #8 should be redacted to more properly fit with = section 7.1, which by itself looks quite reasonable. Regards, J. Gomez From prvs=805103602=fmartin@linkedin.com Wed Apr 10 13:32:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E80821F92CD for ; Wed, 10 Apr 2013 13:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhIFIrohy2On for ; Wed, 10 Apr 2013 13:32:38 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7A21F92C1 for ; Wed, 10 Apr 2013 13:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365625958; x=1397161958; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OQcQ9hZ7wmpivAsWQLIvu7Q/GoK9okz0RWUxfDtDrDA=; b=uZWnkWZQdqFXK1z/9b+I4WcKDnLrZPs9I6S2JWTKNtODV+O4Mvh6hk0f 52t+md/UyXVsd+/qkKjP1ipiiSNAHbWUE2SBOs7od3t9M2UdmUOrNHfmV ONfZeoMYx8d9kIBnl9wTv/3jxF+5Tv5oqgCmrCJBXXDqw6UvR1VstHw/+ 0=; X-IronPort-AV: E=Sophos;i="4.87,450,1363158000"; d="scan'208,217";a="43590797" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Wed, 10 Apr 2013 13:32:29 -0700 From: Franck Martin To: Dave Crocker Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHONcZUoCodz3RnZ0iFbS64dw4anJjQJXQAgAAO3ICAAAENgIAAKXwA Date: Wed, 10 Apr 2013 20:32:29 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EEBDD0@ESV4-MBX01.linkedin.biz> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> In-Reply-To: <5165A993.50208@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/alternative; boundary="_000_77426B543150464AA3F30DF1A91365DE52EEBDD0ESV4MBX01linked_" MIME-Version: 1.0 Cc: "" , "Murray S. Kucherawy" , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 20:32:39 -0000 --_000_77426B543150464AA3F30DF1A91365DE52EEBDD0ESV4MBX01linked_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 10, 2013, at 11:04 AM, Dave Crocker > wrote: On 4/10/2013 11:00 AM, Murray S. Kucherawy wrote: 2) The trouble with list-x is that it is not exposed to the end user in any way by any MUA (well may be some but I doubt it) So? What's the usage that you (or whoever) envision here, that is concerned wit= h end-user behavior, and why should/will it work? (If I missed that premise in the thread, apologies; but it's worth reviewin= g carefully.) http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-3.4 point = 1) 1. The RFC5322.From domain is the ide= ntifier used for all message validation operations, as it is the single identifier in the message likely to be visible to the user. Otherwise we could have used the Sender: header or whatever other header. --_000_77426B543150464AA3F30DF1A91365DE52EEBDD0ESV4MBX01linked_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4FAAC6ADAAF86B4A828921143983666D@linkedin.com> Content-Transfer-Encoding: quoted-printable
On Apr 10, 2013, at 11:04 AM, Dave Crocker <dcrocker@gmail.com> wrote:



On 4/10/2013 11:00 AM, Murray S. Kucherawy wrote:
2) The trouble with list-x is that it is not expo= sed to the end user in
any way by any MUA (well may be some but I doubt it)

So?

What's the usage that you (or whoever) envision here, that is concerned wit= h end-user behavior, and why should/will it work?

(If I missed that premise in the thread, apologies; but it's worth reviewin= g carefully.)



1.   The RFC5322.From domain is the identifier used for all message
        validation operations, as it is the single identifier in the
        message likely to be visible to the user.
Otherwise we could have used the Sender: header or whatever other head= er.

--_000_77426B543150464AA3F30DF1A91365DE52EEBDD0ESV4MBX01linked_-- From prvs=805103602=fmartin@linkedin.com Wed Apr 10 13:34:56 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8FB21F92EF for ; Wed, 10 Apr 2013 13:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty8Fd7EIxfNs for ; Wed, 10 Apr 2013 13:34:56 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB5921F9339 for ; Wed, 10 Apr 2013 13:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365626094; x=1397162094; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iCbz5TUGQc/h/XwHOO5O+vYYI1wdFWQb1c6cqMlmGRU=; b=MtwzrpwwWNklYWBcH4voDFbHcvK+niQrHLQ2NjTTEDAxXC04mDyNNS7H Ci0aS0Adwi4nrepFzcl2CfEqP3VW4nArjmBj+LOaHQGRmtnXwlxkzDDsK AlE6Lh17d5HImv5tHoU9xT2JwM1Lg3oxLrJo+OJ+I9TlaevOVLTdkzyO+ c=; X-IronPort-AV: E=Sophos;i="4.87,450,1363158000"; d="scan'208,217";a="43591046" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Wed, 10 Apr 2013 13:34:50 -0700 From: Franck Martin To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHONcZUoCodz3RnZ0iFbS64dw4anJjQJXQAgAAO3ICAACsxgA== Date: Wed, 10 Apr 2013 20:34:50 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EEBE4B@ESV4-MBX01.linkedin.biz> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/alternative; boundary="_000_77426B543150464AA3F30DF1A91365DE52EEBE4BESV4MBX01linked_" MIME-Version: 1.0 Cc: "" , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 20:34:56 -0000 --_000_77426B543150464AA3F30DF1A91365DE52EEBE4BESV4MBX01linked_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 10, 2013, at 11:00 AM, Murray S. Kucherawy > wrote: On Wed, Apr 10, 2013 at 10:07 AM, Franck Martin > wrote: > NEW > 1. Either the RFC5322.From or the RFC2369.List-Post domains are > the identifiers used for all message validation operations, as > they are the single identifiers in the message whose upshot is > paramountly visible to the user. > > We can specify mailing list recognition to be as stringent as needed, > tunable, and possibly deploying VBR, DNSWL, and triple opt-in. We > know we'll never be able to catch all list messages, but could do the > right thing when we see one. 1) Why List-Post and not List-Id or another List-Header? None of them are suitable. If we were to do this, I can craft a message wi= th a From: of security@paypal.com that will pas= s DMARC via the List-* header field containing whatever domain I want. Yes, sure, my question is outside this alignment business and header spoofi= ng. What header "most" describes a mailing list? Is there some convention a= lready in place? --_000_77426B543150464AA3F30DF1A91365DE52EEBE4BESV4MBX01linked_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Apr 10, 2013, at 11:00 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Wed, Apr 10, 2013 at 10:07 AM, Franck Martin <fmar= tin@linkedin.com> wrote:
> NEW
> 1.   Either the RFC5322.From or the RFC2369.Lis= t-Post domains are
>      the identifiers used for all message validation op= erations, as
>      they are the single identifiers in the message who= se upshot is
>      paramountly visible to the user.
>
> We can specify mailing list recognition to be as stringent as needed,<= br> > tunable, and possibly deploying VBR, DNSWL, and triple opt-in.  W= e
> know we'll never be able to catch all list messages, but could do the<= br> > right thing when we see one.

1) Why List-Post and not List-Id or another List-Header?

None of them are suitable.  If we were to do this, I can craft a = message with a From: of security@paypal.com that will pa= ss DMARC via the List-* header field containing whatever domain I want.

Yes, sure, my question is outside this alignment business and header s= poofing. What header "most" describes a mailing list? Is there so= me convention already in place?

--_000_77426B543150464AA3F30DF1A91365DE52EEBE4BESV4MBX01linked_-- From jgomez@seryrich.com Wed Apr 10 13:49:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF75C21F91D8 for ; Wed, 10 Apr 2013 13:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP5842yvmR83 for ; Wed, 10 Apr 2013 13:49:14 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4F521F92E8 for ; Wed, 10 Apr 2013 13:49:14 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Apr 2013 22:49:12 +0200 Message-ID: <8776B592E1C84D2296CEFB29C537ADFA@fgsr.local> From: "J. Gomez" To: Date: Wed, 10 Apr 2013 22:50:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 20:49:14 -0000 Hello all. It is 'somewhat' clear that in the realm of DMARC-processing only a = 'positive' SPF match constitutes a pass for the SPF-mechanism. I.e., = that a SPF match for 'neutral' does NOT constitute a pass for the = SPF-mechanism in the realm of DMARC-processing. However, this is not = clearly stated, beyond reasonable doubt and discussion, in the DMARC = draft specification. Possible result of a SPF check, according to RFC 4408, are: --Pass --Fail --SoftFail --Neutral --None --TempError --PermError So I think that it should be clearly stated, in Section 4.1, where the = SPF mechanims is specified, that only a 'positive' match in the = SPF-mechanism constitutes a pass in the realm of DMARC-processing; or = even better, stating that a 'neutral' match in the SPF-mechanism does = NOT constitute a pass-result for the SPF-mechanism in the realm of = DMARC-processing. https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D1 Regards, J. Gomez From superuser@gmail.com Wed Apr 10 14:20:58 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8983A21F8F03 for ; Wed, 10 Apr 2013 14:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PUu6dHXx7ui for ; Wed, 10 Apr 2013 14:20:50 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 149F021F8F02 for ; Wed, 10 Apr 2013 14:20:46 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hj8so937533wib.2 for ; Wed, 10 Apr 2013 14:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fIVPKVoiuWp2PXh5UIpynia0UfITg//sPtIsLS9+0DE=; b=LEE5COjxbgje6ik+HIo7VzKx20ra2DpgdvuLfpk3kNnTeRoVjNc8Hasp+0BA/WbNDi 4IjrCFiNdXO7HDuRhA5JVNzv0HFcp/s+FMtE3Q5k8j+ZAWvdicYfFS2pqKBb2SknWsER Ruayytt9BILzaiXktBDVDMAa9BNxty8IV4IBUeF9E3aQvWYDVYrTCliAJRplTp1Hd8mQ phRzkScvBny9urWTQAru3k+2He/r7EVUEIycdtVwKCwGAiWQPlXH4Avp5Dpr3q66Wsfu 7w38wJrhnae5mTsbiMKuEN9SwjxE7yqkTpkeCzquWrkJv3qx6sGHzHAsb3Z9YmVPSrMe X2MA== MIME-Version: 1.0 X-Received: by 10.180.94.133 with SMTP id dc5mr1327160wib.1.1365628846200; Wed, 10 Apr 2013 14:20:46 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 10 Apr 2013 14:20:45 -0700 (PDT) In-Reply-To: <8776B592E1C84D2296CEFB29C537ADFA@fgsr.local> References: <8776B592E1C84D2296CEFB29C537ADFA@fgsr.local> Date: Wed, 10 Apr 2013 14:20:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d04462e6645e09104da083edc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 21:20:58 -0000 --f46d04462e6645e09104da083edc Content-Type: text/plain; charset=ISO-8859-1 Section 4.1 only identifies the underlying mechanisms and references their defining documents. It doesn't dive into their interpretation at all. Meanwhile, Section 5 says: A Mail Receiver MUST consider an arriving message to pass the DMARC test if and only if one or more of the underlying message authentication mechanisms pass with proper identifier alignment. This doesn't strike me as ambiguous versus the list of possible SPF outcomes, or DKIM's for that matter. On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez wrote: > Hello all. > > It is 'somewhat' clear that in the realm of DMARC-processing only a > 'positive' SPF match constitutes a pass for the SPF-mechanism. I.e., that a > SPF match for 'neutral' does NOT constitute a pass for the SPF-mechanism in > the realm of DMARC-processing. However, this is not clearly stated, beyond > reasonable doubt and discussion, in the DMARC draft specification. > > Possible result of a SPF check, according to RFC 4408, are: > --Pass > --Fail > --SoftFail > --Neutral > --None > --TempError > --PermError > > So I think that it should be clearly stated, in Section 4.1, where the SPF > mechanims is specified, that only a 'positive' match in the SPF-mechanism > constitutes a pass in the realm of DMARC-processing; or even better, > stating that a 'neutral' match in the SPF-mechanism does NOT constitute a > pass-result for the SPF-mechanism in the realm of DMARC-processing. > > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 > > Regards, > > J. Gomez > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f46d04462e6645e09104da083edc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Section 4.1 only identifies the underlying mechanisms and = references their defining documents.=A0 It doesn't dive into their inte= rpretation at all.=A0 Meanwhile, Section 5 says:

   =
A Mail Receiver MUST consider an arriving message to pass the DMARC
   test if and only if one or more of the underlying message
   authentication mechanisms pass with proper identifier alignment.

This do=
esn't strike me as ambiguous versus the list of possible SPF outcomes, =
or DKIM's for that matter.


On Wed, Apr 10, 2013 at 1:50 PM, J. Gome= z <jgomez@seryrich.com> wrote:
Hello all.

It is 'somewhat' clear that in the realm of DMARC-processing only a= 'positive' SPF match constitutes a pass for the SPF-mechanism. I.e= ., that a SPF match for 'neutral' does NOT constitute a pass for th= e SPF-mechanism in the realm of DMARC-processing. However, this is not clea= rly stated, beyond reasonable doubt and discussion, in the DMARC draft spec= ification.

Possible result of a SPF check, according to RFC 4408, are:
=A0--Pass
=A0--Fail
=A0--SoftFail
=A0--Neutral
=A0--None
=A0--TempError
=A0--PermError

So I think that it should be clearly stated, in Section 4.1, where the SPF = mechanims is specified, that only a 'positive' match in the SPF-mec= hanism constitutes a pass in the realm of DMARC-processing; or even better,= stating that a 'neutral' match in the SPF-mechanism does NOT const= itute a pass-result for the SPF-mechanism in the realm of DMARC-processing.=

https://datatracker.ietf.org/doc/draft-kuc= herawy-dmarc-base/?include_text=3D1

Regards,

J. Gomez

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

--f46d04462e6645e09104da083edc-- From jgomez@seryrich.com Wed Apr 10 14:44:03 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC18B21F8E84 for ; Wed, 10 Apr 2013 14:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixn70RNXzwki for ; Wed, 10 Apr 2013 14:44:03 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id CA1ED21F8BD0 for ; Wed, 10 Apr 2013 14:44:02 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Apr 2013 23:44:01 +0200 Message-ID: <6BF223534B2C4D378C844224DD60B7D1@fgsr.local> From: "J. Gomez" To: References: <8776B592E1C84D2296CEFB29C537ADFA@fgsr.local> Date: Wed, 10 Apr 2013 23:44:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 21:44:03 -0000 It does remain dubious whether an alignment with a 'neutral' match if = SPF is a DMARC-pass or not for the SPF-mechanism in the realm of = DMARC-processing. Consider this SPF DNS RR for "example.com": "v=3Dspf1 ip4:195.234.236.237 ?ip4:195.234.236.238 ~all" And here comes an email from a sending MTA at IP 195.234.236.238 = carrying a RFC5321.MailFrom of jsmith@example.com and a RFC5322.From = header of jsmith@example.com. The "From:" header identifier in that email is explicitedly aligned with = a 'neutral' match in SPF. So there is a match, and there is an = alignment. But not an alignment 'good enough' for DMARC, or 'qualified = enough' for DMARC. Therefore this nuance should be clearly stated in the = DMARC specification, to avoid rivers of ink flowing in the future. Regards, J. Gomez ---- Original Message ---- From: Murray S. Kucherawy To: J. G=F3mez Cc: dmarc@ietf.org Sent: Wednesday, April 10, 2013 11:20 PM Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm=20 > Section 4.1 only identifies the underlying mechanisms and references > their defining documents. It doesn't dive into their interpretation > at all. Meanwhile, Section 5 says: =20 >=20 >=20 > A Mail Receiver MUST consider an arriving message to pass the DMARC > test if and only if one or more of the underlying message > authentication mechanisms pass with proper identifier alignment. >=20 > This doesn't strike me as ambiguous versus the list of possible SPF > outcomes, or DKIM's for that matter.=20 >=20 >=20 >=20 > On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez wrote: >=20 > Hello all. >=20 > It is 'somewhat' clear that in the realm of DMARC-processing only a > 'positive' SPF match constitutes a pass for the SPF-mechanism. I.e., > that a SPF match for 'neutral' does NOT constitute a pass for the > SPF-mechanism in the realm of DMARC-processing. However, this is not > clearly stated, beyond reasonable doubt and discussion, in the DMARC > draft specification. =20 >=20 > Possible result of a SPF check, according to RFC 4408, are: > --Pass > --Fail > --SoftFail > --Neutral > --None > --TempError > --PermError >=20 > So I think that it should be clearly stated, in Section 4.1, where > the SPF mechanims is specified, that only a 'positive' match in the > SPF-mechanism constitutes a pass in the realm of DMARC-processing; or > even better, stating that a 'neutral' match in the SPF-mechanism does > NOT constitute a pass-result for the SPF-mechanism in the realm of > DMARC-processing. =20 >=20 > = https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D1 >=20 > Regards, >=20 > J. Gomez >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From sklist@kitterman.com Wed Apr 10 15:02:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE21721F8E94 for ; Wed, 10 Apr 2013 15:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jUme0Ogn931 for ; Wed, 10 Apr 2013 15:02:01 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 572AE21F8E91 for ; Wed, 10 Apr 2013 15:02:00 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 856CB20E40D4; Wed, 10 Apr 2013 18:01:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365631319; bh=EZd7ZngI4CMf7lXKG+doSgwE/fvbo93ruk2kKWU/bEc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ng4SjBqtzYGE6V7/LAscONRo/9mhqF5JbNGtJhB5kIKocDxRRevyTlLbS+/8v7tCE BV2bo99/jvWJKmGeebzk6e3hafv96YpTWsCVi3Y9tJuaINSLnAIk21PgcroZdi7oDQ j1qxm+955wkwCR0kBIqsmAdLubIwJ6IWA5hec7kI= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 69BD620E4062; Wed, 10 Apr 2013 18:01:58 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 10 Apr 2013 18:01:53 -0400 Message-ID: <15186253.T94leth7fX@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <6BF223534B2C4D378C844224DD60B7D1@fgsr.local> References: <8776B592E1C84D2296CEFB29C537ADFA@fgsr.local> <6BF223534B2C4D378C844224DD60B7D1@fgsr.local> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 22:02:03 -0000 So we need to specify that pass means pass? Scott K On Wednesday, April 10, 2013 11:44:57 PM J. Gomez wrote: > It does remain dubious whether an alignment with a 'neutral' match if= SPF is > a DMARC-pass or not for the SPF-mechanism in the realm of DMARC-proce= ssing. >=20 > Consider this SPF DNS RR for "example.com": >=20 > "v=3Dspf1 ip4:195.234.236.237 ?ip4:195.234.236.238 ~all" >=20 > And here comes an email from a sending MTA at IP 195.234.236.238 carr= ying a > RFC5321.MailFrom of jsmith@example.com and a RFC5322.From header of > jsmith@example.com. >=20 > The "From:" header identifier in that email is explicitedly aligned w= ith a > 'neutral' match in SPF. So there is a match, and there is an alignmen= t. But > not an alignment 'good enough' for DMARC, or 'qualified enough' for D= MARC. > Therefore this nuance should be clearly stated in the DMARC specifica= tion, > to avoid rivers of ink flowing in the future. >=20 > Regards, >=20 > J. Gomez >=20 >=20 > ---- Original Message ---- > From: Murray S. Kucherawy > To: J. G=F3mez > Cc: dmarc@ietf.org > Sent: Wednesday, April 10, 2013 11:20 PM > Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a > SPF-pass in the DMARC realm >=20 > > Section 4.1 only identifies the underlying mechanisms and reference= s > > their defining documents. It doesn't dive into their interpretatio= n > >=20 > > at all. Meanwhile, Section 5 says: > > A Mail Receiver MUST consider an arriving message to pass the DM= ARC > > test if and only if one or more of the underlying message > > authentication mechanisms pass with proper identifier alignment.= > >=20 > > This doesn't strike me as ambiguous versus the list of possible SPF= > > outcomes, or DKIM's for that matter. > >=20 > >=20 > >=20 > > On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez wro= te: > >=20 > > Hello all. > >=20 > > It is 'somewhat' clear that in the realm of DMARC-processing only a= > > 'positive' SPF match constitutes a pass for the SPF-mechanism. I.e.= , > > that a SPF match for 'neutral' does NOT constitute a pass for the > > SPF-mechanism in the realm of DMARC-processing. However, this is no= t > > clearly stated, beyond reasonable doubt and discussion, in the DMAR= C > > draft specification. > >=20 > > Possible result of a SPF check, according to RFC 4408, are: > > --Pass > > --Fail > > --SoftFail > > --Neutral > > --None > > --TempError > > --PermError > >=20 > > So I think that it should be clearly stated, in Section 4.1, where > > the SPF mechanims is specified, that only a 'positive' match in the= > > SPF-mechanism constitutes a pass in the realm of DMARC-processing; = or > > even better, stating that a 'neutral' match in the SPF-mechanism do= es > > NOT constitute a pass-result for the SPF-mechanism in the realm of > > DMARC-processing. > >=20 > > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?includ= e_text=3D > > 1 > >=20 > > Regards, > >=20 > > J. Gomez > >=20 > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From kurta@drkurt.com Wed Apr 10 15:23:08 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E9321F89E2 for ; Wed, 10 Apr 2013 15:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtUgGcx8hJKb for ; Wed, 10 Apr 2013 15:23:07 -0700 (PDT) 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 801E521F89A5 for ; Wed, 10 Apr 2013 15:23:06 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi18so976268wib.15 for ; Wed, 10 Apr 2013 15:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20110616; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=WST0nw4B5E3FUZli2ziOPoRPeS4r8UEr4fvnP9Il34w=; b=UMIjtG6F4MFFZ0vmYS9lrZozsY3dspyHupQP2S7iu0h1UnLKpQXumpDfutqvI07Aqk lo+aJUb+2PgoPGcx1D3trBo4qFPQoEGxnNQYJvQxHPeJnGDGEEZoUOZmiChF3n+Xr3Q3 0O/NFFC+zBSI4XguCFOtO4Wmp35RR5zDQZF1E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=WST0nw4B5E3FUZli2ziOPoRPeS4r8UEr4fvnP9Il34w=; b=M47RANk69Sc5qT3lSVwsTN9jMZoQA39G1Z1Dj9Jhl0qMhXFAwtA+aV60vpucUNlxG5 /B5zrxYPFTQI+qNCb8rL3nPw8VmsxzJZF4P0qh5aAYoEaCrdDwFSxLmvLSp2Vy12mgwP ufb1daM+WC8f5Ge8VxHfaiVMZuhsr2ACyOMn1rBrmhYkAtObrtrFOI7LvO7Vqi9at/N6 NI9KizDrSOqtJGMSVOZjNvi9RhXqWyKAg/h0Mcx/VTKu5YVIeAErX5/IQGJ7Mu41mIUO F6leuLkQkQONC914iF7KfKAEMu4tFvrIIKhZmd4/aCPeXIRdXcgUDSch1Qp0MxQOQRMd augQ== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr6441725wjr.33.1365632585422; Wed, 10 Apr 2013 15:23:05 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.65.98 with HTTP; Wed, 10 Apr 2013 15:23:05 -0700 (PDT) In-Reply-To: <15186253.T94leth7fX@scott-latitude-e6320> References: <8776B592E1C84D2296CEFB29C537ADFA@fgsr.local> <6BF223534B2C4D378C844224DD60B7D1@fgsr.local> <15186253.T94leth7fX@scott-latitude-e6320> Date: Wed, 10 Apr 2013 15:23:05 -0700 X-Google-Sender-Auth: cFrlDtbvvdAQXeTSOZID7R9Csm0 Message-ID: From: Kurt Andersen To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=047d7b86e2f825f09104da091dba X-Gm-Message-State: ALoCoQmL+zwrBT+1xOR/c5Z1cSN0G8alHqD/BPaPQTpys8Sxp63aVr7SU/ECk+cHkRGAjztbffi6 Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 22:23:08 -0000 --047d7b86e2f825f09104da091dba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In light of the perception (by some) that SPF is negatively oriented (fail can be relied upon to be meaningful, while all other results are less actionable), I think so. It is a case of what one does with the "excluded middle" for a tri-state response mapped into a binary decision. Does "neutral" map to a positive interpretation (yes for SPF by itself, no for DMARC) or a negative one (DMARC's "not pass"). --Kurt On Wed, Apr 10, 2013 at 3:01 PM, Scott Kitterman wrot= e: > So we need to specify that pass means pass? > > Scott K > > On Wednesday, April 10, 2013 11:44:57 PM J. Gomez wrote: > > It does remain dubious whether an alignment with a 'neutral' match if > SPF is > > a DMARC-pass or not for the SPF-mechanism in the realm of > DMARC-processing. > > > > Consider this SPF DNS RR for "example.com": > > > > "v=3Dspf1 ip4:195.234.236.237 ?ip4:195.234.236.238 ~all" > > > > And here comes an email from a sending MTA at IP 195.234.236.238 > carrying a > > RFC5321.MailFrom of jsmith@example.com and a RFC5322.From header of > > jsmith@example.com. > > > > The "From:" header identifier in that email is explicitedly aligned wit= h > a > > 'neutral' match in SPF. So there is a match, and there is an alignment. > But > > not an alignment 'good enough' for DMARC, or 'qualified enough' for > DMARC. > > Therefore this nuance should be clearly stated in the DMARC > specification, > > to avoid rivers of ink flowing in the future. > > > > Regards, > > > > J. Gomez > > > > > > ---- Original Message ---- > > From: Murray S. Kucherawy > > To: J. G=F3mez > > Cc: dmarc@ietf.org > > Sent: Wednesday, April 10, 2013 11:20 PM > > Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a > > SPF-pass in the DMARC realm > > > > > Section 4.1 only identifies the underlying mechanisms and references > > > their defining documents. It doesn't dive into their interpretation > > > > > > at all. Meanwhile, Section 5 says: > > > A Mail Receiver MUST consider an arriving message to pass the DMAR= C > > > test if and only if one or more of the underlying message > > > authentication mechanisms pass with proper identifier alignment. > > > > > > This doesn't strike me as ambiguous versus the list of possible SPF > > > outcomes, or DKIM's for that matter. > > > > > > > > > > > > On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez wrote= : > > > > > > Hello all. > > > > > > It is 'somewhat' clear that in the realm of DMARC-processing only a > > > 'positive' SPF match constitutes a pass for the SPF-mechanism. I.e., > > > that a SPF match for 'neutral' does NOT constitute a pass for the > > > SPF-mechanism in the realm of DMARC-processing. However, this is not > > > clearly stated, beyond reasonable doubt and discussion, in the DMARC > > > draft specification. > > > > > > Possible result of a SPF check, according to RFC 4408, are: > > > --Pass > > > --Fail > > > --SoftFail > > > --Neutral > > > --None > > > --TempError > > > --PermError > > > > > > So I think that it should be clearly stated, in Section 4.1, where > > > the SPF mechanims is specified, that only a 'positive' match in the > > > SPF-mechanism constitutes a pass in the realm of DMARC-processing; or > > > even better, stating that a 'neutral' match in the SPF-mechanism does > > > NOT constitute a pass-result for the SPF-mechanism in the realm of > > > DMARC-processing. > > > > > > > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D > > > 1 > > > > > > Regards, > > > > > > J. Gomez > > > > > > _______________________________________________ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7b86e2f825f09104da091dba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In light of the perception (by some) that SPF is nega= tively oriented (fail can be relied upon to be meaningful, while all other = results are less actionable), I think so. It is a case of what one does wit= h the "excluded middle" for a tri-state response mapped into a bi= nary decision. Does "neutral" map to a positive interpretation (y= es for SPF by itself, no for DMARC) or a negative one (DMARC's "no= t pass").

--Kurt


On Wed, Apr 10, 2013 at 3:01 PM, Scott Kitterman <sklist@k= itterman.com> wrote:
So we need to specify that pass means pass?<= br>
Scott K

On Wednesday, April 10, 2013 11:44:57 PM J. Gomez wrote:
> It does remain dubious whether an alignment with a 'neutral' m= atch if SPF is
> a DMARC-pass or not for the SPF-mechanism in the realm of DMARC-proces= sing.
>
> Consider this SPF DNS RR for "example.com":
>
> "v=3Dspf1 ip4:195.234.236.237 ?ip4:195.234.236.238 ~all"
>
> And here comes an email from a sending MTA at IP 195.234.236.238 carry= ing a
> RFC5321.MailFrom of jsmith@examp= le.com and a RFC5322.From header of
> jsmith@example.com.
>
> The "From:" header identifier in that email is explicitedly = aligned with a
> 'neutral' match in SPF. So there is a match, and there is an a= lignment. But
> not an alignment 'good enough' for DMARC, or 'qualified en= ough' for DMARC.
> Therefore this nuance should be clearly stated in the DMARC specificat= ion,
> to avoid rivers of ink flowing in the future.
>
> Regards,
>
> J. Gomez
>
>
> ---- Original Message ----
> From: Murray S. Kucherawy
> To: J. G=F3mez
> Cc: dmarc@ietf.org
> Sent: Wednesday, April 10, 2013 11:20 PM
> Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a
> SPF-pass in the DMARC realm
>
> > Section 4.1 only identifies the underlying mechanisms and referen= ces
> > their defining documents. =A0It doesn't dive into their inter= pretation
> >
> > at all. =A0Meanwhile, Section 5 says:
> > =A0 =A0A Mail Receiver MUST consider an arriving message to pass = the DMARC
> > =A0 =A0test if and only if one or more of the underlying message<= br> > > =A0 =A0authentication mechanisms pass with proper identifier alig= nment.
> >
> > This doesn't strike me as ambiguous versus the list of possib= le SPF
> > outcomes, or DKIM's for that matter.
> >
> >
> >
> > On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez <jgomez@seryrich.com> wrote:
> >
> > Hello all.
> >
> > It is 'somewhat' clear that in the realm of DMARC-process= ing only a
> > 'positive' SPF match constitutes a pass for the SPF-mecha= nism. I.e.,
> > that a SPF match for 'neutral' does NOT constitute a pass= for the
> > SPF-mechanism in the realm of DMARC-processing. However, this is = not
> > clearly stated, beyond reasonable doubt and discussion, in the DM= ARC
> > draft specification.
> >
> > Possible result of a SPF check, according to RFC 4408, are:
> > =A0--Pass
> > =A0--Fail
> > =A0--SoftFail
> > =A0--Neutral
> > =A0--None
> > =A0--TempError
> > =A0--PermError
> >
> > So I think that it should be clearly stated, in Section 4.1, wher= e
> > the SPF mechanims is specified, that only a 'positive' ma= tch in the
> > SPF-mechanism constitutes a pass in the realm of DMARC-processing= ; or
> > even better, stating that a 'neutral' match in the SPF-me= chanism does
> > NOT constitute a pass-result for the SPF-mechanism in the realm o= f
> > DMARC-processing.
> >
> > https://datatracker.ietf.org/doc/= draft-kucherawy-dmarc-base/?include_text=3D
> > 1
> >
> > Regards,
> >
> > J. Gomez
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--047d7b86e2f825f09104da091dba-- From jgomez@seryrich.com Wed Apr 10 15:23:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D6821F89A5 for ; Wed, 10 Apr 2013 15:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HS_INDEX_PARAM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGEZiEvzW4bY for ; Wed, 10 Apr 2013 15:23:44 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD9B21F89DE for ; Wed, 10 Apr 2013 15:23:41 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Apr 2013 00:23:39 +0200 Message-ID: From: "J. Gomez" To: References: <8776B592E1C84D2296CEFB29C537ADFA@fgsr.local><6BF223534B2C4D378C844224DD60B7D1@fgsr.local> <15186253.T94leth7fX@scott-latitude-e6320> Date: Thu, 11 Apr 2013 00:24:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass inthe DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 22:23:47 -0000 Specifying that neutral does not mean pass would be better. J. Gomez On Thursday, April 11, 2013 12:01 AM [GMT+1=3DCET], Scott Kitterman = wrote: > So we need to specify that pass means pass? >=20 > Scott K >=20 > On Wednesday, April 10, 2013 11:44:57 PM J. Gomez wrote: > > It does remain dubious whether an alignment with a 'neutral' match > > if SPF is a DMARC-pass or not for the SPF-mechanism in the realm of > > DMARC-processing.=20 > >=20 > > Consider this SPF DNS RR for "example.com": > >=20 > > "v=3Dspf1 ip4:195.234.236.237 ?ip4:195.234.236.238 ~all" > >=20 > > And here comes an email from a sending MTA at IP 195.234.236.238 > > carrying a RFC5321.MailFrom of jsmith@example.com and a > > RFC5322.From header of jsmith@example.com. > >=20 > > The "From:" header identifier in that email is explicitedly aligned > > with a 'neutral' match in SPF. So there is a match, and there is an > > alignment. But not an alignment 'good enough' for DMARC, or > > 'qualified enough' for DMARC. Therefore this nuance should be > > clearly stated in the DMARC specification, to avoid rivers of ink > > flowing in the future.=20 > >=20 > > Regards, > >=20 > > J. Gomez > >=20 > >=20 > > ---- Original Message ---- > > From: Murray S. Kucherawy > > To: J. G=F3mez > > Cc: dmarc@ietf.org > > Sent: Wednesday, April 10, 2013 11:20 PM > > Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a > > SPF-pass in the DMARC realm > >=20 > > > Section 4.1 only identifies the underlying mechanisms and > > > references their defining documents. It doesn't dive into their > > > interpretation=20 > > >=20 > > > at all. Meanwhile, Section 5 says: > > > A Mail Receiver MUST consider an arriving message to pass the > > > DMARC test if and only if one or more of the underlying message > > > authentication mechanisms pass with proper identifier > > > alignment.=20 > > >=20 > > > This doesn't strike me as ambiguous versus the list of possible > > > SPF outcomes, or DKIM's for that matter. > > >=20 > > >=20 > > >=20 > > > On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez > > > wrote:=20 > > >=20 > > > Hello all. > > >=20 > > > It is 'somewhat' clear that in the realm of DMARC-processing only > > > a 'positive' SPF match constitutes a pass for the SPF-mechanism. > > > I.e., that a SPF match for 'neutral' does NOT constitute a pass > > > for the SPF-mechanism in the realm of DMARC-processing. However, > > > this is not clearly stated, beyond reasonable doubt and > > > discussion, in the DMARC draft specification. > > >=20 > > > Possible result of a SPF check, according to RFC 4408, are: > > > --Pass > > > --Fail > > > --SoftFail > > > --Neutral > > > --None > > > --TempError > > > --PermError > > >=20 > > > So I think that it should be clearly stated, in Section 4.1, where > > > the SPF mechanims is specified, that only a 'positive' match in > > > the SPF-mechanism constitutes a pass in the realm of > > > DMARC-processing; or even better, stating that a 'neutral' match > > > in the SPF-mechanism does NOT constitute a pass-result for the > > > SPF-mechanism in the realm of DMARC-processing. > > >=20 > > > = https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D > > > 1 > > >=20 > > > Regards, > > >=20 > > > J. Gomez > > >=20 > > > _______________________________________________ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > >=20 > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From johnl@taugh.com Wed Apr 10 15:48:50 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C518121F874E for ; Wed, 10 Apr 2013 15:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W5XxylS7lCc for ; Wed, 10 Apr 2013 15:48:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id CD86F21F873D for ; Wed, 10 Apr 2013 15:48:49 -0700 (PDT) Received: (qmail 15540 invoked from network); 10 Apr 2013 22:48:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=3cb2.5165ec51.k1304; bh=PY+ql6L5pxcK8PHB71LH7R56zh4eMrbx240ZkNOzPbg=; b=C6lZyG9nsPsrXjbPJRRN99kAeJCiStEbmib4mmW94AeZNejmpQFyKeNVTJDoqucKD1D5Bn0lgRpdAn0F+b+vsUT9sS8nlY65qXch79gqQrz0upY+/1kQYahruj2gXIa+WOPqCo+bvBGCK6WXKsq4BGlgfmiO0wmgqx1yvINT1T0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=3cb2.5165ec51.k1304; bh=PY+ql6L5pxcK8PHB71LH7R56zh4eMrbx240ZkNOzPbg=; b=ZafMl4kipRcUUcFIZVSI482+3AQkhH3TdsN5ul3yuW/TT7TTdNInpl7n/DElNOXXtbpm4qgfL6+13mUnlw6d8IZ44j4CZpQ5YGMdRCEZ+kNi5VtobjTJERy/5u7XbC87RnZqW/GM90TYxDGKqyzQQ8/bfO25s+r8Z8DPlTDjUI8= Received: (ofmipd 127.0.0.1); 10 Apr 2013 22:48:27 -0000 Date: 10 Apr 2013 18:48:45 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <51657132.4000604@gmail.com> References: <20130409164432.68830.qmail@joyce.lan> <51657132.4000604@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 22:48:50 -0000 >> Of course there is. The list can use DKIM and SPF just like anyone or >> anything else. It's not hard, my lists all do it. There is no magic > > John, your response isn't just wrong, it dangerous. Hi, Dave. If you'd read the rest of my note, I think you'd find that we basically agree. My point is that mailing lists can apply an SPF or DKIM identifier to their mail stream just like anyone else. And they don't have to change anything to do it, since neither one depends on what address is in the From: header, or what is or isn't in the subject line, or any of the other stuff that people have wrongly been claiming that cause problems with mailing lists. You are quite right that just an SPF or DKIM pass doesn't prove anything unless you have some other knowledge about the associated domain. But we have ways to deal with that, whether it's per-system lists of known list signing domains or shared lists via VBR. R's, John From dcrocker@gmail.com Wed Apr 10 15:55:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6A821F882A for ; Wed, 10 Apr 2013 15:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z822jM+b-AWV for ; Wed, 10 Apr 2013 15:55:18 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 611BE21F87F5 for ; Wed, 10 Apr 2013 15:55:16 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id kx1so562658pab.28 for ; Wed, 10 Apr 2013 15:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9uISU0SJvyRrcXp6m3s469jMYc+LKnP7WVg3C4Ui6OM=; b=ElPr5/miDkBWk7fVRp7k67uEQM1AFc9xKggdmPoh8VWTbRHMC/pAC5t4uS/yHWQdLi yfEmAenVYdyk45/jpsmi9Bzg88YxcBhahbldIG10CGRIeFW7DjPH5r+03gpuvArqcrxe IUqVO92cYVy2VFuFWO51NVWdSfYpdtq9jCQWAUf7XpxnRTQjdsFpgwG17wlgFIc14mxn O+iQwlmcysqB6VVhDH8xfQvbdwCpRqwr8zU4gJLIjOnl+h7drAPYO/yXRtQ1lCwOuPDH IATuL8c0zIU68yi1Kum2Mo/Tw7Cd7MyZje04z9oEwsm3r5zcJ7KG+W9QhLCmYH3HAXE4 EjiQ== X-Received: by 10.66.174.143 with SMTP id bs15mr6268435pac.17.1365634508600; Wed, 10 Apr 2013 15:55:08 -0700 (PDT) Received: from [10.21.138.85] ([68.65.169.66]) by mx.google.com with ESMTPS id t1sm2128807pab.12.2013.04.10.15.55.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Apr 2013 15:55:07 -0700 (PDT) Message-ID: <5165EDC3.3030700@gmail.com> Date: Wed, 10 Apr 2013 15:54:59 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John R Levine References: <20130409164432.68830.qmail@joyce.lan> <51657132.4000604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 10 Apr 2013 22:55:19 -0000 On 4/10/2013 3:48 PM, John R Levine wrote: >>> Of course there is. The list can use DKIM and SPF just like anyone or >>> anything else. It's not hard, my lists all do it. There is no magic >> >> John, your response isn't just wrong, it dangerous. > > Hi, Dave. If you'd read the rest of my note, I think you'd find that we > basically agree. I wasn't commenting on the larger context. It was your specific statement, and I think it largely undermined the larger point. d/ -- Dave Crocker bbiw.net From superuser@gmail.com Wed Apr 10 18:11:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAEE21F8A2A for ; Wed, 10 Apr 2013 18:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QunV3k7yhoBC for ; Wed, 10 Apr 2013 18:11:19 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id E11F921F870F for ; Wed, 10 Apr 2013 18:11:18 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ez12so35852wid.11 for ; Wed, 10 Apr 2013 18:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2PktsWHabWiOX9uzm50/M8TDlvjBmiJvLdXoQoCjjVE=; b=ZcMaxRiG0Yf27WSrUsy6qjjmRUJRf8WOVcrWJcjBmZvjJ5fiXhr+Fz4NIDs7XqYx6N ZojZAnC/2KXtvsEkyFdCJpA+K7WL53TGnv13Tjt1GsokDrM7ntRW9KHNlDekZfFm7b2+ YGNUxaIoDGhSPLqPf9OS/CgI7kb6Ww4s44I5yPk3LxjURqhOUaXq7o5iYkP5HfIsiWBl ifmLySAc+hVn2xRoqBNwHcaAPUYO8XV6lpkhFHZ4JVOrykHoW2Ge9qUbw3tTKnXC6tvE jtQz2LV+IQ7y9xwebPctgr+Ji87RRZjihVWsYe7pqeNdyU31yOGYc7Q7JxbKcXkWE0y2 WmuA== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr7062177wjb.17.1365642677761; Wed, 10 Apr 2013 18:11:17 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 10 Apr 2013 18:11:17 -0700 (PDT) In-Reply-To: References: <8776B592E1C84D2296CEFB29C537ADFA@fgsr.local> <6BF223534B2C4D378C844224DD60B7D1@fgsr.local> <15186253.T94leth7fX@scott-latitude-e6320> Date: Wed, 10 Apr 2013 18:11:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7b5d8cffb2bf6604da0b76fe Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass inthe DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 01:11:20 -0000 --047d7b5d8cffb2bf6604da0b76fe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are there any existing implementations of SPF that would return a "pass" result for the example you gave? I don't think the rule of the excluded middle applies here. The logic is "pass" vs "does not pass" (which covers the universe of possibilities), not "pass" vs "fail" (which does not). If the consensus really is that this is ambiguous, then I suggest referring to the specific sections of the DKIM and SPF RFCs where "pass" (or equivalent) is defined. But I don't agree that the current draft text is ambiguous. Anyone else? On Wed, Apr 10, 2013 at 3:24 PM, J. Gomez wrote: > Specifying that neutral does not mean pass would be better. > > J. Gomez > > > On Thursday, April 11, 2013 12:01 AM [GMT+1=3DCET], Scott Kitterman wrote= : > > > So we need to specify that pass means pass? > > > > Scott K > > > > On Wednesday, April 10, 2013 11:44:57 PM J. Gomez wrote: > > > It does remain dubious whether an alignment with a 'neutral' match > > > if SPF is a DMARC-pass or not for the SPF-mechanism in the realm of > > > DMARC-processing. > > > > > > Consider this SPF DNS RR for "example.com": > > > > > > "v=3Dspf1 ip4:195.234.236.237 ?ip4:195.234.236.238 ~all" > > > > > > And here comes an email from a sending MTA at IP 195.234.236.238 > > > carrying a RFC5321.MailFrom of jsmith@example.com and a > > > RFC5322.From header of jsmith@example.com. > > > > > > The "From:" header identifier in that email is explicitedly aligned > > > with a 'neutral' match in SPF. So there is a match, and there is an > > > alignment. But not an alignment 'good enough' for DMARC, or > > > 'qualified enough' for DMARC. Therefore this nuance should be > > > clearly stated in the DMARC specification, to avoid rivers of ink > > > flowing in the future. > > > > > > Regards, > > > > > > J. Gomez > > > > > > > > > ---- Original Message ---- > > > From: Murray S. Kucherawy > > > To: J. G=F3mez > > > Cc: dmarc@ietf.org > > > Sent: Wednesday, April 10, 2013 11:20 PM > > > Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a > > > SPF-pass in the DMARC realm > > > > > > > Section 4.1 only identifies the underlying mechanisms and > > > > references their defining documents. It doesn't dive into their > > > > interpretation > > > > > > > > at all. Meanwhile, Section 5 says: > > > > A Mail Receiver MUST consider an arriving message to pass the > > > > DMARC test if and only if one or more of the underlying message > > > > authentication mechanisms pass with proper identifier > > > > alignment. > > > > > > > > This doesn't strike me as ambiguous versus the list of possible > > > > SPF outcomes, or DKIM's for that matter. > > > > > > > > > > > > > > > > On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez > > > > wrote: > > > > > > > > Hello all. > > > > > > > > It is 'somewhat' clear that in the realm of DMARC-processing only > > > > a 'positive' SPF match constitutes a pass for the SPF-mechanism. > > > > I.e., that a SPF match for 'neutral' does NOT constitute a pass > > > > for the SPF-mechanism in the realm of DMARC-processing. However, > > > > this is not clearly stated, beyond reasonable doubt and > > > > discussion, in the DMARC draft specification. > > > > > > > > Possible result of a SPF check, according to RFC 4408, are: > > > > --Pass > > > > --Fail > > > > --SoftFail > > > > --Neutral > > > > --None > > > > --TempError > > > > --PermError > > > > > > > > So I think that it should be clearly stated, in Section 4.1, where > > > > the SPF mechanims is specified, that only a 'positive' match in > > > > the SPF-mechanism constitutes a pass in the realm of > > > > DMARC-processing; or even better, stating that a 'neutral' match > > > > in the SPF-mechanism does NOT constitute a pass-result for the > > > > SPF-mechanism in the realm of DMARC-processing. > > > > > > > > > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D > > > > 1 > > > > > > > > Regards, > > > > > > > > J. Gomez > > > > > > > > _______________________________________________ > > > > dmarc mailing list > > > > dmarc@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dmarc > > > > > > _______________________________________________ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7b5d8cffb2bf6604da0b76fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Are there any existing implementations of SPF th= at would return a "pass" result for the example you gave?

=
I don't think the rule of the excluded middle applies here.=A0 Th= e logic is "pass" vs "does not pass" (which covers the = universe of possibilities), not "pass" vs "fail" (which= does not).

If the consensus really is that this is ambi= guous, then I suggest referring to the specific sections of the DKIM and SP= F RFCs where "pass" (or equivalent) is defined.=A0 But I don'= t agree that the current draft text is ambiguous.=A0 Anyone else?



On Wed, Apr 10, 2013 at 3:24 PM, J. Gomez <jgomez@seryrich.com<= /a>> wrote:
Specifying that neutral does not mean pass w= ould be better.

J. Gomez


On Thursday, April 11, 2013 12:01 AM [GMT+1=3DCET], Scott Kitterman wrote:<= br>
> So we need to specify that pass means pass?
>
> Scott K
>
> On Wednesday, April 10, 2013 11:44:57 PM J. Gomez wrote:
> > It does remain dubious whether an alignment with a 'neutral&#= 39; match
> > if SPF is a DMARC-pass or not for the SPF-mechanism in the realm = of
> > DMARC-processing.
> >
> > Consider this SPF DNS RR for "example.com":
> >
> > "v=3Dspf1 ip4:195.234.236.237 ?ip4:195.234.236.238 ~all"= ;
> >
> > And here comes an email from a sending MTA at IP 195.234.236.238<= br> > > carrying a RFC5321.MailFrom of jsmith@example.com and a
> > RFC5322.From header of jsmi= th@example.com.
> >
> > The "From:" header identifier in that email is explicit= edly aligned
> > with a 'neutral' match in SPF. So there is a match, and t= here is an
> > alignment. But not an alignment 'good enough' for DMARC, = or
> > 'qualified enough' for DMARC. Therefore this nuance shoul= d be
> > clearly stated in the DMARC specification, to avoid rivers of ink=
> > flowing in the future.
> >
> > Regards,
> >
> > J. Gomez
> >
> >
> > ---- Original Message ----
> > From: Murray S. Kucherawy
> > To: J. G=F3mez
> > Cc: dmarc@ietf.org
> > Sent: Wednesday, April 10, 2013 11:20 PM
> > Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a<= br> > > SPF-pass in the DMARC realm
> >
> > > Section 4.1 only identifies the underlying mechanisms and > > > references their defining documents. =A0It doesn't dive = into their
> > > interpretation
> > >
> > > at all. =A0Meanwhile, Section 5 says:
> > > =A0 =A0A Mail Receiver MUST consider an arriving message to = pass the
> > > =A0 =A0DMARC test if and only if one or more of the underlyi= ng message
> > > =A0 =A0authentication mechanisms pass with proper identifier=
> > > alignment.
> > >
> > > This doesn't strike me as ambiguous versus the list of p= ossible
> > > SPF outcomes, or DKIM's for that matter.
> > >
> > >
> > >
> > > On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez <jgomez@seryrich.com>
> > > wrote:
> > >
> > > Hello all.
> > >
> > > It is 'somewhat' clear that in the realm of DMARC-pr= ocessing only
> > > a 'positive' SPF match constitutes a pass for the SP= F-mechanism.
> > > I.e., that a SPF match for 'neutral' does NOT consti= tute a pass
> > > for the SPF-mechanism in the realm of DMARC-processing. Howe= ver,
> > > this is not clearly stated, beyond reasonable doubt and
> > > discussion, in the DMARC draft specification.
> > >
> > > Possible result of a SPF check, according to RFC 4408, are:<= br> > > > =A0--Pass
> > > =A0--Fail
> > > =A0--SoftFail
> > > =A0--Neutral
> > > =A0--None
> > > =A0--TempError
> > > =A0--PermError
> > >
> > > So I think that it should be clearly stated, in Section 4.1,= where
> > > the SPF mechanims is specified, that only a 'positive= 9; match in
> > > the SPF-mechanism constitutes a pass in the realm of
> > > DMARC-processing; or even better, stating that a 'neutra= l' match
> > > in the SPF-mechanism does NOT constitute a pass-result for t= he
> > > SPF-mechanism in the realm of DMARC-processing.
> > >
> > > https://datatracker.ietf.org= /doc/draft-kucherawy-dmarc-base/?include_text=3D
> > > 1
> > >
> > > Regards,
> > >
> > > J. Gomez
> > >
> > > _______________________________________________
> > > dmarc mailing list
> > > dmarc@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dmarc
> >
> > _______________________________________________
> > dmarc mailing list
> > dmarc@ietf.org
> > https://www.ietf.org/mailman/listinfo/dmarc
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--047d7b5d8cffb2bf6604da0b76fe-- From sklist@kitterman.com Wed Apr 10 18:24:36 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A8021F8A6B for ; Wed, 10 Apr 2013 18:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WvQXv9gjKmg for ; Wed, 10 Apr 2013 18:24:35 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id CCEDE21F8A69 for ; Wed, 10 Apr 2013 18:24:34 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id ED3F6D04088; Wed, 10 Apr 2013 20:24:33 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365643474; bh=hEDpx0GZGQzs7ty6WnDF/HcrJpxBePeZ+sswHjtYEsc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=mc4wzjSjTOszMFWqiXk0B7/H2yX2/3ZEZ7MOPmxKti3afEFa/psIbexYLDic9RFhK pBTGTaBTVBCQDKJJnsjBQ6eHI4ynRlHh+mZy9Kw4Q1UMHP8GI0Q/FqRtw6PE9DvUQI rkmxvQWFQM0CgbzBNDROG6MSYGng/hpW2INw9fQg= Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id ADFC2D04046; Wed, 10 Apr 2013 20:24:33 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <8776B592E1C84D2296CEFB29C537ADFA@fgsr.local><6BF223534B2C4D378C844224DD60B7D1@fgsr.local> <15186253.T94leth7fX@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Wed, 10 Apr 2013 21:22:31 -0400 To: dmarc@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass inthe DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 01:24:36 -0000 If the definition of neutral in 4408 or 4408bis isn't clear enough, I don't think the DMARC spec is going to close the comprehension gap. Scott K "J. Gomez" wrote: >Specifying that neutral does not mean pass would be better. > >J. Gomez > > >On Thursday, April 11, 2013 12:01 AM [GMT+1=CET], Scott Kitterman >wrote: > >> So we need to specify that pass means pass? >> >> Scott K >> >> On Wednesday, April 10, 2013 11:44:57 PM J. Gomez wrote: >> > It does remain dubious whether an alignment with a 'neutral' match >> > if SPF is a DMARC-pass or not for the SPF-mechanism in the realm of >> > DMARC-processing. >> > >> > Consider this SPF DNS RR for "example.com": >> > >> > "v=spf1 ip4:195.234.236.237 ?ip4:195.234.236.238 ~all" >> > >> > And here comes an email from a sending MTA at IP 195.234.236.238 >> > carrying a RFC5321.MailFrom of jsmith@example.com and a >> > RFC5322.From header of jsmith@example.com. >> > >> > The "From:" header identifier in that email is explicitedly aligned >> > with a 'neutral' match in SPF. So there is a match, and there is an >> > alignment. But not an alignment 'good enough' for DMARC, or >> > 'qualified enough' for DMARC. Therefore this nuance should be >> > clearly stated in the DMARC specification, to avoid rivers of ink >> > flowing in the future. >> > >> > Regards, >> > >> > J. Gomez >> > >> > >> > ---- Original Message ---- >> > From: Murray S. Kucherawy >> > To: J. Gómez >> > Cc: dmarc@ietf.org >> > Sent: Wednesday, April 10, 2013 11:20 PM >> > Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a >> > SPF-pass in the DMARC realm >> > >> > > Section 4.1 only identifies the underlying mechanisms and >> > > references their defining documents. It doesn't dive into their >> > > interpretation >> > > >> > > at all. Meanwhile, Section 5 says: >> > > A Mail Receiver MUST consider an arriving message to pass the >> > > DMARC test if and only if one or more of the underlying >message >> > > authentication mechanisms pass with proper identifier >> > > alignment. >> > > >> > > This doesn't strike me as ambiguous versus the list of possible >> > > SPF outcomes, or DKIM's for that matter. >> > > >> > > >> > > >> > > On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez >> > > wrote: >> > > >> > > Hello all. >> > > >> > > It is 'somewhat' clear that in the realm of DMARC-processing only >> > > a 'positive' SPF match constitutes a pass for the SPF-mechanism. >> > > I.e., that a SPF match for 'neutral' does NOT constitute a pass >> > > for the SPF-mechanism in the realm of DMARC-processing. However, >> > > this is not clearly stated, beyond reasonable doubt and >> > > discussion, in the DMARC draft specification. >> > > >> > > Possible result of a SPF check, according to RFC 4408, are: >> > > --Pass >> > > --Fail >> > > --SoftFail >> > > --Neutral >> > > --None >> > > --TempError >> > > --PermError >> > > >> > > So I think that it should be clearly stated, in Section 4.1, >where >> > > the SPF mechanims is specified, that only a 'positive' match in >> > > the SPF-mechanism constitutes a pass in the realm of >> > > DMARC-processing; or even better, stating that a 'neutral' match >> > > in the SPF-mechanism does NOT constitute a pass-result for the >> > > SPF-mechanism in the realm of DMARC-processing. >> > > >> > > >https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= >> > > 1 >> > > >> > > Regards, >> > > >> > > J. Gomez >> > > >> > > _______________________________________________ >> > > dmarc mailing list >> > > dmarc@ietf.org >> > > https://www.ietf.org/mailman/listinfo/dmarc >> > >> > _______________________________________________ >> > dmarc mailing list >> > dmarc@ietf.org >> > https://www.ietf.org/mailman/listinfo/dmarc >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From johnl@iecc.com Wed Apr 10 21:07:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C786021F8B9C for ; Wed, 10 Apr 2013 21:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.099 X-Spam-Level: X-Spam-Status: No, score=-111.099 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSXJHRTNMQyf for ; Wed, 10 Apr 2013 21:07:43 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E0A2621F8B9B for ; Wed, 10 Apr 2013 21:07:42 -0700 (PDT) Received: (qmail 4521 invoked from network); 11 Apr 2013 04:07:42 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Apr 2013 04:07:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5166370c.xn--hew.k1304; i=johnl@user.iecc.com; bh=KxlQjcgaF0FeazFZexWataguheEB91OWd2uxRG0lFiE=; b=KRzNO17tJOjpLOm2l0r2K8tLuPlLPoNx0VuFSzifa5pD3EsFNuWJqhA2KafW1VEBBtaGg7Id7zTZ7PIKWAsKbFraa1VE0A4x0CdaiiCqIhZfsn9dYr/n+q8ECjfR7JXInPJCT/OUOMNCOUFgV2CiKljW+bP4b/mrxpG3CLoRS7c= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5166370c.xn--hew.k1304; olt=johnl@user.iecc.com; bh=KxlQjcgaF0FeazFZexWataguheEB91OWd2uxRG0lFiE=; b=05NIgxMRH/r6kyswh+V1CxjekN1zjlgOjazNyfYrrZbtCMgFdokhS4yDmKAgrJpBt9rZJTge5rX5zhCcBbQYwbspGjPh1wTxGqyn4DbKKKz+v+PkUGW12ZAezwy+58vlvleZXs7ffBKEC6vSWDGxi5leWg0Kje4NpijRazK9/hU= Date: 11 Apr 2013 04:07:18 -0000 Message-ID: <20130411040718.9032.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EEBE4B@ESV4-MBX01.linkedin.biz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: fmartin@linkedin.com Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 04:07:43 -0000 >Yes, sure, my question is outside this alignment business and header spoofing. What header "most" describes a mailing list? >Is there some convention already in place? Before we go down this rathole, I would point out that I do not think I have ever seen spam that pretended to be from a real mailing list. The identfier is List-ID defined in RFC 2919, but since any bad guy can insert any List-ID he wants, it's not useful for any sort of security. (It's plenty useful for mail sorting, of course.) As is always the case, assertions about the virtue of your own mail are not credible, so there is no way that lists can securely identify themselves without outside help. If you want to securely whitelist mail from lists, you need to to the same thing you do to whitelist any other kind of mail: A) define a convention to associate identifers with lists, e.g. DKIM signing domains or SPF bounce domains, and B) create private or shared sets of reputable identifiers. Of course, since lists tend to have good reputations anyway, we wouldn't need to worry about this if people didn't deliberately break list mail by publishing false DMARC policy assertions and signing up for lists. R's, John From johnl@iecc.com Wed Apr 10 21:10:11 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BE121F8C35 for ; Wed, 10 Apr 2013 21:10:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.124 X-Spam-Level: X-Spam-Status: No, score=-111.124 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h0g3kZXGM-X for ; Wed, 10 Apr 2013 21:10:10 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 010AD21F8C23 for ; Wed, 10 Apr 2013 21:10:09 -0700 (PDT) Received: (qmail 5191 invoked from network); 11 Apr 2013 04:10:10 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Apr 2013 04:10:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516637a0.xn--i8sz2z.k1304; i=johnl@user.iecc.com; bh=hKrRMMEnLFkFFX5P97bnxUmiv5R1uaOE7il5gcYcjpc=; b=Ms1GYXGttOlW9GJ/Pq6iSabADk1XpeQ3C++8D2a2O5HiA0+i24+frTaYQcjyFL88gJpJ25oFdazHKP5yMZE7oAtqPFX4ei1kyASDjSoprHXeieJX52AA1Z9tGy6NYmfS+IOOc58tGYWBkRJTNJeNae3Nk3rGNrv/hhUTcctSktU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516637a0.xn--i8sz2z.k1304; olt=johnl@user.iecc.com; bh=hKrRMMEnLFkFFX5P97bnxUmiv5R1uaOE7il5gcYcjpc=; b=kclTQ3j63GYoLwiHEGbxlxX4bQecWRfQ+nAE9DpF4jpG/rhpN3C2vb7AHQLaqeKcfARJ3Vw58/m/Yp49n0XoBCBYo+719x8m6QsAOhdxROxTxzW/Hm3F1DbIgNCkg86+zRvjDve/2HsgI24rcCyVm3N5nWPwbGwR8/YaiBxysEg= Date: 11 Apr 2013 04:09:46 -0000 Message-ID: <20130411040946.9056.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: kboth@drkurt.com Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 04:10:11 -0000 >In light of the perception (by some) that SPF is negatively oriented (fail >can be relied upon to be meaningful, while all other results are less >actionable), I think so. The SPF spec is plenty clear on this point. SPF pass is well defined, it means what the spec says is means. I don't think it is a good idea for the DMARC spec to argue with people who inisist on misreading it. From steven.m.jones@gmail.com Wed Apr 10 21:18:22 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF4621F8BE8 for ; Wed, 10 Apr 2013 21:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AA6aHD-weXV for ; Wed, 10 Apr 2013 21:18:20 -0700 (PDT) Received: from mail-ia0-x22a.google.com (mail-ia0-x22a.google.com [IPv6:2607:f8b0:4001:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7366A21F8976 for ; Wed, 10 Apr 2013 21:18:19 -0700 (PDT) Received: by mail-ia0-f170.google.com with SMTP id j38so1073171iad.1 for ; Wed, 10 Apr 2013 21:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ClmQgcbGn/rIvGQzTDxMyjtv1tLx0FSlQLZvZPppgzQ=; b=MZQF0KgS1KfavS45wrhg4G9NRgzrc5MQxl2QQWC9hTKZ8X1MLcMSR/mA+0Cl0fcvh0 Fv4k5EHR37/aI4MaAYW/p6pDywsEjPqNoCe+6tf/HblbXViT21V7HxYhHPM2p4bpmPow DXCYbBkwcUPbQo5EAIXi59uGDzA9QmL+0KsSYbn1Gp8HUSLFj1HIWUE+DPoliNQErAr3 cMV09t01rbBV0x80g0MMf0GIKlcE2ePmejWEs3KYeXOPPZqZyCqxzF5zJouPHg3Fr/ay GRAAi8aUkP7+7PydvsqDnQXGrClxVU2kwh3TiO8CPMo6DgjuJI+e8Y30+8C5lNygcJwF MNNw== MIME-Version: 1.0 X-Received: by 10.50.57.5 with SMTP id e5mr3353398igq.57.1365653894904; Wed, 10 Apr 2013 21:18:14 -0700 (PDT) Received: by 10.50.156.168 with HTTP; Wed, 10 Apr 2013 21:18:14 -0700 (PDT) In-Reply-To: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> Date: Wed, 10 Apr 2013 21:18:14 -0700 Message-ID: From: Steve Jones To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7bdc18684ac4a004da0e1308 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 04:18:22 -0000 --047d7bdc18684ac4a004da0e1308 Content-Type: text/plain; charset=ISO-8859-1 Requirement 8 reflects the earliest usage, where section 7.1 reflects the "step-down" practice that evolved quite some time ago. I guess it's still accurate for 2/3 of the cases? :) Thanks for catching and pointing out the inconsistency. On Wed, Apr 10, 2013 at 1:31 PM, J. Gomez wrote: > I think there is minor contradiction in the draft specification of DMARC, > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 > > Requirement #8 reads: > > Senders should be able to specify a percentage of their messages > to which their policies should be applied, with the rest > unaffected, in order to experiment and to understand and > minimize deployment risk. > > And the first paragraph in section 7.1 reads: > > If the "pct" tag is present in a policy record, application of policy > is done on a selective basis. The stated percentage of messages that > fail the DMARC test MUST be subjected to whatever policy is selected > by the "p" or "sp" tag (if present). Those that are not thus > selected MUST instead be subjected to the next policy lower in terms > of severity. > > I think Requirement #8 should be redacted to more properly fit with > section 7.1, which by itself looks quite reasonable. > > Regards, > > J. Gomez > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7bdc18684ac4a004da0e1308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Requirement 8 reflects the earliest usage, where sect= ion 7.1 reflects the "step-down" practice that evolved quite some= time ago. I guess it's still accurate for 2/3 of the cases? :)

Thanks for catching and pointing out the inconsistency.


On Wed, Apr 10, 2= 013 at 1:31 PM, J. Gomez <jgomez@seryrich.com> wrote:
I think there is minor contradiction in the = draft specification of DMARC,
https://datatracker.ietf.org/doc/draft-kuc= herawy-dmarc-base/?include_text=3D1

Requirement #8 reads:

=A0Senders should be able to specify a percentage of their messages
=A0to which their policies should be applied, with the rest
=A0unaffected, in order to experiment and to understand and
=A0minimize deployment risk.

And the first paragraph in section 7.1 reads:

=A0If the "pct" tag is present in a policy record, application of= policy
=A0is done on a selective basis. =A0The stated percentage of messages that<= br> =A0fail the DMARC test MUST be subjected to whatever policy is selected
=A0by the "p" or "sp" tag (if present). =A0Those that a= re not thus
=A0selected MUST instead be subjected to the next policy lower in terms
=A0of severity.

I think Requirement #8 should be redacted to more properly fit with section= 7.1, which by itself looks quite reasonable.

Regards,

J. Gomez

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

--047d7bdc18684ac4a004da0e1308-- From superuser@gmail.com Wed Apr 10 22:43:11 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E2A21F8D8D for ; Wed, 10 Apr 2013 22:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCosM1qY5wAZ for ; Wed, 10 Apr 2013 22:43:10 -0700 (PDT) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3299C21F8D7A for ; Wed, 10 Apr 2013 22:43:10 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id a12so1214857wgh.33 for ; Wed, 10 Apr 2013 22:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n6xh2m8F7VgRPPTxWjl9n3j06uCmrvDlJBvCA7PUWBE=; b=0RMGFZQ3bJWDEOlawQLfE3apjB8CTmAjKQa4NFhvqfmqS4fe6PuyKsBWh5Ok7vmKNk gkon7GKg2WO9QtHH6ZZgpezY+HvOe6MfR4f+8rIIRZvml5TOGJH91BRj2L24Om2MO/Fj APGCWwJBZrAGybJu1WyjqWiXSmYJXe6iIxfxHThATmEvS8bAtPNl9U67PcDM6m/N7J2o jUNW0Suq9OWvW+jkuGwZEz4dzHZcL5esrX05vUNYuv6sik0dCqP0gk19vWCdLDD9ffR2 bWrYOY2qPqTg07INzdLt3EW0WCx5ZTL/h45RlVHQKebjRL2bWToJyYiY7+b+mv3J2KNa ST4w== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr8001556wjb.15.1365658989435; Wed, 10 Apr 2013 22:43:09 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 10 Apr 2013 22:43:09 -0700 (PDT) In-Reply-To: References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> Date: Wed, 10 Apr 2013 22:43:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Steve Jones Content-Type: multipart/alternative; boundary=089e010d8574f321fc04da0f428f Cc: "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 05:43:11 -0000 --089e010d8574f321fc04da0f428f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 10, 2013 at 9:18 PM, Steve Jones wrote: > Requirement 8 reflects the earliest usage, where section 7.1 reflects the > "step-down" practice that evolved quite some time ago. I guess it's still > accurate for 2/3 of the cases? :) > Technically speaking, we can't redact a requirement. That's like altering a purchase order to match what's being delivered. Rather, it's left in there as documentation of the evolution of the idea to what we ultimately produced. That said, he's right, the inconsistency is rather striking. > Thanks for catching and pointing out the inconsistency. > +1. Now we have to decide what to do about it. Off the top of my head, I suggest a parenthetical remark acknowledging the inconsistency and saying materially what I've said here. Does anyone have a better idea? -MSK --089e010d8574f321fc04da0f428f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 10, 2013 at 9:18 PM, Steve Jones <stev= en.m.jones@gmail.com> wrote:
Requirement 8 reflects= the earliest usage, where section 7.1 reflects the "step-down" p= ractice that evolved quite some time ago. I guess it's still accurate f= or 2/3 of the cases? :)

Technically speaking, we can&#= 39;t redact a requirement.=A0 That's like altering a purchase order to = match what's being delivered.=A0 Rather, it's left in there as docu= mentation of the evolution of the idea to what we ultimately produced.

That said, he's right, the inconsistency is rather striking.
=A0
Thanks for catching and pointing out the inconsistency.
=A0
+1.=A0 Now we have to decide what to do abo= ut it.=A0 Off the top of my head, I suggest a parenthetical remark acknowle= dging the inconsistency and saying materially what I've said here. Does= anyone have a better idea?

-MSK
--089e010d8574f321fc04da0f428f-- From vesely@tana.it Thu Apr 11 01:28:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDBD21F8E94 for ; Thu, 11 Apr 2013 01:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ItL0xycURgo for ; Thu, 11 Apr 2013 01:28:39 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 427DC21F8E9A for ; Thu, 11 Apr 2013 01:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365668917; bh=weGo7oFtMZFUixhJOWAcc/zBRrWtQIMKKvTiJX4Z0JE=; l=1544; h=Date:From:To:References:In-Reply-To; b=UGp/+y/7exwiwIRxtmW9qlC8LR+f3/JridfgsAaPkS5SssRxGBcZUFPfyjnzUgwQT G+OZyL9w9WpQ+1i5bShH+QG7eNH8ivDn/hDgexE27aamUx6UGxxQdYk+oTLUzCflav mYOiuQn96OSFoWLckkTF9rNRHYhzwZkguuQb6fxE= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 11 Apr 2013 10:28:37 +0200 id 00000000005DC02B.0000000051667435.00003853 Message-ID: <51667435.4010701@tana.it> Date: Thu, 11 Apr 2013 10:28:37 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 08:28:41 -0000 On Wed 10/Apr/2013 19:07:02 +0200 Franck Martin wrote: > On Apr 10, 2013, at 1:34 AM, Alessandro Vesely wrote: > >> OLD >> 1. The RFC5322.From domain is the identifier used for all message >> validation operations, as it is the single identifier in the >> message likely to be visible to the user. >> >> NEW >> 1. Either the RFC5322.From or the RFC2369.List-Post domains are >> the identifiers used for all message validation operations, as >> they are the single identifiers in the message whose upshot is >> paramountly visible to the user. >> >> We can specify mailing list recognition to be as stringent as needed, >> tunable, and possibly deploying VBR, DNSWL, and triple opt-in. We >> know we'll never be able to catch all list messages, but could do the >> right thing when we see one. > > 1) Why List-Post and not List-Id or another List-Header? It is not straightforward to extract the domain from List-Id. In addition, a system that tracks recurrent targets --for example, to implement an auto address-book feature-- can verify whether the user had previously written mail to such address. > 2) The trouble with list-x is that it is not exposed to the end > user in any way by any MUA (well may be some but I doubt it). IME it is a no-brainer to see that a message pertains to a mailing list, and also to discern which one. Possibly end users are not aware of some particular list-x, but lists tend to make sure their subscribers can tell list traffic from the rest of their mail. From vesely@tana.it Thu Apr 11 01:34:25 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9621521F8DDF for ; Thu, 11 Apr 2013 01:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21i1PVxO3m6l for ; Thu, 11 Apr 2013 01:34:24 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A2FDE21F8EB5 for ; Thu, 11 Apr 2013 01:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365669263; bh=5VUf2EIexFjcDFK7YVDKMVt95tsgZGDG+goc/3ilEVU=; l=1937; h=Date:From:To:References:In-Reply-To; b=cieUxwO9pfNqiJ6OOSA39meTmieiUf5rHZWZjEpTSvqR/pjb4jMpkUtmPXgTpcP9s eudQ9SAZqhiXB6ilqWJmm479q79ipHku0BDgW4Nyj99L0pac49sWSHQXJlmQRg6LWQ 9j0vYbu2aAIx87alXhOFWUnNZVd7yYei2D5wHl8g= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 11 Apr 2013 10:34:23 +0200 id 00000000005DC02B.000000005166758F.00005228 Message-ID: <5166758F.1040906@tana.it> Date: Thu, 11 Apr 2013 10:34:23 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 08:34:25 -0000 On Wed 10/Apr/2013 20:17:13 +0200 Murray S. Kucherawy wrote: > Unless I'm mistaken, Alessandro proposed solving the lists problem by > having DMARC authenticate an identifier from the List-* header field set > rather than only the From: field. Yes. Currently, the I-D just says that mailing lists need to be considered. My proposal is to identify them as one out of two possible mail-stream controllers. > The issue, as was discussed back in the ADSP days, is that you're > then deciding this message passes based on an identifier the end > user will never see. So I could craft a message with: > > From: security@paypal.com > List-Something: myaddress@phish-r-us.example > > ...and then arrange that the message passes DKIM and SPF for > phish-r-us.example, and put a DMARC policy up for that domain which will > also pass. The end user sees "security@paypal.com" in their inbox, > possibly even with a gold star next to it, and would likely not be shown > the List-Something field. Assuming spf=pass smtp.mailfrom=phish-r-us.example, the above is a /hint/ that the message may belong to such mailing list. I don't think DMARC should specify how to make sure that's the case, albeit it can mention some techniques (user's address-book, VBR, DNSWL, OAuth-driven opt-in, ...) Needless to say, receivers should err on the safe side. If, for any reason, the receiver is unable to ascertain the true mailing-listness of a message, it discards the hint and proceeds as it does currently. > Better yet, PayPal isn't notified of the problem because no DMARC > report request applies here. I'm not sure on this. Perhaps tuning could allow to determine notifications and policies from a matrix. Both notifications may be important: letting PayPal know that its user subscribed using the wrong domain, and letting the MLM know that one of its subscribers' domains switched to a transaction-only policy. From steven.m.jones@gmail.com Thu Apr 11 03:40:57 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE10321F8EFE for ; Thu, 11 Apr 2013 03:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjUny6iNJWAS for ; Thu, 11 Apr 2013 03:40:57 -0700 (PDT) Received: from mail-ia0-x22e.google.com (mail-ia0-x22e.google.com [IPv6:2607:f8b0:4001:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F126C21F8EFC for ; Thu, 11 Apr 2013 03:40:56 -0700 (PDT) Received: by mail-ia0-f174.google.com with SMTP id r13so1253731iar.19 for ; Thu, 11 Apr 2013 03:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SQ/3YJlNg8kDhq/mVgViPsW2btLAcI/th9PapLD2ICA=; b=tBNVwE/oIv5ko+sdbtN43eRl98fjFnKCweUvnxXoSRCpBqKIIGYXnG21WTxDX3SXpQ yOWE8/f3mAwEx5eZ17tYzCGNe53aTQ/lbyYZmjQ+Pw1cMm2rkjExVRf7TsYXj7A//Dul MpgOEtR+d2qci5lOJDakK4LL+YSMKKR3H79cA/czuxThn0PpM/LgEea1xiYjjRmH0/Mp vnln6JTu0KMxLfyzEifvYbmunwSl6lepK4wfoX4D6NeBHTdmC3s11I3bTJzaKhID47yd M6xbwKHHRDqeY6LSI9v4csFPf/Y8rq/7GukUirVuQDauWmnyjA0S+hY8eQGExIe6g6PI vQAw== MIME-Version: 1.0 X-Received: by 10.50.154.133 with SMTP id vo5mr4006033igb.77.1365676856585; Thu, 11 Apr 2013 03:40:56 -0700 (PDT) Received: by 10.50.156.168 with HTTP; Thu, 11 Apr 2013 03:40:56 -0700 (PDT) In-Reply-To: References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> Date: Thu, 11 Apr 2013 03:40:56 -0700 Message-ID: From: Steve Jones To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=14dae93405b9ea377f04da136b90 Cc: "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 10:40:57 -0000 --14dae93405b9ea377f04da136b90 Content-Type: text/plain; charset=ISO-8859-1 So maybe flagging any of the original requirements that were modified based on subsequent deployment experience would be a useful thing to avoid confusion - either in the reader's understanding, or in the impression that the prior contributors were confused. Perhaps add a sentence to the intro to the section: 2. Requirements Specification of DMARC is guided by the following high-level requirements, security dependencies, detailed requirements, and items that are documented as out-of-scope. Those requirements which were subsequently modified based on implementation experience have been indicated with _____. Not sure if a reference to, in this specific example, section 7.1 would be practical or you just add a "*" or something. Though without the reference, how useful is it? "And then there's this requirement. Which we might have tossed, or just changed in part. Figuring out which is left as an exercise for the reader." ;) No better idea here I'm afraid. On Wed, Apr 10, 2013 at 10:43 PM, Murray S. Kucherawy wrote: > On Wed, Apr 10, 2013 at 9:18 PM, Steve Jones wrote: > >> Requirement 8 reflects the earliest usage, where section 7.1 reflects the >> "step-down" practice that evolved quite some time ago. I guess it's still >> accurate for 2/3 of the cases? :) >> > > Technically speaking, we can't redact a requirement. That's like altering > a purchase order to match what's being delivered. Rather, it's left in > there as documentation of the evolution of the idea to what we ultimately > produced. > > That said, he's right, the inconsistency is rather striking. > > >> Thanks for catching and pointing out the inconsistency. >> > > +1. Now we have to decide what to do about it. Off the top of my head, I > suggest a parenthetical remark acknowledging the inconsistency and saying > materially what I've said here. Does anyone have a better idea? > > -MSK > --14dae93405b9ea377f04da136b90 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So maybe flagging any of the original requiremen= ts that were modified based on subsequent deployment experience would be a = useful thing to avoid confusion - either in the reader's understanding,= or in the impression that the prior contributors were confused.=A0 Perhaps= add a sentence to the intro to the section:

2.  Requirements

   Specification of DMARC is guided by the following high-level
   requirements, security dependencies, detailed requirements, and items
   that are documented as out-of-scope. Those requirements which were
  =
 subsequently modified based on implementation experience have been
   i=
ndicated with _____.


Not sure if a reference to, in = this specific example, section 7.1 would be practical or you just add a &qu= ot;*" or something. Though without the reference, how useful is it? &q= uot;And then there's this requirement. Which we might have tossed, or j= ust changed in part. Figuring out which is left as an exercise for the read= er." ;)

No better idea here I'm afraid.



On Wed, Apr 10, 20= 13 at 10:43 PM, Murray S. Kucherawy <superuser@gmail.com> = wrote:
On Wed, A= pr 10, 2013 at 9:18 PM, Steve Jones <steven.m.jones@gmail.com&g= t; wrote:
Requirement 8 reflects= the earliest usage, where section 7.1 reflects the "step-down" p= ractice that evolved quite some time ago. I guess it's still accurate f= or 2/3 of the cases? :)

Technically speaking, we= can't redact a requirement.=A0 That's like altering a purchase ord= er to match what's being delivered.=A0 Rather, it's left in there a= s documentation of the evolution of the idea to what we ultimately produced= .

That said, he's right, the inconsistency is rather striking.
=A0
Thanks for catching and pointing out the inconsistency.
=A0
+1.=A0 Now we have to decide what to = do about it.=A0 Off the top of my head, I suggest a parenthetical remark ac= knowledging the inconsistency and saying materially what I've said here= . Does anyone have a better idea?

-MSK

--14dae93405b9ea377f04da136b90-- From sklist@kitterman.com Thu Apr 11 05:03:17 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320A121F8C1E for ; Thu, 11 Apr 2013 05:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfZIHH5c4myJ for ; Thu, 11 Apr 2013 05:03:16 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8784121F8AE7 for ; Thu, 11 Apr 2013 05:03:16 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E233420E40CF; Thu, 11 Apr 2013 08:03:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365681795; bh=trT1RmHXIDIg/+8tCh166v776dVP9OYEJG2RrMrvuw0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bbXfYdiDXd+ooGsaR7rdKh8ror5uexdZS6Nw5J2OzOu8xOQ9oHoaHoooBJ++a93Z8 lQwn0s1v0wUR3VXfL1qXO5glblCCLPJdyOrAD9kBI14NmBKZwA//iBeyDUDT6b/37f zJhyL5nNpXsv7odR+d1VQWEiAO6a64HZ5IjWmBwQ= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 9C93B20E409E; Thu, 11 Apr 2013 08:03:05 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 11 Apr 2013 08:03:04 -0400 Message-ID: <1493788.cSHXJOYAQG@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 12:03:17 -0000 On Wednesday, April 10, 2013 10:43:09 PM Murray S. Kucherawy wrote: > On Wed, Apr 10, 2013 at 9:18 PM, Steve Jones wrote: > > Requirement 8 reflects the earliest usage, where section 7.1 reflects the > > "step-down" practice that evolved quite some time ago. I guess it's still > > accurate for 2/3 of the cases? :) > > Technically speaking, we can't redact a requirement. That's like altering > a purchase order to match what's being delivered. Rather, it's left in > there as documentation of the evolution of the idea to what we ultimately > produced. > > That said, he's right, the inconsistency is rather striking. > > > Thanks for catching and pointing out the inconsistency. > > +1. Now we have to decide what to do about it. Off the top of my head, I > suggest a parenthetical remark acknowledging the inconsistency and saying > materially what I've said here. Does anyone have a better idea? Why can't we change it? This is a new draft. Scott K From superuser@gmail.com Thu Apr 11 06:20:56 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9DB21F8AA8 for ; Thu, 11 Apr 2013 06:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK9f0b77Ah6X for ; Thu, 11 Apr 2013 06:20:55 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 855ED21F8A55 for ; Thu, 11 Apr 2013 06:20:53 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hn17so541586wib.6 for ; Thu, 11 Apr 2013 06:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SmAcsOVW2ZKFRRe3ipfbUKUdjiPVCRZy4ZwE829Jg+4=; b=IREu2dzwicic7bz1IV3KQ6qQwmIrZ5CxKqQF7FleP0Cl35og4SUMcyWf4zFXlTnAxB M8931GXnU6DbKa2mj0RlHnmhw6zKOZP+pfA9uvHvXPZfWqHD3jkTuiptoky+ixhT3IeW 5ruMI1yvDLCojAXDL8zy++UVaEp+45KNdoa0Ku62d8io5gQLSosiTv1k5VDoKoeT1/u/ YJDzBzFOn9WrZMLgFbt8+oukdRsaxtQXs3P5oMisS5i1Q2/Tp02BvbM2y8fOZouRTiiD ng8t2tXzEqXtWelEKPvZrSbSJwof8UQr13fvCowtqQ9/Ui6vk/cFnchoQfUDzRHVqcIb F2+A== MIME-Version: 1.0 X-Received: by 10.194.222.100 with SMTP id ql4mr10617967wjc.59.1365686452496; Thu, 11 Apr 2013 06:20:52 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 11 Apr 2013 06:20:52 -0700 (PDT) In-Reply-To: <5166758F.1040906@tana.it> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> Date: Thu, 11 Apr 2013 06:20:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a11c1b942e0386d04da15a7f6 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 13:20:56 -0000 --001a11c1b942e0386d04da15a7f6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 11, 2013 at 1:34 AM, Alessandro Vesely wrote: > Yes. Currently, the I-D just says that mailing lists need to be > considered. My proposal is to identify them as one out of two > possible mail-stream controllers. > This can't be done with any accuracy. If you relax DMARC processing of messages because they appear to be lists merely because of the presence of List-* header fields, then attackers will simply make all their mail look like list traffic. It feels a lot like we can make some fast progress by taking the DKIM mailing list archives, replace ADSP with DMARC, and skip to the end. :-) Assuming spf=pass smtp.mailfrom=phish-r-us.example, the above is a > /hint/ that the message may belong to such mailing list. I don't > think DMARC should specify how to make sure that's the case, albeit it > can mention some techniques (user's address-book, VBR, DNSWL, > OAuth-driven opt-in, ...) Needless to say, receivers should err on > the safe side. If, for any reason, the receiver is unable to > ascertain the true mailing-listness of a message, it discards the hint > and proceeds as it does currently. > I would say we should go no further than we have, which is to say that there's a way in the reports to indicate the report generator has a means to indicate it thinks the message came from a list. I'm wary of recommending any heuristics at all; that's like saying to an attacker "There's a big hole around here somewhere, if you can find it, and it might look something like this..." Existing implementations apply their own heuristics to relax for traffic they think is a list. DMARC as it stands provides for that option and includes it as a report parameter. I really think we should stop there. -MSK --001a11c1b942e0386d04da15a7f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2013 at 1:34 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
Yes. =A0Currently, the I-D just says that ma= iling lists need to be
considered. =A0My proposal is to identify them as one out of two
possible mail-stream controllers.

This = can't be done with any accuracy.=A0 If you relax DMARC processing of me= ssages because they appear to be lists merely because of the presence of Li= st-* header fields, then attackers will simply make all their mail look lik= e list traffic.

It feels a lot like we can make some fast progress by taking the = DKIM mailing list archives, replace ADSP with DMARC, and skip to the end.= =A0 :-)

Assuming spf=3Dpass smtp.mailfrom=3Dphish-r-us.example, the above is a
/hint/ that the message may belong to such mailing list. =A0I don't
think DMARC should specify how to make sure that's the case, albeit it<= br> can mention some techniques (user's address-book, VBR, DNSWL,
OAuth-driven opt-in, ...) =A0Needless to say, receivers should err on
the safe side. =A0If, for any reason, the receiver is unable to
ascertain the true mailing-listness of a message, it discards the hint
and proceeds as it does currently.

I wo= uld say we should go no further than we have, which is to say that there= 9;s a way in the reports to indicate the report generator has a means to in= dicate it thinks the message came from a list.=A0 I'm wary of recommend= ing any heuristics at all; that's like saying to an attacker "Ther= e's a big hole around here somewhere, if you can find it, and it might = look something like this..."

Existing implementations apply their own heuristics to relax= for traffic they think is a list.=A0 DMARC as it stands provides for that = option and includes it as a report parameter.=A0 I really think we should s= top there.

-MSK
--001a11c1b942e0386d04da15a7f6-- From sm@elandsys.com Thu Apr 11 03:28:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C35721F8ED8 for ; Thu, 11 Apr 2013 03:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEdSVEU6DqP8 for ; Thu, 11 Apr 2013 03:28:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E845B21F8EA7 for ; Thu, 11 Apr 2013 03:28:42 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.160]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3BASQro010594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Apr 2013 03:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365676122; bh=Pr3AuVqAEXX1k7B4fAPBBlvy2IMgGZJDKgYDW/jV+1U=; h=Date:To:From:Subject; b=nOIKdhngnJ+yM1gZF8GpNSlCCkyC7oQs/0DiTWPOn6aFmk/hAlMJOpnxYWVeGIPI0 7rMFVZoKb7OLf6jFSJV4yLn+tR9sIi565OGfNRXR+1+mFUHN4TcK7fqIl3mbByEGZS YKHNzcr/HrRCGjmRyDJe+JPfWq8Ug5kYuicfSri0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365676122; i=@elandsys.com; bh=Pr3AuVqAEXX1k7B4fAPBBlvy2IMgGZJDKgYDW/jV+1U=; h=Date:To:From:Subject; b=V345G9lIGuBellghmTQJ920zeg2+LZNVNwXTXfIGonOboxiuM3FdD5lbuit8YgL4X gOfCFthlnTzPwO81kCEhtrddKJ9YkNDuY1tPtM+2bst9TXcrCsYmkswn/5gQ7hAjpU iHJVCaVjLEf0JI5ZQx0F7M0EIgYj+GMaZoje8bU4= Message-Id: <6.2.5.6.2.20130411031751.0ce5baa8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 11 Apr 2013 03:21:28 -0700 To: dmarc@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Thu, 11 Apr 2013 06:23:50 -0700 Subject: [dmarc-ietf] Implementation status of draft-ietf-spfbis-4408bis X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 10:28:43 -0000 Hello, There is currently a WGLC for draft-ietf-spfbis-4408bis-14 [1]. I would like to have some information about the implementation of draft-ietf-spfbis-4408bis [2]. If you have implemented the draft, could you please send me the following information: (a) Implementation name (b) Description of implementation (please include a link to a web page if it contains information about the implementation) (c) The versions of the draft which were implemented (c) The parts of draft-ietf-spfbis-4408bis which were implemented Please follow up on spfbis@ietf.org. Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/spfbis/current/msg03347.html 2. http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-14 From superuser@gmail.com Thu Apr 11 06:27:00 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C296121F8493 for ; Thu, 11 Apr 2013 06:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K-WnXRtJU+k for ; Thu, 11 Apr 2013 06:27:00 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 028E621F848A for ; Thu, 11 Apr 2013 06:26:59 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id f12so1647661wgh.10 for ; Thu, 11 Apr 2013 06:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JYvlmuctbYAiHUHz5a42jPgm3T1r5fCEK44vJfe67jo=; b=hDAgRL/y9Db6JaFalhW8q7hPCNC1mxvQjRVnzOSI+3HU8ju3WylsoNqvwz6vu1cM4E vyLh3vQuHku+lC4Igf4LQ2ygojQx1m6svkXZrphuqibOCm173Nm3EK6ZTJGMUjEPB4Ga 2hTogQrneslsG///tfamAO/6DoOEE3jMp9S3BmwBItH9VMXS+JIjOUSBqmMgaeY2NvH6 5HwXtALf5w8Xc+kFBaeoHPFNzP8TUD90z/E4U9lFTXd8ygH063kwHtZTlKGKPWHwrCwS lWTXnQwyu6SRWrK5/pjqygiftzevi8TdN7snM9JrUwqDGvTuBEt28WFEjGvDFalznixD tj/A== MIME-Version: 1.0 X-Received: by 10.194.109.35 with SMTP id hp3mr10824052wjb.15.1365686819201; Thu, 11 Apr 2013 06:26:59 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 11 Apr 2013 06:26:59 -0700 (PDT) In-Reply-To: <1493788.cSHXJOYAQG@scott-latitude-e6320> References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> <1493788.cSHXJOYAQG@scott-latitude-e6320> Date: Thu, 11 Apr 2013 06:26:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=089e010d8574bba94a04da15bd94 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 13:27:00 -0000 --089e010d8574bba94a04da15bd94 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 11, 2013 at 5:03 AM, Scott Kitterman wrote: > > Why can't we change it? This is a new draft. > > The Requirements section, to me at least, documents the original set of goals we set out to address with DMARC; it's a historical record of what we wanted to produce, rather than an inventory of what we did produce. It seems fundamentally wrong to try to rewrite history. I won't die on this hill if consensus is otherwise. It just feels like a pretty strange thing to do. -MSK --089e010d8574bba94a04da15bd94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2013 at 5:03 AM, Scott Kitterman <skli= st@kitterman.com> wrote:

Why can't we change it? =A0This is a new draft.


The Requirements section, to me at lea= st, documents the original set of goals we set out to address with DMARC; i= t's a historical record of what we wanted to produce, rather than an in= ventory of what we did produce.=A0 It seems fundamentally wrong to try to r= ewrite history.

I won't die on this hill if consensus is otherwise.=A0 I= t just feels like a pretty strange thing to do.

-MSK
<= /div>
--089e010d8574bba94a04da15bd94-- From jtrentadams@gmail.com Thu Apr 11 08:08:23 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC20421F8FCF for ; Thu, 11 Apr 2013 08:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7df1am1zhb3 for ; Thu, 11 Apr 2013 08:08:23 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1256921F8D86 for ; Thu, 11 Apr 2013 08:08:22 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wp18so1499246obc.14 for ; Thu, 11 Apr 2013 08:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=RZSuHOz9OxAxo0iykY0UeslSH8wfquALVmMr3EPdA6A=; b=Dv0XTkk75kbj7pOWkzNqLSlY1TtjEBHNhhiqieaJHd2vMtdHWMQDBJ1ap6y3XpFTb3 Pn+4i8w3RwyJXMjMti+/M7YdNlWs1/8RmZAqgvx+xsPMl0a0ek/jrU6le3Wpyt7d/J9B k0UkffsdqCYthk7wZ+AkbhB0TEW0GVvNCG+8gXmx5oJmhAGeJRQb5ctTnIILL00xg+j7 X0Aq6pMY1zUilSVsztpDfgcQDkC2VP3+BIT01C5K/dmwrR4sYqmUDcX7wS23FqdsOAmy uvrilBnml1skr2P9ZFSD15R/4OtioOHEdKlmKZjCrAQDT5iCYrXfJuUqe/+Svt/GdQ3D 4Wwg== X-Received: by 10.182.180.67 with SMTP id dm3mr2353031obc.78.1365692902711; Thu, 11 Apr 2013 08:08:22 -0700 (PDT) Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPS id ru4sm366338obb.4.2013.04.11.08.08.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Apr 2013 08:08:22 -0700 (PDT) Message-ID: <5166D1E5.8020604@gmail.com> Date: Thu, 11 Apr 2013 09:08:21 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Steve Jones References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , "J. Gomez" Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 15:08:23 -0000 Good catch... and +1 to Steve's suggested approach. It seems to satisfy the "don't rewrite history" bit, plus it adds a useful indication that one idea was tried, but experience tempered the result (all without requiring lengthy discourse). - Trent On 4/11/13 4:40 AM, Steve Jones wrote: > So maybe flagging any of the original requirements that were modified > based on subsequent deployment experience would be a useful thing to > avoid confusion - either in the reader's understanding, or in the > impression that the prior contributors were confused. Perhaps add a > sentence to the intro to the section: > > 2. Requirements > > Specification of DMARC is guided by the following high-level > requirements, security dependencies, detailed requirements, and items > that are documented as out-of-scope. Those requirements which were > subsequently modified based on implementation experience have been > indicated with _____. > > > Not sure if a reference to, in this specific example, section 7.1 > would be practical or you just add a "*" or something. Though without > the reference, how useful is it? "And then there's this requirement. > Which we might have tossed, or just changed in part. Figuring out > which is left as an exercise for the reader." ;) > > No better idea here I'm afraid. > > > > On Wed, Apr 10, 2013 at 10:43 PM, Murray S. Kucherawy > > wrote: > > On Wed, Apr 10, 2013 at 9:18 PM, Steve Jones > > wrote: > > Requirement 8 reflects the earliest usage, where section 7.1 > reflects the "step-down" practice that evolved quite some time > ago. I guess it's still accurate for 2/3 of the cases? :) > > > Technically speaking, we can't redact a requirement. That's like > altering a purchase order to match what's being delivered. > Rather, it's left in there as documentation of the evolution of > the idea to what we ultimately produced. > > That said, he's right, the inconsistency is rather striking. > > > Thanks for catching and pointing out the inconsistency. > > > +1. Now we have to decide what to do about it. Off the top of my > head, I suggest a parenthetical remark acknowledging the > inconsistency and saying materially what I've said here. Does > anyone have a better idea? > > -MSK > > > > > _______________________________________________ > 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 johnl@iecc.com Thu Apr 11 08:34:33 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7576321F8F3A for ; Thu, 11 Apr 2013 08:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.139 X-Spam-Level: X-Spam-Status: No, score=-111.139 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvfaT2m+g7XE for ; Thu, 11 Apr 2013 08:34:30 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2927D21F8F2F for ; Thu, 11 Apr 2013 08:34:28 -0700 (PDT) Received: (qmail 86162 invoked from network); 11 Apr 2013 15:34:28 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Apr 2013 15:34:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5166d804.xn--9vv.k1304; i=johnl@user.iecc.com; bh=BRlGT6PWiVM3mwNh6II23H/G0+C0pDCYgd6HQnPBuzI=; b=gClQl91jqFXBqJ5Mdt61YfaAxLz3uW6JIKUbjp4nQoCfmipDIGalC5lJNI4j5KqM5PQRJ+gF+FHEfgjVXgalrW6SGmgGcvi3Xa6em773FOWb4aeudH5Oll8gJKDV+hUx/0eMYqDUPU1pIUJy9CX+z05I1+zYUrNnk9jxiqOPE1Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5166d804.xn--9vv.k1304; olt=johnl@user.iecc.com; bh=BRlGT6PWiVM3mwNh6II23H/G0+C0pDCYgd6HQnPBuzI=; b=NVqbVK6OCHjsLwgEh2i79sr5H+pN8v2dO3PRsOPTgZ1UFCpgpxFGctKITAz8h5eDo0O9MOMig+CZtk48fzPkRXfmeuqts2cuaB0Tkb2RinhvVkykJAENxQIDkG+X3KuiPcOqwAmtXOyxLro/re9SYuzFgY0XkSJYF6SO70h8jgU= Date: 11 Apr 2013 15:34:06 -0000 Message-ID: <20130411153406.13909.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 15:34:33 -0000 >It feels a lot like we can make some fast progress by taking the DKIM >mailing list archives, replace ADSP with DMARC, and skip to the end. :-) What he said. From prvs=806c9063e=fmartin@linkedin.com Thu Apr 11 09:51:32 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA77921F8F7F for ; Thu, 11 Apr 2013 09:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6wqp0R7aHPt for ; Thu, 11 Apr 2013 09:51:29 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2635F21F8F3C for ; Thu, 11 Apr 2013 09:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365699089; x=1397235089; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l4EUvaEkHXiwy50xSUgM2KvAtv3OTNh7+bx6dakJYpI=; b=T3qjHsRg+fA61rdJ/HUk+SKFU/yFLGMeA7IH8Y38kNdoR7LgA9JMDoaD JPAPyN9x1J2NbxNqnJ3F6AQk4iB0kyK2M7YYgBH7GMEfI9qH+kjUEoM4l zgHZfmwGGb+NGJeKhO1RZrsd5FZx1509v8k0C4EEfQa3K0fHz2HrphLn1 Y=; X-IronPort-AV: E=Sophos;i="4.87,456,1363158000"; d="scan'208,217";a="43697493" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Thu, 11 Apr 2013 09:51:20 -0700 From: Franck Martin To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHONcZUoCodz3RnZ0iFbS64dw4anJjQJXQAgAAO3ICAAAENgIAAA66AgADvfYCAAFALAIAAOtGA Date: Thu, 11 Apr 2013 16:51:20 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/alternative; boundary="_000_77426B543150464AA3F30DF1A91365DE52EF64A1ESV4MBX01linked_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 16:51:32 -0000 --_000_77426B543150464AA3F30DF1A91365DE52EF64A1ESV4MBX01linked_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 11, 2013, at 6:20 AM, Murray S. Kucherawy > wrote: On Thu, Apr 11, 2013 at 1:34 AM, Alessandro Vesely > wrote: Yes. Currently, the I-D just says that mailing lists need to be considered. My proposal is to identify them as one out of two possible mail-stream controllers. This can't be done with any accuracy. If you relax DMARC processing of mes= sages because they appear to be lists merely because of the presence of Lis= t-* header fields, then attackers will simply make all their mail look like= list traffic. It feels a lot like we can make some fast progress by taking the DKIM maili= ng list archives, replace ADSP with DMARC, and skip to the end. :-) Except there is a slight difference, ADSP was seldom adopted at receivers. = At best it became a score in spamassassin. DMARC is widely adopted. This I think change the perspective. Remember the difference between theory= and practice. In theory there should be no spam... --_000_77426B543150464AA3F30DF1A91365DE52EF64A1ESV4MBX01linked_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <287551885E3D17408D5D6EF02264E881@linkedin.com> Content-Transfer-Encoding: quoted-printable
On Apr 11, 2013, at 6:20 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Thu, Apr 11, 2013 at 1:34 AM, Alessandro Vesely <vesely@tana.it&= gt; wrote:
Yes.  Currently, the I-D just says that mailing lists need to be
considered.  My proposal is to identify them as one out of two
possible mail-stream controllers.

This can't be done with any accuracy.  If you relax DMARC process= ing of messages because they appear to be lists merely because of the prese= nce of List-* header fields, then attackers will simply make all their mail= look like list traffic.

It feels a lot like we can make some fast progress by taking the DKIM maili= ng list archives, replace ADSP with DMARC, and skip to the end.  :-)

Except there is a slight difference, ADSP was seldom adopted at receiv= ers. At best it became a score in spamassassin. DMARC is widely adopted.

This I think change the perspective. Remember the difference between t= heory and practice. In theory there should be no spam...
--_000_77426B543150464AA3F30DF1A91365DE52EF64A1ESV4MBX01linked_-- From superuser@gmail.com Thu Apr 11 10:19:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90D421F926E for ; Thu, 11 Apr 2013 10:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8+ITokSg3z9 for ; Thu, 11 Apr 2013 10:19:51 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id E5C8B21F9227 for ; Thu, 11 Apr 2013 10:19:50 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so1936463wgh.29 for ; Thu, 11 Apr 2013 10:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=+N0D8M1cIH4xHp4vu0NRW29qRD/ITRblpHUtTRZquog=; b=XHQDscwgCaonk3IJQPCTzim7xxvtjrF/UXNDa965d15LYcIynjrV90xx4IvU8LNW51 dF3UUGmBwDcnpK3xl4KYaY+k3f+REI1ZRY93pz1hwjOfJU2rlNkQkvcuwXmKElNQl6ZO uUCUCTFMQB1hwQPXY/rU3J5sMyCtvWjVS2/O7jig+93Z+s4KwyJSK5c/1iH7El1OHntL NY6W5KhmqsQAS4x6WRlFwRli2lU7OBuARiZtqm0dVEaK5kFV7DAQQMYJl32BJiTrrbxj PoQ4ZQecnzZLOvU5Atp3VEkl4zZXOPRPWeWCq53OnYrbmjWiJ0huj319YdPlUmBQ4Fbs DpVg== MIME-Version: 1.0 X-Received: by 10.180.74.67 with SMTP id r3mr35381287wiv.14.1365700790125; Thu, 11 Apr 2013 10:19:50 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 11 Apr 2013 10:19:49 -0700 (PDT) In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> Date: Thu, 11 Apr 2013 10:19:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d0438914d7709b104da18fe05 Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 17:19:52 -0000 --f46d0438914d7709b104da18fe05 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 11, 2013 at 9:51 AM, Franck Martin wrote: > > It feels a lot like we can make some fast progress by taking the DKIM > mailing list archives, replace ADSP with DMARC, and skip to the end. :-) > > > Except there is a slight difference, ADSP was seldom adopted at receivers. > At best it became a score in spamassassin. DMARC is widely adopted. > > This I think change the perspective. Remember the difference between > theory and practice. In theory there should be no spam... > I think all of us experienced in this space are aware of the difference. The best solutions appear to be those that look at the problem through both lenses, wouldn't you say? --f46d0438914d7709b104da18fe05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2013 at 9:51 AM, Franck Martin <fmar= tin@linkedin.com> wrote:

It feels a lot like we can make some fast progress by taking the DKIM maili= ng list archives, replace ADSP with DMARC, and skip to the end.=A0 :-)

Except there is a slight difference, ADSP was seldom adopted at = receivers. At best it became a score in spamassassin. DMARC is widely adopt= ed.

This I think change the perspective. Remember the difference between t= heory and practice. In theory there should be no spam...

I think all of us e= xperienced in this space are aware of the difference.=A0 The best solutions= appear to be those that look at the problem through both lenses, wouldn= 9;t you say?

--f46d0438914d7709b104da18fe05-- From prvs=806c9063e=fmartin@linkedin.com Thu Apr 11 10:33:26 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939CE21F8F69 for ; Thu, 11 Apr 2013 10:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDHKrpp9AaQ4 for ; Thu, 11 Apr 2013 10:33:25 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id C619721F910B for ; Thu, 11 Apr 2013 10:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365701605; x=1397237605; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0P2iKT7yMGdOcSmqIv/wtWRIosvzPwoNzb6G/TnW3fQ=; b=fhs6y3N69uuV4Mo/PwueGBjxDYSWiIus1E0AkrNvq2HIUzQS2p5PBAvh 2jZFYgu0wHtQ69T1B+PLmSf2cXAMC8SmlBgTjfXsSjY6z1fBMBcZgPKrH OsfQkIa6mC8zNwzcBlExcyJV4OwHlNh2Ba08khCJfUs4wPGN6Af5uitw4 M=; X-IronPort-AV: E=Sophos;i="4.87,456,1363158000"; d="scan'208,217";a="43703919" Received: from ESV4-HT01.linkedin.biz (172.18.46.235) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 11 Apr 2013 10:33:18 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Thu, 11 Apr 2013 10:33:18 -0700 From: Franck Martin To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHONcZUoCodz3RnZ0iFbS64dw4anJjQJXQAgAAO3ICAAAENgIAAA66AgADvfYCAAFALAIAAOtGAgAAH8oCAAAPIgA== Date: Thu, 11 Apr 2013 17:33:17 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EF6DAE@ESV4-MBX01.linkedin.biz> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: multipart/alternative; boundary="_000_77426B543150464AA3F30DF1A91365DE52EF6DAEESV4MBX01linked_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 17:33:26 -0000 --_000_77426B543150464AA3F30DF1A91365DE52EF6DAEESV4MBX01linked_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 11, 2013, at 10:19 AM, Murray S. Kucherawy > wrote: On Thu, Apr 11, 2013 at 9:51 AM, Franck Martin > wrote: It feels a lot like we can make some fast progress by taking the DKIM maili= ng list archives, replace ADSP with DMARC, and skip to the end. :-) Except there is a slight difference, ADSP was seldom adopted at receivers. = At best it became a score in spamassassin. DMARC is widely adopted. This I think change the perspective. Remember the difference between theory= and practice. In theory there should be no spam... I think all of us experienced in this space are aware of the difference. T= he best solutions appear to be those that look at the problem through both = lenses, wouldn't you say Sure, but I was not there and the landscape has changed, and DMARC is the e= xample of an operator group, coming to IETF to create a standard with resea= rchers. It has been argued that IETF has lost some of its running code powe= r since the operators do not attend much IETF anymore and prefer to meet at= various nog. Anyhow, saying we had this discussion before, read the archives, has always= been what I disliked about IETF group theory. --_000_77426B543150464AA3F30DF1A91365DE52EF6DAEESV4MBX01linked_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <753C2598E4248944AE80DA493AA396BF@linkedin.com> Content-Transfer-Encoding: quoted-printable
On Apr 11, 2013, at 10:19 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Thu, Apr 11, 2013 at 9:51 AM, Franck Martin <fmar= tin@linkedin.com> wrote:

It feels a lot like we can make some fast progress by taking the DKIM maili= ng list archives, replace ADSP with DMARC, and skip to the end.  :-)

Except there is a slight difference, ADSP was seldom adopted at receiv= ers. At best it became a score in spamassassin. DMARC is widely adopted.

This I think change the perspective. Remember the difference between t= heory and practice. In theory there should be no spam...

I think all of us experienced in this space are = aware of the difference.  The best solutions appear to be those that l= ook at the problem through both lenses, wouldn't you say

Sure, but I was not there and the landscape has changed, and DMARC is = the example of an operator group, coming to IETF to create a standard with = researchers. It has been argued that IETF has lost some of its running code= power since the operators do not attend much IETF anymore and prefer to meet at various nog.

Anyhow, saying we had this discussion before, read the archives, has a= lways been what I disliked about IETF group theory.

--_000_77426B543150464AA3F30DF1A91365DE52EF6DAEESV4MBX01linked_-- From sklist@kitterman.com Thu Apr 11 12:26:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7333121F8952 for ; Thu, 11 Apr 2013 12:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V92aqfAHITZ5 for ; Thu, 11 Apr 2013 12:26:36 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id A393B21F891D for ; Thu, 11 Apr 2013 12:26:36 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id EA453D04088; Thu, 11 Apr 2013 14:26:34 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365708394; bh=TQatMgq6iPXJIkgWvHCzRgwCwY5gVN21CZG1aVN/W8A=; h=In-Reply-To:References:Subject:From:Date:To:From; b=n32nisqQ09i+wcn5/X6kTLrjYkLT6rqAKY7XK48wT2u/2spaNPC1JC+dn8vWm7aks LFkXfywIrfjewP6aiCOIG+Vb3ZnQ4ZSZ3rgXGYLHENyz6U8RNcNBVvAfTidcQQEYWc lRyG44JQlalKZJ3SEmeUFxqxP5s+zp8l5JwVNXw4= Received: from [IPV6:2600:1003:b003:1ea7:cf58:5d1c:f993:381e] (unknown [IPv6:2600:1003:b003:1ea7:cf58:5d1c:f993:381e]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8EFAFD04059; Thu, 11 Apr 2013 14:26:34 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> <1493788.cSHXJOYAQG@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Thu, 11 Apr 2013 15:26:29 -0400 To: "dmarc@ietf.org" Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 19:26:37 -0000 "Murray S. Kucherawy" wrote: >On Thu, Apr 11, 2013 at 5:03 AM, Scott Kitterman >wrote: > >> >> Why can't we change it? This is a new draft. >> >> >The Requirements section, to me at least, documents the original set of >goals we set out to address with DMARC; it's a historical record of >what we >wanted to produce, rather than an inventory of what we did produce. It >seems fundamentally wrong to try to rewrite history. > >I won't die on this hill if consensus is otherwise. It just feels like >a >pretty strange thing to do. > >-MSK I don't see fixing a bug in the requirements as being fundamentally different than fixing a bug in the protocol. Since fixing the requirements be shouldn't affect implementation, is should be easy to fix. If the requirements are purely historical and not the requirements for the current effort, then I start to wonder why they are in the document at all. Scott K From prvs=806c9063e=fmartin@linkedin.com Thu Apr 11 12:57:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AF521F861B for ; Thu, 11 Apr 2013 12:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkjL78C2eZHZ for ; Thu, 11 Apr 2013 12:57:05 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id CFFDB21F84E9 for ; Thu, 11 Apr 2013 12:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365710225; x=1397246225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vhM0IN8PqSmIwvzcnmeuRsvA4jV7kvYTYww4U/6Mjnk=; b=aXBRuyjMXg7cKd6ZGKursv19C44C1WC6Y+mx/hKA9tamBXQ6nG4JNNl1 UTTYGAnO/eBIURqnZY6KET5ZzZbZy/JhvKjTTNliMRTUrE2W14GjH1iX1 Aqp/g2w4TxcWUAqQW8/TQDp4eD6GDMSCRssUjcIF1OkvI/iIfnFZAfV+h g=; X-IronPort-AV: E=Sophos;i="4.87,456,1363158000"; d="scan'208";a="44967522" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Thu, 11 Apr 2013 12:56:59 -0700 From: Franck Martin To: Scott Kitterman Thread-Topic: [dmarc-ietf] Minor contradiction in the draft specification Thread-Index: AQHONipL+Erge0gSGEyv/BV4DgFz2JjQ4C8AgAAXuoCAAGolAIAAF3OAgABkcYCAAAiJAA== Date: Thu, 11 Apr 2013 19:56:58 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EF81C1@ESV4-MBX01.linkedin.biz> References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> <1493788.cSHXJOYAQG@scott-latitude-e6320> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="us-ascii" Content-ID: <5D7276B9FC96A94DB98D4460CA5DF6C1@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 19:57:06 -0000 On Apr 11, 2013, at 12:26 PM, Scott Kitterman wrote: >=20 >=20 > "Murray S. Kucherawy" wrote: >=20 >> On Thu, Apr 11, 2013 at 5:03 AM, Scott Kitterman >> wrote: >>=20 >>>=20 >>> Why can't we change it? This is a new draft. >>>=20 >>>=20 >> The Requirements section, to me at least, documents the original set of >> goals we set out to address with DMARC; it's a historical record of >> what we >> wanted to produce, rather than an inventory of what we did produce. It >> seems fundamentally wrong to try to rewrite history. >>=20 >> I won't die on this hill if consensus is otherwise. It just feels like >> a >> pretty strange thing to do. >>=20 >> -MSK >=20 > I don't see fixing a bug in the requirements as being fundamentally diffe= rent than fixing a bug in the protocol. Since fixing the requirements be sh= ouldn't affect implementation, is should be easy to fix. >=20 > If the requirements are purely historical and not the requirements for th= e current effort, then I start to wonder why they are in the document at al= l. >=20 So we don't say go and read the archives :P From sklist@kitterman.com Thu Apr 11 12:59:41 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D839E21F86BA for ; Thu, 11 Apr 2013 12:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-9EtT-8BRBD for ; Thu, 11 Apr 2013 12:59:41 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2421F8682 for ; Thu, 11 Apr 2013 12:59:41 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 44F6720E40CF; Thu, 11 Apr 2013 15:59:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365710380; bh=ZFPIaa0xD8S4Dhi/KI1RVxDuHmXQSCw+bV7HMeigNaI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=acxvnNaCHsR9F58PeRNQYg8ruAPbIx930x9duU9JuT6Vkem6abLXPCE/bqxDNWPuk JvgM1SPqaklNPWuCoKB3MPgqbnb9DUHTRbNmA+SKI/7Feto9l8lSkPK9D/CnX4co52 +JUrhPTrBQHSZNXLWHOVKBsFn+xTQrBee1OFs5fg= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 2D6EE20E409E; Thu, 11 Apr 2013 15:59:40 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 11 Apr 2013 15:59:39 -0400 Message-ID: <6515954.SxZXNtBnX2@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EF81C1@ESV4-MBX01.linkedin.biz> References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> <77426B543150464AA3F30DF1A91365DE52EF81C1@ESV4-MBX01.linkedin.biz> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 19:59:42 -0000 On Thursday, April 11, 2013 07:56:58 PM Franck Martin wrote: > On Apr 11, 2013, at 12:26 PM, Scott Kitterman wrote: > > "Murray S. Kucherawy" wrote: > >> On Thu, Apr 11, 2013 at 5:03 AM, Scott Kitterman > >> > >> wrote: > >>> Why can't we change it? This is a new draft. > >> > >> The Requirements section, to me at least, documents the original set of > >> goals we set out to address with DMARC; it's a historical record of > >> what we > >> wanted to produce, rather than an inventory of what we did produce. It > >> seems fundamentally wrong to try to rewrite history. > >> > >> I won't die on this hill if consensus is otherwise. It just feels like > >> a > >> pretty strange thing to do. > >> > >> -MSK > > > > I don't see fixing a bug in the requirements as being fundamentally > > different than fixing a bug in the protocol. Since fixing the > > requirements be shouldn't affect implementation, is should be easy to > > fix. > > > > If the requirements are purely historical and not the requirements for the > > current effort, then I start to wonder why they are in the document at > > all. > So we don't say go and read the archives :P Then I think they should reflect the requirements the spec is currently trying to support. Historical requirements that aren't relevant to the current effort, um, aren't relevant. Let's just fix it. Scott K From jgomez@seryrich.com Thu Apr 11 13:15:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D3821F86DE for ; Thu, 11 Apr 2013 13:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWPqGeV6500N for ; Thu, 11 Apr 2013 13:15:18 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA3A21F86B9 for ; Thu, 11 Apr 2013 13:15:17 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Apr 2013 22:15:15 +0200 Message-ID: <9CC188BB13DE4AC79F740DD3E86EA0EF@fgsr.local> From: "J. Gomez" To: References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local><77426B543150464AA3F30DF1A91365DE52EF81C1@ESV4-MBX01.linkedin.biz> <6515954.SxZXNtBnX2@scott-latitude-e6320> Date: Thu, 11 Apr 2013 22:16:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 20:15:19 -0000 On Thursday, April 11, 2013 9:59 PM [GMT+1=3DCET], Scott Kitterman = wrote: > On Thursday, April 11, 2013 07:56:58 PM Franck Martin wrote: > > On Apr 11, 2013, at 12:26 PM, Scott Kitterman > > wrote:=20 > > > "Murray S. Kucherawy" wrote: > > > > On Thu, Apr 11, 2013 at 5:03 AM, Scott Kitterman > > > >=20 > > > > wrote: > > > > > Why can't we change it? This is a new draft. > > > >=20 > > > > The Requirements section, to me at least, documents the > > > > original set of goals we set out to address with DMARC; it's a > > > > historical record of what we > > > > wanted to produce, rather than an inventory of what we did > > > > produce. It seems fundamentally wrong to try to rewrite > > > > history.=20 > > > >=20 > > > > I won't die on this hill if consensus is otherwise. It just > > > > feels like a > > > > pretty strange thing to do. > > > >=20 > > > > -MSK > > >=20 > > > I don't see fixing a bug in the requirements as being > > > fundamentally different than fixing a bug in the protocol. Since > > > fixing the requirements be shouldn't affect implementation, is > > > should be easy to fix. > > >=20 > > > If the requirements are purely historical and not the > > > requirements for the current effort, then I start to wonder why > > > they are in the document at all. > > So we don't say go and read the archives :P >=20 > Then I think they should reflect the requirements the spec is > currently trying to support. Historical requirements that aren't > relevant to the current effort, um, aren't relevant. Let's just fix > it. I vote for fixing the requirement. This is to be a technical standard, = whose internal consistency should be paramount over any historical = traceability of its long past and generally vague guiding orders. In my opinion, if the historical requirements are to survive unaltered = in the RFC document, they should go at the end of it as an Appendix, and = not at the beginning of the document. Regards, J. Gomez From jgomez@seryrich.com Thu Apr 11 13:35:22 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EA221F8D0F for ; Thu, 11 Apr 2013 13:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iD-HdsmaNY-i for ; Thu, 11 Apr 2013 13:35:22 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id DC9F221F8AF0 for ; Thu, 11 Apr 2013 13:35:21 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 11 Apr 2013 22:35:20 +0200 Message-ID: <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it><77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz><5165A993.50208@gmail.com><5166758F.1040906@tana.it><77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> Date: Thu, 11 Apr 2013 22:36:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 20:35:22 -0000 Murray S. Kucherawy said: > On Thu, Apr 11, 2013 at 9:51 AM, Franck Martin > wrote:=20 >=20 >=20 > It feels a lot like we can make some fast progress by taking the DKIM > mailing list archives, replace ADSP with DMARC, and skip to the end.=20 > :-) =20 >=20 >=20 >=20 > Except there is a slight difference, ADSP was seldom adopted at > receivers. At best it became a score in spamassassin. DMARC is widely > adopted. =20 There is another difference: DMARC states as a high level requirement = for itself to "Minimize false positives", see Section 3.1 = https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D1 Mailing list messages are a know false positive for DMARC. What is DMARC = doing to minimize it, as per its own high level requirement? We can not dismiss this issue and pretend at the same time we are = "minimizing false positives", but rather "ignoring false positives". It may be the case that DMARC cannot avoid the false positives in = mailing list messages. But what is DMARC doing to "minimize them"? This problem is far from "already discussed, read the archives for = 'gizmo-foo'. Regards, J. Gomez From R.E.Sonneveld@sonnection.nl Thu Apr 11 14:56:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7E21F87D5 for ; Thu, 11 Apr 2013 14:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk9iG1h+HBFi for ; Thu, 11 Apr 2013 14:56:02 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1E75021F8758 for ; Thu, 11 Apr 2013 14:56:02 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 761A78C1310; Thu, 11 Apr 2013 23:55:32 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 502C78C130F; Thu, 11 Apr 2013 23:55:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 18CAB12315A; Thu, 11 Apr 2013 23:55:32 +0200 (CEST) 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 hUsWYaI-AhP3; Thu, 11 Apr 2013 23:55:29 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 30CBB122B95; Thu, 11 Apr 2013 23:55:29 +0200 (CEST) Message-ID: <51673150.50202@sonnection.nl> Date: Thu, 11 Apr 2013 23:55:28 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Levine References: <20130411040946.9056.qmail@joyce.lan> In-Reply-To: <20130411040946.9056.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kboth@drkurt.com, dmarc@ietf.org Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 21:56:02 -0000 On 04/11/2013 06:09 AM, John Levine wrote: >> In light of the perception (by some) that SPF is negatively oriented (fail >> can be relied upon to be meaningful, while all other results are less >> actionable), I think so. > The SPF spec is plenty clear on this point. SPF pass is well defined, > it means what the spec says is means. I don't think it is a good idea > for the DMARC spec to argue with people who inisist on misreading it. +1. Although pages like http://www.openspf.org/SPF_Record_Syntax may give the impression that SPF is a 'policy enforcement vehicle', from a standards point of view we have to deal with the bare RFC4408 and 4408bis specs and as such DMARC can simply refer to these specifications without having to explain things for a 2nd time. Having said that, I wonder whether people deploying DMARC with a p=reject for transactional mail will realize how important it is to get (and keep) their SPF and DKIM records present and available/reachable in DNS. This might be something for the BCP document of Dave? Furthermore, the fact that DNS problems may have the effect of getting mail rejected, introduces an attack vector, which may need to be described in the 'security' section. /rolf From prvs=806c9063e=fmartin@linkedin.com Thu Apr 11 15:25:29 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC7121F8610 for ; Thu, 11 Apr 2013 15:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aARLHEh5Fj-T for ; Thu, 11 Apr 2013 15:25:17 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED8021F86BA for ; Thu, 11 Apr 2013 15:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365719116; x=1397255116; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HxNyy20E/Q9muSw2c+ceP23jN88xxRSIblTcKX/+Nec=; b=ZlZsfUGC5PRCTpJVnpEmeAcKfoUj7WdJzcKefCy07aNVBxkeccEemTdp rZfS8J6pvt700essb5kSTnDZ5aLJlU+8/cFp+9ckZEfFhFjQwFdUAMmj/ ntDM4JPdjNBxpifFku6o0+0Si/+Opf+gzWj+I2FuDzrLrG0ngWq1zCAfh g=; X-IronPort-AV: E=Sophos;i="4.87,458,1363158000"; d="scan'208";a="43738617" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Thu, 11 Apr 2013 15:25:08 -0700 From: Franck Martin To: "" Thread-Topic: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm Thread-Index: AQHONv9o6GyCWOCHQk+iB/miUjxyqJjSDjWA Date: Thu, 11 Apr 2013 22:25:07 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> In-Reply-To: <51673150.50202@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <542AE08A889BC846B37504793CA6C4B4@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , John Levine Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 22:25:29 -0000 On Apr 11, 2013, at 2:55 PM, Rolf E. Sonneveld wrote: > On 04/11/2013 06:09 AM, John Levine wrote: >>> In light of the perception (by some) that SPF is negatively oriented (f= ail >>> can be relied upon to be meaningful, while all other results are less >>> actionable), I think so. >> The SPF spec is plenty clear on this point. SPF pass is well defined, >> it means what the spec says is means. I don't think it is a good idea >> for the DMARC spec to argue with people who inisist on misreading it. >=20 > +1. Although pages like http://www.openspf.org/SPF_Record_Syntax may give= the impression that SPF is a 'policy enforcement vehicle', from a standard= s point of view we have to deal with the bare RFC4408 and 4408bis specs and= as such DMARC can simply refer to these specifications without having to e= xplain things for a 2nd time. >=20 > Having said that, I wonder whether people deploying DMARC with a p=3Dreje= ct for transactional mail will realize how important it is to get (and keep= ) their SPF and DKIM records present and available/reachable in DNS. This m= ight be something for the BCP document of Dave? >=20 > Furthermore, the fact that DNS problems may have the effect of getting ma= il rejected, introduces an attack vector, which may need to be described in= the 'security' section. >=20 This tool is useful as for example: http://www.dmarcian.com/spf-survey/goda= ddy.com My experience is that a SPF DNS error, will tempfail the email, till DNS wo= rks but not with DKIM. Am I right to assume this is the common behavior? May be a word on possibilities here in the BCP could help.= From superuser@gmail.com Thu Apr 11 16:52:32 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244BB21F84F1 for ; Thu, 11 Apr 2013 16:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ge0vKei4XmrZ for ; Thu, 11 Apr 2013 16:52:31 -0700 (PDT) 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 1D3D821F84D9 for ; Thu, 11 Apr 2013 16:52:30 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hr17so1099606wib.5 for ; Thu, 11 Apr 2013 16:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=o8X324o21kSeJUsq9R9sNjCEcl5L2nT81IjiWrKtuBc=; b=KHQlYEoR6ZN0Guz4GIO45Zak1/Mj0pctfVTS56xHETYUwruOEUTLnD1qPaa048GoTG i5A4MSG0CQFIOV704/a6EZyo5TGm97gmRdAz81EXhAVDBN7vaaavWcdWFae3WZattLNB Dg8Ois1ZArCfzZcgc11Hd7xrXZxAPu70i8RZ0EzBySfi0WI5z+C8R3wNgSNTPT3Q86MR 9qivA2j3axmqyKEHV0USV5OsKJDgbOyYF6CHIcAYQ6Au/MyNN1uowjGUBtwP6IR0V1+n 6sMELlSvFfiyx/m90UICGI6+Xq92z2ptuKEueS5EZLt8mIcBOxhJoS+N9BRANQK5qqQK pdow== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr14034748wjb.17.1365724345899; Thu, 11 Apr 2013 16:52:25 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 11 Apr 2013 16:52:25 -0700 (PDT) In-Reply-To: <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> Date: Thu, 11 Apr 2013 16:52:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7b5d8cff7fa25904da1e7ade Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 23:52:32 -0000 --047d7b5d8cff7fa25904da1e7ade Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 11, 2013 at 1:36 PM, J. Gomez wrote: > There is another difference: DMARC states as a high level requirement for > itself to "Minimize false positives", see Section 3.1 > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 > > Mailing list messages are a know false positive for DMARC. What is DMARC > doing to minimize it, as per its own high level requirement? > > We can not dismiss this issue and pretend at the same time we are > "minimizing false positives", but rather "ignoring false positives". > > It may be the case that DMARC cannot avoid the false positives in mailing > list messages. But what is DMARC doing to "minimize them"? > The simplest answer is: If we can't fix this problem directly, then de facto they're already minimized; we can't make the problem smaller. The more complex answer is that DMARC enables operators to identify lists using its own heuristics and apply whatever special local policy handling they want to use, for whatever value of "special" is appropriate for them. Gmail has been held up as the prime example of this. Another part of the answer is that DMARC doesn't target mailing lists as part of its problem space. Just how much phishing takes place through mailing lists? This problem is far from "already discussed, read the archives for > 'gizmo-foo'. > > I have no doubt that the community would be happy to act on new information in this context, but so far there has been none. That's when "read the archives" becomes the right answer. For the rest of us that have expended huge energy going down this path before, it's better for us to save our remaining energy for the work ahead. It may well be the case that you weren't around for the discussions, but that doesn't mean it hasn't been beaten until it's just a moist place in the dirt. Those of us who ignore history are doomed to repeat it. -MSK --047d7b5d8cff7fa25904da1e7ade Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2013 at 1:36 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
There is another differen= ce: DMARC states as a high level requirement for itself to "Minimize f= alse positives", see Section 3.1 http= s://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=3D1

Mailing list messages are a know false positive for DMARC. What is DMARC do= ing to minimize it, as per its own high level requirement?=A0

We can not dismiss this issue and pretend at the same time we are "min= imizing false positives", but rather "ignoring false positives&qu= ot;.=A0

It may be the case that DMARC cannot avoid the false positives in mailing l= ist messages. But what is DMARC doing to "minimize them"?

The simplest answer is: If we can't fix this pr= oblem directly, then de facto they're already minimized; we can't m= ake the problem smaller.

The more complex answer is that DMARC enables operators to identify lis= ts using its own heuristics and apply whatever special local policy handlin= g they want to use, for whatever value of "special" is appropriat= e for them.=A0 Gmail has been held up as the prime example of this.

Another part of the answer is that DMA= RC doesn't target mailing lists as part of its problem space.=A0 Just h= ow much phishing takes place through mailing lists?

This problem is far from "already discussed, read the archives for = 9;gizmo-foo'.


I have no doubt that = the community would be happy to act on new information in this context, but= so far there has been none.=A0 That's when "read the archives&quo= t; becomes the right answer.=A0 For the rest of us that have expended huge = energy going down this path before, it's better for us to save our rema= ining energy for the work ahead.

It may well be the case tha= t you weren't around for the=20 discussions, but that doesn't mean it hasn't been beaten until it&#= 39;s just a moist place in the dirt.

Those o= f us who ignore history are doomed to repeat it.

--047d7b5d8cff7fa25904da1e7ade-- From superuser@gmail.com Thu Apr 11 16:54:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CACBA21F8501 for ; Thu, 11 Apr 2013 16:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiYobjgBJURr for ; Thu, 11 Apr 2013 16:54:08 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6E26B21F87B6 for ; Thu, 11 Apr 2013 16:54:08 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u12so1642679wey.19 for ; Thu, 11 Apr 2013 16:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=21BTTZegL9sQ6en1AlW1Rv9RJpWvT0XkWnq8Y2zbxa0=; b=Q+4yAakZvGTjXyJKgje7e+udVo7B8EULsoiV1tgiH+7iqmV+9IDMjc6FMaqiILLcQ2 5LsGPpjf/0wec/klOdf+VRgCaQBymz2sCzEvX8/zQ41iJHRfAJ2D/GChO9LskmMYkoA2 7Pi84Zm97T/etZT5S5RSpXuKjV+5WJhKziZdJRtEk/0fheIkvBQBmm680BBnJ47juQrE 9SAJ5emgHjakVC0St2KVgfzAKvLt/1i7nReJf1rLllgx5xOEQ5LufBLBzMMHyvwWSjXW JrgTaH0FBxvhL3d05ZNqzaHqaCe52Fl/kPd9lA2s9JNP1Jdq6Eh8qpfa/Fbpgmoibl1J QLtg== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr602083wiz.14.1365724447556; Thu, 11 Apr 2013 16:54:07 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 11 Apr 2013 16:54:07 -0700 (PDT) In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> Date: Thu, 11 Apr 2013 16:54:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d044271948ecb5704da1e80bf Cc: "" , "" , John Levine , "" Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 11 Apr 2013 23:54:09 -0000 --f46d044271948ecb5704da1e80bf Content-Type: text/plain; charset=ISO-8859-1 It depends on the kind of error and on the implementation. Generally, a temporary DNS error should result in a temp-fail of the message, while a permanent DNS error should not. "Record not found" is not a temporary error. I'd say both of those points are true for both protocols. On Thu, Apr 11, 2013 at 3:25 PM, Franck Martin wrote: > > On Apr 11, 2013, at 2:55 PM, Rolf E. Sonneveld < > R.E.Sonneveld@sonnection.nl> wrote: > > > On 04/11/2013 06:09 AM, John Levine wrote: > >>> In light of the perception (by some) that SPF is negatively oriented > (fail > >>> can be relied upon to be meaningful, while all other results are less > >>> actionable), I think so. > >> The SPF spec is plenty clear on this point. SPF pass is well defined, > >> it means what the spec says is means. I don't think it is a good idea > >> for the DMARC spec to argue with people who inisist on misreading it. > > > > +1. Although pages like http://www.openspf.org/SPF_Record_Syntax may > give the impression that SPF is a 'policy enforcement vehicle', from a > standards point of view we have to deal with the bare RFC4408 and 4408bis > specs and as such DMARC can simply refer to these specifications without > having to explain things for a 2nd time. > > > > Having said that, I wonder whether people deploying DMARC with a > p=reject for transactional mail will realize how important it is to get > (and keep) their SPF and DKIM records present and available/reachable in > DNS. This might be something for the BCP document of Dave? > > > > Furthermore, the fact that DNS problems may have the effect of getting > mail rejected, introduces an attack vector, which may need to be described > in the 'security' section. > > > > This tool is useful as for example: > http://www.dmarcian.com/spf-survey/godaddy.com > > My experience is that a SPF DNS error, will tempfail the email, till DNS > works but not with DKIM. Am I right to assume this is the common behavior? > > May be a word on possibilities here in the BCP could help. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f46d044271948ecb5704da1e80bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It depends on the kind of error and on the imple= mentation.=A0 Generally, a temporary DNS error should result in a temp-fail= of the message, while a permanent DNS error should not.

"= ;Record not found" is not a temporary error.

I'd say both of those points are true for both protocols.
=


On Thu,= Apr 11, 2013 at 3:25 PM, Franck Martin <fmartin@linkedin.com> wrote:

On Apr 11, 2013, at 2:55 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:

> On 04/11/2013 06:09 AM, John Levine wrote:
>>> In light of the perception (by some) that SPF is negatively or= iented (fail
>>> can be relied upon to be meaningful, while all other results a= re less
>>> actionable), I think so.
>> The SPF spec is plenty clear on this point. =A0SPF pass is well de= fined,
>> it means what the spec says is means. =A0I don't think it is a= good idea
>> for the DMARC spec to argue with people who inisist on misreading = it.
>
> +1. Although pages like http://www.openspf.org/SPF_Record_Syntax may g= ive the impression that SPF is a 'policy enforcement vehicle', from= a standards point of view we have to deal with the bare RFC4408 and 4408bi= s specs and as such DMARC can simply refer to these specifications without = having to explain things for a 2nd time.
>
> Having said that, I wonder whether people deploying DMARC with a p=3Dr= eject for transactional mail will realize how important it is to get (and k= eep) their SPF and DKIM records present and available/reachable in DNS. Thi= s might be something for the BCP document of Dave?
>
> Furthermore, the fact that DNS problems may have the effect of getting= mail rejected, introduces an attack vector, which may need to be described= in the 'security' section.
>

This tool is useful as for example: http://www.dmarcian.com/s= pf-survey/godaddy.com

My experience is that a SPF DNS error, will tempfail the email, till DNS wo= rks but not with DKIM. Am I right to assume this is the common behavior?
May be a word on possibilities here in the BCP could help.
___________________________________= ____________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--f46d044271948ecb5704da1e80bf-- From MHammer@ag.com Thu Apr 11 17:21:38 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B294421F87C3 for ; Thu, 11 Apr 2013 17:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Sgqj+5gqIFS for ; Thu, 11 Apr 2013 17:21:38 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 11F0121F87B6 for ; Thu, 11 Apr 2013 17:21:37 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Thu, 11 Apr 2013 20:21:37 -0400 From: "MH Michael Hammer (5304)" To: Franck Martin , Scott Kitterman Thread-Topic: [dmarc-ietf] Minor contradiction in the draft specification Thread-Index: AQHONio/95/ElB8w00CUgQeSlzz0CpjQreQAgAAXuoCAAGomAIAAF3KAgABkcYCAAAiFAP//8J6A Date: Fri, 12 Apr 2013 00:21:36 +0000 Message-ID: References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> <1493788.cSHXJOYAQG@scott-latitude-e6320> <77426B543150464AA3F30DF1A91365DE52EF81C1@ESV4-MBX01.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE52EF81C1@ESV4-MBX01.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.201] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 00:21:38 -0000 This sounds like a perfect candidate for a footnote (or the equivalent in I= ETF land). Make the change with a footnote indicating the contradiction in = the original requirements. Mike > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Franck Martin > Sent: Thursday, April 11, 2013 3:57 PM > To: Scott Kitterman > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification >=20 >=20 > On Apr 11, 2013, at 12:26 PM, Scott Kitterman > wrote: >=20 > > > > > > "Murray S. Kucherawy" wrote: > > > >> On Thu, Apr 11, 2013 at 5:03 AM, Scott Kitterman > >> wrote: > >> > >>> > >>> Why can't we change it? This is a new draft. > >>> > >>> > >> The Requirements section, to me at least, documents the original set > >> of goals we set out to address with DMARC; it's a historical record > >> of what we wanted to produce, rather than an inventory of what we did > >> produce. It seems fundamentally wrong to try to rewrite history. > >> > >> I won't die on this hill if consensus is otherwise. It just feels > >> like a pretty strange thing to do. > >> > >> -MSK > > > > I don't see fixing a bug in the requirements as being fundamentally > different than fixing a bug in the protocol. Since fixing the requirement= s be > shouldn't affect implementation, is should be easy to fix. > > > > If the requirements are purely historical and not the requirements for = the > current effort, then I start to wonder why they are in the document at al= l. > > >=20 > So we don't say go and read the archives :P >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From prvs=78145f36b6=madkins@fb.com Thu Apr 11 17:46:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF4D21F899E for ; Thu, 11 Apr 2013 17:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3wDF+y2I-tK for ; Thu, 11 Apr 2013 17:46:38 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8024A21F891D for ; Thu, 11 Apr 2013 17:46:38 -0700 (PDT) Received: from pps.filterd (m0044008 [127.0.0.1]) by m0044008.ppops.net (8.14.5/8.14.5) with SMTP id r3C0gZhe022883; Thu, 11 Apr 2013 17:46:37 -0700 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=1TDKbXeqoqxRwBWeqbCjYkV5svaBA2WJ612xe13EHz4=; b=PGU+i8Kp5LvXdnyQVDs9db82lbcITbyXRxrjoe70xk+VoSZimPus+4oVi4zRvu3meCWd 5KyPEa9pRF3usbWsESFgqP3vNcFwCKhbkTlD6ihZHaGu5+PAiHirm9/v6mdKjY+34gcE lvYkJ61dR83BlJWrN+638ZG+TGoflxVs608= Received: from prn1-cmdf-dc01-fw1-nat.corp.tfbnw.net (prn1-cmdf-dc01-fw1-nat.corp.tfbnw.net [173.252.71.129] (may be forged)) by mx0a-00082601.pphosted.com with ESMTP id 1bntd825n8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Apr 2013 17:46:37 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.5.232]) by PRN-CHUB04.TheFacebook.com ([fe80::7ded:c10e:ef04:80d8%12]) with mapi id 14.02.0328.011; Thu, 11 Apr 2013 17:46:36 -0700 From: Michael Adkins To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHONxcuEa1NBqW6G0GvjzlKr/dNtQ== Date: Fri, 12 Apr 2013 00:46:35 +0000 Message-ID: In-Reply-To: <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.168.16.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <1BE5F733AEB38B4C8DAF67D77BA7CC16@fb.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-11_09:2013-04-11, 2013-04-11, 1970-01-01 signatures=0 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 00:46:39 -0000 DMARC minimizes false positives by providing reporting to inform domain owners of potential false positives prior to them adopting an overly or unnecessarily strict policy for their domain. DMARC also provides sufficient data to judge whether stopping the amount of actual abuse that exists, and that it can stop, is worth the damage caused by potential false positives. There is no assumption that every domain on the internet needs a reject policy, nor would there be a reason for every domain on the internet to adopt one, as not every domain on the internet has the kind of phishing problem that DMARC attempts to solve. Just as every personal residence doesn't need the same level of physical security as a bank, every person doesn't need an armed escort everywhere they go, every vehicle doesn't need to be bulletproof, etc. because they aren't under constant threat of being robbed/abducted/shot. Unless someone has some aggregate reports they want to share for domains that actually have both a large phishing problem and a large mailing list false positive problem, its not worth spending time trying to fix. We've been looking and asking for a couple of years now, and still haven't found sufficient evidence of a practical problem. On 4/11/13 1:36 PM, "J. Gomez" wrote: >Murray S. Kucherawy said: > >> On Thu, Apr 11, 2013 at 9:51 AM, Franck Martin >> wrote:=20 >>=20 >>=20 >> It feels a lot like we can make some fast progress by taking the DKIM >> mailing list archives, replace ADSP with DMARC, and skip to the end. >> :-) =20 >>=20 >>=20 >>=20 >> Except there is a slight difference, ADSP was seldom adopted at >> receivers. At best it became a score in spamassassin. DMARC is widely >> adopted. =20 > >There is another difference: DMARC states as a high level requirement for >itself to "Minimize false positives", see Section 3.1 >https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D >1 > >Mailing list messages are a know false positive for DMARC. What is DMARC >doing to minimize it, as per its own high level requirement? > >We can not dismiss this issue and pretend at the same time we are >"minimizing false positives", but rather "ignoring false positives". > >It may be the case that DMARC cannot avoid the false positives in mailing >list messages. But what is DMARC doing to "minimize them"? > >This problem is far from "already discussed, read the archives for >'gizmo-foo'. > >Regards, > >J. Gomez > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From MHammer@ag.com Thu Apr 11 17:50:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246E321F86FA for ; Thu, 11 Apr 2013 17:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJlpGjerAe-d for ; Thu, 11 Apr 2013 17:50:18 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA7321F8765 for ; Thu, 11 Apr 2013 17:50:15 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Thu, 11 Apr 2013 20:50:14 -0400 From: "MH Michael Hammer (5304)" To: Michael Adkins , "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHONxc1Cj/BPsnFSkCZMZkJRixQCpjRwP3A Date: Fri, 12 Apr 2013 00:50:13 +0000 Message-ID: References: <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.201] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 00:50:19 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Michael Adkins > Sent: Thursday, April 11, 2013 8:47 PM > To: J. Gomez; dmarc@ietf.org > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not abo= ut > outsourcing strategies >=20 > DMARC minimizes false positives by providing reporting to inform domain > owners of potential false positives prior to them adopting an overly or > unnecessarily strict policy for their domain. >=20 > DMARC also provides sufficient data to judge whether stopping the amount > of actual abuse that exists, and that it can stop, is worth the damage ca= used > by potential false positives. >=20 > There is no assumption that every domain on the internet needs a reject > policy, nor would there be a reason for every domain on the internet to > adopt one, as not every domain on the internet has the kind of phishing > problem that DMARC attempts to solve. Just as every personal residence > doesn't need the same level of physical security as a bank, every person > doesn't need an armed escort everywhere they go, every vehicle doesn't > need to be bulletproof, etc. because they aren't under constant threat of > being robbed/abducted/shot. >=20 > Unless someone has some aggregate reports they want to share for domains > that actually have both a large phishing problem and a large mailing list= false > positive problem, its not worth spending time trying to fix. We've been > looking and asking for a couple of years now, and still haven't found suf= ficient > evidence of a practical problem. >=20 A big +1 From johnl@taugh.com Thu Apr 11 20:18:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB5A21F86C4 for ; Thu, 11 Apr 2013 20:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRe+0oZIbrzx for ; Thu, 11 Apr 2013 20:18:15 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDBF21F86C3 for ; Thu, 11 Apr 2013 20:18:15 -0700 (PDT) Received: (qmail 85840 invoked from network); 12 Apr 2013 03:18:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=14f4f.51677cf7.k1304; bh=KcaOI40/CeRNbOuwm5RAk+O0SpitPvPlmrdcYqQxChA=; b=npwCCcWFNJvoSikjzYT9YIbhLhUUit1ZHG8BX95xIo6DPYIklj8xO4+3x28Zvn4CodBkc9r7qnN9f5/UUXu3Rlfkhtj1Tjd5G7wMgqsV9SL2gCWs2ECC8PEPbGLltvxUX7/GvjSxlO8E8qsEu2VoFdMTuHDRJvSOx92+q7IFgh8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=14f4f.51677cf7.k1304; bh=KcaOI40/CeRNbOuwm5RAk+O0SpitPvPlmrdcYqQxChA=; b=tkd2Up+rvh/38NBASOsUJzs06PIw0+HJhSP46Ren4sjapNDfOLVyceK17vvlzP3E7LTEZGiPiUXe7v+AVJPHj03vpvOIio/K+7OedRHXglbRl1qRogjGgtEJYHYJQjFDELZJD1/S0ezUlFugKarz1ljepzslCEjfhFQUnVleDJo= Received: (ofmipd 127.0.0.1); 12 Apr 2013 03:17:53 -0000 Date: 11 Apr 2013 23:18:13 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1304275000-1365736694=:14913" Cc: "" Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 03:18:16 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-1304275000-1365736694=:14913 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >> My experience is that a SPF DNS error, will tempfail the email, till DNS >> works but not with DKIM. Am I right to assume this is the common behavior? Since nobody uses ADSP, until DMARC came along there wasn't any reason to reject on DKIM failure. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-1304275000-1365736694=:14913 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDEyMDMxODE0WjAjBgkqhkiG 9w0BCQQxFgQUxklPt2JXKilX36Re1LNe7H/fLwAweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAlHiF2ypO3OMf eac9QO/QVAbIiCRDULdhdHvmAIESTEQSTWeW1NO3cEgR/EjgtViDlSyOm3Pu 67q2lqsT/4IB9Z3cxw0qW8TPZHk/WA5SECNNWp50FSx/QEHhxKuMeZwBtcgi c3H6A7vX8+lROWKqG3XeUj4sUkQGxqyuHLbd8Z9A8Vw2ZhsTM+9BHiQQDka+ 3t7GvdpyZPeYajguCDasnkEpq8dTRRuTrkm3KkDi6FMre3e2Cz0IVp8t3iZ9 zMWwZ0Ln4gWYpt1qFsd2setj7b1JVmKsq8SRhvbLY4LfpbO7gpawZimLxXgf TlgjMB66OYf/fYPwr2FNwpcDwuKBCQ== --3825401791-1304275000-1365736694=:14913-- From dcrocker@gmail.com Fri Apr 12 06:40:22 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E7221F8B13 for ; Fri, 12 Apr 2013 06:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=1.377, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9LakIYcE-6C for ; Fri, 12 Apr 2013 06:40:21 -0700 (PDT) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4872321F8A8A for ; Fri, 12 Apr 2013 06:40:21 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id bs12so873709qab.11 for ; Fri, 12 Apr 2013 06:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2emKvPgbnncFfJYrEpcZBqKgXUjEoAUt+26XC0YYxL4=; b=WVETOg8mO26MSlT+Tkbl+uIsHTjBtTz+7NE2EidtV8WQmV0GcqML/SBpQeMKJs//cd xEF/3e2QbmlrjaE6dsWezAJPgDbgL/vVo1XFxyAW4BNEWGShCwfeWE8xH99dsbvEuI5I GP3JcFAjqHndG1zPF6+ipXmXN3+85M0eRdIKl+OKDrrnVfx44MP2jA5ZOpvc+2qfOdHs 0MRllE416n3wQo4a4IbJYkxDUjlExgmXdmVNAfOF5yMFviG+TlFiz4dY/rlVYNVCk0zc uiOPB5er8voRXenOVoPMGjEX4T6H4d+7dmbujI4/5e21CSlga0OcOifyMOLLoqqF4uSr sADg== X-Received: by 10.224.59.9 with SMTP id j9mr11920430qah.14.1365774020861; Fri, 12 Apr 2013 06:40:20 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id k8sm13240776qej.2.2013.04.12.06.40.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Apr 2013 06:40:19 -0700 (PDT) Message-ID: <51680EBA.2040705@gmail.com> Date: Fri, 12 Apr 2013 06:40:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John R Levine References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 13:40:22 -0000 On 4/11/2013 8:18 PM, John R Levine wrote: >>> My experience is that a SPF DNS error, will tempfail the email, till DNS >>> works but not with DKIM. Am I right to assume this is the common >>> behavior? > > Since nobody uses ADSP, until DMARC came along there wasn't any reason > to reject on DKIM failure. I think it worth making a significantly stronger statement: Until receivers had a basis for getting distinctive claims from senders, it was essential that receivers /not/ reject based on a DKIM failure. Absent that information, the receiver could not distinguish between transit failures that killed the signature, from other errors. Of course, they still can't, but the claim from the sender is presumed to be based on the sender's knowledge that transit breakage is extremely unlikely. d/ -- Dave Crocker bbiw.net From vesely@tana.it Fri Apr 12 07:41:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8249D21F8A3F for ; Fri, 12 Apr 2013 07:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.019 X-Spam-Level: X-Spam-Status: No, score=-4.019 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUWQD+vYcaUk for ; Fri, 12 Apr 2013 07:41:13 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 22E6021F8B65 for ; Fri, 12 Apr 2013 07:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365777671; bh=FjOj5qUDlyszox54sI3ksTByDq13TGBvsd7ro0Jccik=; l=2808; h=Date:From:To:References:In-Reply-To; b=odY/forbsy6UPB348oGYDx1mACHc7qb4ftDGPYNYN/pXvHx9PS8dL3bOj6vsWP25f Q56nku55qSonLVGbeHiIqqeE1iBHzuZtlzv4whliRicutc2rTnkeu0YSpy5vynPPr4 dmFBK1uTQQMXrzxkueYEdRo4WiSYUpSBx8hsbolQ= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 12 Apr 2013 16:41:11 +0200 id 00000000005DC035.0000000051681D07.00001D95 Message-ID: <51681D07.1030006@tana.it> Date: Fri, 12 Apr 2013 16:41:11 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 14:41:14 -0000 On Fri 12/Apr/2013 01:52:25 +0200 Murray S. Kucherawy wrote: > On Thu, Apr 11, 2013 at 1:36 PM, J. Gomez wrote: > >> Mailing list messages are a known false positive for DMARC. What is DMARC >> doing to minimize it, as per its own high level requirement? > >> We can not dismiss this issue and pretend at the same time we are >> "minimizing false positives", but rather "ignoring false positives". > >> It may be the case that DMARC cannot avoid the false positives in mailing >> list messages. But what is DMARC doing to "minimize them"? > > The simplest answer is: If we can't fix this problem directly, then de > facto they're already minimized; we can't make the problem smaller. > > The more complex answer is that DMARC enables operators to identify lists > using its own heuristics and apply whatever special local policy handling > they want to use, for whatever value of "special" is appropriate for them. > Gmail has been held up as the prime example of this. My reading of the spec is not deep, but glancing at Section 11.2 I find no step where mailing list heuristics come to play. > Another part of the answer is that DMARC doesn't target mailing lists as > part of its problem space. Just how much phishing takes place through > mailing lists? Right. But feedback might be valuable for MLM admins too. >> This problem is far from "already discussed, read the archives for >> 'gizmo-foo'. > > I have no doubt that the community would be happy to act on new information > in this context, but so far there has been none. That's when "read the > archives" becomes the right answer. For the rest of us that have expended > huge energy going down this path before, it's better for us to save our > remaining energy for the work ahead. Feedback and cohesive integration with SPF are new tasks, not new info. > It may well be the case that you weren't around for the discussions, but > that doesn't mean it hasn't been beaten until it's just a moist place in > the dirt. > > Those of us who ignore history are doomed to repeat it. What I think we don't want to repeat is the transactional-mail-only applicability restriction: Don't think of it as domains wishing to make strong assertions breaking mailing lists. Think of it as domains making strong assertions voluntarily excluding themselves. They value security more than the pleasure of your company on a list that does not respect their assertion with regard to their domain. They wish to be master of their domain. If they wish to have the pleasure of your company they will either have to change their assertion/ practice or participate using another account at a more flexible domain. http://mipassoc.org/pipermail/ietf-dkim/2008q1/009196.html From prvs=8077a908a=fmartin@linkedin.com Fri Apr 12 08:22:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60A721F8CEB for ; Fri, 12 Apr 2013 08:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY21ni1F6OL9 for ; Fri, 12 Apr 2013 08:22:27 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 70F3B21F87D0 for ; Fri, 12 Apr 2013 08:22:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1365780147; x=1397316147; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CmsLJFuqzmpeTDsZNuxdG+TtlzOcU5aHxA0oYz1jNrE=; b=GHHHHvLzRLNy71+k4qYrEfDF7L1GVXBMQcwC3SwW+gz5/bG+I2cIL9qm lJFVpAFFw2tweWSiKeAko4TlUbZwusQBm7Hl/aCr+mIM1ffhSYq+yFQeB Y0JBbi1Rb/30dd3GsiAsIu0rej7BTv2t4OQhvFUKsr7mwQVl1FWT+zIzD Q=; X-IronPort-AV: E=Sophos;i="4.87,462,1363158000"; d="scan'208";a="43819761" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas02.linkedin.biz (172.18.46.142) with Microsoft SMTP Server (TLS) id 14.2.328.11; Fri, 12 Apr 2013 08:22:14 -0700 Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Fri, 12 Apr 2013 08:22:14 -0700 From: Franck Martin To: Dave Crocker Thread-Topic: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm Thread-Index: AQHONv9o6GyCWOCHQk+iB/miUjxyqJjSDjWAgAAY2YCAADkHgIAArcUAgAAciIA= Date: Fri, 12 Apr 2013 15:22:14 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52F037BC@ESV4-MBX01.linkedin.biz> References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> <51680EBA.2040705@gmail.com> In-Reply-To: <51680EBA.2040705@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.253] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Murray S. Kucherawy" , "" , John R Levine Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 15:22:35 -0000 On Apr 12, 2013, at 6:40 AM, Dave Crocker wrote: >=20 >=20 > On 4/11/2013 8:18 PM, John R Levine wrote: >>>> My experience is that a SPF DNS error, will tempfail the email, till D= NS >>>> works but not with DKIM. Am I right to assume this is the common >>>> behavior? >>=20 >> Since nobody uses ADSP, until DMARC came along there wasn't any reason >> to reject on DKIM failure. >=20 >=20 > I think it worth making a significantly stronger statement: >=20 > Until receivers had a basis for getting distinctive claims from sende= rs, it was essential that receivers /not/ reject based on a DKIM failure. >=20 > Absent that information, the receiver could not distinguish between trans= it failures that killed the signature, from other errors. >=20 > Of course, they still can't, but the claim from the sender is presumed to= be based on the sender's knowledge that transit breakage is extremely unli= kely. >=20 I mean in DKIM there is one DNS operation, which is to fetch the key. If th= e DNS does not answer (not that the DNS answers there is no key), I think s= ystems would not tempfail the email and just carry on? What happens if ther= e is more than one DKIM signature, and one has DNS failing? From dcrocker@gmail.com Fri Apr 12 09:18:04 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1E221F8E06 for ; Fri, 12 Apr 2013 09:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.681 X-Spam-Level: X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[AWL=0.918, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrXjw3LmF35m for ; Fri, 12 Apr 2013 09:18:04 -0700 (PDT) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8A21F8E04 for ; Fri, 12 Apr 2013 09:18:04 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id i11so1620437qej.17 for ; Fri, 12 Apr 2013 09:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dm/v27S3mfUAG6HCfAl3hHP9urhjl1dEEFXMWaTkni0=; b=HBFb6zC8uen/DvhFSHtyNg+7pFfIxigRFVLVHaCjhHfbsrdqdWyKCae5wL+xKu4GsC cGg53ZBcFxV+HPEeQ78hW8Mlkr1y44nhBiNiclIjNP0yiKBfmxsj7zGbpFHnsz+BQfH7 9lIVuxIlRiCIprcXpX5hwbVBYChXstcIvlt2idX8DdHFcWlg4tTtjlvkQDhnFukPM7wy 32tZkJJw/T4NcKz1Y5oU06g43X8GLIUH7jYaKl4fXfIEcbj+Vlf13wcOw8Au/b+rOjHH R9JN4GIveLSJYwFcmqc8GyJwbpfVzJr7bjXl1E9LCCp4tPLevCSK2rL9f0WLH6k9qRpB cC1A== X-Received: by 10.229.140.96 with SMTP id h32mr4596292qcu.89.1365783483648; Fri, 12 Apr 2013 09:18:03 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id ei3sm14757245qab.10.2013.04.12.09.18.01 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Apr 2013 09:18:02 -0700 (PDT) Message-ID: <516833B2.2030109@gmail.com> Date: Fri, 12 Apr 2013 09:17:54 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Franck Martin References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> <51680EBA.2040705@gmail.com> <77426B543150464AA3F30DF1A91365DE52F037BC@ESV4-MBX01.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE52F037BC@ESV4-MBX01.linkedin.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Murray S. Kucherawy" , "" , John R Levine Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 16:18:04 -0000 On 4/12/2013 8:22 AM, Franck Martin wrote: > I mean in DKIM there is one DNS operation, which is to fetch the key. > If the DNS does not answer (not that the DNS answers there is no > key), I think systems would not tempfail the email and just carry on? If they believd that DNS queries were perfectly reliable, perhaps. But they aren't, so they shouldn't. d/ -- Dave Crocker bbiw.net From superuser@gmail.com Fri Apr 12 09:28:41 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0406221F8EDE for ; Fri, 12 Apr 2013 09:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-nCLfu97iN9 for ; Fri, 12 Apr 2013 09:28:40 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id B2EE521F8ED5 for ; Fri, 12 Apr 2013 09:28:39 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id e11so691213wgh.1 for ; Fri, 12 Apr 2013 09:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QbhSe0uDLv44PRFcWubyFUdF3bwNx9meLOoLYPmG5f8=; b=sYX0zPd+cCRXXZiZy1u+wIeRWM2QlVa862O+sWhPsmlp+gxS38RsnKcGPX1fKUt6KF DTRGoaZKWScJjV5VRJzhk30khRRpEH3Jetqat1NFy4qLuSPWIgBjuiFnSmiMSvEf/ooj gLHW9IHE6Eaw4TricoqpJ69YtsET1A4BtsgLu+T/kQdz2WP8PB38iNRJ9ZMKJmXSbyU4 6cj8uYp5azTb9BCgE2f7PVDZb1uHI5OlYzlja0a7nXDWSCp8ADEwWslxfg5Hh09NfCmN Wjepjhp/Oz9ywqBdTkVJ0mrgU8YEyaw3EV+CQjgCmjXcBxcqedNEZszI56n8Kg4W1AlH flmg== MIME-Version: 1.0 X-Received: by 10.180.90.116 with SMTP id bv20mr5161875wib.32.1365784111316; Fri, 12 Apr 2013 09:28:31 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 12 Apr 2013 09:28:31 -0700 (PDT) In-Reply-To: <51681D07.1030006@tana.it> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> <51681D07.1030006@tana.it> Date: Fri, 12 Apr 2013 09:28:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d043c7f4ecb870e04da2c647b Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 16:28:41 -0000 --f46d043c7f4ecb870e04da2c647b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 12, 2013 at 7:41 AM, Alessandro Vesely wrote: > > The simplest answer is: If we can't fix this problem directly, then de > > facto they're already minimized; we can't make the problem smaller. > > > > The more complex answer is that DMARC enables operators to identify lists > > using its own heuristics and apply whatever special local policy handling > > they want to use, for whatever value of "special" is appropriate for > them. > > Gmail has been held up as the prime example of this. > > My reading of the spec is not deep, but glancing at Section 11.2 I > find no step where mailing list heuristics come to play. > Correct. They belong to the operators, not to the specification. > >> This problem is far from "already discussed, read the archives for > >> 'gizmo-foo'. > > > > I have no doubt that the community would be happy to act on new > information > > in this context, but so far there has been none. That's when "read the > > archives" becomes the right answer. For the rest of us that have > expended > > huge energy going down this path before, it's better for us to save our > > remaining energy for the work ahead. > > Feedback and cohesive integration with SPF are new tasks, not new info. > I'm afraid I don't know what that means. > > > It may well be the case that you weren't around for the discussions, but > > that doesn't mean it hasn't been beaten until it's just a moist place in > > the dirt. > > > > Those of us who ignore history are doomed to repeat it. > > What I think we don't want to repeat is the transactional-mail-only > applicability restriction: > > Don't think of it as domains wishing to make strong assertions > breaking mailing lists. Think of it as domains making strong > assertions voluntarily excluding themselves. They value security > more than the pleasure of your company on a list that does not > respect their assertion with regard to their domain. They wish to > be master of their domain. If they wish to have the pleasure of > your company they will either have to change their assertion/ > practice or participate using another account at a more flexible > domain. > http://mipassoc.org/pipermail/ietf-dkim/2008q1/009196.html What's changed since 2008 to change either the problem space or the solution space? -MSK --f46d043c7f4ecb870e04da2c647b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 12, 2013 at 7:41 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> The simplest answer is: If we can't= fix this problem directly, then de
> facto they're already minimized; we can't make the problem sma= ller.
>
> The more complex answer is that DMARC enables operators to identify li= sts
> using its own heuristics and apply whatever special local policy handl= ing
> they want to use, for whatever value of "special" is appropr= iate for them.
> Gmail has been held up as the prime example of this.

My reading of the spec is not deep, but glancing at Section 11.2 I find no step where mailing list heuristics come to play.

Correct.=A0 They belong to the operators, not to the spec= ification.
=A0
>> This problem is far from "already discussed, read the archive= s for
>> 'gizmo-foo'.
>
> I have no doubt that the community would be happy to act on new inform= ation
> in this context, but so far there has been none. =A0That's when &q= uot;read the
> archives" becomes the right answer. =A0For the rest of us that ha= ve expended
> huge energy going down this path before, it's better for us to sav= e our
> remaining energy for the work ahead.

Feedback and cohesive integration with SPF are new tasks, not new inf= o.

I'm afraid I don't know what= that means.
=A0

> It may well be the case that you weren't around for the discussion= s, but
> that doesn't mean it hasn't been beaten until it's just a = moist place in
> the dirt.
>
> Those of us who ignore history are doomed to repeat it.

What I think we don't want to repeat is the transactional-mail-on= ly
applicability restriction:

=A0 =A0Don't think of it as domains wishing to make strong assertions =A0 =A0breaking mailing lists. Think of it as domains making strong
=A0 =A0assertions voluntarily excluding themselves. They value security
=A0 =A0more than the pleasure of your company on a list that does not
=A0 =A0respect their assertion with regard to their domain. They wish to =A0 =A0be master of their domain. If they wish to have the pleasure of
=A0 =A0your company they will either have to change their assertion/
=A0 =A0practice or participate using another account at a more flexible
=A0 =A0domain.
=A0 =A0 =A0 =A0 =A0 http://mipassoc.org/pipermail/ietf-dkim/2= 008q1/009196.html

What's changed since 2008 to chan= ge either the problem space or the solution space?

-MSK
--f46d043c7f4ecb870e04da2c647b-- From superuser@gmail.com Fri Apr 12 09:36:50 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFEB21F8F1C for ; Fri, 12 Apr 2013 09:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4M3S5A9bcHc for ; Fri, 12 Apr 2013 09:36:49 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 11C9321F8F13 for ; Fri, 12 Apr 2013 09:36:48 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hm14so1780299wib.16 for ; Fri, 12 Apr 2013 09:36:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IK4T3JE1v09DZMzQ5M4BMPT7mlxEftceXRjxnuhPYCM=; b=AEZlss4eSnVev8K8REl8IvI41p+5pJYo8bkoO+nXIA8tPw1ZJrn0SN/NV9b7yQsp+P AM43oQ/oVzftsY6+3P/7y1VY6eQFvawGanyq3RPftOJQc3Azf5rfwqQvi7GcOWaO1Mcu unUPJQIfQeBBvwk8ygliSR+/n0jJMYFKcfB4du0ylmKONyritxV/TPw2rbqy2BaUqhKz 6JS2f7BDa1i1lFndLyuFjI0ACnfX1pH6a7EnAACdsNDOrkjO3XlQZIhGPY7s90C64QHq fyaJxZNYv1WImtBrVhDmlSRBhMfUPUf1TsSm2Gv+T7TirltjMKkn6Hr0jLQ5jrm04zsS smGA== MIME-Version: 1.0 X-Received: by 10.180.74.67 with SMTP id r3mr5272313wiv.14.1365784608256; Fri, 12 Apr 2013 09:36:48 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 12 Apr 2013 09:36:47 -0700 (PDT) In-Reply-To: <77426B543150464AA3F30DF1A91365DE52F037BC@ESV4-MBX01.linkedin.biz> References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> <51680EBA.2040705@gmail.com> <77426B543150464AA3F30DF1A91365DE52F037BC@ESV4-MBX01.linkedin.biz> Date: Fri, 12 Apr 2013 09:36:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d0438914d6a3a5e04da2c82ae Cc: Dave Crocker , "" , John R Levine Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 16:36:50 -0000 --f46d0438914d6a3a5e04da2c82ae Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 12, 2013 at 8:22 AM, Franck Martin wrote: > I mean in DKIM there is one DNS operation, which is to fetch the key. If > the DNS does not answer (not that the DNS answers there is no key), I think > systems would not tempfail the email and just carry on? What happens if > there is more than one DKIM signature, and one has DNS failing? > > I don't believe either SPF or DKIM specifies a single action to be taken when the DNS query results in a temporary error of some kind. It would be perfectly legitimate to temp-fail the message until the DNS query works, and it would be perfectly legitimate to allow it to pass without completing verification. It's a local policy matter. As one data point, OpenDKIM offers the operator the ability to choose the action taken in this situation, defaulting to temp-failing for transient DNS errors and passing with an error noted for permanent DNS errors (e.g., key not found). --f46d0438914d6a3a5e04da2c82ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 12, 2013 at 8:22 AM, Franck Martin <fmar= tin@linkedin.com> wrote:
I mean in DKIM there is one DNS operation, w= hich is to fetch the key. If the DNS does not answer (not that the DNS answ= ers there is no key), I think systems would not tempfail the email and just= carry on? What happens if there is more than one DKIM signature, and one h= as DNS failing?


I don't believe= either SPF or DKIM specifies a single action to be taken when the DNS quer= y results in a temporary error of some kind.=A0 It would be perfectly legit= imate to temp-fail the message until the DNS query works, and it would be p= erfectly legitimate to allow it to pass without completing verification.=A0= It's a local policy matter.

As one data point, OpenDKIM offers the operator the ability to choose t= he action taken in this situation, defaulting to temp-failing for transient= DNS errors and passing with an error noted for permanent DNS errors (e.g.,= key not found).
--f46d0438914d6a3a5e04da2c82ae-- From R.E.Sonneveld@sonnection.nl Fri Apr 12 11:56:56 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6204521F8842 for ; Fri, 12 Apr 2013 11:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMx4JP5sehHp for ; Fri, 12 Apr 2013 11:56:55 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id CF81521F8825 for ; Fri, 12 Apr 2013 11:56:54 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 234368C1310; Fri, 12 Apr 2013 20:56:53 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id DFA908C130F; Fri, 12 Apr 2013 20:56:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 6E3DF12315A; Fri, 12 Apr 2013 20:56:52 +0200 (CEST) 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 yeVNYjZas4F8; Fri, 12 Apr 2013 20:56:44 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 518841230A5; Fri, 12 Apr 2013 20:56:44 +0200 (CEST) Message-ID: <516858EC.8070106@sonnection.nl> Date: Fri, 12 Apr 2013 20:56:44 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030402020003040609080601" Cc: "" , Franck Martin , "" , John Levine Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 18:56:56 -0000 This is a multi-part message in MIME format. --------------030402020003040609080601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote: > It depends on the kind of error and on the implementation. Generally, > a temporary DNS error should result in a temp-fail of the message, > while a permanent DNS error should not. SPF leaves this open. Quoting 4408bis: A "temperror" result means the SPF verifier encountered a transient (generally DNS) error while performing the check. Checking software can choose to accept or temporarily reject the message. > > "Record not found" is not a temporary error. > > I'd say both of those points are true for both protocols. Unless I'm missing something obvious, an SPF temporary DNS error reduces the DMARC mechanism check to a DKIM-only check, correct? At least: this is how I read the DMARC spec: 4. Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check if evaluation returned a "pass" result. and 5. Conduct identifier alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks if Authenticated Identifiers fall into alignment as decribed in Section 4 . If one or more of the Authenticated Identifiers align with theRFC5322 .From domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures. means: we have two things to check for: SPF and DKIM. If SPF evaluation does not provide a 'pass' (i.e. when the outcome is one of "None", "Neutral", "Fail", "SoftFail", "TempError" or "PermError") we're left with only DKIM. As SPF allows for the include: mechanism, it is possible that now and then DKIM and DMARC records can be retrieved from DNS, while SPF records (temporarily) can't. Suppose I'm using MessageLabs and I have an include:spf.messagelabs.com in my SPF record, while my DNS provides my DMARC p=reject record to any DNS client asking for it and meanwhile the DNS servers of MessageLabs are under a DDoS, this may impact delivery of my mail (in the 5? percent of all cases where DKIM validation fails [1]). Or am I misinterpreting DMARC? /rolf [1] http://www.ietf.org/iesg/implementation/report-rfc4871.txt --------------030402020003040609080601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote:
It depends on the kind of error and on the implementation.  Generally, a temporary DNS error should result in a temp-fail of the message, while a permanent DNS error should not.

SPF leaves this open. Quoting 4408bis:

   A "temperror" result means the SPF verifier encountered a transient
   (generally DNS) error while performing the check.  Checking software
   can choose to accept or temporarily reject the message.


"Record not found" is not a temporary error.

I'd say both of those points are true for both protocols.

Unless I'm missing something obvious, an SPF temporary DNS error reduces the DMARC mechanism check to a DKIM-only check, correct? At least: this is how I read the DMARC spec:

   4.  Perform SPF validation checks.  The results of this step are
       passed to the remainder of the algorithm and MUST include the
       domain name used to complete the SPF check if evaluation returned
       a "pass" result.
and

   5.  Conduct identifier alignment checks.  With authentication checks
       and policy discovery performed, the Mail Receiver checks if
       Authenticated Identifiers fall into alignment as decribed in
       Section 4.  If one or more of the Authenticated Identifiers align
       with the RFC5322.From domain, the message is considered to pass
       the DMARC mechanism check.  All other conditions (authentication
       failures, identifier mismatches) are considered to be DMARC
       mechanism check failures.

means: we have two things to check for: SPF and DKIM. If SPF evaluation does not provide a 'pass' (i.e. when the outcome is one of "None", "Neutral", "Fail", "SoftFail", "TempError" or "PermError") we're left with only DKIM.
 
As SPF allows for the include: mechanism, it is possible that now and then DKIM and DMARC records can be retrieved from DNS, while SPF records (temporarily) can't. Suppose I'm using MessageLabs and I have an include:spf.messagelabs.com in my SPF record, while my DNS provides my DMARC p=reject record to any DNS client asking for it and meanwhile the DNS servers of MessageLabs are under a DDoS, this may impact delivery of my mail (in the 5? percent of all cases where DKIM validation fails [1]).

Or am I misinterpreting DMARC?

/rolf

[1] http://www.ietf.org/iesg/implementation/report-rfc4871.txt
--------------030402020003040609080601-- From sklist@kitterman.com Fri Apr 12 12:11:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDB721F8F28 for ; Fri, 12 Apr 2013 12:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qce9wKJ18EaQ for ; Fri, 12 Apr 2013 12:11:11 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3DE21F8F1E for ; Fri, 12 Apr 2013 12:11:11 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 79FADD04088; Fri, 12 Apr 2013 14:11:07 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365793867; bh=pWJqVBGTiOYfKD/w6G8zGRXNh5eCbBnyfzgDvWlefrE=; h=In-Reply-To:References:Subject:From:Date:To:From; b=GJw/lc25+U7sjqaMNTdpFXBYNIC3Kqb/k/7T/2iRVF8MCykNr9W+21bhvdByGP0eP BRwQkckBzz+cj/TVeWa/i5T1A3UiuzI2NzrUlmJIMPftPCcMu4Cs7CIflFLDdmRxbg rMAmvEgT2JSGofgwfIrSuMmjZnUTX3HZRh4iO3uw= Received: from [IPV6:2600:1003:b029:46f3:818b:2ec6:56a7:dc18] (unknown [IPv6:2600:1003:b029:46f3:818b:2ec6:56a7:dc18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 1280AD04059; Fri, 12 Apr 2013 14:11:06 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <516858EC.8070106@sonnection.nl> References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> <516858EC.8070106@sonnection.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 12 Apr 2013 15:11:04 -0400 To: "" Message-ID: <47f2dc67-3f02-4917-a52d-2a91560e8453@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 19:11:16 -0000 "Rolf E. Sonneveld" wrote: >On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote: >> It depends on the kind of error and on the implementation. >Generally, >> a temporary DNS error should result in a temp-fail of the message, >> while a permanent DNS error should not. > >SPF leaves this open. Quoting 4408bis: > > A "temperror" result means the SPF verifier encountered a transient > (generally DNS) error while performing the check. Checking software > can choose to accept or temporarily reject the message. > > >> >> "Record not found" is not a temporary error. >> >> I'd say both of those points are true for both protocols. > >Unless I'm missing something obvious, an SPF temporary DNS error >reduces >the DMARC mechanism check to a DKIM-only check, correct? At least: this > >is how I read the DMARC spec: > > 4. Perform SPF validation checks. The results of this step are > passed to the remainder of the algorithm and MUST include the > domain name used to complete the SPF check if evaluation returned > a "pass" result. > >and > > 5. Conduct identifier alignment checks. With authentication checks > and policy discovery performed, the Mail Receiver checks if > Authenticated Identifiers fall into alignment as decribed in >Section 4 >. >If one or more of the Authenticated Identifiers align >with theRFC5322 .From domain, the >message is considered to pass > the DMARC mechanism check. All other conditions (authentication > failures, identifier mismatches) are considered to be DMARC > mechanism check failures. > > >means: we have two things to check for: SPF and DKIM. If SPF evaluation > >does not provide a 'pass' (i.e. when the outcome is one of "None", >"Neutral", "Fail", "SoftFail", "TempError" or "PermError") we're left >with only DKIM. > >As SPF allows for the include: mechanism, it is possible that now and >then DKIM and DMARC records can be retrieved from DNS, while SPF >records >(temporarily) can't. Suppose I'm using MessageLabs and I have an >include:spf.messagelabs.com in my SPF record, while my DNS provides my >DMARC p=reject record to any DNS client asking for it and meanwhile the > >DNS servers of MessageLabs are under a DDoS, this may impact delivery >of >my mail (in the 5? percent of all cases where DKIM validation fails >[1]). > >Or am I misinterpreting DMARC? > >/rolf > >[1] http://www.ietf.org/iesg/implementation/report-rfc4871.txt > It depends on which of the two options that RFC 4408 gives you've chosen to use. If you defer the message based on SPF temperror, then DMARC doesn't even come up. Scott K From johnl@taugh.com Fri Apr 12 13:03:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0044821F8DD0 for ; Fri, 12 Apr 2013 13:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqk3DZ3Kad9k for ; Fri, 12 Apr 2013 13:03:38 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DDB7621F8DB4 for ; Fri, 12 Apr 2013 13:03:37 -0700 (PDT) Received: (qmail 54543 invoked from network); 12 Apr 2013 20:03:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=d50d.51686899.k1304; bh=GXKu3PsmfXcqJ/wf8B3JGaBwWySCvACQ00UsA5ZUtBA=; b=DZvs12Ceovpjmn2XTp2pGk8hVrlW1MweuPKEnna3/kdPYb595PTXke+vAnJDDJSx+8J+6V6bE/cds3v+N6Z4f11kCuJ1EWudaFuVvi/l3DnCpX+o0OkoVqi5pMmRSB00cFW1fQin+B8fNU4fR1Z5Yt2zS8xLpD2esn5lfg1crhc= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=d50d.51686899.k1304; bh=GXKu3PsmfXcqJ/wf8B3JGaBwWySCvACQ00UsA5ZUtBA=; b=ui6VWbZikythSpp9UwwpnGLZJS0DQtHy5JT+AHW3SAd2zcQBUY3Wj+MLbHmOX8rb5YM8jQHH6/mfLzCK25n9/5mjRK1SlUCTITkeibPlEoJV9LCV6I4Z8JAndSC0LZPa7lUGffYzVnMhT2WmetHVuDT6mPte1TzXlkbEWuXs/Ss= Received: (ofmipd 127.0.0.1); 12 Apr 2013 20:03:15 -0000 Date: 12 Apr 2013 16:03:36 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> <51680EBA.2040705@gmail.com> <77426B543150464AA3F30DF1A91365DE52F037BC@ESV4-MBX01.linkedin.biz> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-291955466-1365797016=:3018" Cc: "" Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 20:03:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-291955466-1365797016=:3018 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > I don't believe either SPF or DKIM specifies a single action to be taken > when the DNS query results in a temporary error of some kind. It would be > perfectly legitimate to temp-fail the message until the DNS query works, > and it would be perfectly legitimate to allow it to pass without completing > verification. It's a local policy matter. Right. Until DMARC came along, there was no particular reason to do the DKIM verification during the SMTP session. My system has always done it as part of the spamassassin step that happens when the message is about to be delivered. At that point, if there's any sort of DNS failure, the DKIM verification just fails and the delivery goes ahead without it. I'm doing it in the SMTP session now for DMARC and adding an A-R header, but I still don't see much point in tempfailing the mail on DKIM failure. It's fairly hard to think of a plausible scenario in which the DKIM check would tempfail, but the DMARC would succeed, since they're generally handled by the same DNS server. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-291955466-1365797016=:3018 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDEyMjAwMzM2WjAjBgkqhkiG 9w0BCQQxFgQUPvUtWPZhbregtohigigVr8Yl54UweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAVluY5ubh/P4O NmA0WCMdxsxxingloe3iggc5IuNrSfS/psyP7ml+b+jmUFcO02dkPrHypIVJ NF0vpwDAB1sFcewFWSAAQw0D4Kaz6xavYgtiTNyFQHfsB+vimjH06ee6SiPg SP+TsUcEV4n0NN8ReGDJ3o80Cuf6KxDNHqoYbo7e959cNptb6GnH8Et9GFT5 w4Ky5++8lVMUviHyPOgwUdWPOnroAbAmGqqhT7JEKNSlwHi2iD3yVsSlNKT6 agP4CSKIwn38sjPX8aTM5g49Ff6+vCi8Hff9RKtMQmNiWxwWMnO7c2WWxPP8 kgyDKtT4IrCbEljLYmFwr/PSxwTwAw== --3825401791-291955466-1365797016=:3018-- From jgomez@seryrich.com Fri Apr 12 13:13:55 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0021F8E87 for ; Fri, 12 Apr 2013 13:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTQkJLmIQmJo for ; Fri, 12 Apr 2013 13:13:54 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 57A9F21F8E7E for ; Fri, 12 Apr 2013 13:13:54 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 12 Apr 2013 22:13:52 +0200 Message-ID: <445CC2AC45CE4317BE9744E6D637BA28@fgsr.local> From: "J. Gomez" To: References: <20130411040946.9056.qmail@joyce.lan><51673150.50202@sonnection.nl><77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz><516858EC.8070106@sonnection.nl> <47f2dc67-3f02-4917-a52d-2a91560e8453@email.android.com> Date: Fri, 12 Apr 2013 22:14:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass inthe DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 20:13:55 -0000 On Friday, April 12, 2013 9:11 PM [GMT+1=3DCET], Scott Kitterman wrote: > "Rolf E. Sonneveld" wrote: >=20 > > On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote: > > > It depends on the kind of error and on the implementation. > > Generally, > > > a temporary DNS error should result in a temp-fail of the message, > > > while a permanent DNS error should not. > >=20 > > SPF leaves this open. Quoting 4408bis: > >=20 > > A "temperror" result means the SPF verifier encountered a > > transient (generally DNS) error while performing the check.=20 > > Checking software can choose to accept or temporarily reject the > > message.=20 > >=20 > >=20 > > >=20 > > > "Record not found" is not a temporary error. > > >=20 > > > I'd say both of those points are true for both protocols. > >=20 > > Unless I'm missing something obvious, an SPF temporary DNS error > > reduces > > the DMARC mechanism check to a DKIM-only check, correct? At least: > > this=20 > >=20 > > is how I read the DMARC spec: > >=20 > > 4. Perform SPF validation checks. The results of this step are > > passed to the remainder of the algorithm and MUST include the > > domain name used to complete the SPF check if evaluation > > returned a "pass" result. > >=20 > > and > >=20 > > 5. Conduct identifier alignment checks. With authentication > > checks and policy discovery performed, the Mail Receiver > > checks if Authenticated Identifiers fall into alignment as > > decribed in=20 > > Section 4 > > = . > > If one or more of the Authenticated Identifiers align > > with theRFC5322 .From domain, > > the message is considered to pass > > the DMARC mechanism check. All other conditions > > (authentication failures, identifier mismatches) are > > considered to be DMARC mechanism check failures. > >=20 > >=20 > > means: we have two things to check for: SPF and DKIM. If SPF > > evaluation=20 > >=20 > > does not provide a 'pass' (i.e. when the outcome is one of "None", > > "Neutral", "Fail", "SoftFail", "TempError" or "PermError") we're > > left with only DKIM. > >=20 > > As SPF allows for the include: mechanism, it is possible that now > > and then DKIM and DMARC records can be retrieved from DNS, while SPF > > records > > (temporarily) can't. Suppose I'm using MessageLabs and I have an > > include:spf.messagelabs.com in my SPF record, while my DNS provides > > my DMARC p=3Dreject record to any DNS client asking for it and > > meanwhile the=20 > >=20 > > DNS servers of MessageLabs are under a DDoS, this may impact > > delivery of > > my mail (in the 5? percent of all cases where DKIM validation fails > > [1]). > >=20 > > Or am I misinterpreting DMARC? > >=20 > > /rolf > >=20 > > [1] http://www.ietf.org/iesg/implementation/report-rfc4871.txt > >=20 > It depends on which of the two options that RFC 4408 gives you've > chosen to use. If you defer the message based on SPF temperror, > then DMARC doesn't even come up. Allow me to quote Requirement #7 for DMARC: "Message disposition = requests via DMARC override those requested by any other public = mechanism." Which amounts to your reply does not apply, and Rolf's = question is still pertinent. https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D1 Regards, J. Gomez From superuser@gmail.com Fri Apr 12 13:23:17 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC77721F8EAA for ; Fri, 12 Apr 2013 13:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQcg+VMLXZkr for ; Fri, 12 Apr 2013 13:23:05 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD6E21F8E9A for ; Fri, 12 Apr 2013 13:23:01 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr17so947310wib.17 for ; Fri, 12 Apr 2013 13:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7Hx94Y3OYYvOvZiQHncvh4s83CWNaiOE3mAe3wuINGM=; b=QfMyDPogAUYMTh5aNUUBdYJ3Z8QJuna9iQmHpVLoho4GBhxrrY6LvnEvLrajYq/wlK +UcyQl782oUCb1qAQ/mNVitpCTv4RHz/zU0CeXlTZOFETTC3+jaQhEa8e96SJk8ylaPP 0XKk3o7AzG9sjw6in5AQHioA7VtCfAb579TCoum6pmaWLUaJpf6r9YkgEAyE9uQCORcU pO4m3nov+TAl4koQBgmc3hAIosuW30S+vCBKIDhUQs1D6TwLFFywKmowQtwyGu26Iusr wxRberU8Y7hcLSEEs+JGcM7altjm9+H1z1VhojQ8wM+5HCQNs27oiP6mf679b++d+PQD CC+g== MIME-Version: 1.0 X-Received: by 10.194.93.68 with SMTP id cs4mr20006245wjb.17.1365798180568; Fri, 12 Apr 2013 13:23:00 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 12 Apr 2013 13:23:00 -0700 (PDT) In-Reply-To: <445CC2AC45CE4317BE9744E6D637BA28@fgsr.local> References: <20130411040946.9056.qmail@joyce.lan> <51673150.50202@sonnection.nl> <77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz> <516858EC.8070106@sonnection.nl> <47f2dc67-3f02-4917-a52d-2a91560e8453@email.android.com> <445CC2AC45CE4317BE9744E6D637BA28@fgsr.local> Date: Fri, 12 Apr 2013 13:23:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7b5d8cff63456d04da2fabff Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass inthe DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 20:23:17 -0000 --047d7b5d8cff63456d04da2fabff Content-Type: text/plain; charset=ISO-8859-1 There's nothing the protocol can do, or specify, to make sure this happens. The operator has to make sure of it. On Fri, Apr 12, 2013 at 1:14 PM, J. Gomez wrote: > On Friday, April 12, 2013 9:11 PM [GMT+1=CET], Scott Kitterman wrote: > > > "Rolf E. Sonneveld" wrote: > > > > > On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote: > > > > It depends on the kind of error and on the implementation. > > > Generally, > > > > a temporary DNS error should result in a temp-fail of the message, > > > > while a permanent DNS error should not. > > > > > > SPF leaves this open. Quoting 4408bis: > > > > > > A "temperror" result means the SPF verifier encountered a > > > transient (generally DNS) error while performing the check. > > > Checking software can choose to accept or temporarily reject the > > > message. > > > > > > > > > > > > > > "Record not found" is not a temporary error. > > > > > > > > I'd say both of those points are true for both protocols. > > > > > > Unless I'm missing something obvious, an SPF temporary DNS error > > > reduces > > > the DMARC mechanism check to a DKIM-only check, correct? At least: > > > this > > > > > > is how I read the DMARC spec: > > > > > > 4. Perform SPF validation checks. The results of this step are > > > passed to the remainder of the algorithm and MUST include the > > > domain name used to complete the SPF check if evaluation > > > returned a "pass" result. > > > > > > and > > > > > > 5. Conduct identifier alignment checks. With authentication > > > checks and policy discovery performed, the Mail Receiver > > > checks if Authenticated Identifiers fall into alignment as > > > decribed in > > > Section 4 > > > . > > > If one or more of the Authenticated Identifiers align > > > with theRFC5322 .From domain, > > > the message is considered to pass > > > the DMARC mechanism check. All other conditions > > > (authentication failures, identifier mismatches) are > > > considered to be DMARC mechanism check failures. > > > > > > > > > means: we have two things to check for: SPF and DKIM. If SPF > > > evaluation > > > > > > does not provide a 'pass' (i.e. when the outcome is one of "None", > > > "Neutral", "Fail", "SoftFail", "TempError" or "PermError") we're > > > left with only DKIM. > > > > > > As SPF allows for the include: mechanism, it is possible that now > > > and then DKIM and DMARC records can be retrieved from DNS, while SPF > > > records > > > (temporarily) can't. Suppose I'm using MessageLabs and I have an > > > include:spf.messagelabs.com in my SPF record, while my DNS provides > > > my DMARC p=reject record to any DNS client asking for it and > > > meanwhile the > > > > > > DNS servers of MessageLabs are under a DDoS, this may impact > > > delivery of > > > my mail (in the 5? percent of all cases where DKIM validation fails > > > [1]). > > > > > > Or am I misinterpreting DMARC? > > > > > > /rolf > > > > > > [1] http://www.ietf.org/iesg/implementation/report-rfc4871.txt > > > > > It depends on which of the two options that RFC 4408 gives you've > > chosen to use. If you defer the message based on SPF temperror, > > then DMARC doesn't even come up. > > Allow me to quote Requirement #7 for DMARC: "Message disposition requests > via DMARC override those requested by any other public mechanism." Which > amounts to your reply does not apply, and Rolf's question is still > pertinent. > > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 > > Regards, > > J. Gomez > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7b5d8cff63456d04da2fabff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There's nothing the protocol can do, or specify, to ma= ke sure this happens.=A0 The operator has to make sure of it.


On Fri, Apr 12, 2= 013 at 1:14 PM, J. Gomez <jgomez@seryrich.com> wrote:
On F= riday, April 12, 2013 9:11 PM [GMT+1=3DCET], Scott Kitterman wrote:

> "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl> wrote:
>
> > On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote:
> > > It depends on the kind of error and on the implementation. > > Generally,
> > > a temporary DNS error should result in a temp-fail of the me= ssage,
> > > while a permanent DNS error should not.
> >
> > SPF leaves this open. Quoting 4408bis:
> >
> > =A0 =A0A "temperror" result means the SPF verifier enco= untered a
> > =A0 transient (generally DNS) error while performing the check. > > =A0 =A0Checking software can choose to accept or temporarily reje= ct the
> > message.
> >
> >
> > >
> > > "Record not found" is not a temporary error.
> > >
> > > I'd say both of those points are true for both protocols= .
> >
> > Unless I'm missing something obvious, an SPF temporary DNS er= ror
> > reduces
> > the DMARC mechanism check to a DKIM-only check, correct? At least= :
> > this
> >
> > is how I read the DMARC spec:
> >
> > =A0 =A04. =A0Perform SPF validation checks. =A0The results of thi= s step are
> > =A0 =A0 =A0 =A0passed to the remainder of the algorithm and MUST = include the
> > =A0 =A0 =A0domain name used to complete the SPF check if evaluati= on
> > =A0 =A0 =A0 =A0returned a "pass" result.
> >
> > and
> >
> > =A0 5. =A0Conduct identifier alignment checks. =A0With authentica= tion
> > =A0 =A0 =A0 =A0checks and policy discovery performed, the Mail Re= ceiver
> > =A0 =A0 =A0 =A0checks if Authenticated Identifiers fall into alig= nment as
> > decribed in
> > Section 4
> > <http://tools.ietf.org/html/draft-kucher= awy-dmarc-base-00#section-4>.
> > If one or more of the Authenticated Identifiers align
> > with theRFC5322 =A0<http://tools.ietf.org/html/rfc5322>.From doma= in,
> > the message is considered to pass
> > =A0 =A0 =A0 the DMARC mechanism check. =A0All other conditions > > =A0 =A0 =A0 =A0(authentication failures, identifier mismatches) a= re
> > =A0 =A0 =A0 =A0considered to be DMARC mechanism check failures. > >
> >
> > means: we have two things to check for: SPF and DKIM. If SPF
> > evaluation
> >
> > does not provide a 'pass' (i.e. when the outcome is one o= f "None",
> > "Neutral", "Fail", "SoftFail", &quo= t;TempError" or "PermError") we're
> > left with only DKIM.
> >
> > As SPF allows for the include: mechanism, it is possible that now=
> > and then DKIM and DMARC records can be retrieved from DNS, while = SPF
> > records
> > (temporarily) can't. Suppose I'm using MessageLabs and I = have an
> > include:= spf.messagelabs.com in my SPF record, while my DNS provides
> > my DMARC p=3Dreject record to any DNS client asking for it and > > meanwhile the
> >
> > DNS servers of MessageLabs are under a DDoS, this may impact
> > delivery of
> > my mail (in the 5? percent of all cases where DKIM validation fai= ls
> > [1]).
> >
> > Or am I misinterpreting DMARC?
> >
> > /rolf
> >
> > [1] http://www.ietf.org/iesg/implementation/report-= rfc4871.txt
> >
> It depends on which of the two options that RFC 4408 gives you've<= br> > chosen to use. =A0 If you defer the message based on SPF temperror, > then DMARC doesn't even come up.

Allow me to quote Requirement #7 for DMARC: "Message dispo= sition requests via DMARC override those requested by any other public mech= anism." Which amounts to your reply does not apply, and Rolf's que= stion is still pertinent.

https://datatracker.ietf.org/doc/draft-kuc= herawy-dmarc-base/?include_text=3D1

Regards,

J. Gomez

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

--047d7b5d8cff63456d04da2fabff-- From sklist@kitterman.com Fri Apr 12 13:30:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4B21F8EC3 for ; Fri, 12 Apr 2013 13:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ul5rBkSBaDt2 for ; Fri, 12 Apr 2013 13:30:39 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id F3E4121F8E7E for ; Fri, 12 Apr 2013 13:30:38 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9F16FD04088; Fri, 12 Apr 2013 15:30:37 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365798637; bh=WFuF2/qNcMoHfWjaTVINsOdsGTa7U8XF5aYMEuPGrV8=; h=In-Reply-To:References:Subject:From:Date:To:From; b=pIkNqXpA++raSVi8CDDYbXMaOvMw6WNjeyfQZQ1mIeWu3ejbTg9KOQwY0K9i4JEh+ qnvUa7Wuwx5Ja7RNQUECIoauzZMdnqsc8UG9XOSMsj5FDfnMRcaEe1HWTfoQzVSRNs 85Ig52tA4Q0yyGCG+D8CMDwcv5O/9k7qDFre6RXE= Received: from [IPV6:2600:1003:b024:f124:8b4d:a49d:910d:c021] (unknown [IPv6:2600:1003:b024:f124:8b4d:a49d:910d:c021]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3FCE2D04046; Fri, 12 Apr 2013 15:30:36 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: <445CC2AC45CE4317BE9744E6D637BA28@fgsr.local> References: <20130411040946.9056.qmail@joyce.lan><51673150.50202@sonnection.nl><77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz><516858EC.8070106@sonnection.nl> <47f2dc67-3f02-4917-a52d-2a91560e8453@email.android.com> <445CC2AC45CE4317BE9744E6D637BA28@fgsr.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 12 Apr 2013 16:30:35 -0400 To: dmarc@ietf.org Message-ID: <42eaf7e9-8952-41f0-9641-58dcf5c5e479@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass inthe DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 20:30:40 -0000 "J. Gomez" wrote: >On Friday, April 12, 2013 9:11 PM [GMT+1=CET], Scott Kitterman wrote: > >> "Rolf E. Sonneveld" wrote: >> >> > On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote: >> > > It depends on the kind of error and on the implementation. >> > Generally, >> > > a temporary DNS error should result in a temp-fail of the >message, >> > > while a permanent DNS error should not. >> > >> > SPF leaves this open. Quoting 4408bis: >> > >> > A "temperror" result means the SPF verifier encountered a >> > transient (generally DNS) error while performing the check. >> > Checking software can choose to accept or temporarily reject the >> > message. >> > >> > >> > > >> > > "Record not found" is not a temporary error. >> > > >> > > I'd say both of those points are true for both protocols. >> > >> > Unless I'm missing something obvious, an SPF temporary DNS error >> > reduces >> > the DMARC mechanism check to a DKIM-only check, correct? At least: >> > this >> > >> > is how I read the DMARC spec: >> > >> > 4. Perform SPF validation checks. The results of this step are >> > passed to the remainder of the algorithm and MUST include >the >> > domain name used to complete the SPF check if evaluation >> > returned a "pass" result. >> > >> > and >> > >> > 5. Conduct identifier alignment checks. With authentication >> > checks and policy discovery performed, the Mail Receiver >> > checks if Authenticated Identifiers fall into alignment as >> > decribed in >> > Section 4 >> > >. >> > If one or more of the Authenticated Identifiers align >> > with theRFC5322 .From domain, >> > the message is considered to pass >> > the DMARC mechanism check. All other conditions >> > (authentication failures, identifier mismatches) are >> > considered to be DMARC mechanism check failures. >> > >> > >> > means: we have two things to check for: SPF and DKIM. If SPF >> > evaluation >> > >> > does not provide a 'pass' (i.e. when the outcome is one of "None", >> > "Neutral", "Fail", "SoftFail", "TempError" or "PermError") we're >> > left with only DKIM. >> > >> > As SPF allows for the include: mechanism, it is possible that now >> > and then DKIM and DMARC records can be retrieved from DNS, while >SPF >> > records >> > (temporarily) can't. Suppose I'm using MessageLabs and I have an >> > include:spf.messagelabs.com in my SPF record, while my DNS provides >> > my DMARC p=reject record to any DNS client asking for it and >> > meanwhile the >> > >> > DNS servers of MessageLabs are under a DDoS, this may impact >> > delivery of >> > my mail (in the 5? percent of all cases where DKIM validation fails >> > [1]). >> > >> > Or am I misinterpreting DMARC? >> > >> > /rolf >> > >> > [1] http://www.ietf.org/iesg/implementation/report-rfc4871.txt >> > >> It depends on which of the two options that RFC 4408 gives you've >> chosen to use. If you defer the message based on SPF temperror, >> then DMARC doesn't even come up. > >Allow me to quote Requirement #7 for DMARC: "Message disposition >requests via DMARC override those requested by any other public >mechanism." Which amounts to your reply does not apply, and Rolf's >question is still pertinent. > >https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 SPF temperror is a protocol result, not a message disposition request. It's a matter of local policy. Scott K From jgomez@seryrich.com Fri Apr 12 14:34:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A834321F8EDF for ; Fri, 12 Apr 2013 14:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhQmSMZRsuLX for ; Fri, 12 Apr 2013 14:34:46 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 7B16E21F8EDE for ; Fri, 12 Apr 2013 14:34:46 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 12 Apr 2013 23:34:44 +0200 Message-ID: From: "J. Gomez" To: Date: Fri, 12 Apr 2013 23:35:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 21:34:47 -0000 Hello all. I would like to propose an extension to DMARC, in order to address its = mailing list problem, as much as it can be addressed --which is not = much-- considering current mailing list software behaviour of keeping = the original RFC5322.From header (while altering either/both the Subject = and the Body) when forwarding emails to its subscribers, therefore both = (A) breaking the original DKIM signature and (B) relaying from a MTA = which is not SPF-authorized by the Organizational Domain in the = RFC5322.From header; all of which causes DMARC-failures for those posts = being received from mailing lists. I propose an additional tag for the DMARC resource record in DNS. This = tag is to be optional. This optional tag is "l=3D" and it could have the = values "yes" or "no" or "dunno". Default value would be "dunno" which = would be the effective value if the "l=3D" tag was omitted. The meaning = of "dunno" in the "l=3D" tag is explicitly 'undefined'. The meaning of = "yes" and "no" in the "l=3D" tag are described in the next paragraph. The "l=3D" tag is an informative declaration from the Sending Domain = Owner to all Receivers about whether the sending Organizational Domain's = users may participate or not in mailing lists. The "l=3D" tag does no = convey policy from Sender to Receiver, and Receivers are not formally = required nor recommended any course of action based on the content of = the "l=3D" tag. Instead the "l=3D" tag only conveys dry, aseptic = information from Sender to Receiver. Receivers are free to either = disregard the contents of the "l=3D" tag altogether or apply local = policies based on the information disclosed by the Sender by means of = the "l=3D" tag. This approach basically outsources to the Receivers the problem of = dealing --if at all, at the Receiver's discretion-- with the by-design = DMARC false positives of mailing lists posts. As the default value for = the "l=3D" tag is "dunno", this 'outsourcing' is an opt-in tunable knob = which the Sender can enable or disable at will, and also a dry, aseptic = information exchange which the Receiver can choose to either ignore or = apply special local policies/checks/verifications on it. ---- Counter-replies to possible objections: 1. (Operative problem) There is a considerable already functional base = of pre-standard DMARC installations on the field and this proposition of = a new tag in the DNS RR for DMARC makes their lives hard. --> This proposition just adds a new tag to the DMARC RR in DNS, and = that same thing has already happened when the DMARC draft was moved from = pre-IETF track to the IETF track less than a month ago, when the new tag = "fo=3D" was added to the DMARC RR in DNS apparently to none's objection. = ( See Section 6.2, "General Record Format", = http://www.dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html ) --- 2. (Semantic problem) There is a considerable already functional base of = pre-standard DMARC installations on the field and this proposition = changes the semantics of DMARC and therefore makes their lives hard. --> The "l=3D" tag is optional, and its default value is explicitly = 'undefined' (i.e., "dunno"). This means the semantics of a DMARC RR in = DNS do not change unless the Sender explicitly deviates from default = behaviour, and even then Receivers are free to disregard the additional = information provided by the Sender by means of the "l=3D" tag. --- 3. (Complexity problem) This propositions makes DMARC more complex, and = complexity tends to deter adoption. --> The "l=3D" tag is optional, and it's default value changes = nothing from the current DMARC status quo. Most senders can ignore the = "l=3D" tag when configuring their DMARC RR in DNS, and most Receivers = will just do whatever their DMARC plugin/milter does by default = regarding the "l=3D" tag without giving it a second thought unless they = feel the itch of the mailing list problem. --- 4. (Uselessness problem) This proposition achieves nothing. --> True. It's not the intent of the "l=3D" tag to achieve anything = nor to convey policy from Sender to Receiver. The "l=3D" tag merely = conveys additional information from Sender to Receiver, and the Receiver = is free to consume it as he wishes or to disregard it altogether. --- 5. (There ain't a problem in the first place) This proposition is not = needed. --> Yeah, right. ---- Regards, J. Gomez From jgomez@seryrich.com Fri Apr 12 15:04:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99A121F8C98 for ; Fri, 12 Apr 2013 15:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ypkBFSi3JCK for ; Fri, 12 Apr 2013 15:04:21 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id D0B0F21F8BD0 for ; Fri, 12 Apr 2013 15:04:20 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 13 Apr 2013 00:04:19 +0200 Message-ID: From: "J. Gomez" To: References: <20130411040946.9056.qmail@joyce.lan><51673150.50202@sonnection.nl><77426B543150464AA3F30DF1A91365DE52EF9408@ESV4-MBX01.linkedin.biz><516858EC.8070106@sonnection.nl><47f2dc67-3f02-4917-a52d-2a91560e8453@email.android.com><445CC2AC45CE4317BE9744E6D637BA28@fgsr.local> <42eaf7e9-8952-41f0-9641-58dcf5c5e479@email.android.com> Date: Sat, 13 Apr 2013 00:05:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 22:04:22 -0000 On Friday, April 12, 2013 10:30 PM [GMT+1=3DCET], Scott Kitterman wrote: > "J. Gomez" wrote: >=20 > > On Friday, April 12, 2013 9:11 PM [GMT+1=3DCET], Scott Kitterman > > wrote:=20 > >=20 > > > "Rolf E. Sonneveld" wrote: > > >=20 > > > > On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote: > > > > > It depends on the kind of error and on the implementation. > > > > Generally, > > > > > a temporary DNS error should result in a temp-fail of the > > message, > > > > > while a permanent DNS error should not. > > > >=20 > > > > SPF leaves this open. Quoting 4408bis: > > > >=20 > > > > A "temperror" result means the SPF verifier encountered a > > > > transient (generally DNS) error while performing the check. > > > > Checking software can choose to accept or temporarily reject > > > > the message. > > > >=20 > > > >=20 > > > > >=20 > > > > > "Record not found" is not a temporary error. > > > > >=20 > > > > > I'd say both of those points are true for both protocols. > > > >=20 > > > > Unless I'm missing something obvious, an SPF temporary DNS error > > > > reduces > > > > the DMARC mechanism check to a DKIM-only check, correct? At > > > > least: this > > > >=20 > > > > is how I read the DMARC spec: > > > >=20 > > > > 4. Perform SPF validation checks. The results of this step > > > > are passed to the remainder of the algorithm and MUST > > > > include=20 > > the > > > > domain name used to complete the SPF check if evaluation > > > > returned a "pass" result. > > > >=20 > > > > and > > > >=20 > > > > 5. Conduct identifier alignment checks. With authentication > > > > checks and policy discovery performed, the Mail Receiver > > > > checks if Authenticated Identifiers fall into alignment > > > > as decribed in > > > > Section 4 > > > >=20 > > = . > > > > If one or more of the Authenticated Identifiers align > > > > with theRFC5322 .From > > > > domain, the message is considered to pass > > > > the DMARC mechanism check. All other conditions > > > > (authentication failures, identifier mismatches) are > > > > considered to be DMARC mechanism check failures. > > > >=20 > > > >=20 > > > > means: we have two things to check for: SPF and DKIM. If SPF > > > > evaluation > > > >=20 > > > > does not provide a 'pass' (i.e. when the outcome is one of > > > > "None", "Neutral", "Fail", "SoftFail", "TempError" or > > > > "PermError") we're left with only DKIM. > > > >=20 > > > > As SPF allows for the include: mechanism, it is possible that > > > > now and then DKIM and DMARC records can be retrieved from DNS, > > > > while=20 > > SPF > > > > records > > > > (temporarily) can't. Suppose I'm using MessageLabs and I have an > > > > include:spf.messagelabs.com in my SPF record, while my DNS > > > > provides my DMARC p=3Dreject record to any DNS client asking for > > > > it and meanwhile the > > > >=20 > > > > DNS servers of MessageLabs are under a DDoS, this may impact > > > > delivery of > > > > my mail (in the 5? percent of all cases where DKIM validation > > > > fails [1]). > > > >=20 > > > > Or am I misinterpreting DMARC? > > > >=20 > > > > /rolf > > > >=20 > > > > [1] http://www.ietf.org/iesg/implementation/report-rfc4871.txt > > > >=20 > > > It depends on which of the two options that RFC 4408 gives you've > > > chosen to use. If you defer the message based on SPF temperror, > > > then DMARC doesn't even come up. > >=20 > > Allow me to quote Requirement #7 for DMARC: "Message disposition > > requests via DMARC override those requested by any other public > > mechanism." Which amounts to your reply does not apply, and Rolf's > > question is still pertinent. > >=20 > > = https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D1 >=20 > SPF temperror is a protocol result, not a message disposition > request. It's a matter of local policy. No. DMARC requires to pass the results of the SPF-check to the = "remainder of the [DMARC] algorithm". If you take any action (whatever = action) directly on the results of the SPF-check which is different from = the action of passing said results to "the remainder of [DMARC] the = algorithm", then you are not DMARC-compliant. Period. So whatever the = SPF-result is, you must go straight after it to check "identifier = alignment checks", and if in that step the identifier is DKIM-aligned = then you have a DMARC pass (and not a SPF-temperror on which you can = act, unless you are not checking DMARC at all). [See Section 11.2.4 and = 11.2.5] https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D1 Regards, J. Gomez From prvs=78145f36b6=madkins@fb.com Fri Apr 12 15:06:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F0721F8EAA for ; Fri, 12 Apr 2013 15:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O78bW6-r-Mh for ; Fri, 12 Apr 2013 15:06:46 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by ietfa.amsl.com (Postfix) with ESMTP id 924BD21F8EDA for ; Fri, 12 Apr 2013 15:06:46 -0700 (PDT) Received: from pps.filterd (m0044008 [127.0.0.1]) by m0044008.ppops.net (8.14.5/8.14.5) with SMTP id r3CM3SX9006573; Fri, 12 Apr 2013 15:06:46 -0700 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=TyMw+deYPu6ODUECtgGtQ0H9VQbw/4z3I7LNAxdbuY0=; b=KZJfECf2Qh0yUuvogLwDrbDRq4IFyR02p7EDJdXZPwz6OMQmPbwvet1JqXFo9wEuDIlj aXNuMoao/DXxrphjDN4CC7OU/QHQwqOFbSRZG3so0tX1HOvM2ZYBgaUyYaE4c7A2yWYn Zk3U93zoOnfeYHOzZiMevSwqS/rBm/8GymQ= Received: from prn1-cmdf-dc01-fw1-nat.corp.tfbnw.net (prn1-cmdf-dc01-fw1-nat.corp.tfbnw.net [173.252.71.129] (may be forged)) by mx0a-00082601.pphosted.com with ESMTP id 1bpf4pa7yv-9 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Apr 2013 15:06:46 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.5.232]) by PRN-CHUB03.TheFacebook.com ([fe80::fd64:bd05:4514:bbad%12]) with mapi id 14.02.0328.011; Fri, 12 Apr 2013 15:03:03 -0700 From: Michael Adkins To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity Thread-Index: AQHON8mA/iQq4VhGjUOzXM4Y7OppVg== Date: Fri, 12 Apr 2013 22:03:02 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.168.16.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <4DD8D5D75DF82049A7DC2B862A462C1F@fb.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-12_07:2013-04-12, 2013-04-12, 1970-01-01 signatures=0 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 22:06:47 -0000 You forgot=20 6. Layering Violation DMARC doesn't have a problem with mailing lists. DKIM and SPF have a problem with mailing lists and trying to fix their problem in DMARC is the wrong place. And 7. Operational Issue This problem is better solved by making data about legitimate mailing lists publicially available so everyone can apply local policy overrides consistently. On 4/12/13 2:35 PM, "J. Gomez" wrote: >Hello all. > >I would like to propose an extension to DMARC, in order to address its >mailing list problem, as much as it can be addressed --which is not >much-- considering current mailing list software behaviour of keeping the >original RFC5322.From header (while altering either/both the Subject and >the Body) when forwarding emails to its subscribers, therefore both (A) >breaking the original DKIM signature and (B) relaying from a MTA which is >not SPF-authorized by the Organizational Domain in the RFC5322.From >header; all of which causes DMARC-failures for those posts being received >from mailing lists. > >I propose an additional tag for the DMARC resource record in DNS. This >tag is to be optional. This optional tag is "l=3D" and it could have the >values "yes" or "no" or "dunno". Default value would be "dunno" which >would be the effective value if the "l=3D" tag was omitted. The meaning of >"dunno" in the "l=3D" tag is explicitly 'undefined'. The meaning of "yes" >and "no" in the "l=3D" tag are described in the next paragraph. > >The "l=3D" tag is an informative declaration from the Sending Domain Owner >to all Receivers about whether the sending Organizational Domain's users >may participate or not in mailing lists. The "l=3D" tag does no convey >policy from Sender to Receiver, and Receivers are not formally required >nor recommended any course of action based on the content of the "l=3D" >tag. Instead the "l=3D" tag only conveys dry, aseptic information from >Sender to Receiver. Receivers are free to either disregard the contents >of the "l=3D" tag altogether or apply local policies based on the >information disclosed by the Sender by means of the "l=3D" tag. > >This approach basically outsources to the Receivers the problem of >dealing --if at all, at the Receiver's discretion-- with the by-design >DMARC false positives of mailing lists posts. As the default value for >the "l=3D" tag is "dunno", this 'outsourcing' is an opt-in tunable knob >which the Sender can enable or disable at will, and also a dry, aseptic >information exchange which the Receiver can choose to either ignore or >apply special local policies/checks/verifications on it. > > >---- > > >Counter-replies to possible objections: > > >1. (Operative problem) There is a considerable already functional base of >pre-standard DMARC installations on the field and this proposition of a >new tag in the DNS RR for DMARC makes their lives hard. > > --> This proposition just adds a new tag to the DMARC RR in DNS, and >that same thing has already happened when the DMARC draft was moved from >pre-IETF track to the IETF track less than a month ago, when the new tag >"fo=3D" was added to the DMARC RR in DNS apparently to none's objection. ( >See Section 6.2, "General Record Format", >http://www.dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html ) > >--- > >2. (Semantic problem) There is a considerable already functional base of >pre-standard DMARC installations on the field and this proposition >changes the semantics of DMARC and therefore makes their lives hard. > > --> The "l=3D" tag is optional, and its default value is explicitly >'undefined' (i.e., "dunno"). This means the semantics of a DMARC RR in >DNS do not change unless the Sender explicitly deviates from default >behaviour, and even then Receivers are free to disregard the additional >information provided by the Sender by means of the "l=3D" tag. > >--- > >3. (Complexity problem) This propositions makes DMARC more complex, and >complexity tends to deter adoption. > > --> The "l=3D" tag is optional, and it's default value changes nothing >from the current DMARC status quo. Most senders can ignore the "l=3D" tag >when configuring their DMARC RR in DNS, and most Receivers will just do >whatever their DMARC plugin/milter does by default regarding the "l=3D" ta= g >without giving it a second thought unless they feel the itch of the >mailing list problem. > >--- > >4. (Uselessness problem) This proposition achieves nothing. > > --> True. It's not the intent of the "l=3D" tag to achieve anything no= r >to convey policy from Sender to Receiver. The "l=3D" tag merely conveys >additional information from Sender to Receiver, and the Receiver is free >to consume it as he wishes or to disregard it altogether. > >--- > >5. (There ain't a problem in the first place) This proposition is not >needed. > > --> Yeah, right. > >---- > > >Regards, > >J. Gomez > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From sklist@kitterman.com Fri Apr 12 15:09:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C5A21F8F2F for ; Fri, 12 Apr 2013 15:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LktC5XGFht5Z for ; Fri, 12 Apr 2013 15:09:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A1F3621F8F3C for ; Fri, 12 Apr 2013 15:09:38 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2D91120E40D2; Fri, 12 Apr 2013 18:09:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365804578; bh=3EwN9skgRjEQ44kGC+7GOj3Ft6M3ov0xN31800t3ACk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OOjtIG0fgwuxMmIBYAXfSaWY9n79YSYmWbapdUNrI5GrtI3Fcfo6FJ8O4acNSU5NZ eE5plM30/LE1p5F4vOhKhsehhDIXI3YXCKb5iRD2U58JKKy4+7w4LbMcCZ/9n7ilYQ 90mNAULp2dbyOETZMdQYWqEkih3ToJpkIZo1U1m8= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 0FEBE20E40B0; Fri, 12 Apr 2013 18:09:37 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Apr 2013 18:09:37 -0400 Message-ID: <1406296.sgmforF3Ss@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 22:09:39 -0000 What problem does SPF have with mailing lists (hint: there aren't any)? Scott K On Friday, April 12, 2013 10:03:02 PM Michael Adkins wrote: > You forgot > 6. Layering Violation > DMARC doesn't have a problem with mailing lists. DKIM and SPF have a > problem with mailing lists and trying to fix their problem in DMARC is the > wrong place. > > And > > 7. Operational Issue > This problem is better solved by making data about legitimate mailing > lists publicially available so everyone can apply local policy overrides > consistently. > > On 4/12/13 2:35 PM, "J. Gomez" wrote: > >Hello all. > > > >I would like to propose an extension to DMARC, in order to address its > >mailing list problem, as much as it can be addressed --which is not > >much-- considering current mailing list software behaviour of keeping the > >original RFC5322.From header (while altering either/both the Subject and > >the Body) when forwarding emails to its subscribers, therefore both (A) > >breaking the original DKIM signature and (B) relaying from a MTA which is > >not SPF-authorized by the Organizational Domain in the RFC5322.From > >header; all of which causes DMARC-failures for those posts being received > >from mailing lists. > > > >I propose an additional tag for the DMARC resource record in DNS. This > >tag is to be optional. This optional tag is "l=" and it could have the > >values "yes" or "no" or "dunno". Default value would be "dunno" which > >would be the effective value if the "l=" tag was omitted. The meaning of > >"dunno" in the "l=" tag is explicitly 'undefined'. The meaning of "yes" > >and "no" in the "l=" tag are described in the next paragraph. > > > >The "l=" tag is an informative declaration from the Sending Domain Owner > >to all Receivers about whether the sending Organizational Domain's users > >may participate or not in mailing lists. The "l=" tag does no convey > >policy from Sender to Receiver, and Receivers are not formally required > >nor recommended any course of action based on the content of the "l=" > >tag. Instead the "l=" tag only conveys dry, aseptic information from > >Sender to Receiver. Receivers are free to either disregard the contents > >of the "l=" tag altogether or apply local policies based on the > >information disclosed by the Sender by means of the "l=" tag. > > > >This approach basically outsources to the Receivers the problem of > >dealing --if at all, at the Receiver's discretion-- with the by-design > >DMARC false positives of mailing lists posts. As the default value for > >the "l=" tag is "dunno", this 'outsourcing' is an opt-in tunable knob > >which the Sender can enable or disable at will, and also a dry, aseptic > >information exchange which the Receiver can choose to either ignore or > >apply special local policies/checks/verifications on it. > > > > > >---- > > > > > >Counter-replies to possible objections: > > > > > >1. (Operative problem) There is a considerable already functional base of > >pre-standard DMARC installations on the field and this proposition of a > >new tag in the DNS RR for DMARC makes their lives hard. > > > > --> This proposition just adds a new tag to the DMARC RR in DNS, and > > > >that same thing has already happened when the DMARC draft was moved from > >pre-IETF track to the IETF track less than a month ago, when the new tag > >"fo=" was added to the DMARC RR in DNS apparently to none's objection. ( > >See Section 6.2, "General Record Format", > >http://www.dmarc.org/Diff_draft-dmarc-base-00-02_IETF-00.html ) > > > >--- > > > >2. (Semantic problem) There is a considerable already functional base of > >pre-standard DMARC installations on the field and this proposition > >changes the semantics of DMARC and therefore makes their lives hard. > > > > --> The "l=" tag is optional, and its default value is explicitly > > > >'undefined' (i.e., "dunno"). This means the semantics of a DMARC RR in > >DNS do not change unless the Sender explicitly deviates from default > >behaviour, and even then Receivers are free to disregard the additional > >information provided by the Sender by means of the "l=" tag. > > > >--- > > > >3. (Complexity problem) This propositions makes DMARC more complex, and > >complexity tends to deter adoption. > > > > --> The "l=" tag is optional, and it's default value changes nothing > > > >from the current DMARC status quo. Most senders can ignore the "l=" tag > >when configuring their DMARC RR in DNS, and most Receivers will just do > >whatever their DMARC plugin/milter does by default regarding the "l=" tag > >without giving it a second thought unless they feel the itch of the > >mailing list problem. > > > >--- > > > >4. (Uselessness problem) This proposition achieves nothing. > > > > --> True. It's not the intent of the "l=" tag to achieve anything nor > > > >to convey policy from Sender to Receiver. The "l=" tag merely conveys > >additional information from Sender to Receiver, and the Receiver is free > >to consume it as he wishes or to disregard it altogether. > > > >--- > > > >5. (There ain't a problem in the first place) This proposition is not > >needed. > > > > --> Yeah, right. > > > >---- > > > > > >Regards, > > > >J. Gomez > > > >_______________________________________________ > >dmarc mailing list > >dmarc@ietf.org > >https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From sklist@kitterman.com Fri Apr 12 15:13:58 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A2621F8BE2 for ; Fri, 12 Apr 2013 15:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_CHICKENPOX_16=0.6, MANGLED_WANT=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdfTOKDVBbi2 for ; Fri, 12 Apr 2013 15:13:57 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 395E321F8B13 for ; Fri, 12 Apr 2013 15:13:57 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id BA2FE20E40D2; Fri, 12 Apr 2013 18:13:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365804836; bh=YVhKoLj6sgqwow1mkARm8OWObUy+vIlluWqGl7TEkNY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ia8tWto0+owfQk1t0jr4rjRYmEfoSzsdoPLKOzhAlTQVGTq6l2ZocBPQljv3EAqpd ykf1uzecNrxaiSiO1uqftvjtN+WsVSUxNchka/ckMxQG/1/fsfwaVXTQXnqtdT28pC xoshlHqf7L1co+WD3VAluhu5ujBv6rS1shRm86g4= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 90AE220E40B0; Fri, 12 Apr 2013 18:13:56 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Apr 2013 18:13:50 -0400 Message-ID: <1437260.NQDOl4qKT7@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <20130411040946.9056.qmail@joyce.lan> <42eaf7e9-8952-41f0-9641-58dcf5c5e479@email.android.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 22:13:58 -0000 On Saturday, April 13, 2013 12:05:10 AM J. Gomez wrote: > On Friday, April 12, 2013 10:30 PM [GMT+1=CET], Scott Kitterman wrote: > > "J. Gomez" wrote: > > > On Friday, April 12, 2013 9:11 PM [GMT+1=CET], Scott Kitterman > > > > > > wrote: > > > > "Rolf E. Sonneveld" wrote: > > > > > On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote: > > > > > > It depends on the kind of error and on the implementation. > > > > > > > > > > Generally, > > > > > > > > > > > a temporary DNS error should result in a temp-fail of the > > > > > > message, > > > > > > > > > while a permanent DNS error should not. > > > > > > > > > > SPF leaves this open. Quoting 4408bis: > > > > > A "temperror" result means the SPF verifier encountered a > > > > > > > > > > transient (generally DNS) error while performing the check. > > > > > > > > > > Checking software can choose to accept or temporarily reject > > > > > > > > > > the message. > > > > > > > > > > > "Record not found" is not a temporary error. > > > > > > > > > > > > I'd say both of those points are true for both protocols. > > > > > > > > > > Unless I'm missing something obvious, an SPF temporary DNS error > > > > > reduces > > > > > the DMARC mechanism check to a DKIM-only check, correct? At > > > > > least: this > > > > > > > > > > is how I read the DMARC spec: > > > > > 4. Perform SPF validation checks. The results of this step > > > > > > > > > > are passed to the remainder of the algorithm and MUST > > > > > > > > > > include > > > > > > the > > > > > > > > domain name used to complete the SPF check if evaluation > > > > > > > > > > returned a "pass" result. > > > > > > > > > > and > > > > > > > > > > 5. Conduct identifier alignment checks. With authentication > > > > > > > > > > checks and policy discovery performed, the Mail Receiver > > > > > checks if Authenticated Identifiers fall into alignment > > > > > > > > > > as decribed in > > > > > Section 4 > > > > > > . > > > > > > > > If one or more of the Authenticated Identifiers align > > > > > with theRFC5322 .From > > > > > domain, the message is considered to pass > > > > > > > > > > the DMARC mechanism check. All other conditions > > > > > > > > > > (authentication failures, identifier mismatches) are > > > > > considered to be DMARC mechanism check failures. > > > > > > > > > > means: we have two things to check for: SPF and DKIM. If SPF > > > > > evaluation > > > > > > > > > > does not provide a 'pass' (i.e. when the outcome is one of > > > > > "None", "Neutral", "Fail", "SoftFail", "TempError" or > > > > > "PermError") we're left with only DKIM. > > > > > > > > > > As SPF allows for the include: mechanism, it is possible that > > > > > now and then DKIM and DMARC records can be retrieved from DNS, > > > > > while > > > > > > SPF > > > > > > > > records > > > > > (temporarily) can't. Suppose I'm using MessageLabs and I have an > > > > > include:spf.messagelabs.com in my SPF record, while my DNS > > > > > provides my DMARC p=reject record to any DNS client asking for > > > > > it and meanwhile the > > > > > > > > > > DNS servers of MessageLabs are under a DDoS, this may impact > > > > > delivery of > > > > > my mail (in the 5? percent of all cases where DKIM validation > > > > > fails [1]). > > > > > > > > > > Or am I misinterpreting DMARC? > > > > > > > > > > /rolf > > > > > > > > > > [1] http://www.ietf.org/iesg/implementation/report-rfc4871.txt > > > > > > > > It depends on which of the two options that RFC 4408 gives you've > > > > chosen to use. If you defer the message based on SPF temperror, > > > > then DMARC doesn't even come up. > > > > > > Allow me to quote Requirement #7 for DMARC: "Message disposition > > > requests via DMARC override those requested by any other public > > > mechanism." Which amounts to your reply does not apply, and Rolf's > > > question is still pertinent. > > > > > > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_tex > > > t=1 > > > > SPF temperror is a protocol result, not a message disposition > > request. It's a matter of local policy. > > No. DMARC requires to pass the results of the SPF-check to the "remainder of > the [DMARC] algorithm". If you take any action (whatever action) directly > on the results of the SPF-check which is different from the action of > passing said results to "the remainder of [DMARC] the algorithm", then you > are not DMARC-compliant. Period. So whatever the SPF-result is, you must go > straight after it to check "identifier alignment checks", and if in that > step the identifier is DKIM-aligned then you have a DMARC pass (and not a > SPF-temperror on which you can act, unless you are not checking DMARC at > all). [See Section 11.2.4 and 11.2.5] > > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 I think in the spirit of that requirement, it's quite reasonable to wait for a final disposition (wait for the temperror to resolve itself) before acting on that requirement. Also, before DMARC was submitted to the IETF, it was discussed and I had thought agreed that if the DMARC policy for a domain was none then that should mean DMARC policy should have no effect, not that DMARC and all other email authentication related policies should have no effect. I'm also not at all convinced that the requirement in the current draft is necessary or appropriate. If senders don't wan't receivers to reject mail based on SPF, all they have to do is not publish -all SPF records. There's no need to reach down from the DMARC layer to the SPF layer to override what it does. Scott K From jgomez@seryrich.com Fri Apr 12 15:19:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636DC21F8E8F for ; Fri, 12 Apr 2013 15:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2ImxPAEhCVu for ; Fri, 12 Apr 2013 15:19:36 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 907E221F8D33 for ; Fri, 12 Apr 2013 15:19:36 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 13 Apr 2013 00:19:35 +0200 Message-ID: <9A201BD8BF794909A448346A4BEF7D86@fgsr.local> From: "J. Gomez" To: References: Date: Sat, 13 Apr 2013 00:20:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 22:19:37 -0000 On Saturday, April 13, 2013 12:03 AM [GMT+1=3DCET], Michael Adkins = wrote: > You forgot > 6. Layering Violation > DMARC doesn't have a problem with mailing lists. DKIM and SPF have a > problem with mailing lists and trying to fix their problem in DMARC > is the wrong place. I'm sorry, but the posts I get from this "dmarc-ietf" mailing list are = SPF-by-itself "pass" (and could be DKIM-by-itself "pass" if the list = administrator wanted to DKIM-sign also). Only when DMARC enters the game = is it that I get DMARC "fail", because DMARC mandates "RFC5322.From = header alignment" which is not mandated in either SPF nor DKIM by = themselves. So SPF by itself has NO PROBLEM with mailing list. And DKIM by itself = has NO PROBLEM with mailing list. It is DMARC which has problems with = mailing lists. Regards, J. Gomez From prvs=78145f36b6=madkins@fb.com Fri Apr 12 15:33:48 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB2D21F8E69 for ; Fri, 12 Apr 2013 15:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-9Cv-1Pywv0 for ; Fri, 12 Apr 2013 15:33:47 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by ietfa.amsl.com (Postfix) with ESMTP id BA99021F8D94 for ; Fri, 12 Apr 2013 15:33:47 -0700 (PDT) Received: from pps.filterd (m0044008 [127.0.0.1]) by m0044008.ppops.net (8.14.5/8.14.5) with SMTP id r3CMWbt4031972; Fri, 12 Apr 2013 15:33:47 -0700 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=tVyyR9HJyxYsopBkllrS5NHT5He0CeS/QGq5cJkJ+Ss=; b=cXI5kdpmOYBdaDfsPEUYluAakiKfOlbCUjUStJ7bNpkzzkSkTWtpZxwgqU4Z3jdgHXCj ATz8LUz07d7Eh2gxY/r95/+i90aBmXeSfB37geLWvP7FAw1l9D4pnUml59juqFxd0OKk mdMAsD6hDPmUPDPVHFWO3YCYUhETtzOhiSk= Received: from prn1-cmdf-dc01-fw1-nat.corp.tfbnw.net (prn1-cmdf-dc01-fw1-nat.corp.tfbnw.net [173.252.71.129] (may be forged)) by mx0a-00082601.pphosted.com with ESMTP id 1bpf4paamv-11 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Apr 2013 15:33:47 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.5.232]) by PRN-CHUB01.TheFacebook.com ([fe80::d5cc:849:f520:db6b%12]) with mapi id 14.02.0328.011; Fri, 12 Apr 2013 15:31:15 -0700 From: Michael Adkins To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity Thread-Index: AQHON81x0jqwM8QHnkehjhfzBW6VDA== Date: Fri, 12 Apr 2013 22:31:14 +0000 Message-ID: In-Reply-To: <9A201BD8BF794909A448346A4BEF7D86@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.168.16.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <6FF89B2355B28F419CCCB59AF4C96DDF@fb.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-12_07:2013-04-12, 2013-04-12, 1970-01-01 signatures=0 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 22:33:48 -0000 The original authentication mechanisms no longer pass after transiting a mailing list. If either of them did, then it wouldn't be a problem, would it? On 4/12/13 3:20 PM, "J. Gomez" wrote: >On Saturday, April 13, 2013 12:03 AM [GMT+1=3DCET], Michael Adkins wrote: > >> You forgot >> 6. Layering Violation >> DMARC doesn't have a problem with mailing lists. DKIM and SPF have a >> problem with mailing lists and trying to fix their problem in DMARC >> is the wrong place. > >I'm sorry, but the posts I get from this "dmarc-ietf" mailing list are >SPF-by-itself "pass" (and could be DKIM-by-itself "pass" if the list >administrator wanted to DKIM-sign also). Only when DMARC enters the game >is it that I get DMARC "fail", because DMARC mandates "RFC5322.From >header alignment" which is not mandated in either SPF nor DKIM by >themselves. > >So SPF by itself has NO PROBLEM with mailing list. And DKIM by itself has >NO PROBLEM with mailing list. It is DMARC which has problems with mailing >lists. > >Regards, > >J. Gomez > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From sklist@kitterman.com Fri Apr 12 15:41:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F2621F8EE6 for ; Fri, 12 Apr 2013 15:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzbtY61mNq5B for ; Fri, 12 Apr 2013 15:41:38 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6B43521F85B3 for ; Fri, 12 Apr 2013 15:41:38 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E61EA20E40D2; Fri, 12 Apr 2013 18:41:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365806497; bh=UYuv+dX1viSI+ljG/Kkggl0ABkCAqeDMvjNWdoTFB0E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hGp7JQr8pMBpCUIfkrZpfo30nUORslEx/I0q+gXPRpzrnKLclhmBiQwHSPSe7hTKt d+gSzJj76OYFBk74vjIFWlpczXT3Mg0A4IczhCOjYGXyKsVqPza3atzxfCsRSDvpgi kgBlY67e8azIapg+ap39Sg1pfwKblzlFE2lD0+3c= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id C5A4820E40B0; Fri, 12 Apr 2013 18:41:37 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Apr 2013 18:41:37 -0400 Message-ID: <3010976.deRMyQJPGd@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 22:41:39 -0000 For email lists that retransmit mail using their own mail from (which is any list that is more than a simple expander) they will pass SPF just fine. The issue from a DMARC perspective is that typically there's no identity alignment between the mailing list's Mail From and the original messages Body From. That's not an SPF issue. SPF has nothing to do with what happens inside the body of the message. Scott K On Friday, April 12, 2013 10:31:14 PM Michael Adkins wrote: > The original authentication mechanisms no longer pass after transiting a > mailing list. If either of them did, then it wouldn't be a problem, would > it? > > On 4/12/13 3:20 PM, "J. Gomez" wrote: > >On Saturday, April 13, 2013 12:03 AM [GMT+1=CET], Michael Adkins wrote: > >> You forgot > >> 6. Layering Violation > >> DMARC doesn't have a problem with mailing lists. DKIM and SPF have a > >> problem with mailing lists and trying to fix their problem in DMARC > >> is the wrong place. > > > >I'm sorry, but the posts I get from this "dmarc-ietf" mailing list are > >SPF-by-itself "pass" (and could be DKIM-by-itself "pass" if the list > >administrator wanted to DKIM-sign also). Only when DMARC enters the game > >is it that I get DMARC "fail", because DMARC mandates "RFC5322.From > >header alignment" which is not mandated in either SPF nor DKIM by > >themselves. > > > >So SPF by itself has NO PROBLEM with mailing list. And DKIM by itself has > >NO PROBLEM with mailing list. It is DMARC which has problems with mailing > >lists. > > > >Regards, > > > >J. Gomez > > > >_______________________________________________ > >dmarc mailing list > >dmarc@ietf.org > >https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From johnl@iecc.com Fri Apr 12 15:55:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD30D21F8C3C for ; Fri, 12 Apr 2013 15:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.149 X-Spam-Level: X-Spam-Status: No, score=-111.149 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RauUji2lzgN8 for ; Fri, 12 Apr 2013 15:55:30 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E9B3421F8BD0 for ; Fri, 12 Apr 2013 15:55:29 -0700 (PDT) Received: (qmail 369 invoked from network); 12 Apr 2013 22:55:29 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Apr 2013 22:55:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516890e1.xn--btvx9d.k1304; i=johnl@user.iecc.com; bh=v1iX0Eup4BuC4SxOcqIbw3LeP+2rTLAJ32lab0yIzrI=; b=VAowH+F/R+s9/SeuJ+ZGEsOnw2mrO71G3u+48G61LfSJB0VGXJ2fkcjuyH6y+opxQvRSYfKdmyYHcs6jm6YCZhb8PIr4hFnZBhGEko7uoCUxtd0l+eB7FMIu5y/D+9tX10XJKqhLNDNsop8ah3R/DHbdWV0UxpGlTQux4tZNACQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516890e1.xn--btvx9d.k1304; olt=johnl@user.iecc.com; bh=v1iX0Eup4BuC4SxOcqIbw3LeP+2rTLAJ32lab0yIzrI=; b=Qv4n3JFAstgJE5WBB7indq46DVLymUhhTyrCvICtTvLfbVAOHGy8XbMhmSL/LD7vIzUjuB0xbcUyXWrw6FapMNPjFe/qMqR7OQ7tYchmB5pPw3M3EbvCqVlEUAQag0HCV1ypgJd28AIi0RYZ+bWO+sEAK8sjxqeTftMDdOdyTDA= Date: 12 Apr 2013 22:55:06 -0000 Message-ID: <20130412225506.2589.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <1406296.sgmforF3Ss@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 22:55:30 -0000 In article <1406296.sgmforF3Ss@scott-latitude-e6320> you write: >What problem does SPF have with mailing lists (hint: there aren't any)? If you consider a forwarder that forwards to multiple addresses a very simple mailing list, you get the usual forwarder issues. In case anyone (not Scott) was wondering, this is not DMARC's problem. From sklist@kitterman.com Fri Apr 12 16:26:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEE921F8EF7 for ; Fri, 12 Apr 2013 16:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MipaFsvCA0wN for ; Fri, 12 Apr 2013 16:26:50 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 40D6821F8EC9 for ; Fri, 12 Apr 2013 16:26:50 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id AF6FA20E40D2; Fri, 12 Apr 2013 19:26:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365809209; bh=vex+qRIibuzx5efmHJOojwRjz0JXGFhL0kgHkCB+uvw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=T4IwxgnvBXynTZBGmhSj5F9HimioKOghv8+glhY63lmYY0P2BXxDQlSKCl7BL+byb oSzUIVGJzRtCQOZ7NGfq2pEJOdOU+CPDnlFj/XVlIeLuHsiXE/bnDPkYRt91+SOl/p TLWCocoNPKpAJqJdIbFp5jOH4vGx50LHNZaKDrec= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 9028820E40B0; Fri, 12 Apr 2013 19:26:49 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 12 Apr 2013 19:26:48 -0400 Message-ID: <2219814.V8RhjUlGEg@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <20130412225506.2589.qmail@joyce.lan> References: <20130412225506.2589.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 23:26:51 -0000 On Friday, April 12, 2013 10:55:06 PM John Levine wrote: > In article <1406296.sgmforF3Ss@scott-latitude-e6320> you write: > >What problem does SPF have with mailing lists (hint: there aren't any)? > > If you consider a forwarder that forwards to multiple addresses a very > simple mailing list, you get the usual forwarder issues. > > In case anyone (not Scott) was wondering, this is not DMARC's problem. For the subset of lists that are essentially operating as forwarders, this is correct. The good news is that the original DKIM signature generally has a high survival rate with this class of lists. For transparent forwarding (including cases where it's expanded as above) SPF will tend to fail and DKIM will tend to succeed, so DMARC should mostly work OK. This issue with mailing lists and DMARC is really confined to the case of lists that modify the message in transit (generally with a new Mail From) so that the original DKIM signature no longer validates and the SPF check will pass, but does not have the identifier alignment that DMARC wants. Just as the well known SPF forwarding "problem" is not DMARC's problem (as John says), DMARC checks failing due to this lack of alignment is not SPF's problem either. Scott K From superuser@gmail.com Fri Apr 12 16:48:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFE821F8F56 for ; Fri, 12 Apr 2013 16:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DknLY1m0B3rH for ; Fri, 12 Apr 2013 16:48:02 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 030AF21F8E8F for ; Fri, 12 Apr 2013 16:48:01 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hm14so76064wib.15 for ; Fri, 12 Apr 2013 16:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Je3jxXY/SmoQ51EriwZ0XjhHLgu/UH+xmDPEjQcajoM=; b=aFtLu6l8sA5jC+KZAKj+Qu+e+SUTx/ZkOwdfm/RBeE6mgZJ79H4irzkmocvrpbP9XW 7HLA+EdZx1SaHogIwkdKiTjuAWMVcnJd3JD3XKDF6iexXUQpEXwPhJ1SAWWkCEaHtF56 HOPwmGh79mAnYXouBJ0HTLZExPwyNxV5LkfRO3nKHkkbKJmw5351xdaa2omHh3/Ib4Dj OjHw+fPsVGWBUJuYBJXN1bMGh0Rj+8Y8PgIstwFK4QerMwRQiHCSmJlJmKAxMhB9oBFF hF3D1+SjPrWxta/qTfVVv1y5rslKY23RwN5iOEIM25biyaKq2EPd10mwcVtdLpJ+Qa93 i+bg== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr707281wix.20.1365810481184; Fri, 12 Apr 2013 16:48:01 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Fri, 12 Apr 2013 16:48:00 -0700 (PDT) Date: Fri, 12 Apr 2013 16:48:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f46d041825388fc68904da328869 Subject: [dmarc-ietf] On proposing extensions X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 12 Apr 2013 23:48:02 -0000 --f46d041825388fc68904da328869 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, Just a reminder that, while it's certainly all well and good to identify and discuss proposed extensions, fixes, improvements, etc., to the base document, we're still developing a charter that will decide what path that document will follow through publication, and how extensions and changes will be handled. So this list is the right place to have those discussions and record opinions, but it'll be a little while yet before we can actually act on any of the decisions thus made. (The exceptions, of course, are simple prose corrections or typos that don't change the meaning of any of the base draft.) Carry on, -MSK --f46d041825388fc68904da328869 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

Just a reminder that, wh= ile it's certainly all well and good to identify and discuss proposed e= xtensions, fixes, improvements, etc., to the base document, we're still= developing a charter that will decide what path that document will follow = through publication, and how extensions and changes will be handled.=A0 So = this list is the right place to have those discussions and record opinions,= but it'll be a little while yet before we can actually act on any of t= he decisions thus made.

(The exceptions, of course, are simple prose corrections or typos= that don't change the meaning of any of the base draft.)

= Carry on,

-MSK
--f46d041825388fc68904da328869-- From jgomez@seryrich.com Sat Apr 13 02:37:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B135921F8314 for ; Sat, 13 Apr 2013 02:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HS_INDEX_PARAM=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqv4XO1NCmKB for ; Sat, 13 Apr 2013 02:37:39 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 83B4021F841C for ; Sat, 13 Apr 2013 02:37:38 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 13 Apr 2013 11:37:36 +0200 Message-ID: <626C7E5D954946F687BD03F890B0214D@fgsr.local> From: "J. Gomez" To: References: <20130411040946.9056.qmail@joyce.lan><42eaf7e9-8952-41f0-9641-58dcf5c5e479@email.android.com> <1437260.NQDOl4qKT7@scott-latitude-e6320> Date: Sat, 13 Apr 2013 11:38:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Apr 2013 09:37:40 -0000 On Saturday, April 13, 2013 12:13 AM [GMT+1=3DCET], Scott Kitterman = wrote: > On Saturday, April 13, 2013 12:05:10 AM J. Gomez wrote: > > On Friday, April 12, 2013 10:30 PM [GMT+1=3DCET], Scott Kitterman = wrote:=20 > > > "J. Gomez" wrote: > > > > On Friday, April 12, 2013 9:11 PM [GMT+1=3DCET], Scott Kitterman > > > > > It depends on which of the two options that RFC 4408 gives > > > > > you've chosen to use. If you defer the message based on SPF > > > > > temperror, then DMARC doesn't even come up. > > > >=20 > > > > Allow me to quote Requirement #7 for DMARC: "Message disposition > > > > requests via DMARC override those requested by any other public > > > > mechanism." Which amounts to your reply does not apply, and > > > > Rolf's question is still pertinent. > > > >=20 > > > > = https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_tex > > > > t=3D1 > > >=20 > > > SPF temperror is a protocol result, not a message disposition > > > request. It's a matter of local policy. > >=20 > > No. DMARC requires to pass the results of the SPF-check to the > > "remainder of the [DMARC] algorithm". If you take any action > > (whatever action) directly on the results of the SPF-check which is > > different from the action of passing said results to "the remainder > > of [DMARC] the algorithm", then you are not DMARC-compliant. > > Period. So whatever the SPF-result is, you must go straight after > > it to check "identifier alignment checks", and if in that step the > > identifier is DKIM-aligned then you have a DMARC pass (and not a > > SPF-temperror on which you can act, unless you are not checking > > DMARC at all). [See Section 11.2.4 and 11.2.5]=20 > >=20 > > = https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D1 >=20 > I think in the spirit of that requirement, it's quite reasonable to > wait for a final disposition (wait for the temperror to resolve > itself) before acting on that requirement. Yes, you can wait for the SPF-temperror to resolve itself, but then you = are not checking SPF in the realm of DMARC, i.e. you are not checking = for DMARC proper (because that is not what the DMARC algorithm dictates) = but checking SPF-by-itself and applying local policies to the results of = those checks of SPF-by-itself. > Also, before DMARC was submitted to the IETF, it was discussed and I > had thought agreed that if the DMARC policy for a domain was none > then that should mean DMARC policy should have no effect, not that > DMARC and all other email authentication related policies should have > no effect.=20 In DMARC "p=3Dnone" is not 'undeclared policy' but 'apply no policy', = which is not the same. So if the DMARC check fails and there is a policy = of "p=3Dnone" then I think you should not override the DMARC request to = 'apply no policy' with any other public mechanism's requested policy, as = per Requirement #7 for DMARC. And if the DMARC check passes but you also got a SPF-temperror when = checking SPF in the realm of DMARC, I don't think you can defer the = message as per the DMARC-algorithm itself (but you could defer it as per = local policies outside of the scope of DMARC processing, to be applied = only after DMARC processing has ended or before DMARC processing has = begun). This case is problematic because DMARC only states policy for = DMARC-fail cases, not for DMARC-pass cases. DMARC allows you to = post-process the message with other mechanisms after the message exists = the DMARC algorithm [*], and I guess you can in that stage defer it = until the SPF-temperror solves itself, but you should not make such a = message deferral inside the DMARC algorithm processing (ie., inside of = the DMARC plugin/milter). [*] DMARC allows to post-process a message with other mechanisms after = the message exists the DMARC processing, but does not allow to apply = policies --if any-- stated by any other PUBLIC mechanism. Therefore, you = can post-process a message with other PUBLIC mechanisms after DMARC = processing, but you cannot apply any discovered policy from those other = PUBLIC mechanisms, you can only apply local policies based on the = results from those other PUBLIC mechanisms. I.e, you cannot reject a = message based on SPF "-all" after DMARC processing or while DMARC = processing, because that is a policy in a PUBLIC mechanism other than = DMARC, but you could defer based on SPF-temperror after and only after = DMARC processing has ended, because that would be a local policy in the = scope of DMARC post-processing. Regards,=20 J. Gomez From vesely@tana.it Sat Apr 13 04:15:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061CF21F86CE for ; Sat, 13 Apr 2013 04:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.159 X-Spam-Level: X-Spam-Status: No, score=-4.159 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rqDRh9b9bCD for ; Sat, 13 Apr 2013 04:15:50 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 961E721F86AD for ; Sat, 13 Apr 2013 04:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365851748; bh=BawpxDyLLwkFKgkguoOrnlyC/dNIF1I3HxvvBjKq2jc=; l=1682; h=Date:From:To:References:In-Reply-To; b=jIUKs374WQXZoJ3S2L1ONEjjKdcRre9LzR0h9lMRSj+ZJ0VAaXsZq+iefFlTYbXH7 lWXdRgIiLrHvWZtpCIydjF+jQTDBRX/Ij/XVrwbgE3FK6Edozr/ZrvmiaW2qXjTfkl 5zzwSfxycU2d6pvfIBniQ0W+E4fgiiOLs0QwnT/g= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sat, 13 Apr 2013 13:15:48 +0200 id 00000000005DC039.0000000051693E64.00004929 Message-ID: <51693E64.2020308@tana.it> Date: Sat, 13 Apr 2013 13:15:48 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> <51681D07.1030006@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Apr 2013 11:15:52 -0000 On Fri 12/Apr/2013 18:28:31 +0200 Murray S. Kucherawy wrote: > On Fri, Apr 12, 2013 at 7:41 AM, Alessandro Vesely wrote: > >> My reading of the spec is not deep, but glancing at Section 11.2 I >> find no step where mailing list heuristics come to play. > > Correct. They belong to the operators, not to the specification. If applications are coded according to specifications, what should operators tweak in order to apply heuristics? A challenge here is that there have to be databases of messages and domains on which to operate. While it sounds clumsy to maintain one DB for DMARC, one for greylisting, one for FBL, ..., customizing SQL statements makes applications difficult to install, so it sounds daunting to integrate all operations on a single DB. Neither we want to specify APIs, since all of that stuff is going to be hosted on existing MTAs, which dictate the architecture, the programming model, and so forth. Nevertheless, because of its stance at integrating DKIM, SPF, and possibly more, DMARC has a chance to inspire implementations that take the lead in establishing a data model that other mail filtering utilities may want to adapt to. >> Feedback and cohesive integration with SPF are new tasks, not new >> info. > > I'm afraid I don't know what that means. > What's changed since 2008 to change either the problem space or the > solution space? The problem seems to be tackled differently, except for the policy part. And I see that "a mechanism for mitigating the effect of failures of DMARC policy when a message transits a mailing list" is on the todo list. A most welcome change w.r.t. 2008 :-) From vesely@tana.it Sat Apr 13 06:23:57 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3912621F853A for ; Sat, 13 Apr 2013 06:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puRLVI9SO5QD for ; Sat, 13 Apr 2013 06:23:56 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9A321F84A6 for ; Sat, 13 Apr 2013 06:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1365859435; bh=vbUCsuqcERHAYqDhP9MdoVL+wz2QwRUxfD/2HI/9Zqs=; l=1333; h=Date:From:To:References:In-Reply-To; b=KcAuz5o06KmxBNAIm1goB2QYibfU7RCCB8f8siWllFNDNJX4W6D5g+uWG7Vp7YFTX MrGgECt97iHVdnbDKWTDaktn0gYNiQIffctoG2iAbprflo2NVGj8I3By6gIFCDrJMp m/76yyNBzpL6ifhwEznUo1QM2AlyimDhRFcGosQ8= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sat, 13 Apr 2013 15:23:55 +0200 id 00000000005DC035.0000000051695C6B.00001769 Message-ID: <51695C6B.9020503@tana.it> Date: Sat, 13 Apr 2013 15:23:55 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <9A201BD8BF794909A448346A4BEF7D86@fgsr.local> In-Reply-To: <9A201BD8BF794909A448346A4BEF7D86@fgsr.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Apr 2013 13:23:57 -0000 On Sat 13/Apr/2013 00:20:26 +0200 J. Gomez wrote: > On Saturday, April 13, 2013 12:03 AM [GMT+1=CET], Michael Adkins wrote: > >> DMARC doesn't have a problem with mailing lists. DKIM and SPF have a >> problem with mailing lists and trying to fix their problem in DMARC >> is the wrong place. > > I'm sorry, but the posts I get from this "dmarc-ietf" mailing list > are SPF-by-itself "pass" (and could be DKIM-by-itself "pass" if the > list administrator wanted to DKIM-sign also). Only when DMARC > enters the game is it that I get DMARC "fail", because DMARC > mandates "RFC5322.From header alignment" which is not mandated in > either SPF nor DKIM by themselves. As a purely syntactical exercise, let me try and rewrite the last paragraph using the syntax of the A-R header field: I'm sorry, but the posts I get from this "dmarc-ietf" mailing list have spf=pass (and could have dkim=pass if the list administrator wanted to DKIM-sign also). Only when DMARC enters the game is it that I get dmarc=fail, because DMARC mandates header.from alignment which is not mandated in either SPF nor DKIM by themselves. Nice eh? IMHO, a DKIM-Signature by the MLM would help when the post is transparently forwarded to some account different from from the subscribed address. In that case one gets spf=fail. From superuser@gmail.com Sat Apr 13 08:08:25 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D980221F86D2 for ; Sat, 13 Apr 2013 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R01eyVCnPd3j for ; Sat, 13 Apr 2013 08:08:23 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 429CA21F84DC for ; Sat, 13 Apr 2013 08:08:23 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id m6so396345wiv.12 for ; Sat, 13 Apr 2013 08:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jfWP2qIRol5WMTODM0S8w8BgesfwfSEeLOfcl3PTW+4=; b=mI6A7XLE6TFBxnWH0JUmDgQ3DXYpW1OUA1aWUxbl4f8ZX/kR/hE9rrdtULEWdzByQp uKbuFIkM+Yp3I7/2XZKbj0OS6foB5rJuYPWQHyLaC/LsFnW00V6vuH9wbM6Xr1hS89fW l7h3skJW25nYiKCRiwpaut39F+NcD3rsE7NiiOhRLHx5/uMQ5rrz4DyKKckim7I11sfE VuD0c2NeNxfiUrmIDvgtsyzaE7nGTVRBuJfymL8crrJ8aAFlTgegYZ3eUpBC0Ivk0fd0 BujPcZDo4iq26iWLlalDNXsJLR9FlDrj7CPkccZPs0YNcrfg3fjo5nH9vvS4RpPbWygJ Uunw== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr3450035wiz.14.1365865697854; Sat, 13 Apr 2013 08:08:17 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sat, 13 Apr 2013 08:08:17 -0700 (PDT) In-Reply-To: <51693E64.2020308@tana.it> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> <51681D07.1030006@tana.it> <51693E64.2020308@tana.it> Date: Sat, 13 Apr 2013 08:08:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d04427194bb4a3904da3f6307 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 13 Apr 2013 15:08:25 -0000 --f46d04427194bb4a3904da3f6307 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 13, 2013 at 4:15 AM, Alessandro Vesely wrote: > > Correct. They belong to the operators, not to the specification. > > If applications are coded according to specifications, what should > operators tweak in order to apply heuristics? > Anything they want, based on local operational needs and capabilities. DMARC hands a result to the operator; what it does with that result is its own business. > > A challenge here is that there have to be databases of messages and > domains on which to operate. While it sounds clumsy to maintain one > DB for DMARC, one for greylisting, one for FBL, ..., customizing SQL > statements makes applications difficult to install, so it sounds > daunting to integrate all operations on a single DB. Neither we want > to specify APIs, since all of that stuff is going to be hosted on > existing MTAs, which dictate the architecture, the programming model, > and so forth. > > Nevertheless, because of its stance at integrating DKIM, SPF, and > possibly more, DMARC has a chance to inspire implementations that take > the lead in establishing a data model that other mail filtering > utilities may want to adapt to. > Sure, but none of that belongs in a protocol document. > The problem seems to be tackled differently, except for the policy > part. And I see that "a mechanism for mitigating the effect of > failures of DMARC policy when a message transits a mailing list" is on > the todo list. A most welcome change w.r.t. 2008 :-) > You'll have to explain how it's tackled differently in protocol, because I can't think of what you might be referring to here. The charter also says if that turns into a rathole that produces nothing, it will be abandoned. -MSK --f46d04427194bb4a3904da3f6307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 13, 2013 at 4:15 AM, Alessandro Vesely <vesely@t= ana.it> wrote:
> Correct. =A0They belong to the operator= s, not to the specification.

If applications are coded according to specifications, what should operators tweak in order to apply heuristics?

Anything they want, based on local operational needs and capabilitie= s. DMARC hands a result to the operator; what it does with that result is i= ts own business.
=A0

A challenge here is that there have to be databases of messages and
domains on which to operate. =A0While it sounds clumsy to maintain one
DB for DMARC, one for greylisting, one for FBL, ..., customizing SQL
statements makes applications difficult to install, so it sounds
daunting to integrate all operations on a single DB. =A0Neither we want
to specify APIs, since all of that stuff is going to be hosted on
existing MTAs, which dictate the architecture, the programming model,
and so forth.

Nevertheless, because of its stance at integrating DKIM, SPF, and
possibly more, DMARC has a chance to inspire implementations that take
the lead in establishing a data model that other mail filtering
utilities may want to adapt to.

Sure, b= ut none of that belongs in a protocol document.
=A0
The problem seems to be tackled differently, except for t= he policy
part. =A0And I see that "a mechanism for mitigating the effect of
failures of DMARC policy when a message transits a mailing list" is on=
the todo list. =A0A most welcome change w.r.t. 2008 :-)

You'll have to explain how it's tackled differentl= y in protocol, because I can't think of what you might be referring to = here.

The charter also says if that turns into a rathole that prod= uces nothing, it will be abandoned.

-MSK
<= br>
--f46d04427194bb4a3904da3f6307-- From tim@eudaemon.net Sun Apr 14 17:55:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E1B21F8920 for ; Sun, 14 Apr 2013 17:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhVyGrgHDmXN for ; Sun, 14 Apr 2013 17:55:05 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1135821F868B for ; Sun, 14 Apr 2013 17:55:05 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id E5421CB46; Sun, 14 Apr 2013 20:55:41 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Tim Draegen X-Priority: 3 In-Reply-To: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> Date: Sun, 14 Apr 2013 20:55:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23CFA3411ADA4D259AB72FCA88F50C9F@fgsr.local> To: J. Gomez X-Mailer: Apple Mail (2.1503) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 00:55:07 -0000 On Apr 10, 2013, at 4:31 PM, J. Gomez wrote: > I think there is minor contradiction in the draft specification of = DMARC, > = https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=3D= 1 >=20 > Requirement #8 reads: >=20 > Senders should be able to specify a percentage of their messages =20 > to which their policies should be applied, with the rest =20 > unaffected, in order to experiment and to understand and =20 > minimize deployment risk. Nice catch! After catching up on this thread, maybe 2 ways forward: 1. I'm not sure if this is possible, but it would be nice to strike the = "with the rest unaffected" part and drop in a footnote explaining why it = was done. 2. Maybe leave this as is, and put in a footnote after "with the rest = unaffected" to reference how the requirement is met in section 7.1. =3D- Tim From tim@eudaemon.net Sun Apr 14 18:36:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EA721F9298 for ; Sun, 14 Apr 2013 18:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MANGLED_WANT=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kog4w0QsfDPN for ; Sun, 14 Apr 2013 18:36:19 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id CCADE21F91AB for ; Sun, 14 Apr 2013 18:36:19 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id B2237CB46 for ; Sun, 14 Apr 2013 21:36:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Draegen In-Reply-To: <1437260.NQDOl4qKT7@scott-latitude-e6320> Date: Sun, 14 Apr 2013 21:36:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7ACEB607-1498-49CF-B0AA-A1C85E548C1C@eudaemon.net> References: <20130411040946.9056.qmail@joyce.lan> <42eaf7e9-8952-41f0-9641-58dcf5c5e479@email.android.com> <1437260.NQDOl4qKT7@scott-latitude-e6320> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 01:36:20 -0000 On Apr 12, 2013, at 6:13 PM, Scott Kitterman = wrote: > I think in the spirit of that requirement, it's quite reasonable to = wait for a=20 > final disposition (wait for the temperror to resolve itself) before = acting on=20 > that requirement. As an implementor, I'd treat temporary errors as exceptions to normal = processing, and either reply with "Try again later" or, if a message has = already been accepted, queue until some timeout occurs. If anything = times out (SPF, DKIM, or DMARC-related), I'd flag these failures in = related XML/Forensic feedback as TempErrors for the domain owner to = track down (with "can't retrieve DMARC record" being a possible security = hole if the resulting behavior is "fail open"). IMO, Rolf suggested that mentioning this in a BCP document would be nice = to connect the dots for people that are deploying on top of DNS. +1 to = that idea. Finally, Rolf put up the question about "SPF produces temp-err, which = means DMARC-verdict then becomes solely based on DKIM result, right?". = =46rom my narrow perspective as a DMARC receiver, I'm searching for a = reliable way to assert "NOT PASS" so I can enforce policy without = incurring support burden. If DKIM produces a passing DMARC-verdict, = then the value of resolving an SPF temperr goes way down. FWIW. > Also, before DMARC was submitted to the IETF, it was discussed and I = had=20 > thought agreed that if the DMARC policy for a domain was none then = that should=20 > mean DMARC policy should have no effect, not that DMARC and all other = email=20 > authentication related policies should have no effect. The context then was "if I publish a DMARC record with p=3Dnone, will I = be causing a change in receiver behave?". Specifically, this was around = having an SPF "-all" policy in place causing rejections that might be = modified if a DMARC record was found. FTR, consensus was to allow people to publish "p=3Dnone" to collect = feedback without impacting existing email behavior. > I'm also not at all convinced that the requirement in the current = draft is=20 > necessary or appropriate. If senders don't wan't receivers to reject = mail=20 > based on SPF, all they have to do is not publish -all SPF records. = There's no=20 > need to reach down from the DMARC layer to the SPF layer to override = what it=20 > does. How about: I want receivers that are not doing DMARC to continue to = reject email based on my "-all" policy, but I want receivers that *are* = doing DMARC to use DMARC's policy mechanism instead? Maintain existing = functionality but take advantage of newness if its available. Clunkily = worded, eh! =3D- Tim From sklist@kitterman.com Sun Apr 14 19:00:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7F21F85ED for ; Sun, 14 Apr 2013 19:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.968 X-Spam-Level: X-Spam-Status: No, score=-0.968 tagged_above=-999 required=5 tests=[AWL=-1.269, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MANGLED_WANT=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZQZ8dUtpDyd for ; Sun, 14 Apr 2013 19:00:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB9721F8488 for ; Sun, 14 Apr 2013 19:00:35 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 24C5520E410C; Sun, 14 Apr 2013 22:00:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365991234; bh=b16NiLP1WTp76/8ELFe9DYYwc3ajFusWKa5Nq9O8XKc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=n8Rp464SQgYWGLma+xyQAqIvDxJUIJ04INWqGoQYwPknXgWYNAmjobxCcTtVpF4c9 ZcWmeEEaIci7dIKxPbNEE5kvzlv0uNhe7B66beqaWrOe72fpFwzKiVsJyOZpMN6TUx dhdVkgCNXzrV9W4Rj3IPOqtVQTsZBZ+PNRwX6O9g= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 052B920E401D; Sun, 14 Apr 2013 22:00:33 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 14 Apr 2013 22:00:30 -0400 Message-ID: <1569108.iPfjjv1XD4@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <7ACEB607-1498-49CF-B0AA-A1C85E548C1C@eudaemon.net> References: <20130411040946.9056.qmail@joyce.lan> <1437260.NQDOl4qKT7@scott-latitude-e6320> <7ACEB607-1498-49CF-B0AA-A1C85E548C1C@eudaemon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 02:00:36 -0000 On Sunday, April 14, 2013 09:36:28 PM Tim Draegen wrote: > On Apr 12, 2013, at 6:13 PM, Scott Kitterman wrote: > > I think in the spirit of that requirement, it's quite reasonable to wait > > for a final disposition (wait for the temperror to resolve itself) before > > acting on that requirement. > > As an implementor, I'd treat temporary errors as exceptions to normal > processing, and either reply with "Try again later" or, if a message has > already been accepted, queue until some timeout occurs. If anything times > out (SPF, DKIM, or DMARC-related), I'd flag these failures in related > XML/Forensic feedback as TempErrors for the domain owner to track down > (with "can't retrieve DMARC record" being a possible security hole if the > resulting behavior is "fail open"). > > IMO, Rolf suggested that mentioning this in a BCP document would be nice to > connect the dots for people that are deploying on top of DNS. +1 to that > idea. > > Finally, Rolf put up the question about "SPF produces temp-err, which means > DMARC-verdict then becomes solely based on DKIM result, right?". From my > narrow perspective as a DMARC receiver, I'm searching for a reliable way to > assert "NOT PASS" so I can enforce policy without incurring support burden. > If DKIM produces a passing DMARC-verdict, then the value of resolving an > SPF temperr goes way down. FWIW. > > Also, before DMARC was submitted to the IETF, it was discussed and I had > > thought agreed that if the DMARC policy for a domain was none then that > > should mean DMARC policy should have no effect, not that DMARC and all > > other email authentication related policies should have no effect. > > The context then was "if I publish a DMARC record with p=none, will I be > causing a change in receiver behave?". Specifically, this was around > having an SPF "-all" policy in place causing rejections that might be > modified if a DMARC record was found. > > FTR, consensus was to allow people to publish "p=none" to collect feedback > without impacting existing email behavior. > > I'm also not at all convinced that the requirement in the current draft is > > necessary or appropriate. If senders don't wan't receivers to reject mail > > based on SPF, all they have to do is not publish -all SPF records. > > There's no need to reach down from the DMARC layer to the SPF layer to > > override what it does. > > How about: I want receivers that are not doing DMARC to continue to reject > email based on my "-all" policy, but I want receivers that *are* doing > DMARC to use DMARC's policy mechanism instead? Maintain existing > functionality but take advantage of newness if its available. Clunkily > worded, eh! I'm not certain what the best answer is, but I think that at least getting the spec to say you can publish p=none and not affect existing behavior is very important. Unfortunately, there's no venue to discuss updating the base spec. Scott K From tim@eudaemon.net Sun Apr 14 19:08:34 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AC421F8F44 for ; Sun, 14 Apr 2013 19:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=1.074, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMNt5I6A9vud for ; Sun, 14 Apr 2013 19:08:33 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2B90E21F8B0C for ; Sun, 14 Apr 2013 19:08:33 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 57ED7CB46; Sun, 14 Apr 2013 22:09:10 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Tim Draegen X-Priority: 3 In-Reply-To: Date: Sun, 14 Apr 2013 22:08:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: J. Gomez X-Mailer: Apple Mail (2.1503) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 02:08:34 -0000 On Apr 12, 2013, at 5:35 PM, J. Gomez wrote: > 4. (Uselessness problem) This proposition achieves nothing. >=20 > --> True. It's not the intent of the "l=3D" tag to achieve anything = nor to convey policy from Sender to Receiver. The "l=3D" tag merely = conveys additional information from Sender to Receiver, and the Receiver = is free to consume it as he wishes or to disregard it altogether. This here. If the tag doesn't achieve anything and could very well be = wrong ('cause there is no measurable impact to getting it right), it'll = just add noise to a receiver's decision making, and therefore {all of = your other counter-arguments}. To game this out, *IF* this tag existed and was accurately used, as a = receiver I'd still have to figure out what sources are mailing lists in = order to make the extra "l=3D{yes,no,dunno}" tag useful. Let's say I = have perfect mailing list knowledge, what then am I supposed to do with = email coming through a mailing list from a domain with the "l=3Dno" tag? = If the answer is "nothing", then why is this tag even there for me to = look at? I guess I'm left with "How does this make anything better?" IMO Michael Adkins wrote it best: > 7. Operational Issue > This problem is better solved by making data about legitimate mailing > lists publicially available so everyone can apply local policy = overrides > consistently. I'd add an additional option: "patch mailing list software to play = better with DMARC", but I'm only offering this up with the understanding = that upgrading stuff that everyone uses all the time is a slow and = painful process, and really doesn't have much to do with = DMARC-the-protocol. -=3D Tim From tim@eudaemon.net Sun Apr 14 19:59:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AD221F8D94 for ; Sun, 14 Apr 2013 19:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSv1aSULoqjx for ; Sun, 14 Apr 2013 19:59:05 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF8821F8C9B for ; Sun, 14 Apr 2013 19:59:05 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id C0A2BCB46 for ; Sun, 14 Apr 2013 22:59:42 -0400 (EDT) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_2ACD7F01-29ED-4C46-A63A-D60BE5D12CF3" Message-Id: <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Sun, 14 Apr 2013 22:59:16 -0400 References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> To: dmarc@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1503) Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 02:59:06 -0000 --Apple-Mail=_2ACD7F01-29ED-4C46-A63A-D60BE5D12CF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 11, 2013, at 9:20 AM, Murray S. Kucherawy = wrote: > Existing implementations apply their own heuristics to relax for = traffic they think is a list. DMARC as it stands provides for that = option and includes it as a report parameter. I really think we should = stop there. I'd like to second this view, but add my understanding. DMARC as a = specification can't fix "the mailing list problem", but has a place to = drop in "hey I thought this came from a mailing list so I didn't apply = your policy". In other words, fixing the mailing list problem is not = something DMARC does, but at least it can point out an area that needs = work. Alessandro Vesely mentioned something about "a mechanism for mitigating = the effect of failures of DMARC policy when a message transits a mailing = list", but I see this as more of a spin off effort to: 1. create a standardized way for mailing lists to identify themselves, 2. include some sort of authentication, 3. write up a specification to tie it all together. I'm not sure the above would matter to the installed base of mailing = list authors, operators, and users, though. It would be useful for some = set of people that want to the right thing but don't know what right is. = Updating all the rest might be impossible or take a long time. In the = meantime, though, receivers are getting email through mailing lists from = domains that want policy applied, and yet would lead to bad end-user = experiences. Bad user experience is currently mitigated by through a = local decision to apply an "override" reason of "mailing_list". =46rom = DMARC's PoV.... done! I wish there was an association of mailing list operators to squeeze to = get the spin off effort done. Aside from that, I agree with the = expressed sentiment "need more tools and patches to fix stuff", 'cause = IMO, fixing the mailing list problem is similar to "fixing the problem = of unauthenticated email"... requiring a long, multi-year commitment = that relies on strangers to determine success. =3D- Tim --Apple-Mail=_2ACD7F01-29ED-4C46-A63A-D60BE5D12CF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 superuser@gmail.com> = wrote:
Existing implementations apply their = own heuristics to relax for traffic they think is a list.  DMARC as = it stands provides for that option and includes it as a report = parameter.  I really think we should stop = there.

I'd like to second this view, = but add my understanding.  DMARC as a specification can't fix "the = mailing list problem", but has a place to drop in "hey I thought this = came from a mailing list so I didn't apply your policy".  In other = words, fixing the mailing list problem is not something DMARC does, but = at least it can point out an area that needs = work.

Alessandro Vesely mentioned something = about "a mechanism for mitigating the effect of failures of DMARC = policy when a message transits a mailing list", but I see this as more = of a spin off effort to:

1. create a = standardized way for mailing lists to identify themselves,
2. = include some sort of authentication,
3. write up a = specification to tie it all together.

I'm not = sure the above would matter to the installed base of mailing list = authors, operators, and users, though.  It would be useful for some = set of people that want to the right thing but don't know what right is. =  Updating all the rest might be impossible or take a long time. =  In the meantime, though, receivers are getting email through = mailing lists from domains that want policy applied, and yet would lead = to bad end-user experiences.  Bad user experience is currently = mitigated by through a local decision to apply an "override" reason of = "mailing_list".  =46rom DMARC's PoV.... = done!

I wish there was an association of = mailing list operators to squeeze to get the spin off effort done. =  Aside from that, I agree with the expressed sentiment "need more = tools and patches to fix stuff", 'cause IMO, fixing the mailing list = problem is similar to "fixing the problem of unauthenticated email"... = requiring a long, multi-year commitment that relies on strangers to = determine success.

=3D- = Tim

= --Apple-Mail=_2ACD7F01-29ED-4C46-A63A-D60BE5D12CF3-- From superuser@gmail.com Sun Apr 14 20:51:03 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C6E21F8B15 for ; Sun, 14 Apr 2013 20:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVArO6IMO3c7 for ; Sun, 14 Apr 2013 20:51:03 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id DFE6D21F90AF for ; Sun, 14 Apr 2013 20:50:58 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id j13so1790405wgh.14 for ; Sun, 14 Apr 2013 20:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jQqoBt22MkYEjOdRcRn5WBZhaVjkzQvg5SbjuyJ00io=; b=Vz3SsDXa/FeUATxK2gwYH3i7pdtnuWgCirpl7xp2RhlBevpHusMLZ0+spHQ62Tb/zb k/Z9CaTgDHKmKkkhF25djfZIkPPQsp0V3iqpGZ2SQqhds+vZJ/h4kTGXf6R1llCvQfRu +XWNBKAk61TIex0ON8UeocTgAeZmoQUTL8TngTTxKInh0+Jj3vz0DBQpJQA3rC0SlcCI VJRAgOoFILh4xzmwNNys7i9Yco2sh7nlU6EIjfFtRs/BnfhqWY+GMNBY9HILXGMPacEm /S/g89pHHnV8eZfmWVBnQvAN02dX7WjRHnTG8Tgxo3gnJpkb3gkVP8ULnD50Yf0afUPI aEKg== MIME-Version: 1.0 X-Received: by 10.180.37.73 with SMTP id w9mr5557321wij.32.1365997858065; Sun, 14 Apr 2013 20:50:58 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sun, 14 Apr 2013 20:50:57 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Apr 2013 20:50:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tim Draegen Content-Type: multipart/alternative; boundary=e89a8f502ee81813d704da5e2910 Cc: "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 03:51:03 -0000 --e89a8f502ee81813d704da5e2910 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Apr 14, 2013 at 7:08 PM, Tim Draegen wrote: > I guess I'm left with "How does this make anything better?" > > IMO Michael Adkins wrote it best: > > > 7. Operational Issue > > This problem is better solved by making data about legitimate mailing > > lists publicially available so everyone can apply local policy overrides > > consistently. > > I'd add an additional option: "patch mailing list software to play better > with DMARC", but I'm only offering this up with the understanding that > upgrading stuff that everyone uses all the time is a slow and painful > process, and really doesn't have much to do with DMARC-the-protocol. > > +1 to all of that. An option like this in DMARC could be set by anyone, including bad actors. That means an operator needs to decide whether it believes the flag's presence for a given domain, because the domain owner may or may not be legit. That means an operator needs intelligence about the domain to make that decision. That means an operator can gather that intelligence and apply it irrespective of whether this flag is set for a given domain. That means we don't need the flag. This feels like an instantiation of the evil bit. (See RFC3514) -MSK --e89a8f502ee81813d704da5e2910 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 14, 2013 at 7:08 PM, Tim Draegen <tim@eudaemon= .net> wrote:
I guess I'm left with "How does thi= s make anything better?"

IMO Michael Adkins wrote it best:

> 7. =A0Operational Issue
> This problem is better solved by making data about legitimate mailing<= br> > lists publicially available so everyone can apply local policy overrid= es
> consistently.

I'd add an additional option: "patch mailing list software t= o play better with DMARC", but I'm only offering this up with the = understanding that upgrading stuff that everyone uses all the time is a slo= w and painful process, and really doesn't have much to do with DMARC-th= e-protocol.


+1 to all of that.

An option like this = in DMARC could be set by anyone, including bad actors.=A0 That means an ope= rator needs to decide whether it believes the flag's presence for a giv= en domain, because the domain owner may or may not be legit.=A0 That means = an operator needs intelligence about the domain to make that decision.=A0 T= hat means an operator can gather that intelligence and apply it irrespectiv= e of whether this flag is set for a given domain.=A0 That means we don'= t need the flag.

This feels like an instantiation of th= e evil bit.=A0 (See RFC3514)

-MSK

--e89a8f502ee81813d704da5e2910-- From vesely@tana.it Mon Apr 15 04:14:32 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2F21F9305 for ; Mon, 15 Apr 2013 04:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2hDBJLJLsgg for ; Mon, 15 Apr 2013 04:14:32 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id EFA9C21F86DE for ; Mon, 15 Apr 2013 04:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366024467; bh=2ukCgLCD3+iQn3wVRGAGYdF1DEXdG1BLg+jUPXIQn10=; l=1863; h=Date:From:To:References:In-Reply-To; b=YNvx8MetdPvkaFFUgwVf83dUBR8QdIHeo56Kk7Pb3MrMmB0Yh8IApl7F0zJe1bi+K r6o/P9dgSKJTiPSrHkMY/4Yx07ZgWTIbl7UhsjZiVxi63NkiWFeWBPg6VBXDb/0szN ix+7WAICfDCoDRhQ6Zu2p0vD3qe2wpVfJewq/z7g= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 15 Apr 2013 13:14:27 +0200 id 00000000005DC03F.00000000516BE113.0000330B Message-ID: <516BE113.7080001@tana.it> Date: Mon, 15 Apr 2013 13:14:27 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <77426B543150464AA3F30DF1A91365DE52EF64A1@ESV4-MBX01.linkedin.biz> <233F2BB85E1A42B59E6F8D5E09C06889@fgsr.local> <51681D07.1030006@tana.it> <51693E64.2020308@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 11:14:33 -0000 On Sat 13/Apr/2013 17:08:17 +0200 Murray S. Kucherawy wrote: > On Sat, Apr 13, 2013 at 4:15 AM, Alessandro Vesely wrote: > >> Nevertheless, because of its stance at integrating DKIM, SPF, >> and possibly more, DMARC has a chance to inspire implementations >> that take the lead in establishing a data model that other mail >> filtering utilities may want to adapt to. > > Sure, but none of that belongs in a protocol document. The protocol specifies the XML table used in transfer, and that may suffice. Outlining some of the relevant features and characteristics of the database might be useful, just like outlining the algorithm. >> The problem seems to be tackled differently, except for the >> policy part. > > You'll have to explain how it's tackled differently in protocol, > because I can't think of what you might be referring to here. The feedback protocol is about a meta-SMTP data flow. While the transport uses XML and SMTP, the data semantics stay somewhat parallel to the SMTP protocol. Someone tells a peer: "Look, your mail is being forwarded here by X, so what are you gonna do about that?" In that respect, it's rather similar to FBL, as depicted in RFC 6650. The peer can reply: "Oh, X? That's legitimate, let them through." Such replies use SPF/DKIM and DNS, and are not as synchronous and specific as it might be desirable. Moreover, X is identified loosely, and has no say. SPF and ADSP simply tried to push a new layer on top of email. FBL and DMARC break new ground by establishing real communication. > The charter also says if that turns into a rathole that produces > nothing, it will be abandoned. It should be a joy to design a suite such that more and more protocols can come forth in the meta-SMTP arena, neither over-constrained nor marooned by prior design decisions. From johnl@iecc.com Mon Apr 15 04:17:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0214821F85EE for ; Mon, 15 Apr 2013 04:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XBflVMDWz8i for ; Mon, 15 Apr 2013 04:17:46 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0A70521F8B2B for ; Mon, 15 Apr 2013 04:17:45 -0700 (PDT) Received: (qmail 35697 invoked from network); 15 Apr 2013 11:19:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Apr 2013 11:19:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516be1d8.xn--30v786c.k1304; i=johnl@user.iecc.com; bh=QYnl4jHPDjwa5TSmL59aJOnBL9cQk/K+uTmOCDAKFqY=; b=l4JuJLWhFRF6keqLBdsCrOcN6NM0sFDePnWJl1KgeSXk4IqqTI/U8bfKCOCfLrHJBqjF+E4DFVWYugUaG1rT3mgTq0F5THNDIX5+4jdvpvzmPIJKRP8LdXjkCU0f8tBcbzj4wD/co0P/ONsHhpXDk6bJkUc82OSqso5GXRnLWd8= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516be1d8.xn--30v786c.k1304; olt=johnl@user.iecc.com; bh=QYnl4jHPDjwa5TSmL59aJOnBL9cQk/K+uTmOCDAKFqY=; b=uNCo/E2Biqf6NFpflRkOPeM+qmz11Ymi0+hYIbFb0wpBZj7pbAb57gaFNbodcxdhI3KiFnFtT0MG7es2AWNTBHca2kPQQhDRbUvTzcP3Vk8Wt1JzlYRUVDfWc2ftqxDTWy5VLPwtE8ww9jwpE7qcpFG1BthiBl4e/YwYddV8zb4= Date: 15 Apr 2013 11:17:22 -0000 Message-ID: <20130415111722.8457.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 11:17:47 -0000 >This feels like an instantiation of the evil bit. (See RFC3514) Indeed, and not the first time someone didn't understand that 3514 is a joke. From johnl@iecc.com Mon Apr 15 04:34:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C7821F848D for ; Mon, 15 Apr 2013 04:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhTT2aLXO7Q0 for ; Mon, 15 Apr 2013 04:34:00 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC6721F8511 for ; Mon, 15 Apr 2013 04:34:00 -0700 (PDT) Received: (qmail 39644 invoked from network); 15 Apr 2013 11:35:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Apr 2013 11:35:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516be5a7.xn--hew.k1304; i=johnl@user.iecc.com; bh=EZjnEXkJFfMjw1+JAJewto8UAr4TOtCBUDoRWrKmrDI=; b=iaJSu90ZOmcXy+6F3npy8WUDyFVuNtlxzBNgoDCmmShy5BB+uZMxZrYaCfvv21Ja8H8YD66GcpysL+L6UKg2lzovSvXLVsfeQV+BLJFMhbYsNbwjjuBAU3h9hBYzeSdO5dbfDoJbJ6tChP2HWi7BAS/vXoQbRx4bS/FOAUbXzWI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516be5a7.xn--hew.k1304; olt=johnl@user.iecc.com; bh=EZjnEXkJFfMjw1+JAJewto8UAr4TOtCBUDoRWrKmrDI=; b=paBVIi4HReuXcHZA27kwC/eeNcwSA9nZjHyo5t/GlBW20igE0n9HR9CAxSvbxyx5LZIsoG5V2dG6+Jq/x1jnY9CRxidKXOWhQlRBjwzYmC8R1ZOjeHgHceVFanpCovYyoVyZq7oQPixkSTBInNkUVhvI1HaBgpQU3LTrEQXEMCg= Date: 15 Apr 2013 11:33:37 -0000 Message-ID: <20130415113337.8535.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: tim@eudaemon.net Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 11:34:02 -0000 >1. create a standardized way for mailing lists to identify themselves, >2. include some sort of authentication, >3. write up a specification to tie it all together. Does anyone actually have trouble recognizing and delivering mail from mailing lists? (Real discussion lists, that is.) Not that I've ever heard. This is an awful lot of mechanism to work around Franck publishing a wrong DMARC policy and refusing to fix it. Should DMARC rejections become a problem for lists, I can assure you that list managers will solve the problem by telling people with those DMARC policies to change them, and if they don't, kicking them off either manually or with a shim in front of the list to reject their mail. In the one actual case I know like this, in which a wrong ADSP policy and an overenthusiastic receiver implementation combined to bounce people off some IETF lists, the list managers told them DON'T DO THAT and it was fixed immediately. Case closed, problem's gone. Can we stop now, please? Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From vesely@tana.it Mon Apr 15 04:36:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC23621F8EFD for ; Mon, 15 Apr 2013 04:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.79 X-Spam-Level: X-Spam-Status: No, score=-3.79 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KQKKDWhm5jZ for ; Mon, 15 Apr 2013 04:36:52 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id E67E321F8511 for ; Mon, 15 Apr 2013 04:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366025810; bh=CSWaAaDBTevJMeN8T7ZPkt1YVMSIyelk2z11VxwBtgc=; l=2405; h=Date:From:To:References:In-Reply-To; b=VeOmU72LwMvPCdu6OwPm9eHqVMsuevaVBSV3hHkEm+ga6BtuRXI174Zk/4b8SSRJu mCtxyrfV2B2gsjqVV3iY7GYKbn/pMhsKIq5VSqf0m5JVHDIe1WadxWnqiGMrw6+HXt aIBNlOskKFTh4YnWC4MUFXkmDMDwmvUPe3IUr/2c= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 15 Apr 2013 13:36:50 +0200 id 00000000005DC03F.00000000516BE652.00001B1A Message-ID: <516BE652.5010604@tana.it> Date: Mon, 15 Apr 2013 13:36:50 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> In-Reply-To: <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 11:36:53 -0000 On Mon 15/Apr/2013 04:59:16 +0200 Tim Draegen wrote: > > DMARC as a specification can't fix "the mailing list problem", but > has a place to drop in "hey I thought this came from a mailing list > so I didn't apply your policy". That could be made a bit sharper: "I thought" and "I knew" are quite different from one another. > In other words, fixing the mailing list problem is not something > DMARC does, but at least it can point out an area that needs work. Better yet, it can spell what a wished-for work on such problem is expected to come out with. > Alessandro Vesely mentioned something about "a mechanism for > mitigating the effect of failures of DMARC policy when a message > transits a mailing list", but I see this as more of a spin off > effort to: > > 1. create a standardized way for mailing lists to identify themselves What's wrong with using List-Post:? > 2. include some sort of authentication How about SPF or, in case list posts get forwarded, DKIM? > 3. write up a specification to tie it all together. TBD. With DMARC end points clearly in place, it could be a breeze. A difficulty is that it can take quite some time --and some messages-- between "I think" and "I know". For example, that spec might require that the user sends a message to the List-Post address. > I'm not sure the above would matter to the installed base of > mailing list authors, operators, and users, though. It would be > useful for some set of people that want to the right thing but > don't know what right is. Updating all the rest might be > impossible or take a long time. In the meantime, though, receivers > are getting email through mailing lists from domains that want > policy applied, and yet would lead to bad end-user experiences. > Bad user experience is currently mitigated by through a local > decision to apply an "override" reason of "mailing_list". IMHO, doing mailing lists can remain an optional part of DMARC. > From DMARC's PoV.... done! Yes, nearly so. A sender may want to be able to specify a different policy for those DMARC receivers that recognize mailing lists, rather than simply trusting that receivers will do what best fits their users' needs, whether they formally implement that DMARC-ML extension or not. Hm... Murray's argument likening l= and the evil bit seems to apply to p= as well, doesn't it? From superuser@gmail.com Mon Apr 15 06:34:01 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33D021F93A6 for ; Mon, 15 Apr 2013 06:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWcF4A47QzR2 for ; Mon, 15 Apr 2013 06:34:01 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1D27721F93A5 for ; Mon, 15 Apr 2013 06:34:00 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id o7so1518259wea.8 for ; Mon, 15 Apr 2013 06:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1hZAuBK/G2TGW+oJaO6ioFKs92ANmTJX4KQevyGyd34=; b=UK6iHbyydzBLKZj9hUkbeyjZhPrBI3kg7HG1HRYaAlaTDkXvt1+vL4q46Ovvyrn0O2 iv7RviyFO/lpPFM/dc8XbmQ7CZU9Gc8F4nO+j00njEEyoqJo0Qovq0RcR0wOoL/F0dWQ Ae7oPHaro7PKhnort/qd7IxDFcOjsIukvxSiFsDK2GvggVLjbXZqmU9nx9GxvSS8qD1l r1+0TFx1yUyU/D8eB89EncEc63Me8U/IvQxyRPNNi/wcZi6PBkpCskukrp3OiJDjzjdy Ei0tABZ/Z2Q2mXReujx9/Uw/vHyi2z9nBJ/cgi3mAgmge5pMmbEVL7m5eAZ/2KPUj3MO s9Pg== MIME-Version: 1.0 X-Received: by 10.194.222.100 with SMTP id ql4mr32164885wjc.59.1366032840025; Mon, 15 Apr 2013 06:34:00 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 15 Apr 2013 06:33:59 -0700 (PDT) In-Reply-To: <516BE652.5010604@tana.it> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> <516BE652.5010604@tana.it> Date: Mon, 15 Apr 2013 06:33:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=001a11c1b9422e6d6704da664e92 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 13:34:01 -0000 --001a11c1b9422e6d6704da664e92 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 15, 2013 at 4:36 AM, Alessandro Vesely wrote: > > Hm... Murray's argument likening l= and the evil bit seems to > apply to p= as well, doesn't it? > Not exactly. It's more like: Who's to say DMARC can't or won't be (or isn't being) tried by phishers? As with DKIM and SPF, a "pass" doesn't tell you anything about the party sending you the message, only something about the way it got to you. You have to decide for yourself if the content is safe to consume. --001a11c1b9422e6d6704da664e92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 15, 2013 at 4:36 AM, Alessandro Vesely <vesely@t= ana.it> wrote:

Hm... Murray's argument likening l=3D and the evil bit seems to
apply to p=3D as well, doesn't it?

= Not exactly.=A0 It's more like:=A0 Who's to say DMARC can't or = won't be (or isn't being) tried by phishers?=A0 As with DKIM and SP= F, a "pass" doesn't tell you anything about the party sending= you the message, only something about the way it got to you.=A0 You have t= o decide for yourself if the content is safe to consume.

--001a11c1b9422e6d6704da664e92-- From tim@eudaemon.net Mon Apr 15 06:39:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B31521F93B4 for ; Mon, 15 Apr 2013 06:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bg8qJ4hnA6g for ; Mon, 15 Apr 2013 06:39:36 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8C15621F93B2 for ; Mon, 15 Apr 2013 06:39:36 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 3BD9BCB46; Mon, 15 Apr 2013 09:40:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Draegen In-Reply-To: <20130415113337.8535.qmail@joyce.lan> Date: Mon, 15 Apr 2013 09:39:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130415113337.8535.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1503) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 13:39:37 -0000 On Apr 15, 2013, at 7:33 AM, "John Levine" wrote: > Does anyone actually have trouble recognizing and delivering mail from > mailing lists? (Real discussion lists, that is.) Not that I've ever > heard. I totally agree; this discussion would benefit from input of folks = involved in professional email list management. =3D- Tim From tim@eudaemon.net Mon Apr 15 07:05:13 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B8921F93F4 for ; Mon, 15 Apr 2013 07:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYwWyzj7Ypye for ; Mon, 15 Apr 2013 07:05:13 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 04F2C21F93CD for ; Mon, 15 Apr 2013 07:05:13 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id E279FCB46; Mon, 15 Apr 2013 10:05:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Tim Draegen In-Reply-To: <516BE652.5010604@tana.it> Date: Mon, 15 Apr 2013 10:05:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> <516BE652.5010604@tana.it> To: Alessandro Vesely X-Mailer: Apple Mail (2.1503) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 14:05:13 -0000 On Apr 15, 2013, at 7:36 AM, Alessandro Vesely wrote: > That could be made a bit sharper: "I thought" and "I knew" are quite > different from one another. Alessandro, I think this is the crux of the issue. Today there is not a reliable = way to systematically identify mailing lists. Michael Adkins suggested = that what is needed today is a shared public repo of such info that will = bring some consistency to how receivers are applying the "mailing_list" = override. I'd add that, in parallel, it would be nice if the people involved in = professional email list management context got together and normalized = aspects of how they generated email, made a spec out of it, and spent = some cycles advocating for changes. Because I'm not a mailing list pro = and I think that "market forces" will cause changes faster than I could = get done anyway, I'm happy to take a back seat on this one. >=20 >> In other words, fixing the mailing list problem is not something >> DMARC does, but at least it can point out an area that needs work. >=20 > Better yet, it can spell what a wished-for work on such problem is > expected to come out with. FWIW, I agree with Murray Kucherawy's opinion that DMARC has already = carved out a place for a drop in solution, and that's good enough. = Since its going to take a very long time for the mailing list problem to = be fixed, might as well focus on the interface for the drop in solution, = call it a day and move on. > What's wrong with using List-Post:? I can't speak to whether or not this is wrong or right. I'd have to = look at a whole lot of data to form an opinion on which header covers = the most ground. =20 >> 2. include some sort of authentication >=20 > How about SPF or, in case list posts get forwarded, DKIM? This would be ideal, for sure, but without a real mountain of data to = work from or people involved in developing mailing lists, who is to say = how easy it is to deploy SPF and/or DKIM in a mailing list operator = context? >> 3. write up a specification to tie it all together. >=20 > TBD. With DMARC end points clearly in place, it could be a breeze. I agree! Hopefully I'm clear in articulating why I don't think the = proto DMARC WG is the place to get this done, though. There simply = isn't enough representation of the mailing list community. > IMHO, doing mailing lists can remain an optional part of DMARC. Given that DMARC is shining a light on mailing lists, it might be = possible to get the mailing list community together to work something = out. Leaving this specific item as an optional WG item, though, feels = like it would become an excuse for not taking action. If we say "No, = its not going to happen here", it'll force the issue to be resolved in a = more effective context/group. >=20 >> =46rom DMARC's PoV.... done! >=20 > Yes, nearly so. A sender may want to be able to specify a different > policy for those DMARC receivers that recognize mailing lists, rather > than simply trusting that receivers will do what best fits their > users' needs, whether they formally implement that DMARC-ML extension > or not. Hm... Murray's argument likening l=3D and the evil bit seems = to > apply to p=3D as well, doesn't it? A little evil bit, yes. In terms of senders specifying different = policies for various ways that break DMARC, I think this is a bad idea. = Give the domain owner visibility into what is actually happening, and = let the domain owner figure out how to clean up their own practices. = Otherwise, punching out holes for the various ways that break DMARC = could be a slippery slope of exceptions. =3D- Tim From johnl@taugh.com Mon Apr 15 09:14:46 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242D821F93C4 for ; Mon, 15 Apr 2013 09:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujaDZYA1HxVU for ; Mon, 15 Apr 2013 09:14:45 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D7F5321F92C1 for ; Mon, 15 Apr 2013 09:14:44 -0700 (PDT) Received: (qmail 12471 invoked from network); 15 Apr 2013 16:16:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=30b6.516c27d2.k1304; bh=Y4hjWYvsjTGNIMpfUsGvEGY2VcPFc761hAlw0tyWbI8=; b=nY6WEvikEljzYKlrAz8eN7FUFEYNe8VZ9L9KGrm/yOb+pVr3+SdEmSZykMjTEiGRsWKQX0btNpo+fMW39Bi0IytJEngUqa412i88SsQ6ybxvzNcacXYhjJam5a7YpxZlUdUntDV1ebrJAsFk3YMV3jqE74Sng3M/u0Gex5ax0wY= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=30b6.516c27d2.k1304; bh=Y4hjWYvsjTGNIMpfUsGvEGY2VcPFc761hAlw0tyWbI8=; b=Fa5bMe6dg+C1SB10BVJ/x9hoIsx+Rkbp7AZRVMDTjqLagV8ut8CLQ7u4OxVdUj9CthiwcPhKsmrYfnPceKL7es/exnCiW4DMaxWLFHO2gQWqyO4WD9ebeJi+JCXFR9UnTDFHQSnsKS/2YrhiOiE/m8qNufrKt3tcDXBzLo9GCXE= Received: (ofmipd 127.0.0.1); 15 Apr 2013 16:15:56 -0000 Date: 15 Apr 2013 18:14:44 +0200 Message-ID: From: "John R Levine" To: "Tim Draegen" In-Reply-To: References: <20130415113337.8535.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 16:14:46 -0000 > I totally agree; this discussion would benefit from input of folks involved in professional email list management. I'm not sure I count as a professional, but I've been running more lists than I can remember lists for about 30 years. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. From MHammer@ag.com Mon Apr 15 09:15:31 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E6A21F9350 for ; Mon, 15 Apr 2013 09:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLn51P3FOtjO for ; Mon, 15 Apr 2013 09:15:27 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id E850121F8F70 for ; Mon, 15 Apr 2013 09:15:26 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 12:15:26 -0400 From: "MH Michael Hammer (5304)" To: Tim Draegen , Alessandro Vesely Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOeJCI9+KGSYx+UaCVlj4QhVIZ5jXbZMw Date: Mon, 15 Apr 2013 16:15:25 +0000 Message-ID: References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> <516BE652.5010604@tana.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.201] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 16:15:31 -0000 I'm going to top post (apologies). The bottom line is that when an (abused)= sending domain publishes a p=3Dreject DMARC policy it is taking responsibi= lity for any discarded legitimate mail that fails to pass - for whatever re= ason. As soon as a validator starts trying to determine which failing mail = is legitimate, it takes back responsibility for any malicious mail (that fa= iled to validate) which reaches an enduser.=20 Don't muddy the waters. Sending domains with endusers should not allow thos= e endusers to subscribe to maillists from that domain. While validators/mai= lbox providors will do what they will do, they really should apply pressure= to sending domains that publish p=3Dreject b and allow their endusers to s= end through maillists. Mike=20 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Tim Draegen > Sent: Monday, April 15, 2013 10:05 AM > To: Alessandro Vesely > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not abo= ut > outsourcing strategies >=20 > On Apr 15, 2013, at 7:36 AM, Alessandro Vesely wrote: > > That could be made a bit sharper: "I thought" and "I knew" are quite > > different from one another. >=20 > Alessandro, >=20 > I think this is the crux of the issue. Today there is not a reliable way= to > systematically identify mailing lists. Michael Adkins suggested that wha= t is > needed today is a shared public repo of such info that will bring some > consistency to how receivers are applying the "mailing_list" override. >=20 > I'd add that, in parallel, it would be nice if the people involved in pro= fessional > email list management context got together and normalized aspects of how > they generated email, made a spec out of it, and spent some cycles > advocating for changes. Because I'm not a mailing list pro and I think t= hat > "market forces" will cause changes faster than I could get done anyway, I= 'm > happy to take a back seat on this one. >=20 > > > >> In other words, fixing the mailing list problem is not something > >> DMARC does, but at least it can point out an area that needs work. > > > > Better yet, it can spell what a wished-for work on such problem is > > expected to come out with. >=20 > FWIW, I agree with Murray Kucherawy's opinion that DMARC has already > carved out a place for a drop in solution, and that's good enough. Since= its > going to take a very long time for the mailing list problem to be fixed, = might > as well focus on the interface for the drop in solution, call it a day an= d move > on. >=20 >=20 > > What's wrong with using List-Post:? >=20 > I can't speak to whether or not this is wrong or right. I'd have to look= at a > whole lot of data to form an opinion on which header covers the most > ground. >=20 > >> 2. include some sort of authentication > > > > How about SPF or, in case list posts get forwarded, DKIM? >=20 > This would be ideal, for sure, but without a real mountain of data to wor= k > from or people involved in developing mailing lists, who is to say how ea= sy it > is to deploy SPF and/or DKIM in a mailing list operator context? >=20 > >> 3. write up a specification to tie it all together. > > > > TBD. With DMARC end points clearly in place, it could be a breeze. >=20 > I agree! Hopefully I'm clear in articulating why I don't think the prot= o DMARC > WG is the place to get this done, though. There simply isn't enough > representation of the mailing list community. >=20 > > IMHO, doing mailing lists can remain an optional part of DMARC. >=20 > Given that DMARC is shining a light on mailing lists, it might be possibl= e to get > the mailing list community together to work something out. Leaving this > specific item as an optional WG item, though, feels like it would become = an > excuse for not taking action. If we say "No, its not going to happen her= e", it'll > force the issue to be resolved in a more effective context/group. >=20 > > > >> From DMARC's PoV.... done! > > > > Yes, nearly so. A sender may want to be able to specify a different > > policy for those DMARC receivers that recognize mailing lists, rather > > than simply trusting that receivers will do what best fits their > > users' needs, whether they formally implement that DMARC-ML extension > > or not. Hm... Murray's argument likening l=3D and the evil bit seems t= o > > apply to p=3D as well, doesn't it? >=20 > A little evil bit, yes. In terms of senders specifying different policie= s for > various ways that break DMARC, I think this is a bad idea. Give the doma= in > owner visibility into what is actually happening, and let the domain owne= r > figure out how to clean up their own practices. Otherwise, punching out > holes for the various ways that break DMARC could be a slippery slope of > exceptions. >=20 > =3D- Tim >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From prvs=81035173e=fmartin@linkedin.com Mon Apr 15 10:57:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7EE21F94A6 for ; Mon, 15 Apr 2013 10:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYHk5p+gw5BB for ; Mon, 15 Apr 2013 10:57:19 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7508821F90B9 for ; Mon, 15 Apr 2013 10:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1366048639; x=1397584639; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FtOWxnoXomIjWUhREDbZSWp4BnRnsgkT8HKPyCQSZtw=; b=Ieb32NfkftwMNiznaGIlaNPep07quAw8KJ8I0FH8zgxyPVbRXBbFI0me 9G1VXyp0GPFRrD4yOvNJM0aafojBlipvU0giBvrp2Lb/RrGvIxB8ckv/k NZUX1faY2QD5zObMvLOF7HJTjIolUyGRJFPKUKRv7HyTxOfu5+O9/ueXz 0=; X-IronPort-AV: E=Sophos;i="4.87,477,1363158000"; d="scan'208";a="45299441" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Mon, 15 Apr 2013 10:57:11 -0700 From: Franck Martin To: "MH Michael Hammer (5304)" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOfSFdrz7H0iWUESW0fv2j4mWUZjYBsKA Date: Mon, 15 Apr 2013 17:57:11 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52F35B8D@ESV4-MBX01.linkedin.biz> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> <516BE652.5010604@tana.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" , Tim Draegen , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 17:57:20 -0000 On Apr 15, 2013, at 6:15 PM, MH Michael Hammer (5304) wrot= e: > I'm going to top post (apologies). The bottom line is that when an (abuse= d) sending domain publishes a p=3Dreject DMARC policy it is taking responsi= bility for any discarded legitimate mail that fails to pass - for whatever = reason. As soon as a validator starts trying to determine which failing mai= l is legitimate, it takes back responsibility for any malicious mail (that = failed to validate) which reaches an enduser.=20 >=20 > Don't muddy the waters. Sending domains with endusers should not allow th= ose endusers to subscribe to maillists from that domain.=20 In theory it works, in practice... How do you plan to do that?= From MHammer@ag.com Mon Apr 15 11:47:03 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1952421F96C1 for ; Mon, 15 Apr 2013 11:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zTrpacNuw8Z for ; Mon, 15 Apr 2013 11:47:02 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 445BC21F96A0 for ; Mon, 15 Apr 2013 11:47:02 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 14:47:01 -0400 From: "MH Michael Hammer (5304)" To: Franck Martin Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOgKrztZRiLw23EKiv5SRThiaX5jXnpPg Date: Mon, 15 Apr 2013 18:47:01 +0000 Message-ID: References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> <516BE652.5010604@tana.it> <77426B543150464AA3F30DF1A91365DE52F35B8D@ESV4-MBX01.linkedin.biz> In-Reply-To: <77426B543150464AA3F30DF1A91365DE52F35B8D@ESV4-MBX01.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" , Tim Draegen , Alessandro Vesely Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 18:47:03 -0000 > -----Original Message----- > From: Franck Martin [mailto:fmartin@linkedin.com] > Sent: Monday, April 15, 2013 1:57 PM > To: MH Michael Hammer (5304) > Cc: Tim Draegen; Alessandro Vesely; dmarc@ietf.org > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not abo= ut > outsourcing strategies >=20 >=20 > On Apr 15, 2013, at 6:15 PM, MH Michael Hammer (5304) > wrote: >=20 > > I'm going to top post (apologies). The bottom line is that when an (abu= sed) > sending domain publishes a p=3Dreject DMARC policy it is taking responsib= ility > for any discarded legitimate mail that fails to pass - for whatever reaso= n. As > soon as a validator starts trying to determine which failing mail is legi= timate, it > takes back responsibility for any malicious mail (that failed to validate= ) which > reaches an enduser. > > > > Don't muddy the waters. Sending domains with endusers should not allow > those endusers to subscribe to maillists from that domain. >=20 > In theory it works, in practice... How do you plan to do that? I do it now for my domains. It is called self control.=20 From jgomez@seryrich.com Mon Apr 15 13:56:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5697921F93E8 for ; Mon, 15 Apr 2013 13:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXmCiL03o1hm for ; Mon, 15 Apr 2013 13:56:18 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 6228A21F93E5 for ; Mon, 15 Apr 2013 13:56:17 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 15 Apr 2013 22:56:15 +0200 Message-ID: <5F4FD46FD8EC4D85B017AF7B96BAB25B@fgsr.local> From: "J. Gomez" To: References: Date: Mon, 15 Apr 2013 22:56:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 20:56:19 -0000 On Monday, April 15, 2013 4:08 AM [GMT+1=3DCET], Tim Draegen wrote: > On Apr 12, 2013, at 5:35 PM, J. Gomez wrote: > > 4. (Uselessness problem) This proposition achieves nothing. > >=20 > > --> True. It's not the intent of the "l=3D" tag to achieve > > anything nor to convey policy from Sender to Receiver. The "l=3D" = tag > > merely conveys additional information from Sender to Receiver, and > > the Receiver is free to consume it as he wishes or to disregard it > > altogether. =20 >=20 >=20 > This here. If the tag doesn't achieve anything and could very well > be wrong ('cause there is no measurable impact to getting it right), > it'll just add noise to a receiver's decision making, and therefore > {all of your other counter-arguments}. It's not noise. It's additional information the domain owner makes = publicly available about what can or cannot be expected from his mailing = users. If the domain owner uses the "l=3D" tag, the information is = there. If the receivers decides to not apply local policies based on it, = that's fine and their choice. But I don't see that as noise. If you see a ship at the high seas with a pirate flag, you can choose to = ignore it because you think it's a joke, or you can choose to change = your sailing route. But you have the option to choose based on the = information you got from the other party. The information is there. You = opt to not believe it? Fine. But don't pretend the information was not = there, because it was. The "l=3D" flag achieves nothing by itself, because it is not about = declaring the policy of the Sender, but about declaring the practices of = the Sender so that the Receiver can apply his local policies for that = practices of the Sender. So it's the receiver who can opt to achieve = something based on that information, or to ignore it. > To game this out, *IF* this tag existed and was accurately used, as a > receiver I'd still have to figure out what sources are mailing lists > in order to make the extra "l=3D{yes,no,dunno}" tag useful. Let's say > I have perfect mailing list knowledge, what then am I supposed to do > with email coming through a mailing list from a domain with the > "l=3Dno" tag? If the answer is "nothing", then why is this tag even > there for me to look at? The idea in that case is that you as a Receiver are supposed to do = whatever your local policy is about accepting mail from mailing lists. I = myself, when acting as a Receiver, if I got email which failed DMARC = because of "p=3Dreject" and also found "l=3Dno" in the Sender's DMARC = record, then I would irrevocably reject/dump that incoming message and = avoid the processing time/effort of post-processing it after-DMARC = against any additional local mailing-list detection = heuristics/whitelists. I see value in having that option as a Receiver, = makes life easier for the Receiver, don't you think? Regards, J. Gomez From jgomez@seryrich.com Mon Apr 15 14:17:31 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0DF21F93B7 for ; Mon, 15 Apr 2013 14:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwwJebwXxxsY for ; Mon, 15 Apr 2013 14:17:31 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id A6DC321F9380 for ; Mon, 15 Apr 2013 14:17:30 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 15 Apr 2013 23:17:29 +0200 Message-ID: From: "J. Gomez" To: References: Date: Mon, 15 Apr 2013 23:18:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 21:17:31 -0000 Murray S. Kucherawy wrote: > An option like this in DMARC could be set by anyone, including bad > actors. That means an operator needs to decide whether it believes > the flag's presence for a given domain, because the domain owner may > or may not be legit. That means an operator needs intelligence about > the domain to make that decision. An operator also needs intelligence about a domain when he finds an = incoming email that fails DMARC and the Sender has a DMARC policy of = "p=3Dquarantine" -- is that domain reputable?, is that domain frequently = victim of phishing?, etc. > That means an operator can gather > that intelligence and apply it irrespective of whether this flag is > set for a given domain. That means we don't need the flag. Uh? Non sequitur. An operator also has to decide to believe or not to = believe the "p=3Dnone" policy of any sender because it "can be set by = anyone, including bad actors". I guees then we also don't need "p=3Dquarantine" nor "p=3Dnone", right? > This feels like an instantiation of the evil bit. (See RFC3514) LOL Regards, J. Gomez From jgomez@seryrich.com Mon Apr 15 14:36:12 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FF921F9497 for ; Mon, 15 Apr 2013 14:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzgkmrN-Jj7D for ; Mon, 15 Apr 2013 14:36:12 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id CF28C21F9458 for ; Mon, 15 Apr 2013 14:36:11 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 15 Apr 2013 23:36:10 +0200 Message-ID: <94E68CB83ACF4DC5B0323042099F3E76@fgsr.local> From: "J. Gomez" To: References: <20130415113337.8535.qmail@joyce.lan> Date: Mon, 15 Apr 2013 23:36:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 21:36:12 -0000 On Monday, April 15, 2013 1:33 PM [GMT+1=3DCET], John Levine wrote: > Does anyone actually have trouble recognizing and delivering mail from > mailing lists? (Real discussion lists, that is.) Not that I've ever > heard. >=20 > This is an awful lot of mechanism to work around Franck publishing a > wrong DMARC policy and refusing to fix it. Should DMARC rejections > become a problem for lists, I can assure you that list managers will > solve the problem by telling people with those DMARC policies to > change them, and if they don't, kicking them off Your reassurance on the future course of human action is quite dogmatic, = I think. What about this other alternative outcomes? 1. "Should DMARC rejections become a problem for lists, I can assure you = that DMARC will be deemed a failed attempt at solving the authentication = problem of email and not achieve wide adoption." 2. "Should DMARC rejections become a problem for lists, I can assure you = that mailing lists operators will adapt their installations to make them = compatible with DMARC." 3. "Should DMARC rejections become a problem for lists, I can assure you = that mailing lists developers will adapt their software to make it = compatible with DMARC." 4. "Should DMARC rejections become a problem for lists, I can assure you = that mailing lists will become a thing of the past like gopher and = FTP-through-email." And what about a mix of 2+3+4? > Can we stop now, please? I prefer to hear more opinions, and not yet give up looking for some way = to minimize the false positives of mailing lists with DMARC. Regards, J. Gomez From jaberant@twitter.com Mon Apr 15 14:55:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA4A21F93BA for ; Mon, 15 Apr 2013 14:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.085 X-Spam-Level: X-Spam-Status: No, score=-0.085 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, MISSING_HEADERS=1.292, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUlLinsHD0Le for ; Mon, 15 Apr 2013 14:55:39 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 44FDC21F93A9 for ; Mon, 15 Apr 2013 14:55:39 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id s43so4141683wey.35 for ; Mon, 15 Apr 2013 14:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com; s=google; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:cc:content-type; bh=3v9Z0WH691ypi9RR/d2hvud3S6JaZv/cx/ebUo0ZONI=; b=SiTsIJPXfB/CMCnDqLvYlZPUsknQkuXXCnebH9yYI8nJJf3Gm3fgKGjm8+RY+78s8O JWnAj2/DNU9Yp/u22+b1BCJ1IMpsbrXivkYQJIopmDtPqZ8CIjVgrl2RvC4P/8DjehMe UVp572gT5cyWPzfX6EGU2r2uhadHzEQn/tDpY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:cc:content-type:x-gm-message-state; bh=3v9Z0WH691ypi9RR/d2hvud3S6JaZv/cx/ebUo0ZONI=; b=PU/5zm2OpUpp57wCGStKNYms6NAIItUhOZADs2eCsNhgS8N3BwVaWXzRoF5tVCQC6s t54tCG0cUVLJxlJqSu6lTe82LkuOdsyvAJ1zgj3adMG7cR6sH/LB8RVLEmNq4RmCpYSb RU7Zo7KyAYC0qrLVFdLwM4cD0Pz9NXBeuOOQZtmR2IGqRXqiqC3UxPUJmQY86OAMiWsz nt127aAyAyy4qBBZZEKr54kI5wtQvlABO/doxpOLpsz9FwmqRgzQlmqkdZvWiUXfOXbz fxJeZgJBK5ePxP+b9qELTKpgydSEOAGx94Fj9RQltjmGD2yVWqaFLvyPJq+8nqP9XBZ0 Y/MQ== X-Received: by 10.180.79.6 with SMTP id f6mr14772360wix.26.1366062938399; Mon, 15 Apr 2013 14:55:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.21.1 with HTTP; Mon, 15 Apr 2013 14:55:18 -0700 (PDT) In-Reply-To: <20130415113337.8535.qmail@joyce.lan> References: <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> <20130415113337.8535.qmail@joyce.lan> From: Josh Aberant Date: Mon, 15 Apr 2013 14:55:18 -0700 Message-ID: Cc: dmarc@ietf.org Content-Type: multipart/alternative; boundary=f46d044282482f354204da6d500f X-Gm-Message-State: ALoCoQmSyeEGH0H7tM8LigzmNH1znYdvfGYkVypd+4K5rqeSwPM3uxr0G1CuMkeOd87/FhDkODPV Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 21:55:41 -0000 --f46d044282482f354204da6d500f Content-Type: text/plain; charset=ISO-8859-1 As another stakeholder with a domain that has users and p=reject, it seems to me that simply saying the DMARC reject shouldn't be used on domains with users will significantly limit the potential value of DMARC to the email community. One of our main goals in deploying DMARC was to protect our users. Before we deployed p=reject we were seeing phishing attacks on our employees (to their work and personal addresses) that were spoofing our domain. DMARC p=reject made these mostly go away and added a lot of value. Perhaps, a focus of DMARC should be on protecting domains with users. And, yes, I know I'm walking into a land mine here and top posting to boot; fire away.... Josh http://t.co/Josh Josh Aberant @jaberant On Mon, Apr 15, 2013 at 4:33 AM, John Levine wrote: > > Does anyone actually have trouble recognizing and delivering mail from > mailing lists? (Real discussion lists, that is.) Not that I've ever > heard. > > This is an awful lot of mechanism to work around Franck publishing a > wrong DMARC policy and refusing to fix it. Should DMARC rejections > become a problem for lists, I can assure you that list managers will > solve the problem by telling people with those DMARC policies to > change them, and if they don't, kicking them off either manually or > with a shim in front of the list to reject their mail. > > In the one actual case I know like this, in which a wrong ADSP policy > and an overenthusiastic receiver implementation combined to bounce > people off some IETF lists, the list managers told them DON'T DO THAT > and it was fixed immediately. > > Case closed, problem's gone. Can we stop now, please? > > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. http://jl.ly > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f46d044282482f354204da6d500f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As another stakeholder with a domain that has users a= nd p=3Dreject, it seems to me that simply saying the DMARC reject shouldn&#= 39;t be used on domains with users will significantly limit the potential v= alue of DMARC to the email community.=A0 One of our main goals in deploying= DMARC was to protect our users.=A0 Before we deployed p=3Dreject we were s= eeing phishing attacks on our employees (to their work and personal address= es) that were spoofing our domain. DMARC p=3Dreject made these mostly go aw= ay and added a lot of value.

Perhaps, a focus of DMARC should be on protecting domains wi= th users.

And, yes, I know I'm walking into a l= and mine here and top posting to boot; fire away....

Josh


http://t.co/Josh
J= osh Aberant
@jaberant



On Mon, Apr 15, 2013 at 4:33 AM, John Le= vine <johnl@taugh.com> wrote:

Does anyone actually have trouble recognizing and delivering mail fro= m
mailing lists? =A0(Real discussion lists, that is.) =A0Not that I've ev= er
heard.

This is an awful lot of mechanism to work around Franck publishing a
wrong DMARC policy and refusing to fix it. =A0Should DMARC rejections
become a problem for lists, I can assure you that list managers will
solve the problem by telling people with those DMARC policies to
change them, and if they don't, kicking them off either manually or
with a shim in front of the list to reject their mail.

In the one actual case I know like this, in which a wrong ADSP policy
and an overenthusiastic receiver implementation combined to bounce
people off some IETF lists, the list managers told them DON'T DO THAT and it was fixed immediately.

Case closed, problem's gone. =A0Can we stop now, please?

Regards,
John Levine, johnl@iecc.com, Primary = Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_________________________________________= ______
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--f46d044282482f354204da6d500f-- From jgomez@seryrich.com Mon Apr 15 15:04:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAD821F93CC for ; Mon, 15 Apr 2013 15:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[AWL=0.948, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF-HZQ7jCfnj for ; Mon, 15 Apr 2013 15:04:05 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 33B0B21F9385 for ; Mon, 15 Apr 2013 15:04:04 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 00:04:03 +0200 Message-ID: <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it><77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz><5165A993.50208@gmail.com><5166758F.1040906@tana.it><408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net><516BE652.5010604@tana.it> Date: Tue, 16 Apr 2013 00:04:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 22:04:06 -0000 On Monday, April 15, 2013 6:15 PM [GMT+1=3DCET], MH Michael Hammer = (5304) wrote: > I'm going to top post (apologies). The bottom line is that when an > (abused) sending domain publishes a p=3Dreject DMARC policy it is > taking responsibility for any discarded legitimate mail that fails to > pass - for whatever reason. As soon as a validator starts trying to > determine which failing mail is legitimate, it takes back > responsibility for any malicious mail (that failed to validate) which > reaches an enduser. Nice theory. How many of the big four/five mailbox providers (Gmail, = Hotmail, Yahoo, AOL...) who have originally come up privately with DMARC = (in coordination with sending brand owners like Paypal, Ebay, Facebook, = etc.) are following "p=3Dreject" to the letter? I think the number is = zero. Why? Because the theory is nice and clean, the real world not so = much. =20 > Don't muddy the waters. Sending domains with endusers should not > allow those endusers to subscribe to maillists from that domain. Oh, man. Oh, man. I would vote you for President. Regards, J. Gomez From superuser@gmail.com Mon Apr 15 15:12:05 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAC921F94C3 for ; Mon, 15 Apr 2013 15:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Y6x7X420b9a for ; Mon, 15 Apr 2013 15:12:03 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4EA21F94A4 for ; Mon, 15 Apr 2013 15:12:03 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so3905458wgg.28 for ; Mon, 15 Apr 2013 15:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IKRLObgh0vJjg0ZxUVAPRUpuRP1V+9RALBPvVJkEN98=; b=VCd8jZw5f90SO4X91Kf6UjCspsh5MZeDZ4lFz+XgDpIyQMO+ofE3VST5hTfiZ+32jq iLAm9iruWoaHjILB5KFNME7CLIKfIgWup1N51puFRBMBQb7KR3+rH7Jo5TzlJ9dL0Y+3 0kCbmfnfTTf4r8Z9hBsKEk0R/WbLJ9vy5NtZeSK/gx8p/bon/zPtDG6aXVyyFntAEVJJ 44KKwSgOmPaIVTUKal9v9SOEHUJiW0mCGo6BZ+joZOngnt8JtBMFG3WGbnr7KeKgegSu DihGuWy26CWttuTjsXZQtgK18AZrJOZQJNs8CjJixOCLwKlqw8GTKbgnOfl7A9S2JfFd ExrQ== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr14845174wiz.14.1366063922498; Mon, 15 Apr 2013 15:12:02 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 15 Apr 2013 15:12:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Apr 2013 15:12:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d04427194d754d904da6d8a31 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 22:12:05 -0000 --f46d04427194d754d904da6d8a31 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 15, 2013 at 2:18 PM, J. Gomez wrote: > > An option like this in DMARC could be set by anyone, including bad > > actors. That means an operator needs to decide whether it believes > > the flag's presence for a given domain, because the domain owner may > > or may not be legit. That means an operator needs intelligence about > > the domain to make that decision. > > An operator also needs intelligence about a domain when he finds an > incoming email that fails DMARC and the Sender has a DMARC policy of > "p=quarantine" -- is that domain reputable?, is that domain frequently > victim of phishing?, etc. > A domain that publishes "p=quarantine" or "p=reject" does itself no favors in terms of reaching the inbox when a failure occurs. What incentive does an attacker (whose goal is to reach the inbox) have to do that? But more generally, yes, I imagine an operator could (and should, and does, and will) detect an abuser that is saying "p=none" and act accordingly. -MSK --f46d04427194d754d904da6d8a31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 15, 2013 at 2:18 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
> An option like this i= n DMARC could be set by anyone, including bad
> actors. =A0That means an operator needs to decide whether it believes<= br> > the flag's presence for a given domain, because the domain owner m= ay
> or may not be legit. =A0That means an operator needs intelligence abou= t
> the domain to make that decision.

An operator also needs intelligence about a domain when he finds an i= ncoming email that fails DMARC and the Sender has a DMARC policy of "p= =3Dquarantine" -- is that domain reputable?, is that domain frequently= victim of phishing?, etc.

A domain that publishes "p=3Dquaranti= ne" or "p=3Dreject" does itself no favors in terms of reachi= ng the inbox when a failure occurs.=A0 What incentive does an attacker (who= se goal is to reach the inbox) have to do that?

But more generally, yes, I imagine an operator could (and sh= ould, and does, and will) detect an abuser that is saying "p=3Dnone&qu= ot; and act accordingly.

-MSK
--f46d04427194d754d904da6d8a31-- From superuser@gmail.com Mon Apr 15 15:16:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C280821F93EE for ; Mon, 15 Apr 2013 15:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0A60SaFBf6P for ; Mon, 15 Apr 2013 15:16:02 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 11BD021F9318 for ; Mon, 15 Apr 2013 15:16:01 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so3906238wgg.4 for ; Mon, 15 Apr 2013 15:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tSPuksHr0dfAHKDMyvpycY9Lp/S2u6W1BJgEzdJiurQ=; b=ALV4+B331Pa9G4a3dwAhGyDHIMHeWmsLpOaUomcN9rBTuV905T9Nqp+dGhgadqg9Qj 3TZeJoeKq7wIExhiuMHO3VH3IeMFNy1uRa8gYtUhoDStGoYSKxKg2BbT7Hnov8VFh2l9 S7UwQaKa7prViJMfg8TvMYGwrGDiNp/vTsicH3j7QDvt0L1dkVIE7PMsAlbSpylDTu0q ofJ9kPc8ufls29LfYAPN+YveV7schG+DQ8k3jqa4octRvOHodrPpK4CJyurKgROu6TQ+ M3dZF7kYYQw8Ez6NBBdujKyMDgDMQ9ehfJV/9T0yPL1J1t9PyoRyfAl3Xj22y68us4im j1AA== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr14858260wiz.14.1366064161318; Mon, 15 Apr 2013 15:16:01 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 15 Apr 2013 15:16:01 -0700 (PDT) In-Reply-To: <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> <516BE652.5010604@tana.it> <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> Date: Mon, 15 Apr 2013 15:16:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d04427194136d3b04da6d9989 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 22:16:02 -0000 --f46d04427194136d3b04da6d9989 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez wrote: > Nice theory. How many of the big four/five mailbox providers (Gmail, > Hotmail, Yahoo, AOL...) who have originally come up privately with DMARC > (in coordination with sending brand owners like Paypal, Ebay, Facebook, > etc.) are following "p=reject" to the letter? I think the number is zero. > Why? Because the theory is nice and clean, the real world not so much. > At a minimum, Gmail and Facebook are indeed rejecting based on DMARC failures. I don't know about the others. -MSK --f46d04427194136d3b04da6d9989 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
Nice theory. How many of the big four/five m= ailbox providers (Gmail, Hotmail, Yahoo, AOL...) who have originally come u= p privately with DMARC (in coordination with sending brand owners like Payp= al, Ebay, Facebook, etc.) are following "p=3Dreject" to the lette= r? I think the number is zero. Why? Because the theory is nice and clean, t= he real world not so much.

At a minimum, Gmail and Facebook are indeed rejecting base= d on DMARC failures.=A0 I don't know about the others.
=A0
<= /div>
-MSK

--f46d04427194136d3b04da6d9989-- From prvs=81035173e=fmartin@linkedin.com Mon Apr 15 15:21:04 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75A621F93D8 for ; Mon, 15 Apr 2013 15:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+2ZQfLZ4zCN for ; Mon, 15 Apr 2013 15:21:03 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) by ietfa.amsl.com (Postfix) with ESMTP id 98DBB21F939C for ; Mon, 15 Apr 2013 15:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1366064463; x=1397600463; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=RfsCVkCbhVR/rJli1OB7i9ro6yAup7c/yOrUyApzpbU=; b=0PTBpwhC/o5px8TNPvt3tEGbgtLEFsjnU0J0cYKL5FTaApvLT6ZPce1P u1/G1hKLpm2h0eej8+/0cHfrnVnbMI/K4ip0DQX3ijs6twsR85e7tJ2lx be5P3E2AXhfitDqCxAH/SIXg/RAKP7+EgOTSTbF9zxmUp+Kztibn8OBej 0=; X-IronPort-AV: E=Sophos;i="4.87,479,1363158000"; d="scan'208";a="44108844" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas02.linkedin.biz ([172.18.46.142]) with mapi id 14.02.0328.011; Mon, 15 Apr 2013 15:20:55 -0700 From: Franck Martin To: "dmarc@ietf.org" Thread-Topic: A l'abordage! Thread-Index: AQHOOid+2rcWGL/7P0Sj+IQurLgvVw== Date: Mon, 15 Apr 2013 22:20:54 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52F37478@ESV4-MBX01.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.251] Content-Type: text/plain; charset="us-ascii" Content-ID: <2C7571AC4810C74E9AD20552A04F1C71@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dmarc-ietf] A l'abordage! X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 22:21:05 -0000 Arrrr!=20 Let me state a few things. You may not agree with them all but this is wher= e my thinking is at the moment. There is no problem between DMARC and mailing lists. People want emails coming from the mailing lists they subscribed to There is little spam/phishing on mailing lists as if there is, either the l= ist admin resolve the spam source, or the members fork another mailing list We should also document that MS-Exchange by design cannot preserve DKIM whe= n forwarding (this statement may not be completely true, but so far it seem= s, please provide a counter example, I'm looking for one). Applying past lo= gic here, then DMARC is not for transaction emails too. Several hosting providers that break DKIM forwarding, are whitelisted as Kn= ow Forwarder, again if your users want these emails, you do what you need t= o do... Now, list admins cannot remove subscribers from domain with p=3Dreject manu= ally. I cannot stop people from subscribing to mailing lists despite the fa= ct I told them it would create problems. So manually does not scale. It may= work now, because DMARC is still new, but don't expect everyone to get all= the nuances the first time... List software must become DMARC aware like they became ADSP aware (not!) to= refuse subscription from domain with p=3Dreject, or not treat these bounce= towards the unsubscription count or send email aligned with DMARC. Is ther= e any list software that was modified to handle ADSP, I'm curious to know? = So far I feel, it is done manually because ADSP was not widely adopted (lik= e SPF -all). What would help list software is to recognize DMARC bounces, I think we hav= e not standardized in our implementations the bounce message so it can be r= ecognized by list software and ignored, so at least it does not unsubscribe= people that do DMARC or ADSP rejects. Lists have seldom DKIM signed their emails like any other domain. DMARC, as= well a few others technology, are encouraging all domains to implement DKI= M. Getting OAR in lists is also possible.=20 List-Post or List-Id are some good candidate to be identifiers of mailing l= ists (not sole identifiers), but I have noticed some ESPs use List-ID, ezm = does not use list-id. This is why, at the moment I don't know which one to = use. I need to know more what is in the wild out there. As Tim pointed it w= ould be nice to describe what is a mailing list and how to authenticate one= .... Anyway you toss it, list software needs some new code/process. So we are not discovering the pain with authentication and list software an= d some MTA implementations, it has been well documented. We are just now ex= periencing it to an acute level. What the pain will change, this is anyone'= s guess, but I don't think DMARC needs to be made more aware of mailing lis= ts than it is today. What people needs to understand, there are mailing lis= ts, people want the email, what best strategies to recognize safely enough = mailing lists. From prvs=81035173e=fmartin@linkedin.com Mon Apr 15 15:23:38 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B7321F93D8 for ; Mon, 15 Apr 2013 15:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.964 X-Spam-Level: X-Spam-Status: No, score=-6.964 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t3lWFdawnvU for ; Mon, 15 Apr 2013 15:23:37 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 08F1D21F8D28 for ; Mon, 15 Apr 2013 15:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1366064570; x=1397600570; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X/ogyS+kgyqK9Q+Rd0hQNhHlu0IeRrLEo6cvUk0gAHo=; b=zH0sJZkFLrbSyFSvToKJkYS9ADUWDfcPw26SPZLaea2t9+V1RurpBqCn WD/GpuW/tsyH5Ylce9ZZBd/pYleiurxE7TPZ/SsFweoZkjDyAMzhvamQ8 5tsX3+Bkij5MG3F+RjYQf/+04lks2MVqx+yDYrfZ1hBdPsbWSmqFmJR7T 4=; X-IronPort-AV: E=Sophos;i="4.87,479,1363158000"; d="scan'208,217";a="45331296" Received: from ESV4-MBX01.linkedin.biz ([fe80::d029:a1fa:62c4:2641]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.02.0328.011; Mon, 15 Apr 2013 15:22:46 -0700 From: Franck Martin To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOiba9KNX4PAN206ebA08XeA67pjYUJIA Date: Mon, 15 Apr 2013 22:22:45 +0000 Message-ID: <77426B543150464AA3F30DF1A91365DE52F37495@ESV4-MBX01.linkedin.biz> References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it> <77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz> <5165A993.50208@gmail.com> <5166758F.1040906@tana.it> <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> <516BE652.5010604@tana.it> <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.251] Content-Type: multipart/alternative; boundary="_000_77426B543150464AA3F30DF1A91365DE52F37495ESV4MBX01linked_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 22:23:38 -0000 --_000_77426B543150464AA3F30DF1A91365DE52F37495ESV4MBX01linked_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Apr 16, 2013, at 12:16 AM, Murray S. Kucherawy > wrote: On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez > wrote: Nice theory. How many of the big four/five mailbox providers (Gmail, Hotmai= l, Yahoo, AOL...) who have originally come up privately with DMARC (in coor= dination with sending brand owners like Paypal, Ebay, Facebook, etc.) are f= ollowing "p=3Dreject" to the letter? I think the number is zero. Why? Becau= se the theory is nice and clean, the real world not so much. At a minimum, Gmail and Facebook are indeed rejecting based on DMARC failur= es. I don't know about the others. They do have exceptions... --_000_77426B543150464AA3F30DF1A91365DE52F37495ESV4MBX01linked_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <63EF38E13BE8AC45AAF5C3CCC34ED385@linkedin.com> Content-Transfer-Encoding: quoted-printable
On Apr 16, 2013, at 12:16 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
Nice theory. How many of the big four/five mailbox providers (Gmail, Hotmai= l, Yahoo, AOL...) who have originally come up privately with DMARC (in coor= dination with sending brand owners like Paypal, Ebay, Facebook, etc.) are f= ollowing "p=3Dreject" to the letter? I think the number is zero. Why? Because the theory is nice and clean, the= real world not so much.

At a minimum, Gmail and Facebook are indeed rejecting based on DMARC failur= es.  I don't know about the others.
 

They do have exceptions...

--_000_77426B543150464AA3F30DF1A91365DE52F37495ESV4MBX01linked_-- From jgomez@seryrich.com Mon Apr 15 16:09:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F188F21E8039 for ; Mon, 15 Apr 2013 16:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSjMXWiJU3Sd for ; Mon, 15 Apr 2013 16:09:51 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id DFC2F21E8037 for ; Mon, 15 Apr 2013 16:09:50 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 01:09:48 +0200 Message-ID: <1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local> From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><5165242C.2030007@tana.it><77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz><5165A993.50208@gmail.com><5166758F.1040906@tana.it><408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net><516BE652.5010604@tana.it><5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> Date: Tue, 16 Apr 2013 01:10:32 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01CE3A3F.3147C1E0" 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] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:09:52 -0000 ------=_NextPart_000_00F2_01CE3A3F.3147C1E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does that mean that you (who are using a Gmail.com account to subscribe = to this list) are not receiving emails from Franck Martin (who is using = a linkedin.com address --which is sporting a DMARC record of = "p=3Dreject"-- to subscribe to this list) addressed to this mailing = list? Hmm, but I've read you replying to him. What am I missing here? Regards, J. Gomez ---- Original Message ---- From: Murray S. Kucherawy To: J. G=F3mez Cc: dmarc@ietf.org Sent: Tuesday, April 16, 2013 12:16 AM Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies=20 > On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez wrote: >=20 > Nice theory. How many of the big four/five mailbox providers (Gmail, > Hotmail, Yahoo, AOL...) who have originally come up privately with > DMARC (in coordination with sending brand owners like Paypal, Ebay, > Facebook, etc.) are following "p=3Dreject" to the letter? I think the > number is zero. Why? Because the theory is nice and clean, the real > world not so much. =20 >=20 >=20 > At a minimum, Gmail and Facebook are indeed rejecting based on DMARC > failures. I don't know about the others.=20 >=20 >=20 >=20 > -MSK ------=_NextPart_000_00F2_01CE3A3F.3147C1E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Does that mean that you (who are using a Gmail.com = account to=20 subscribe to this list) are not receiving emails from Franck Martin (who = is=20 using a linkedin.com address --which is sporting a DMARC record of = "p=3Dreject"--=20 to subscribe to this list) addressed to this mailing list?
 
Hmm, but I've read you replying to him. What am I = missing=20 here?
 
Regards,
 
J. Gomez
 
 
---- Original Message ----
From: Murray S. Kucherawy
To: J.=20 G=F3mez
Cc: dmarc@ietf.org
Sent: Tuesday, April 16, 2013 12:16=20 AM
Subject: Re: [dmarc-ietf] the endless mailing list silliness, was=20 not
about outsourcing strategies

> On Mon, Apr 15, 2013 at = 3:04=20 PM, J. Gomez <jgomez@seryrich.com> wrote:
>
> Nice = theory.=20 How many of the big four/five mailbox providers (Gmail,
> Hotmail, = Yahoo,=20 AOL...) who have originally come up privately with
> DMARC (in=20 coordination with sending brand owners like Paypal, Ebay,
> = Facebook,=20 etc.) are following "p=3Dreject" to the letter? I think the
> = number is=20 zero. Why? Because the theory is nice and clean, the real
> world = not so=20 much.    
>
>
> At a minimum, = Gmail and=20 Facebook are indeed rejecting based on DMARC
> failures.  I = don't=20 know about the others.
>
>
>
>=20 -MSK
------=_NextPart_000_00F2_01CE3A3F.3147C1E0-- From sklist@kitterman.com Mon Apr 15 16:17:11 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526F021F9132 for ; Mon, 15 Apr 2013 16:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqIIOqm99hBc for ; Mon, 15 Apr 2013 16:17:10 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7334021F9120 for ; Mon, 15 Apr 2013 16:17:10 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B255120E40FE; Mon, 15 Apr 2013 19:17:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366067829; bh=ZRCnR6OS4aH68wac5WFo7CMXdhiMimflvaH0BU0zl+8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kK3phS6FOIQYk9ana5rN0BUyaUC/hSVMDRBgdQHQIlpuO2a+qn1/XpE9AKeAiOp9T nPU+E5zQByX4zv/eSVwvx14Glw1hzeOymlf2VNDz1S5WghJWmKrVE7h00DfBxdDuZx xfeZ2FRTAU5wP+Vn1Ipj+Cz2oQWlvLw+3MEOvBZ8= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 9F5B220E4076; Mon, 15 Apr 2013 19:17:09 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 15 Apr 2013 19:17:09 -0400 Message-ID: <7044732.h21xgsJhV9@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local> References: <20130409164432.68830.qmail@joyce.lan> <1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:17:11 -0000 Perhaps that Gmail uses it's own methods to determine what it thinks is= mail=20 from a mailing list and then doesn't reject/quarantine those solely due= to=20 DMARC. Scott K On Tuesday, April 16, 2013 01:10:32 AM J. Gomez wrote: > Does that mean that you (who are using a Gmail.com account to subscri= be to > this list) are not receiving emails from Franck Martin (who is using = a > linkedin.com address --which is sporting a DMARC record of "p=3Drejec= t"-- to > subscribe to this list) addressed to this mailing list? >=20 > Hmm, but I've read you replying to him. What am I missing here? >=20 > Regards, >=20 > J. Gomez >=20 >=20 > ---- Original Message ---- > From: Murray S. Kucherawy > To: J. G=F3mez > Cc: dmarc@ietf.org > Sent: Tuesday, April 16, 2013 12:16 AM > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not= > about outsourcing strategies >=20 > > On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez wro= te: > >=20 > > Nice theory. How many of the big four/five mailbox providers (Gmail= , > > Hotmail, Yahoo, AOL...) who have originally come up privately with > > DMARC (in coordination with sending brand owners like Paypal, Ebay,= > > Facebook, etc.) are following "p=3Dreject" to the letter? I think t= he > > number is zero. Why? Because the theory is nice and clean, the real= > > world not so much. > >=20 > >=20 > > At a minimum, Gmail and Facebook are indeed rejecting based on DMAR= C > > failures. I don't know about the others. > >=20 > >=20 > >=20 > > -MSK From jgomez@seryrich.com Mon Apr 15 16:20:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E06221F936C for ; Mon, 15 Apr 2013 16:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiVGXQPG09Vo for ; Mon, 15 Apr 2013 16:20:58 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 33E8A21F935B for ; Mon, 15 Apr 2013 16:20:56 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 01:20:54 +0200 Message-ID: From: "J. Gomez" To: References: <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net><20130415113337.8535.qmail@joyce.lan> Date: Tue, 16 Apr 2013 01:21:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:20:59 -0000 Josh Aberant wrote: > As another stakeholder with a domain that has users and p=3Dreject, it > seems to me that simply saying the DMARC reject shouldn't be used on > domains with users will significantly limit the potential value of > DMARC to the email community. +1 Is DMARC going to be tailor made for big-brand Senders and to hell with = the rest? Saying "p=3Dreject" should not be used by domain owners with real users = behind their domains is ... I cannot find the words ... but "very = not-nice" would be about right. If that is the state of DMARC, then DMARC needs to improve. And we know = it. Regards, J. Gomez From jgomez@seryrich.com Mon Apr 15 16:26:08 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F1421F9350 for ; Mon, 15 Apr 2013 16:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.708 X-Spam-Level: X-Spam-Status: No, score=-3.708 tagged_above=-999 required=5 tests=[AWL=0.891, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uJrbeSfRXLj for ; Mon, 15 Apr 2013 16:26:06 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 61D3A21F9377 for ; Mon, 15 Apr 2013 16:26:06 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 01:26:05 +0200 Message-ID: From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local> <7044732.h21xgsJhV9@scott-latitude-e6320> Date: Tue, 16 Apr 2013 01:26:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:26:08 -0000 So are you saying that Gmail does not follow DMARC's "p=3Dreject" to the = letter, and just uses it as an additional input for its internal scoring = system? Then that would take Gmail out of the list of the big four/five mailbox = providers who are following DMARC's "p=3Dreject" to the letter, don't = you think? Regards, J. Gomez On Tuesday, April 16, 2013 1:17 AM [GMT+1=3DCET], Scott Kitterman wrote: > Perhaps that Gmail uses it's own methods to determine what it thinks > is mail from a mailing list and then doesn't reject/quarantine those > solely due to DMARC. >=20 > Scott K >=20 > On Tuesday, April 16, 2013 01:10:32 AM J. Gomez wrote: > > Does that mean that you (who are using a Gmail.com account to > > subscribe to this list) are not receiving emails from Franck Martin > > (who is using a linkedin.com address --which is sporting a DMARC > > record of "p=3Dreject"-- to subscribe to this list) addressed to = this > > mailing list?=20 > >=20 > > Hmm, but I've read you replying to him. What am I missing here? > >=20 > > Regards, > >=20 > > J. Gomez > >=20 > >=20 > > ---- Original Message ---- > > From: Murray S. Kucherawy > > To: J. G=F3mez > > Cc: dmarc@ietf.org > > Sent: Tuesday, April 16, 2013 12:16 AM > > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was > > not about outsourcing strategies > >=20 > > > On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez > > > wrote:=20 > > >=20 > > > Nice theory. How many of the big four/five mailbox providers > > > (Gmail, Hotmail, Yahoo, AOL...) who have originally come up > > > privately with DMARC (in coordination with sending brand owners > > > like Paypal, Ebay, Facebook, etc.) are following "p=3Dreject" to > > > the letter? I think the number is zero. Why? Because the theory > > > is nice and clean, the real world not so much. > > >=20 > > >=20 > > > At a minimum, Gmail and Facebook are indeed rejecting based on > > > DMARC failures. I don't know about the others. > > >=20 > > >=20 > > >=20 > > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From sklist@kitterman.com Mon Apr 15 16:26:25 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBFB21F9377 for ; Mon, 15 Apr 2013 16:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3yY7mel-z4c for ; Mon, 15 Apr 2013 16:26:24 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id A242E21F9350 for ; Mon, 15 Apr 2013 16:26:24 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2F81A20E40FE; Mon, 15 Apr 2013 19:26:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366068384; bh=K5HGIwNawyyEy+S6019uF9wUp04A+WaNt8ytCD6OFSQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RMqiVnYUD7Wjj3/WImyHJSTtM4HMaL/sQgSmXNIjkip/5tTPc2IW/DROFtcO66gEI 7Fufy3ezKtzpEFSZxBP1Wod6ZyYuFi+VTq04fNdHuKcSCrD1qJ/WiHopT7ZfQ0JaYr 1Iybh9bqz+CmH5mEj0AihB8EPMwbBM+BBt14eP/s= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 16BFA20E4076; Mon, 15 Apr 2013 19:26:23 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 15 Apr 2013 19:26:23 -0400 Message-ID: <1946344.m9L2FqAt94@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:26:25 -0000 On Tuesday, April 16, 2013 01:21:38 AM J. Gomez wrote: > Josh Aberant wrote: > > As another stakeholder with a domain that has users and p=reject, it > > seems to me that simply saying the DMARC reject shouldn't be used on > > domains with users will significantly limit the potential value of > > DMARC to the email community. > > +1 > > Is DMARC going to be tailor made for big-brand Senders and to hell with the > rest? > > Saying "p=reject" should not be used by domain owners with real users behind > their domains is ... I cannot find the words ... but "very not-nice" would > be about right. > > If that is the state of DMARC, then DMARC needs to improve. And we know it. I think it is what it is. I've read all these threads and I've yet to see any suggestion that would improve the situation without changing DMARC into something it is not. It's not a panacea, and that's OK. Scott K From sklist@kitterman.com Mon Apr 15 16:28:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43CD21F93D7 for ; Mon, 15 Apr 2013 16:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTcbZyhk-9sO for ; Mon, 15 Apr 2013 16:28:35 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B6DA621F9377 for ; Mon, 15 Apr 2013 16:28:34 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4209720E40FE; Mon, 15 Apr 2013 19:28:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366068514; bh=G/qWO3r8A3am0ySctYmL9GGqnrgUu/mhSwdF5ltYb+w=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CNvQrJdkyqvIm1s5kLjJPHmsqllPzVEPMhEdL30NnlNn5o2QefwcKkZaJrA+Od0/l tAKOeefUxZkr3XLcyBWdeyLxymHIHmlj91rsZrPMbiJLj+xAFPq6Lu5PUSx6k79sl6 FKHRciN9cIL5AWR3nVOQNd90HjPDY5L5Y+dVhKxo= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 250DF20E4076; Mon, 15 Apr 2013 19:28:33 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 15 Apr 2013 19:28:33 -0400 Message-ID: <2537595.FIN36AxgiW@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <20130409164432.68830.qmail@joyce.lan> <7044732.h21xgsJhV9@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:28:35 -0000 No. I think receiver policies belong to the receiver and senders can w= ant=20 what they want, but it's up to receivers to decide. I think it would b= e fair=20 to say that "works fine with Gmail" isn't evidence that there's not an = issue=20 between DMARC and mailing lists, but RFCs aren't compliance specs that = some=20 internet standards inspector grades people on. The real world is what = is is=20 and if they are smart enough to use their data to work around the issue= , good=20 for them. Scott K On Tuesday, April 16, 2013 01:26:48 AM J. Gomez wrote: > So are you saying that Gmail does not follow DMARC's "p=3Dreject" to = the > letter, and just uses it as an additional input for its internal scor= ing > system? >=20 > Then that would take Gmail out of the list of the big four/five mailb= ox > providers who are following DMARC's "p=3Dreject" to the letter, don't= you > think? >=20 > Regards, >=20 > J. Gomez >=20 > On Tuesday, April 16, 2013 1:17 AM [GMT+1=3DCET], Scott Kitterman wro= te: > > Perhaps that Gmail uses it's own methods to determine what it think= s > > is mail from a mailing list and then doesn't reject/quarantine thos= e > > solely due to DMARC. > >=20 > > Scott K > >=20 > > On Tuesday, April 16, 2013 01:10:32 AM J. Gomez wrote: > > > Does that mean that you (who are using a Gmail.com account to > > > subscribe to this list) are not receiving emails from Franck Mart= in > > > (who is using a linkedin.com address --which is sporting a DMARC > > > record of "p=3Dreject"-- to subscribe to this list) addressed to = this > > > mailing list? > > >=20 > > > Hmm, but I've read you replying to him. What am I missing here? > > >=20 > > > Regards, > > >=20 > > > J. Gomez > > >=20 > > >=20 > > > ---- Original Message ---- > > > From: Murray S. Kucherawy > > > To: J. G=F3mez > > > Cc: dmarc@ietf.org > > > Sent: Tuesday, April 16, 2013 12:16 AM > > > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was= > > > not about outsourcing strategies > > >=20 > > > > On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez = > > > > wrote: > > > >=20 > > > > Nice theory. How many of the big four/five mailbox providers > > > > (Gmail, Hotmail, Yahoo, AOL...) who have originally come up > > > > privately with DMARC (in coordination with sending brand owners= > > > > like Paypal, Ebay, Facebook, etc.) are following "p=3Dreject" t= o > > > > the letter? I think the number is zero. Why? Because the theory= > > > > is nice and clean, the real world not so much. > > > >=20 > > > >=20 > > > > At a minimum, Gmail and Facebook are indeed rejecting based on > > > > DMARC failures. I don't know about the others. > > > >=20 > > > >=20 > > > >=20 > > > > -MSK > >=20 > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From MHammer@ag.com Mon Apr 15 16:34:05 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761F521F935B for ; Mon, 15 Apr 2013 16:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LNs+w0YZL+S for ; Mon, 15 Apr 2013 16:34:04 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE6E21F9349 for ; Mon, 15 Apr 2013 16:34:04 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 19:34:03 -0400 From: "MH Michael Hammer (5304)" To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOiU+l/uEMXNFiEqC4F/rpNusa5jX6RPw Date: Mon, 15 Apr 2013 23:34:02 +0000 Message-ID: References: <20130409164432.68830.qmail@joyce.lan> <5165242C.2030007@tana.it><77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz><5165A993.50208@gmail.com><5166758F.1040906@tana.it><408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net><516BE652.5010604@tana.it> <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> In-Reply-To: <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:34:05 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of J. Gomez > Sent: Monday, April 15, 2013 6:05 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not abo= ut > outsourcing strategies >=20 > On Monday, April 15, 2013 6:15 PM [GMT+1=3DCET], MH Michael Hammer > (5304) wrote: >=20 > > I'm going to top post (apologies). The bottom line is that when an > > (abused) sending domain publishes a p=3Dreject DMARC policy it is takin= g > > responsibility for any discarded legitimate mail that fails to pass - > > for whatever reason. As soon as a validator starts trying to determine > > which failing mail is legitimate, it takes back responsibility for any > > malicious mail (that failed to validate) which reaches an enduser. >=20 > Nice theory. How many of the big four/five mailbox providers (Gmail, > Hotmail, Yahoo, AOL...) who have originally come up privately with DMARC > (in coordination with sending brand owners like Paypal, Ebay, Facebook, e= tc.) > are following "p=3Dreject" to the letter? I think the number is zero. Why= ? > Because the theory is nice and clean, the real world not so much. >=20 >From my perspective, if we as a (website) sending domain (we have quite a f= ew) publish DMARC with a p=3Dreject policy then we are asking any mailbox p= rovider to do just that. If an enduser (generally NOT our customers) contac= ts us about an abusive email that would/should have been rejected if DMARC = were followed, our customer service folks are instructed to let the enduser= know it is fraudulent and that they wouldn't have received that email if t= heir ISP/mailbox provider/mail admin were checking and following SPF/DKIM/D= MARC. DMARC is not a magic bullet that solves all problems. It does do a go= od job of mitigating direct domain abuse. I've got a corpus of a billion+ (= can't say how much the + equals) sent messages (with feedback) that tells m= e it works as described if implemented in an appropriate manner. And yes, my organization is a participant in dmarc.org. To answer your ques= tion about mailbox providers following p=3Dreject to the letter, to the ext= ent that they don't, the responsibility for letting badness through to thei= r customers is back on their shoulders. As always, mailbox providers will d= o what they wish (I've been waiting for John Levine to invoke King Canute) = once a message gets to their systems. > > Don't muddy the waters. Sending domains with endusers should not allow > > those endusers to subscribe to maillists from that domain. >=20 > Oh, man. Oh, man. I would vote you for President. >=20 I appreciate the vote of confidence. I'll point out that a domain with endu= sers CAN publish a policy of p=3Dquarantine without causing the worst of th= e problems for maillist operators. That may cause problems for individuals = from the domain that post to a list (presumably their posts will disappear = from the perspective of some (unknown) number of list participants unless t= hey are checking their quarantine folders. There may also be the potential = for reputation damage to the sending domain in this example but I don't hav= e enough data points to speak to that. I don't know how many times it needs= to be said that p=3Dreject is not appropriate for all sending domains. It = is a strong policy statement appropriate for domains that have good control= over their mailstreams. Mike=20 From tim@eudaemon.net Mon Apr 15 16:34:33 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E92F21F9387 for ; Mon, 15 Apr 2013 16:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY9+ZHiRElEu for ; Mon, 15 Apr 2013 16:34:33 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 17FF721F935B for ; Mon, 15 Apr 2013 16:34:33 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 390BFCB46; Mon, 15 Apr 2013 19:35:10 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Tim Draegen X-Priority: 3 In-Reply-To: Date: Mon, 15 Apr 2013 19:34:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130409164432.68830.qmail@joyce.lan><1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local> <7044732.h21xgsJhV9@scott-latitude-e6320> To: J. Gomez X-Mailer: Apple Mail (2.1503) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:34:33 -0000 On Apr 15, 2013, at 7:26 PM, J. Gomez wrote: > So are you saying that Gmail does not follow DMARC's "p=3Dreject" to = the letter, and just uses it as an additional input for its internal = scoring system? This is not the case. GMail has implemented DMARC; if they do *not* = enforce policy, you'll see why under the "override" section of the = corresponding XML. HTH, =3D- Tim > Then that would take Gmail out of the list of the big four/five = mailbox providers who are following DMARC's "p=3Dreject" to the letter, = don't you think? From jgomez@seryrich.com Mon Apr 15 16:36:42 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA53421E8039 for ; Mon, 15 Apr 2013 16:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[AWL=0.764, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoHSCU3rW4cf for ; Mon, 15 Apr 2013 16:36:42 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id A2C2021E8037 for ; Mon, 15 Apr 2013 16:36:41 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 01:36:40 +0200 Message-ID: From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><7044732.h21xgsJhV9@scott-latitude-e6320> <2537595.FIN36AxgiW@scott-latitude-e6320> Date: Tue, 16 Apr 2013 01:37:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:36:42 -0000 Fine. And don't you think that the "l=3D" tag could potentially help = other receivers without Google's IT department to also "work around the = issue"? On Tuesday, April 16, 2013 1:28 AM [GMT+1=3DCET], Scott Kitterman wrote: > No. I think receiver policies belong to the receiver and senders can > want what they want, but it's up to receivers to decide. I think it > would be fair to say that "works fine with Gmail" isn't evidence that > there's not an issue between DMARC and mailing lists, but RFCs aren't > compliance specs that some internet standards inspector grades people > on. The real world is what is is and if they are smart enough to use > their data to work around the issue, good for them. >=20 > Scott K >=20 > On Tuesday, April 16, 2013 01:26:48 AM J. Gomez wrote: > > So are you saying that Gmail does not follow DMARC's "p=3Dreject" to > > the letter, and just uses it as an additional input for its > > internal scoring system? > >=20 > > Then that would take Gmail out of the list of the big four/five > > mailbox providers who are following DMARC's "p=3Dreject" to the > > letter, don't you think? > >=20 > > Regards, > >=20 > > J. Gomez > >=20 > > On Tuesday, April 16, 2013 1:17 AM [GMT+1=3DCET], Scott Kitterman > > wrote:=20 > > > Perhaps that Gmail uses it's own methods to determine what it > > > thinks is mail from a mailing list and then doesn't > > > reject/quarantine those solely due to DMARC. > > >=20 > > > Scott K > > >=20 > > > On Tuesday, April 16, 2013 01:10:32 AM J. Gomez wrote: > > > > Does that mean that you (who are using a Gmail.com account to > > > > subscribe to this list) are not receiving emails from Franck > > > > Martin (who is using a linkedin.com address --which is sporting > > > > a DMARC record of "p=3Dreject"-- to subscribe to this list) > > > > addressed to this mailing list? > > > >=20 > > > > Hmm, but I've read you replying to him. What am I missing here? > > > >=20 > > > > Regards, > > > >=20 > > > > J. Gomez > > > >=20 > > > >=20 > > > > ---- Original Message ---- > > > > From: Murray S. Kucherawy > > > > To: J. G=F3mez > > > > Cc: dmarc@ietf.org > > > > Sent: Tuesday, April 16, 2013 12:16 AM > > > > Subject: Re: [dmarc-ietf] the endless mailing list silliness, > > > > was not about outsourcing strategies > > > >=20 > > > > > On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez > > > > > wrote: > > > > >=20 > > > > > Nice theory. How many of the big four/five mailbox providers > > > > > (Gmail, Hotmail, Yahoo, AOL...) who have originally come up > > > > > privately with DMARC (in coordination with sending brand > > > > > owners like Paypal, Ebay, Facebook, etc.) are following > > > > > "p=3Dreject" to the letter? I think the number is zero. Why? > > > > > Because the theory is nice and clean, the real world not so > > > > > much.=20 > > > > >=20 > > > > >=20 > > > > > At a minimum, Gmail and Facebook are indeed rejecting based on > > > > > DMARC failures. I don't know about the others. > > > > >=20 > > > > >=20 > > > > >=20 > > > > > -MSK > > >=20 > > > _______________________________________________ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > >=20 > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From zwicky@yahoo-inc.com Mon Apr 15 16:44:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019EF21E8039 for ; Mon, 15 Apr 2013 16:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.599 X-Spam-Level: X-Spam-Status: No, score=-20.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkp-PlaPvRCj for ; Mon, 15 Apr 2013 16:44:34 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3405C21E8037 for ; Mon, 15 Apr 2013 16:44:34 -0700 (PDT) Received: from GQ1-EX10-CAHT17.y.corp.yahoo.com (gq1-ex10-caht17.corp.gq1.yahoo.com [10.73.119.198]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r3FNi4e4003130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Apr 2013 16:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1366069447; bh=1T5BUNegtyHDf/TaZKEPiQ0T08ILjk7q+R3ogfXg4Uw=; h=From:To:Subject:Date:Message-ID:In-Reply-To:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=j/whP00i8W5PiJnSiYE4buvBqAVss9lv8hIoX5X3L6RiiMkSQvVSVZ4/19pU//U2U 9A3hc3DwL1XuEeKKwJngpRl+RL1f++q/ShKqRwNg+Y/aNYi0JfXKq2W/zdXF0hHQMs Y8tNVZONjInOPoOwdKdpe7h8+S0tr3FKnGqajX58= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT17.y.corp.yahoo.com ([fe80::55aa:58ee:1792:e6fd%14]) with mapi id 14.02.0342.003; Mon, 15 Apr 2013 16:44:05 -0700 From: Elizabeth Zwicky To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOjMdjut1/og+mkm0vbjbowLWIw== Date: Mon, 15 Apr 2013 23:44:05 +0000 Message-ID: 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.2.130206 x-originating-ip: [216.145.54.50] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 069447003 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:44:35 -0000 No, because the hard part is figuring out what's a valid mailing list, not what the sending domain thinks about mailing lists. Elizabeth On 4/15/13 4:37 PM, "J. Gomez" wrote: >Fine. And don't you think that the "l=3D" tag could potentially help other >receivers without Google's IT department to also "work around the issue"? > > >On Tuesday, April 16, 2013 1:28 AM [GMT+1=3DCET], Scott Kitterman wrote: > >> No. I think receiver policies belong to the receiver and senders can >> want what they want, but it's up to receivers to decide. I think it >> would be fair to say that "works fine with Gmail" isn't evidence that >> there's not an issue between DMARC and mailing lists, but RFCs aren't >> compliance specs that some internet standards inspector grades people >> on. The real world is what is is and if they are smart enough to use >> their data to work around the issue, good for them. >>=20 >> Scott K >>=20 >> On Tuesday, April 16, 2013 01:26:48 AM J. Gomez wrote: >> > So are you saying that Gmail does not follow DMARC's "p=3Dreject" to >> > the letter, and just uses it as an additional input for its >> > internal scoring system? >> >=20 >> > Then that would take Gmail out of the list of the big four/five >> > mailbox providers who are following DMARC's "p=3Dreject" to the >> > letter, don't you think? >> >=20 >> > Regards, >> >=20 >> > J. Gomez >> >=20 >> > On Tuesday, April 16, 2013 1:17 AM [GMT+1=3DCET], Scott Kitterman >> > wrote:=20 >> > > Perhaps that Gmail uses it's own methods to determine what it >> > > thinks is mail from a mailing list and then doesn't >> > > reject/quarantine those solely due to DMARC. >> > >=20 >> > > Scott K >> > >=20 >> > > On Tuesday, April 16, 2013 01:10:32 AM J. Gomez wrote: >> > > > Does that mean that you (who are using a Gmail.com account to >> > > > subscribe to this list) are not receiving emails from Franck >> > > > Martin (who is using a linkedin.com address --which is sporting >> > > > a DMARC record of "p=3Dreject"-- to subscribe to this list) >> > > > addressed to this mailing list? >> > > >=20 >> > > > Hmm, but I've read you replying to him. What am I missing here? >> > > >=20 >> > > > Regards, >> > > >=20 >> > > > J. Gomez >> > > >=20 >> > > >=20 >> > > > ---- Original Message ---- >> > > > From: Murray S. Kucherawy >> > > > To: J. G=F3mez >> > > > Cc: dmarc@ietf.org >> > > > Sent: Tuesday, April 16, 2013 12:16 AM >> > > > Subject: Re: [dmarc-ietf] the endless mailing list silliness, >> > > > was not about outsourcing strategies >> > > >=20 >> > > > > On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez >> > > > > wrote: >> > > > >=20 >> > > > > Nice theory. How many of the big four/five mailbox providers >> > > > > (Gmail, Hotmail, Yahoo, AOL...) who have originally come up >> > > > > privately with DMARC (in coordination with sending brand >> > > > > owners like Paypal, Ebay, Facebook, etc.) are following >> > > > > "p=3Dreject" to the letter? I think the number is zero. Why? >> > > > > Because the theory is nice and clean, the real world not so >> > > > > much.=20 >> > > > >=20 >> > > > >=20 >> > > > > At a minimum, Gmail and Facebook are indeed rejecting based on >> > > > > DMARC failures. I don't know about the others. >> > > > >=20 >> > > > >=20 >> > > > >=20 >> > > > > -MSK >> > >=20 >> > > _______________________________________________ >> > > dmarc mailing list >> > > dmarc@ietf.org >> > > https://www.ietf.org/mailman/listinfo/dmarc >> >=20 >> > _______________________________________________ >> > dmarc mailing list >> > dmarc@ietf.org >> > https://www.ietf.org/mailman/listinfo/dmarc >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From prvs=810c9828a=kandersen@linkedin.com Mon Apr 15 16:45:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D8C21E803D for ; Mon, 15 Apr 2013 16:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.665 X-Spam-Level: X-Spam-Status: No, score=-5.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKgqmiRnRQko for ; Mon, 15 Apr 2013 16:45:51 -0700 (PDT) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id CB0FC21E8039 for ; Mon, 15 Apr 2013 16:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1366069550; x=1397605550; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=MPfBBbTbKOYMWBUaQahIwfX8zA0espCchFILqJWtv4U=; b=ORZvrkeYlLbCxJQnOu28dC5kTEJ7Ax60RrgJDFEubEodRuGd56xOSm2U Kc8Hq2YPSyGmntEM6yYq0cqEfWlw8t1rNTPIbzdGMgUgJycrqjSGv5pxl vVC+1oCwdy+jMXyVQ+7oBJ57JkwOmW2LIQtCF8tFRfP090t354a32xzlc o=; X-IronPort-AV: E=Sophos;i="4.87,479,1363158000"; d="scan'208";a="45339505" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Mon, 15 Apr 2013 16:45:43 -0700 Received: from ESV4-EXC02.linkedin.biz ([fe80::4d74:48bd:e0bd:13ee]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 16:45:43 -0700 From: Kurt Andersen To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOjG3PskaR8q+C0KF9giNCnqeQZjX8k6A Date: Mon, 15 Apr 2013 23:45:43 +0000 Message-ID: <3560C13B3A3EC9408B4BFEDB3B728395096719BD@ESV4-EXC02.linkedin.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.254] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:45:52 -0000 On 2013-04-15 16:34 , "MH Michael Hammer (5304)" wrote: >I don't know how many times it needs to be said that p=3Dreject is not >appropriate for all sending domains. It is a strong policy statement >appropriate for domains that have good control over their mailstreams. I think that it is important to point out that there is also a significant element of business cooperation required too. If a business decides that they want a singular domain presence, all the control in the world won't do a bit of good. And lists which impose a domain-based membership criterion contribute to the problem IMO (you can only join the list if you work for example.com, and have an email address @example.com but example.com has p=3Dreject). --Kurt From jgomez@seryrich.com Mon Apr 15 16:48:48 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9721F8C4F for ; Mon, 15 Apr 2013 16:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynHFzzRup41i for ; Mon, 15 Apr 2013 16:48:48 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 4917121F936C for ; Mon, 15 Apr 2013 16:48:47 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 01:48:39 +0200 Message-ID: <7232F9622BC34D3797786BADF5C72EAA@fgsr.local> From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local> <7044732.h21xgsJhV9@scott-latitude-e6320> Date: Tue, 16 Apr 2013 01:49:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:48:48 -0000 If the sending domain owner publishes through DMARC a policy of = "p=3Dreject", and the receiver chooses not to enforce that policy, I = think it takes a great deal of word-twisting to say that such a receiver = is following "p=3Dreject" to the letter. Also, in DMARC "p=3D" is mandatory, whereas reporting is optional. To = make opting out of the mandatory part of the standard be predicated on = the optional part of the standard, is not what I would call "a proper = thing". This is beginnig to resemble a political debate about the fiscal = cliff... Regards, J. Gomez On Tuesday, April 16, 2013 1:34 AM [GMT+1=3DCET], Tim Draegen wrote: > On Apr 15, 2013, at 7:26 PM, J. Gomez wrote: > > So are you saying that Gmail does not follow DMARC's "p=3Dreject" to > > the letter, and just uses it as an additional input for its > > internal scoring system? =20 >=20 > This is not the case. GMail has implemented DMARC; if they do *not* > enforce policy, you'll see why under the "override" section of the > corresponding XML. =20 >=20 > HTH, > =3D- Tim >=20 > > Then that would take Gmail out of the list of the big four/five > > mailbox providers who are following DMARC's "p=3Dreject" to the > > letter, don't you think? From jgomez@seryrich.com Mon Apr 15 16:51:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EF521F936C for ; Mon, 15 Apr 2013 16:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.005 X-Spam-Level: X-Spam-Status: No, score=-4.005 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIOY8JBIFpQg for ; Mon, 15 Apr 2013 16:51:46 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5921F8E6A for ; Mon, 15 Apr 2013 16:51:45 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 01:51:44 +0200 Message-ID: <9830A1942A13442DAC646F24ACBC9224@fgsr.local> From: "J. Gomez" To: References: Date: Tue, 16 Apr 2013 01:52:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:51:47 -0000 The "l=3D" tag is not about what the sending domain "thinks" about = mailing lists, but about whether the sending domain "uses" mailing lists = or not. On Tuesday, April 16, 2013 1:44 AM [GMT+1=3DCET], Elizabeth Zwicky = wrote: > No, because the hard part is figuring out what's a valid mailing > list, not what the sending domain thinks about mailing lists. >=20 > Elizabeth >=20 > On 4/15/13 4:37 PM, "J. Gomez" wrote: >=20 > > Fine. And don't you think that the "l=3D" tag could potentially help > > other receivers without Google's IT department to also "work around > > the issue"?=20 > >=20 > >=20 > > On Tuesday, April 16, 2013 1:28 AM [GMT+1=3DCET], Scott Kitterman > > wrote:=20 > >=20 > > > No. I think receiver policies belong to the receiver and senders > > > can want what they want, but it's up to receivers to decide. I > > > think it would be fair to say that "works fine with Gmail" isn't > > > evidence that there's not an issue between DMARC and mailing > > > lists, but RFCs aren't compliance specs that some internet > > > standards inspector grades people on. The real world is what is > > > is and if they are smart enough to use their data to work around > > > the issue, good for them.=20 > > >=20 > > > Scott K > > >=20 > > > On Tuesday, April 16, 2013 01:26:48 AM J. Gomez wrote: > > > > So are you saying that Gmail does not follow DMARC's = "p=3Dreject" > > > > to the letter, and just uses it as an additional input for its > > > > internal scoring system? > > > >=20 > > > > Then that would take Gmail out of the list of the big four/five > > > > mailbox providers who are following DMARC's "p=3Dreject" to the > > > > letter, don't you think? > > > >=20 > > > > Regards, > > > >=20 > > > > J. Gomez > > > >=20 > > > > On Tuesday, April 16, 2013 1:17 AM [GMT+1=3DCET], Scott = Kitterman > > > > wrote: > > > > > Perhaps that Gmail uses it's own methods to determine what it > > > > > thinks is mail from a mailing list and then doesn't > > > > > reject/quarantine those solely due to DMARC. > > > > >=20 > > > > > Scott K > > > > >=20 > > > > > On Tuesday, April 16, 2013 01:10:32 AM J. Gomez wrote: > > > > > > Does that mean that you (who are using a Gmail.com account > > > > > > to subscribe to this list) are not receiving emails from > > > > > > Franck Martin (who is using a linkedin.com address --which > > > > > > is sporting a DMARC record of "p=3Dreject"-- to subscribe to > > > > > > this list) addressed to this mailing list? > > > > > >=20 > > > > > > Hmm, but I've read you replying to him. What am I missing > > > > > > here?=20 > > > > > >=20 > > > > > > Regards, > > > > > >=20 > > > > > > J. Gomez > > > > > >=20 > > > > > >=20 > > > > > > ---- Original Message ---- > > > > > > From: Murray S. Kucherawy > > > > > > To: J. G=F3mez > > > > > > Cc: dmarc@ietf.org > > > > > > Sent: Tuesday, April 16, 2013 12:16 AM > > > > > > Subject: Re: [dmarc-ietf] the endless mailing list > > > > > > silliness, was not about outsourcing strategies > > > > > >=20 > > > > > > > On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez > > > > > > > wrote: > > > > > > >=20 > > > > > > > Nice theory. How many of the big four/five mailbox > > > > > > > providers (Gmail, Hotmail, Yahoo, AOL...) who have > > > > > > > originally come up privately with DMARC (in coordination > > > > > > > with sending brand owners like Paypal, Ebay, Facebook, > > > > > > > etc.) are following "p=3Dreject" to the letter? I think = the > > > > > > > number is zero. Why? Because the theory is nice and > > > > > > > clean, the real world not so much. > > > > > > >=20 > > > > > > >=20 > > > > > > > At a minimum, Gmail and Facebook are indeed rejecting > > > > > > > based on DMARC failures. I don't know about the others. > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > -MSK > > > > >=20 > > > > > _______________________________________________ > > > > > dmarc mailing list > > > > > dmarc@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dmarc > > > >=20 > > > > _______________________________________________ > > > > dmarc mailing list > > > > dmarc@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dmarc > > > _______________________________________________ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc From MHammer@ag.com Mon Apr 15 16:53:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95FF21F9305 for ; Mon, 15 Apr 2013 16:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuLBvQh4AI08 for ; Mon, 15 Apr 2013 16:53:14 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3087421F925A for ; Mon, 15 Apr 2013 16:53:14 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 19:53:13 -0400 From: "MH Michael Hammer (5304)" To: Kurt Andersen , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOjNeJdYk+5VzI0Sg0Y4eT3VcYJjX8zWw Date: Mon, 15 Apr 2013 23:53:13 +0000 Message-ID: References: <3560C13B3A3EC9408B4BFEDB3B728395096719BD@ESV4-EXC02.linkedin.biz> In-Reply-To: <3560C13B3A3EC9408B4BFEDB3B728395096719BD@ESV4-EXC02.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:53:15 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Kurt Andersen > Sent: Monday, April 15, 2013 7:46 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not abo= ut > outsourcing strategies >=20 > On 2013-04-15 16:34 , "MH Michael Hammer (5304)" > wrote: >=20 > >I don't know how many times it needs to be said that p=3Dreject is not > >appropriate for all sending domains. It is a strong policy statement > >appropriate for domains that have good control over their mailstreams. >=20 > I think that it is important to point out that there is also a significan= t element > of business cooperation required too. If a business decides that they wan= t a > singular domain presence, all the control in the world won't do a bit of = good. > And lists which impose a domain-based membership criterion contribute to > the problem IMO (you can only join the list if you work for example.com, = and > have an email address @example.com but example.com has p=3Dreject). >=20 > --Kurt >=20 So the choice of ice cream offered is chocolate or vanilla. The domain owne= r wants Neapolitan. That is not on the menu. If a business makes the busine= ss decision that they want a singular domain presence AND they choose to pu= blish p=3Dreject then it becomes a case of: Domain: "Dr., it hurts when I do that." Dr.: "Then don't do that". Mike From jgomez@seryrich.com Mon Apr 15 16:59:36 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7C21F93CD for ; Mon, 15 Apr 2013 16:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.764 X-Spam-Level: X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMO6oIo4bwdZ for ; Mon, 15 Apr 2013 16:59:35 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id B84B721F93BD for ; Mon, 15 Apr 2013 16:59:34 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 01:59:33 +0200 Message-ID: <1085D7C277BA4865B8D5753C3C4D4155@fgsr.local> From: "J. Gomez" To: References: <3560C13B3A3EC9408B4BFEDB3B728395096719BD@ESV4-EXC02.linkedin.biz> Date: Tue, 16 Apr 2013 02:00:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 15 Apr 2013 23:59:36 -0000 On Tuesday, April 16, 2013 1:53 AM [GMT+1=3DCET], MH Michael Hammer = (5304) wrote: > > -----Original Message----- > > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On > > Behalf=20 > > Of Kurt Andersen > > Sent: Monday, April 15, 2013 7:46 PM > > To: dmarc@ietf.org > > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was > > not about outsourcing strategies > >=20 > > On 2013-04-15 16:34 , "MH Michael Hammer (5304)" > > wrote: > >=20 > > > I don't know how many times it needs to be said that p=3Dreject is > > > not appropriate for all sending domains. It is a strong policy > > > statement appropriate for domains that have good control over > > > their mailstreams.=20 > >=20 > > I think that it is important to point out that there is also a > > significant element of business cooperation required too. If a > > business decides that they want a singular domain presence, all the > > control in the world won't do a bit of good. And lists which impose > > a domain-based membership criterion contribute to=20 > > the problem IMO (you can only join the list if you work for > > example.com, and=20 > > have an email address @example.com but example.com has p=3Dreject). > >=20 > > --Kurt > >=20 >=20 > So the choice of ice cream offered is chocolate or vanilla. The > domain owner wants Neapolitan. That is not on the menu. If a business > makes the business decision that they want a singular domain presence > AND they choose to publish p=3Dreject then it becomes a case of: =20 >=20 > Domain: "Dr., it hurts when I do that." > Dr.: "Then don't do that". I say: please defend why is it bad adding Napolitan ice cream to the = menu? Specially now that the ice cream shop has yet to order the = supplies to the distributor? From sklist@kitterman.com Mon Apr 15 17:01:01 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F417511E80A2 for ; Mon, 15 Apr 2013 17:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.166 X-Spam-Level: X-Spam-Status: No, score=-4.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OZbrGr34vfT for ; Mon, 15 Apr 2013 17:01:00 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id B0AFF11E809C for ; Mon, 15 Apr 2013 17:00:59 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D4CD9D04081; Mon, 15 Apr 2013 19:00:58 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366070458; bh=ztQPdQP1w80Xf6BNHVGl+d7F+mCvVvPQLBqI4uzjbSM=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Ee1Dx4H+Ka2uEw9diWBpUecBgZLgJk+AljYlShV8Qnv3df9+Qa6FaKJCYfKQj552U xefqhn1Irdq+O51z2q8Iii2i5ABRFcpkm7U5lljB1SZqI6uX1sWDsBew/8+/6DmtKm s4fcmOMsZjA1FZLl1bXR8SLiL33+9UdJ9TtwiCgw= Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 84494D0401E; Mon, 15 Apr 2013 19:00:58 -0500 (CDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <20130409164432.68830.qmail@joyce.lan><7044732.h21xgsJhV9@scott-latitude-e6320> <2537595.FIN36AxgiW@scott-latitude-e6320> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 15 Apr 2013 20:00:10 -0400 To: dmarc@ietf.org Message-ID: <698db3b3-6f00-4251-a16e-12436f263d75@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 00:01:01 -0000 No. There are only three ways we can solve this problen: 1. Sender keeps a list of lists its users send to 2. Receiver keeps a list of lists its users receive from 3. Arbitrary mediators claim they are a list. #1/2 are not scalable. #3 Makes DMARC useless and inspires the evil bit jokes. Scott K "J. Gomez" wrote: >Fine. And don't you think that the "l=" tag could potentially help >other receivers without Google's IT department to also "work around the >issue"? > > >On Tuesday, April 16, 2013 1:28 AM [GMT+1=CET], Scott Kitterman wrote: > >> No. I think receiver policies belong to the receiver and senders can >> want what they want, but it's up to receivers to decide. I think it >> would be fair to say that "works fine with Gmail" isn't evidence that >> there's not an issue between DMARC and mailing lists, but RFCs aren't >> compliance specs that some internet standards inspector grades people >> on. The real world is what is is and if they are smart enough to use >> their data to work around the issue, good for them. >> >> Scott K >> >> On Tuesday, April 16, 2013 01:26:48 AM J. Gomez wrote: >> > So are you saying that Gmail does not follow DMARC's "p=reject" to >> > the letter, and just uses it as an additional input for its >> > internal scoring system? >> > >> > Then that would take Gmail out of the list of the big four/five >> > mailbox providers who are following DMARC's "p=reject" to the >> > letter, don't you think? >> > >> > Regards, >> > >> > J. Gomez >> > >> > On Tuesday, April 16, 2013 1:17 AM [GMT+1=CET], Scott Kitterman >> > wrote: >> > > Perhaps that Gmail uses it's own methods to determine what it >> > > thinks is mail from a mailing list and then doesn't >> > > reject/quarantine those solely due to DMARC. >> > > >> > > Scott K >> > > >> > > On Tuesday, April 16, 2013 01:10:32 AM J. Gomez wrote: >> > > > Does that mean that you (who are using a Gmail.com account to >> > > > subscribe to this list) are not receiving emails from Franck >> > > > Martin (who is using a linkedin.com address --which is sporting >> > > > a DMARC record of "p=reject"-- to subscribe to this list) >> > > > addressed to this mailing list? >> > > > >> > > > Hmm, but I've read you replying to him. What am I missing here? >> > > > >> > > > Regards, >> > > > >> > > > J. Gomez >> > > > >> > > > >> > > > ---- Original Message ---- >> > > > From: Murray S. Kucherawy >> > > > To: J. Gómez >> > > > Cc: dmarc@ietf.org >> > > > Sent: Tuesday, April 16, 2013 12:16 AM >> > > > Subject: Re: [dmarc-ietf] the endless mailing list silliness, >> > > > was not about outsourcing strategies >> > > > >> > > > > On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez >> > > > > wrote: >> > > > > >> > > > > Nice theory. How many of the big four/five mailbox providers >> > > > > (Gmail, Hotmail, Yahoo, AOL...) who have originally come up >> > > > > privately with DMARC (in coordination with sending brand >> > > > > owners like Paypal, Ebay, Facebook, etc.) are following >> > > > > "p=reject" to the letter? I think the number is zero. Why? >> > > > > Because the theory is nice and clean, the real world not so >> > > > > much. >> > > > > >> > > > > >> > > > > At a minimum, Gmail and Facebook are indeed rejecting based >on >> > > > > DMARC failures. I don't know about the others. >> > > > > >> > > > > >> > > > > >> > > > > -MSK >> > > >> > > _______________________________________________ >> > > dmarc mailing list >> > > dmarc@ietf.org >> > > https://www.ietf.org/mailman/listinfo/dmarc >> > >> > _______________________________________________ >> > dmarc mailing list >> > dmarc@ietf.org >> > https://www.ietf.org/mailman/listinfo/dmarc >> _______________________________________________ >> dmarc mailing list >> dmarc@ietf.org >> https://www.ietf.org/mailman/listinfo/dmarc >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From jgomez@seryrich.com Mon Apr 15 17:13:10 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5E721F937E for ; Mon, 15 Apr 2013 17:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj+oaI9reUik for ; Mon, 15 Apr 2013 17:13:09 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 4F66821F9361 for ; Mon, 15 Apr 2013 17:13:08 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 02:13:07 +0200 Message-ID: From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><5165242C.2030007@tana.it><77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz><5165A993.50208@gmail.com><5166758F.1040906@tana.it><408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net><516BE652.5010604@tana.it> <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> Date: Tue, 16 Apr 2013 02:13:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 00:13:10 -0000 On Tuesday, April 16, 2013 1:34 AM [GMT+1=3DCET], MH Michael Hammer = (5304) wrote: > To answer > your question about mailbox providers following p=3Dreject to the > letter, to the extent that they don't, the responsibility for letting > badness through to their customers is back on their shoulders. It takes two to tango. You can theorize who is to blame and you can = idealize who is the guilty party. The reality is senders what their = legitimate email reaching its destination as much a receivers what to = receive email that is relevant to them. A false DMARC positive because of the intersection of "p=3Dreject" and a = mailing list is as much a problem for the sending party as for the = receiving party. I think we should focus on how to minimize the false positives, not on = distributing guilt. > I appreciate the vote of confidence. I'll point out that a domain > with endusers CAN publish a policy of p=3Dquarantine without causing > the worst of the problems for maillist operators. Ok, so you are saying real-world average-users of DMARC have to choose: = either they shield themselves from phishing with "p=3Dreject", or they = make live palatable for their users behind their domain. Well, I say we need to think more about this problem. Regards, J. Gomez From jgomez@seryrich.com Mon Apr 15 17:19:41 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CF221E8043 for ; Mon, 15 Apr 2013 17:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.995 X-Spam-Level: X-Spam-Status: No, score=-3.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZQ-hwEFh1pr for ; Mon, 15 Apr 2013 17:19:40 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 13C6821F94A4 for ; Mon, 15 Apr 2013 17:19:40 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 02:19:38 +0200 Message-ID: <2D06963047A04BEEA1D84E8A22B6E2EB@fgsr.local> From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><7044732.h21xgsJhV9@scott-latitude-e6320><2537595.FIN36AxgiW@scott-latitude-e6320> <698db3b3-6f00-4251-a16e-12436f263d75@email.android.com> Date: Tue, 16 Apr 2013 02:20:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 00:19:41 -0000 The "l=3Dno" tag means in practical terms that point 2 is no longer = required for all email coming from domains with such a tag. How does not = that make life easier for the receivers when receiving email from those = domains? On Tuesday, April 16, 2013 2:00 AM [GMT+1=3DCET], Scott Kitterman wrote: > No. There are only three ways we can solve this problen: >=20 > 1. Sender keeps a list of lists its users send to > 2. Receiver keeps a list of lists its users receive from > 3. Arbitrary mediators claim they are a list. >=20 > #1/2 are not scalable. > #3 Makes DMARC useless and inspires the evil bit jokes. >=20 > Scott K >=20 > "J. Gomez" wrote: >=20 > > Fine. And don't you think that the "l=3D" tag could potentially help > > other receivers without Google's IT department to also "work around > > the issue"? > >=20 > >=20 > > On Tuesday, April 16, 2013 1:28 AM [GMT+1=3DCET], Scott Kitterman > > wrote:=20 > >=20 > > > No. I think receiver policies belong to the receiver and senders > > > can want what they want, but it's up to receivers to decide. I > > > think it would be fair to say that "works fine with Gmail" isn't > > > evidence that there's not an issue between DMARC and mailing > > > lists, but RFCs aren't compliance specs that some internet > > > standards inspector grades people on. The real world is what is > > > is and if they are smart enough to use their data to work around > > > the issue, good for them.=20 > > >=20 > > > Scott K > > >=20 > > > On Tuesday, April 16, 2013 01:26:48 AM J. Gomez wrote: > > > > So are you saying that Gmail does not follow DMARC's = "p=3Dreject" > > > > to the letter, and just uses it as an additional input for its > > > > internal scoring system? > > > >=20 > > > > Then that would take Gmail out of the list of the big four/five > > > > mailbox providers who are following DMARC's "p=3Dreject" to the > > > > letter, don't you think? > > > >=20 > > > > Regards, > > > >=20 > > > > J. Gomez > > > >=20 > > > > On Tuesday, April 16, 2013 1:17 AM [GMT+1=3DCET], Scott = Kitterman > > > > wrote: > > > > > Perhaps that Gmail uses it's own methods to determine what it > > > > > thinks is mail from a mailing list and then doesn't > > > > > reject/quarantine those solely due to DMARC. > > > > >=20 > > > > > Scott K > > > > >=20 > > > > > On Tuesday, April 16, 2013 01:10:32 AM J. Gomez wrote: > > > > > > Does that mean that you (who are using a Gmail.com account > > > > > > to subscribe to this list) are not receiving emails from > > > > > > Franck Martin (who is using a linkedin.com address --which > > > > > > is sporting a DMARC record of "p=3Dreject"-- to subscribe to > > > > > > this list) addressed to this mailing list? > > > > > >=20 > > > > > > Hmm, but I've read you replying to him. What am I missing > > > > > > here?=20 > > > > > >=20 > > > > > > Regards, > > > > > >=20 > > > > > > J. Gomez > > > > > >=20 > > > > > >=20 > > > > > > ---- Original Message ---- > > > > > > From: Murray S. Kucherawy > > > > > > To: J. G=C3=B3mez > > > > > > Cc: dmarc@ietf.org > > > > > > Sent: Tuesday, April 16, 2013 12:16 AM > > > > > > Subject: Re: [dmarc-ietf] the endless mailing list > > > > > > silliness, was not about outsourcing strategies > > > > > >=20 > > > > > > > On Mon, Apr 15, 2013 at 3:04 PM, J. Gomez > > > > > > > wrote: > > > > > > >=20 > > > > > > > Nice theory. How many of the big four/five mailbox > > > > > > > providers (Gmail, Hotmail, Yahoo, AOL...) who have > > > > > > > originally come up privately with DMARC (in coordination > > > > > > > with sending brand owners like Paypal, Ebay, Facebook, > > > > > > > etc.) are following "p=3Dreject" to the letter? I think = the > > > > > > > number is zero. Why? Because the theory is nice and > > > > > > > clean, the real world not so much. > > > > > > >=20 > > > > > > >=20 > > > > > > > At a minimum, Gmail and Facebook are indeed rejecting > > > > > > > based on DMARC failures. I don't know about the others. > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > -MSK > > > > >=20 > > > > > _______________________________________________ > > > > > dmarc mailing list > > > > > dmarc@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dmarc > > > >=20 > > > > _______________________________________________ > > > > dmarc mailing list > > > > dmarc@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dmarc > > > _______________________________________________ > > > dmarc mailing list > > > dmarc@ietf.org > > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From MHammer@ag.com Mon Apr 15 17:20:06 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88E021F94CC for ; Mon, 15 Apr 2013 17:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN00cE0DD4wV for ; Mon, 15 Apr 2013 17:20:03 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9389F21F94C3 for ; Mon, 15 Apr 2013 17:20:03 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 20:20:03 -0400 From: "MH Michael Hammer (5304)" To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOjVgFthu5mILOUiNR8t4/ccYI5jX9u9A Date: Tue, 16 Apr 2013 00:20:02 +0000 Message-ID: References: <3560C13B3A3EC9408B4BFEDB3B728395096719BD@ESV4-EXC02.linkedin.biz> <1085D7C277BA4865B8D5753C3C4D4155@fgsr.local> In-Reply-To: <1085D7C277BA4865B8D5753C3C4D4155@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 00:20:06 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of J. Gomez > Sent: Monday, April 15, 2013 8:00 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not abo= ut > outsourcing strategies >=20 > On Tuesday, April 16, 2013 1:53 AM [GMT+1=3DCET], MH Michael Hammer > (5304) wrote: >=20 > > > -----Original Message----- > > > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On > > > Behalf Of Kurt Andersen > > > Sent: Monday, April 15, 2013 7:46 PM > > > To: dmarc@ietf.org > > > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was > > > not about outsourcing strategies > > > > > > On 2013-04-15 16:34 , "MH Michael Hammer (5304)" > > > > wrote: > > > > > > > I don't know how many times it needs to be said that p=3Dreject is > > > > not appropriate for all sending domains. It is a strong policy > > > > statement appropriate for domains that have good control over > > > > their mailstreams. > > > > > > I think that it is important to point out that there is also a > > > significant element of business cooperation required too. If a > > > business decides that they want a singular domain presence, all the > > > control in the world won't do a bit of good. And lists which impose > > > a domain-based membership criterion contribute to the problem IMO > > > (you can only join the list if you work for example.com, and have an > > > email address @example.com but example.com has p=3Dreject). > > > > > > --Kurt > > > > > > > So the choice of ice cream offered is chocolate or vanilla. The domain > > owner wants Neapolitan. That is not on the menu. If a business makes > > the business decision that they want a singular domain presence > > AND they choose to publish p=3Dreject then it becomes a case of: > > > > Domain: "Dr., it hurts when I do that." > > Dr.: "Then don't do that". >=20 > I say: please defend why is it bad adding Napolitan ice cream to the menu= ? > Specially now that the ice cream shop has yet to order the supplies to th= e > distributor? There is nothing wrong with adding it to the menu assuming it is available.= The issue is that in Kurt's example, someone is demanding two things which= are in conflict. This is clearly a case of cognitive dissonance. From tim@eudaemon.net Mon Apr 15 17:23:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B7B21F8BE4 for ; Mon, 15 Apr 2013 17:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsxLY6UqsJ95 for ; Mon, 15 Apr 2013 17:23:20 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id C973921F8ADC for ; Mon, 15 Apr 2013 17:23:20 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id F15F9CB46; Mon, 15 Apr 2013 20:23:57 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Tim Draegen X-Priority: 3 In-Reply-To: Date: Mon, 15 Apr 2013 20:23:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130409164432.68830.qmail@joyce.lan><5165242C.2030007@tana.it><77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz><5165A993.50208@gmail.com><5166758F.1040906@tana.it><408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net><516BE652.5010604@tana.it> <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> To: "J. Gomez" X-Mailer: Apple Mail (2.1503) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 00:23:21 -0000 On Apr 15, 2013, at 8:13 PM, "J. Gomez" wrote: > Well, I say we need to think more about this problem. =46rom my perspective, a lot of people have been pretty clear about how = and why solving the mailing list problem is not something that can be = done through adding words to DMARC the technical specification. There is no easy fix, just real work to do along any number of tracks. -=3D Tim From tim@eudaemon.net Mon Apr 15 17:27:59 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16AA21F8E63 for ; Mon, 15 Apr 2013 17:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27ffv0w5QJEc for ; Mon, 15 Apr 2013 17:27:59 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6920821F8E62 for ; Mon, 15 Apr 2013 17:27:59 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id AB464CB46; Mon, 15 Apr 2013 20:28:36 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=us-ascii From: Tim Draegen X-Priority: 3 In-Reply-To: <2D06963047A04BEEA1D84E8A22B6E2EB@fgsr.local> Date: Mon, 15 Apr 2013 20:28:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <51698EB9-2B90-4F2E-919A-67A323941794@eudaemon.net> References: <20130409164432.68830.qmail@joyce.lan><7044732.h21xgsJhV9@scott-latitude-e6320><2537595.FIN36AxgiW@scott-latitude-e6320> <698db3b3-6f00-4251-a16e-12436f263d75@email.android.com> <2D06963047A04BEEA1D84E8A22B6E2EB@fgsr.local> To: "J. Gomez" X-Mailer: Apple Mail (2.1503) Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 00:28:00 -0000 On Apr 15, 2013, at 8:20 PM, "J. Gomez" wrote: > The "l=3Dno" tag means in practical terms that point 2 is no longer = required for all email coming from domains with such a tag. How does not = that make life easier for the receivers when receiving email from those = domains? There is no "l=3Dno" tag. It's been less than a day since people = replied to this suggestion with some pretty good reasons why it doesn't = work. To summarize: receivers aren't looking for a "l=3Dno" directive to = reject email. They're looking to work-around the mailing list problem = so that end-users remain calm while anti-phishing technology is = installed. HTH, =3D- Tim= From jgomez@seryrich.com Mon Apr 15 17:37:39 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F0921F8659 for ; Mon, 15 Apr 2013 17:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl2O3caFUaUV for ; Mon, 15 Apr 2013 17:37:39 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 0172221F85E7 for ; Mon, 15 Apr 2013 17:37:39 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 02:37:37 +0200 Message-ID: From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><5165242C.2030007@tana.it><77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz><5165A993.50208@gmail.com><5166758F.1040906@tana.it><408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net><516BE652.5010604@tana.it> <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> Date: Tue, 16 Apr 2013 02:38:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 00:37:40 -0000 On Tuesday, April 16, 2013 2:23 AM [GMT+1=3DCET], Tim Draegen wrote: > On Apr 15, 2013, at 8:13 PM, "J. Gomez" wrote: > > Well, I say we need to think more about this problem. >=20 > From my perspective, a lot of people have been pretty clear about how > and why solving the mailing list problem is not something that can be > done through adding words to DMARC the technical specification. =20 >=20 > There is no easy fix, just real work to do along any number of tracks. Yes, it is clear DMARC cannot _solve_ the mailing list false positives. = We are already past that. We are now trying to _minimize_ those false positives. One side says: it's totally up to the receiver's 'smarts' and local = policies, a.k.a. the receiver's voodoo. I say: the above, but lets help the receiver's voodoo with a little = optional positive info from the sender, thus the "l=3D" tag. A third side says: there is not really a problem, senders should just = choose between using either "p=3Dreject" or using mailing lists = altogether. Ok, now lets try to detach ourselves from any particular patisanship and = ask ourselves this: "what would be the best course of action for a = healthy and universal email ecosystem as a whole, suitable for both big = and small participants?". Yeah, not an easy question, I know. From MHammer@ag.com Mon Apr 15 17:44:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838EB21F90C5 for ; Mon, 15 Apr 2013 17:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.839 X-Spam-Level: X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gthq4lqEMqC for ; Mon, 15 Apr 2013 17:44:09 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id BDD0021F8D28 for ; Mon, 15 Apr 2013 17:44:08 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 20:44:08 -0400 From: "MH Michael Hammer (5304)" To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOjdFl/uEMXNFiEqC4F/rpNusa5jX/HRA Date: Tue, 16 Apr 2013 00:44:07 +0000 Message-ID: References: <20130409164432.68830.qmail@joyce.lan><5165242C.2030007@tana.it><77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz><5165A993.50208@gmail.com><5166758F.1040906@tana.it><408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net><516BE652.5010604@tana.it> <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 00:44:09 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of J. Gomez > Sent: Monday, April 15, 2013 8:14 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not abo= ut > outsourcing strategies >=20 > On Tuesday, April 16, 2013 1:34 AM [GMT+1=3DCET], MH Michael Hammer > (5304) wrote: >=20 > > To answer > > your question about mailbox providers following p=3Dreject to the > > letter, to the extent that they don't, the responsibility for letting > > badness through to their customers is back on their shoulders. >=20 > It takes two to tango. You can theorize who is to blame and you can ideal= ize > who is the guilty party. The reality is senders what their legitimate ema= il > reaching its destination as much a receivers what to receive email that i= s > relevant to them. >=20 If you look at the history of SPF and DKIM, many mailbox providers would co= nsider them but not act on assertions authoritatively because they couldn't= /wouldn't trust them. The reality with DMARC (in my experience) is that it = works very well for transactional mail, marketing mail and yes, even for do= mains with individual users as long as they avoid maillists. Individual use= rs send mail at the discretion of the domain owner/administrator. We encoun= ter very low rates of false positives for our mail sent under a DMARC polic= y of p=3Dreject. > A false DMARC positive because of the intersection of "p=3Dreject" and a > mailing list is as much a problem for the sending party as for the receiv= ing > party. >=20 Then don't do that. > I think we should focus on how to minimize the false positives, not on > distributing guilt. >=20 So far I haven't seen anything proposed that accomplishes your ask without = opening opportunities for abuse. > > I appreciate the vote of confidence. I'll point out that a domain with > > endusers CAN publish a policy of p=3Dquarantine without causing the > > worst of the problems for maillist operators. >=20 > Ok, so you are saying real-world average-users of DMARC have to choose: > either they shield themselves from phishing with "p=3Dreject", or they ma= ke > live palatable for their users behind their domain. >=20 That is basically what it comes down to. If you or anyone else comes up wit= h something that doesn't open up DMARC for abuse I would gladly support it.= We chose to re-architect our systems and limit individual accounts to only= those that directly support the websites (customer service, security, etc)= . we use an unrelated domain for our corporate mail. If your domain is subj= ect to enough abuse then you will make a choice. If your domain is not that= heavily abused and you want your endusers to be able to participate in mai= llists you will make another choice. The ask I'm hearing is in the realm of= someone wanting to publish an SPF record of +all and then expressing unhap= piness when someone sends mail claiming to be them from some random host. > Well, I say we need to think more about this problem. >=20 The me part of we is focused on thinking about other problems. The proposed= working group charter allows for extensions so my suggestion would be to c= ome up with a detailed proposal. Find some other senders plus some receiver= s and maillist operators that buy into your proposal and engage a proof of = concept exercise. Mike From jgomez@seryrich.com Mon Apr 15 17:45:44 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78ED521F8D28 for ; Mon, 15 Apr 2013 17:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph9NrDa3dpYt for ; Mon, 15 Apr 2013 17:45:44 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id ACF5921F90C5 for ; Mon, 15 Apr 2013 17:45:43 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 02:45:42 +0200 Message-ID: From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><7044732.h21xgsJhV9@scott-latitude-e6320><2537595.FIN36AxgiW@scott-latitude-e6320> <698db3b3-6f00-4251-a16e-12436f263d75@email.android.com> <2D06963047A04BEEA1D84E8A22B6E2EB@fgsr.local> <51698EB9-2B90-4F2E-919A-67A323941794@eudaemon.net> Date: Tue, 16 Apr 2013 02:46:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 00:45:44 -0000 On Tuesday, April 16, 2013 2:28 AM [GMT+1=3DCET], Tim Draegen wrote: > On Apr 15, 2013, at 8:20 PM, "J. Gomez" wrote: > > The "l=3Dno" tag means in practical terms that point 2 is no longer > > required for all email coming from domains with such a tag. How > > does not that make life easier for the receivers when receiving > > email from those domains? =20 >=20 > There is no "l=3Dno" tag. It's been less than a day since people > replied to this suggestion with some pretty good reasons why it > doesn't work. =20 >=20 > To summarize: receivers aren't looking for a "l=3Dno" directive to > reject email. They're looking to work-around the mailing list > problem so that end-users remain calm while anti-phishing technology > is installed. =20 There is a proposed "l=3D" tag. You can think of the "l=3D" tag as = implicitly adjectivized as "proposed" whenever you read about it until = you may happen to see it inside the DMARC draft and/or standard, if at = all. To answer you last paragraph above, the "l=3D" tag is all about helping = receivers better "work-around the mailing list problem". So I think the = "l=3D" tag is totally in line with what you say receivers are looking = for. Regards, J. Gomez From MHammer@ag.com Mon Apr 15 18:01:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28D121F93F3 for ; Mon, 15 Apr 2013 18:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLOKFB4DgVjv for ; Mon, 15 Apr 2013 18:01:19 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1175221F896B for ; Mon, 15 Apr 2013 18:01:19 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Mon, 15 Apr 2013 21:01:18 -0400 From: "MH Michael Hammer (5304)" To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOjqyl/uEMXNFiEqC4F/rpNusa5jYBCsw Date: Tue, 16 Apr 2013 01:01:17 +0000 Message-ID: References: <20130409164432.68830.qmail@joyce.lan><5165242C.2030007@tana.it><77426B543150464AA3F30DF1A91365DE52EE9B2D@ESV4-MBX01.linkedin.biz><5165A993.50208@gmail.com><5166758F.1040906@tana.it><408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net><516BE652.5010604@tana.it> <5F1189DFB93D4955BBFC20FD2041ABB3@fgsr.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 01:01:20 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of J. Gomez > Sent: Monday, April 15, 2013 8:38 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not abo= ut > outsourcing strategies >=20 > On Tuesday, April 16, 2013 2:23 AM [GMT+1=3DCET], Tim Draegen wrote: >=20 > > On Apr 15, 2013, at 8:13 PM, "J. Gomez" wrote: > > > Well, I say we need to think more about this problem. > > > > From my perspective, a lot of people have been pretty clear about how > > and why solving the mailing list problem is not something that can be > > done through adding words to DMARC the technical specification. > > > > There is no easy fix, just real work to do along any number of tracks. >=20 > Yes, it is clear DMARC cannot _solve_ the mailing list false positives. W= e are > already past that. >=20 > We are now trying to _minimize_ those false positives. >=20 > One side says: it's totally up to the receiver's 'smarts' and local polic= ies, a.k.a. > the receiver's voodoo. >=20 > I say: the above, but lets help the receiver's voodoo with a little optio= nal > positive info from the sender, thus the "l=3D" tag. >=20 So what do you do when malicious individuals look for domains publishing yo= ur proposed l=3D tag and start sending mail from purported maillists (or ev= en through legitimate lists) claiming to be from those domains? You may (an= d I emphasize may) have reduced false positives to some unknown extent but = you have encouraged a vector of abuse. > A third side says: there is not really a problem, senders should just cho= ose > between using either "p=3Dreject" or using mailing lists altogether. >=20 This is no different than saying SPF records ending in -all are not suitabl= e for domains that don't know where they emit mail from. It is no different= than saying an ADSP (DKIM) policy of discardable is not suitable for domai= ns that don't properly DKIM sign all their mail. > Ok, now lets try to detach ourselves from any particular patisanship and = ask > ourselves this: "what would be the best course of action for a healthy an= d > universal email ecosystem as a whole, suitable for both big and small > participants?". >=20 > Yeah, not an easy question, I know. >=20 That's easy - throw out SMTP and start from scratch....... never mind. Not = all implementations are suitable for all participants in the sense you are = asking. The issues involved are NOT a function of size. Gmail is not curren= tly in a position to implement a p=3Dreject policy. It is the nature of the= ir mail streams and policy choices. The same goes for some other very large= senders. Mike From jgomez@seryrich.com Mon Apr 15 18:13:57 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C3621F9377 for ; Mon, 15 Apr 2013 18:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.683 X-Spam-Level: X-Spam-Status: No, score=-2.683 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtlDY4lKmSf2 for ; Mon, 15 Apr 2013 18:13:56 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 92EA321F936C for ; Mon, 15 Apr 2013 18:13:56 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 03:13:54 +0200 Message-ID: <4575D15E5387490C81F9139F4A19F61E@fgsr.local> From: "J. Gomez" To: References: <77426B543150464AA3F30DF1A91365DE52F37478@ESV4-MBX01.linkedin.biz> Date: Tue, 16 Apr 2013 03:14:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] A l'abordage! X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 01:13:57 -0000 On Tuesday, April 16, 2013 12:20 AM [GMT+1=3DCET], Franck Martin wrote: > There is no problem between DMARC and mailing lists. >=20 > (...) > > List software must become DMARC aware like they became ADSP aware > (not!) to refuse subscription from domain with p=3Dreject, or not = treat > these bounce towards the unsubscription count or send email aligned > with DMARC. Too many things "must become" for not being a problem to begin with, = don't you think? > What would help list software is to recognize DMARC bounces, I think > we have not standardized in our implementations the bounce message so > it can be recognized by list software and ignored, so at least it > does not unsubscribe people that do DMARC or ADSP rejects. This is a nice suggestion. A special reject message could be useful (to = minimize collateral damage) while "something" happens that settles "the = problem" (be it the death of mailing lists, the death of DMARC, or some = synthesis of them in --hopefully not-- zombified form). > Anyway you toss it, list software needs some new code/process. Yes, assuming DMARC newness gets the upper hand over mailing lists' = incumbency. > So we are not discovering the pain with authentication and list > software and some MTA implementations, it has been well documented. > We are just now experiencing it to an acute level. What the pain will > change, this is anyone's guess, but I don't think DMARC needs to be > made more aware of mailing lists than it is today. What people needs > to understand, there are mailing lists, people want the email, what > best strategies to recognize safely enough mailing lists. =20 Given that you take part in this mailing list subscribing from a domain = sporting a DMARC record of "p=3Dreject", I think that you are saying = it's OK for senders publishing such a policy to outsource to receivers = the responsability of handling the occurrence of exceptions to said = sender's policy; and you are also saying that the previous assertion is = "as things ought to be" because DMARC "does not need to be made more = aware of mailing lists". Sorry, but that is such a bold abordage, to be frank. Regards,=20 J. Gomez From mjones@agari.com Mon Apr 15 18:29:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161BF21F93B7 for ; Mon, 15 Apr 2013 18:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9b1F7RNAd7V for ; Mon, 15 Apr 2013 18:29:46 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1B72021F93B2 for ; Mon, 15 Apr 2013 18:29:46 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so42668pad.2 for ; Mon, 15 Apr 2013 18:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=agari.com; s=s1024; h=x-received:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=ZSS6h84wmi/JMBSH7endt4OtzIW8DojpZXIKnWbk2jY=; b=VoFgrOLxjYOwK+lpaK4jgVf9SFs3Us1Mco7FhqFWcK4aelNr/lZMOXD8S5U9AKADQB UsYTcGQ96wR0pZlRbVC673WinI0oBQwABKltFFbbj3xBhrGlnScpszhFQvDBpKlvUHl2 8wzZ6jYvxy8UY5EydWHg+aV6ccBVLmad4tpas= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:message-id:references:to:x-mailer :x-gm-message-state; bh=ZSS6h84wmi/JMBSH7endt4OtzIW8DojpZXIKnWbk2jY=; b=XvqkigQOcFpdwOUg0c/QEbiiAsj7P7wj1HhW3QzmJCsYCWGXu1XzgVCZmglgCxVjby dspkJrQelTgp1vYtq7+2mlgVcRYC2EmXHuGIK6k9aYq6Qni6M0T7LB/hQMoOQQXNkCvd SBMB1TSb0qUVZAFm4UsF/xwgozI9KL6aHIUBFWAFv+jT0tgvUbnMbEyRzDg20G3hVOVO lnn348U4DTUzEPIisJja0wG1cjrOCl75xFWf0f9pWKU1OG4Ai3BeJYmYh2ZnuzHiHs0A EEXGYMzOzrJ363+byAQz/oMPcMBeFButrziyLxB2f9q+lInwvcmC2FLy4f9ej16vrkiP IuJw== X-Received: by 10.66.154.164 with SMTP id vp4mr791875pab.89.1366075785765; Mon, 15 Apr 2013 18:29:45 -0700 (PDT) Received: from [10.0.1.32] (50-197-151-173-static.hfc.comcastbusiness.net. [50.197.151.173]) by mx.google.com with ESMTPS id cp1sm22304469pbc.42.2013.04.15.18.29.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 18:29:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_7381CE92-8372-4BCF-84CA-0F2BB86DCB7C" From: Mike Jones X-Priority: 3 In-Reply-To: Date: Mon, 15 Apr 2013 18:29:41 -0700 Message-Id: <418B6D2C-4F98-46D8-A22B-84A8882FD2A8@agari.com> References: <20130409164432.68830.qmail@joyce.lan><7044732.h21xgsJhV9@scott-latitude-e6320><2537595.FIN36AxgiW@scott-latitude-e6320> <698db3b3-6f00-4251-a16e-12436f263d75@email.android.com> <2D06963047A04BEEA1D84E8A22B6E2EB@fgsr.local> <51698EB9-2B90-4F2E-919A-67A323941794@eudaemon.net> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQnxNqnemGKqI73j1CZ5olTSQXK0prYQXhZoNC66EQ0j8vT8xi/CyvB4A7K76DYPp7wsFDyy Cc: "J. Gomez" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 01:29:47 -0000 --Apple-Mail=_7381CE92-8372-4BCF-84CA-0F2BB86DCB7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 15, 2013, at 5:46 PM, J. Gomez wrote: >>=20 >> To summarize: receivers aren't looking for a "l=3Dno" directive to >> reject email. They're looking to work-around the mailing list >> problem so that end-users remain calm while anti-phishing technology >> is installed. =20 >=20 > There is a proposed "l=3D" tag. You can think of the "l=3D" tag as = implicitly adjectivized as "proposed" whenever you read about it until = you may happen to see it inside the DMARC draft and/or standard, if at = all. >=20 > To answer you last paragraph above, the "l=3D" tag is all about = helping receivers better "work-around the mailing list problem". So I = think the "l=3D" tag is totally in line with what you say receivers are = looking for. >=20 > Regards, >=20 > J. Gomez >=20 We collect and aggregate DMARC data for a lot of domains, many of which = have reject policies currently in place. I thought I would take a quick = look into current practices in identifying forwarders & mailing lists = and overriding DMARC policies.=20 In the last 30 days we saw: Slightly over 1400 unique domains & sub-domains that had at least one = DMARC reject disposition applied. =20 A total of over 170 million messages were reported with a DMARC reject = disposition Of these, 28.5% had a policy override reported=20 The most common override reason was "forwarded" accounting for roughly = 60%. After that "local policy" accounted for 27% of overrides and = "mailing list" was indicated on about 12% of the overrides. =20 More than one DMARC receiver currently utilizes the policy override, but = not all do. =20 On a per domain basis, the percentage of messages with a reject = disposition and which have a policy override applied varies quite = largely. Below see the distribution of # of domains across buckets of = "% of failing messages with an override" for the top 100 domains by = total messages rejects. As you can seen half of the domains fall into = the first 2 buckets with less than 10% of the reject policies = overridden. But 3 domains had more than 75% of their reject policies = overridden. =20 My conclusions from the data and my experience working with the DMARC = receivers so far is that they are using the flexibility DMARC provides = to override reject policies when they believe it is appropriate for = their users. =20 Thanks, Mike --Apple-Mail=_7381CE92-8372-4BCF-84CA-0F2BB86DCB7C Content-Type: multipart/mixed; boundary="Apple-Mail=_D583A9FC-C7AE-409E-8B09-7B3F529B3BEE" --Apple-Mail=_D583A9FC-C7AE-409E-8B09-7B3F529B3BEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
jgomez@seryrich.com> = wrote:


To= summarize: receivers aren't looking for a "l=3Dno" directive = to
reject email.  They're looking to work-around the mailing = list
problem so that end-users remain calm while anti-phishing = technology
is installed.   

There is a = proposed "l=3D" tag. You can think of the "l=3D" tag as implicitly = adjectivized as "proposed" whenever you read about it until you may = happen to see it inside the DMARC draft and/or standard, if at = all.

To answer you last paragraph above, the "l=3D" tag is all = about helping receivers better "work-around the mailing list problem". = So I think the "l=3D" tag is totally in line with what you say receivers = are looking for.

Regards,

J. = Gomez



We collect and = aggregate DMARC data for a lot of domains, many of which have reject = policies currently in place.  I thought I would take a quick look = into current practices in identifying forwarders & mailing lists and = overriding DMARC policies. 

In the last 30 = days we saw:
  • Slightly over 1400 unique domains & = sub-domains that had at least one DMARC reject disposition applied. =  
  • A total of over 170 million messages were reported with a = DMARC reject disposition
    • Of these, 28.5% had a policy = override reported 
The most common override = reason was "forwarded" accounting for roughly 60%.  After that = "local policy" accounted for 27% of overrides and "mailing list" was = indicated on about 12% of the overrides. =  

More than one DMARC receiver = currently utilizes the policy override, but not all do. =  


On a per domain basis, = the percentage of messages with a reject disposition and which have a = policy override applied varies quite largely.  Below see the = distribution of # of domains across buckets of "% of failing messages = with an override" for the top 100 domains by total messages rejects. =  As you can seen half of the domains fall into the first 2 buckets = with less than 10% of the reject policies overridden.  But 3 = domains had more than 75% of their reject policies overridden. =  

= --Apple-Mail=_D583A9FC-C7AE-409E-8B09-7B3F529B3BEE Content-Disposition: inline; filename=PastedGraphic-1.pdf Content-Type: application/pdf; x-unix-mode=0666; name="PastedGraphic-1.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1WE1z2zYQvfNXrGPZoZ0KwuIb17qdTHtqx5rJoemho3Gq ZqS2ttrp3+8DSJCSKEeUI0sHgsvF8uFhsR98pJ/pkST+2kdSQdPTA32gP2n2fsP0+4Zmd7guNsT5 v1mkByo9kFl7XeZVqzyStMrWVrSkT7dJWSfl7dkmzxYW8xWl+V5E/PJtMtLcViwkft4mg1Deus2W E2zlSGOeUaRU7ID/9PC0ePj7n39/W9HTH0kLz9MCk06eUS3WNPthzfTdX1h9Xn9+l/TOaKM00Gof gIeLTVZeSvoPDz43hNzdJ1DKmihV1Y16Gd3fJVqbJQRvJLuMYborUlY4xaBBWSuYTUjQtLNWE96I awBBU7bGgSLfycBSo6Mxb1+nla2qRoej5rCnU2TFDlsrBzqtrNWpmK3nfTutrNjx3u2rtKKioYMy NlTbi2pE2OUWL57vLJqTYEX3R7aqKn57B/eEv6YdlwR/fcSupSFc0AjDMSoyXtiotCOw/e2cmk1R NF8QN9PyZcqymsNT5nMWyX/nn6i+eHND88/0/fwImuI4OD0Nmup5ND4IGa09CoY6MFUD5vKlYIbU RKEtWxdBQAA3wSdH/CI1PZqWmslYbkbsVA9HR8ESFB5BM9ioyYvJGe5Uj8ZF4aQ9Dqcnp92qq7Hk DByn2ytYaty4g6OkBDkI2cfY6eHkvarqqxez08GBpX04WgrH7E53neux7JziOsrh2CKkHmVn4DvX p7LTpYfqQHrYSgp9ohiZHoLw0bImw8KC2pionWqP+JXSwdRar4XUJsXLTmqkhl9Eh5hpHOKx2tFr RUUJWTvq7NLbxlpRUYIlNtLGPVNFVtRgi4O3YV+tlRU1WFPaBrOnVmRFDdZQH2h2dgd/kRW182QG eK7mGCxpKxQSjm+dpk8HAYwapHFk40FW+AV54QbbrKhGREY2YarffqzzUGfZrzT/8XjSGOHdHVCl d4AeTGEevpFi+jOQP94AIaDevgPqcQgRnapcHJa0NgwHziMIOFRQu0weBGgEvBZO/AzCSUF48e7N N6+B8etJvC0Qz0siS5QqHpF9DIssAk4DCtbD+zy5KBhPonGEM3Yox/BohJVs+bkDdPVaTKbQqTwa hRH+iGpcO58izvCQ19ctfS8o/3JJMShGW2BnIG/6WuShNLXejzvMXyTv8szkFWBnIE9My/k47xlW nJo7ONNXe564bOLfmTyvAzaGPCu8054PBpd6coFt3W2IVMCMgG6ejRHKuNThq8gCeVv1slXVyzSK HIs2PuX7MreXLenDLb5GNG3zwQa9SUj7Tf9un50q1SYDSd924/3LCtDFuprdL5k2y1Obu2EWVFEj 7ASDJSMfSlWK4r6gACDcdC1d00ShkpilSgJZua8fZC4kDNXcDKr6bVdm9FoqP9wuQXSZ1yuZtkyx Lj+zVbFJtc8SvHiYaLG8vY9DXcHbfw85+BXk1IIX+qnqS2Vu2rI1OvVolIkYo5ptx6hpgoOHpQ9N /XjZfCH4H1lh5dUKZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjExMzAKZW5kb2JqCjIgMCBvYmoK PDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0 IDAgUiAvTWVkaWFCb3ggWzAgMCAzNzkgMjgzXQo+PgplbmRvYmoKNiAwIG9iago8PCAvUHJvY1Nl dCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JTcGFjZSA8PCAv Q3MyIDEwIDAgUgovQ3MxIDcgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMyAxNCAwIFIgL0dzMiAx NSAwIFIgL0dzNCAxNiAwIFIgL0dzMSAxNyAwIFIKPj4gL0ZvbnQgPDwgL1RUMS4xIDEyIDAgUiA+ PiAvWE9iamVjdCA8PCAvSW0xIDggMCBSID4+IC9TaGFkaW5nIDw8IC9TaDEgMTMgMCBSCj4+ID4+ CmVuZG9iagoxMyAwIG9iago8PCAvQ29sb3JTcGFjZSA3IDAgUiAvU2hhZGluZ1R5cGUgMiAvQ29v cmRzIFsgMzQ4NzYgMCAzNDg3NiA2OTc1MiBdIC9Eb21haW4KWyAwIDEgXSAvRXh0ZW5kIFsgdHJ1 ZSB0cnVlIF0gL0Z1bmN0aW9uIDE4IDAgUiA+PgplbmRvYmoKOCAwIG9iago8PCAvTGVuZ3RoIDkg MCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjQyIC9IZWlnaHQgMjI5 IC9JbnRlcnBvbGF0ZQp0cnVlIC9Db2xvclNwYWNlIDcgMCBSIC9TTWFzayAxOSAwIFIgL0JpdHNQ ZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZQo+PgpzdHJlYW0KeAHtnfd3Vse19/M/ vOtd73p/eNf94a5bktybchPH3bhj003vkuhFdAkJ0ZGEGiCQACEBopliejXFYIOJk9zkOsFObMd2 bMe9xBUbd5v3u/ee2WeeynNGID2SDmuvYc+e0XOec87nmTNnz8yeH/wg+hddgegKRFcgugId5wos Xbq0PPoXXYEsvgJhf2xlZWVZfDbRV4uuQHlFRUXmVKOJFqQz/5OoZnQFsvkKSBMQ6leQzacTfbfo CkRNdMRAR7oCUa+jI93N6FxwBaJeR4RBB7sCUa+jg93QTn46Ua+jkwPQ8U4/6nV0vHvayc9IkO7k FyE6/Q52BSKqO9gNjU4HVyCiOsKg412BiOqOd0+jM4qojhjoeFcgorrj3dPojNoR1YV15wvrzmUo M5afGj13W3R/O+cVaC9UF9RnyjOwz684DKQjqjsn0jjrdkF1Yd3ZKzfRqwz2ExbvGT2PkI6ojqjO zisQutdheY6ozs4b2jrfKsvb6g2PX85cqC9tqR4VtdWtA1BWHiX7qV7/+GUI2BbFzYpRU3lDBM8i OdHbYlYi1wpfKsupDkg+d3k9BGy7qWStZcYy8nsYqku2RlS3Aj/ZeYh2QDXz3HTusivENlskRREU UD2qZFteyVaRiOrsRK4VvlX2U00wn41B2sXb6FxhuqHagB1R3Qr8ZOchspxqw/PZy40q0mgDY7Ww Dryn1ZzkVjqiOjtZa71vlf1UBzw7GAfGxwLgLdW2B1IUjS22HkhZdaT2QvU6S+86ZhtZsbh2l+rc OVtyIqqzCrVW/DJZTrXQa9KzRHIK+R60g+rckq3gObdkS05EdStSlG2HynqqvxeMGx5zFVe/jCIp DagG0hHV2YZaK36fLKeacQXDxC3JoyYF6kKysXPp1OoT1PFQiXogrQhSVh0qE6olrgKihbT+v7qD fzckK9iPfb9W2HY5t1QHSBdvKV5U2/pfODpiW10B92d1RaqBNOq0VQzJtcLwo0SyCnHOWTdF6ZTq E4bq4i05kKitdu90Z9LTU52+tBWuk1DNPH+nVK99FLoIUFf7d4bq4i0jmephEdWtcIey8hCpuM2S aE6rqU1Whr9bwwyvOUMW6EYo+z30KVUnqIkmqjdDhhVtyspLHn2pa34FklLdtr0O95xBNRhOIkA6 wQ6qhWdLdTQK417LTqQnUp1oacPLAapXM71IRQBzokWM+UQ1dT+I6qKorW7D+9bGh45jGC+wsLTx d3IOL1QTz6e/5ZTZFp2MgjoXnfmWqaa+h22rox6Icyk7k6pUZ0+vw738xC0x/G09UlUke4YsYq9n S37VcWmlRxRthkT9avdKdipdqJa0rdx3aS54/envwK0rQrJrUV2oFqSHR1SnuawdvUipzs4TNVQ/ EgN2neW87vQ39VL0yLcwTq48zkhvQjq8aFPUVmfnPW2Fb6U9kFY4lsch6h75jtA9/W0duH3kG6BL yulvjE6KtVuqwTPJ7E3DZkX9ao9L3hH+JOupZoAZ3VWgmsVVVAfeaKuFZyAdUd0R6PQ9h/ZA9ber ThHPAjBSFTKe4ixXmFT5sPAcUe2LQwf5u2yn2kK7EkqMfI3sylOUKtiTKiKqOwiWLTyN7KeaeTYM QwfJSjjrlBW7UD0MPWqRqF/dQjja7Z9nOdWE60nhNqCXLciyhUq/FsvEiocV6aGFzdHbYrulsqVf PMuprj1B0NYCXaa3lnXJQjdF1qhUD529KaK6pWS057/PfqrBcIYywbbVQwsjqtszlC3+7llP9Vcu 0iuY8BUnAiNbTBZUo4lWiXogLaajvX5A9lMNhlectAJdhYxfm1KuM37pMUV6SNSvbq9IXoXvneVU Bwyf+Go58yyp2t2sUg2kI6qvAhzt9iPaBdVAV5EWPWkqVAvSEdXtFsmr8MWznOplx79YfuJLy/CX y48T3suOi4XSZSgV44kvxy09ZpAuaB5SsHFQ5K++CoC0y4/IeqqJ4WXHmWTAzEJUWwvrqEBCVBPP zYNZIqrbJZFX40u3E6oNt0JvqnRcOVHNSG8cTG31+qtxhaLPaH9XIOup/qLm+Jc1D5MA5phU7Ei5 oUbRuPKjgDmiuv1ReLW/cZZTXfPwF4z0F9XHRAHYUIxRijgl+9gypnoWWmmRqK2+2ri0k8/LfqrB syBd/fAXEDBsFcfOdcZKW22Q3hD1QNoJg1f/a2Y51QQwEyskGx0WtUupUM1ttW2oI6qvPi3t5ROz n+oqyy0U0V0FnGuFMWVHBemBszZAora6vUB41b9nhlQjrkKb/Kt8mKC18nm8chQWNh6lOmPKjoBq QRrp1JJVbfKdo4O2yRVwfxqZUC112iSt3PU8cUv0flHJDCMlRcQYpYioJqRnGilcuLxNvnN00Da5 AqGobttoTsJwXFp1lDBOlNGgGkhbsPtF/mr3TncmXX5WSc8Yz5G2RRrfKhHdyiNJeJZqo0uZam6r B8zcEFGd9LZ2BmMqqsXe5tGcgGvF0UsVnAq6FUeQvcR2wpuybEGdUZZqID1gRkR1Z+A3+TkmpTqp MfnfX2MrQ0voLj1yqVIAdlIYDdKsgGrALEhHVF/jO5PVHx8HcDb0OtzrVc48G3oZXegqQruW5i05 QkhTQ70eEvVA3CvZqXSXatHbvNfhXn+lWkleevgSibLt6EQ184y0f0S1ex07ma5Uq5JVF4CoPnyp nEkuP/yZ6EYxRZ+hDiyok7fkMDoe4Fkkaquz6la25pcRmNvc15HqlC2xgPbKEkP19KgHkuqidnx7 FvY63ItedvhS2eHPIOWHKDXKISKcdKSOPXfJYdNKo7kG1dMa3I+K9M5zBbKz46HXn6gGtyLCsGYT lIDq6U39IBHVeh07mZLlVJce/rT00KegupREFJMtc7Jc4dPcxYf7TUcrzUhHVHcykt3TzX6qQS94 Lj1oBXhDF4tJmfmDoPoQqKZWmqV31Fa7d7oz6dlOtYV5iVXAM+nMs2sE6jmLQLX0PZr6TmuKqO5M IMeca/ZTDXQzFFDddzrxLBJRHXOnO1OmHVB94NPFBy8S2AcgonAaQ/tFFOUsOqhIPzCtMaK6M4Ec c65ZTvXiAxcXH/yUUlIkpewS0dkO2heTXBy58JBDddQDibnRnSrTDqgWpDNIhWq00iJRW92pSHZP NsupXmRhhrJo/0XJks52sUgR2uoRCw8q0n2iHoh7mzuZnu1UM8kBvcTzJ5Ql+cToBvhPmOqmB6Y2 9mGJ2upOxnJwutlP9ULQKwwb5SIsYuQ00E1bHVEd3N5OqmU51Qv3G4aF5PTp8IUHpZWO2upOSrM9 7Wyneu/FBdwyU7qPmmWkYjGEc1YswxccUKp7T10X9UDsTe50/2c51fP3frIA3JJ8bBU36xo/Hmap JqQjqjsdy8EJZz/V84lnoZcUmzUWzhLzUEC14RlIT1nXe3I0EzW40Z1Ky3Kq5+39ZP5eIpbSvYZq 0dluS7nC0AX7lepeEdWdiuPYk20fVDPSAcwJ2XlsIaoBM0tEdex97ly5bKd6z0fz934EaOft+ZhS 6Hs46xpRxMah8w3VQLpXftQD6Vwku2eb/VQTyQSzRdowzEainTmn9GNQTTyLRFS7t7mT6VlO9dw9 H0EE3bl7jS4WTaUO0iFKdX5Dr/yG6G2xk7EcnG6GVCP6jdRs5XT+lmcU2rm7iWqTMu0x2d0fDZm3 Hx0PFqJ6QnFtK3/b6HBteAUCpn/wA/kariVRl7gKiH7T+v/mMMkluz8q2f0hUkFadKTIkpEJh6JU 98xvgEycU9v6Xzg6YltdAZfb9FRLE43v6f5Ja+qgmhkG0iqGcMdi8B4yb5/wLGn3yF/dmrcqm46V hmopakOkcZ2E6jm7P4QIxqrEZec89OFgS3WP/AZIy6kurDufueTN35pNN7ZTf5dUVGdJNCdQDVyF ZFJYdxWwTcxzUUD15IYek1tKNfN8rrAuI8mvODx67rZOTVI2nXwi1W3e63Avj6GaoP3AwCw6k1wc axw8dx+10ox0C6kuqM8IZmGekJ63LaLavXFtq8dRnQ29DveCFO/+EOimkPiiQVeDam6iz16hiV51 rhBSd27G8lMTFu8B0qPmbsuL2mr3zrWp7lKdJb0O93oI1UUC9i4Hb9GtpWjXB6hDVAcN9VqPfnXz +csLmy9kKEBammggHVHt3rU214VqdUe3+feJ+wJFuz4kYkEvp6IH6UNcxCmMg0qI6u6TwPNaSseH nrO3/vzlDY8nl/XWrsqi5qfQ62Ckt+aVbM2bE/Wr4+5em2WFaqRt6+tIdf5KdUByDN7vO/b3iepJ TDWQ9qK68dzlpnOX16eSx2OKFjY/RUiXbCOkierIB5LqNra23e2BtPaxMzgeoJ1N8v4VpWgXqN4L mLtZ8Wirheqms8T2FWXBxqeY54jqDG5k61bJdqp3MtI7meq4lLIfzBYjsN/5/sA5ey3Sa6D4Ud14 9jIEYIsSlyXgbZGlemvunC25JUijtrp12U19tCynuhBU73y/ELKDUzAs2WTGAQHV1GL7UP3Y5XVW wDPpzDBStUORovncVueWbAHVOQA7ojo1Zq1ckv1UF+78B1GdSnYEpZZqNNRruk1c0zX822KjQfp7 ZhipyOUGUgC2WkiZt+GCIg2qc4qjtrqV4U15uCynumDnPwqYW0p3vG+yUHaw3SqSZaqJZ1B9vxfV DWe+a3iMGG549HtK40SMtghUE8zEs8jmlFc5KmjdK9AuqE7KMBsN3gXbCfIBc/YAZhWPthpUr30U 8r0K8FbdKt+Jca5QzUiPLN6cUxxR3brspj5aS6gOO6yc+lukLBGeZwHaOOG2WmA2RTv+0b84oPq+ CT49kDVM9ZpHv2OFeCadODcpgX2GdMjc9RdGFm8xUrR5RER1ytvY2gV+VPsMK3sNKM9iemfteA/o gm3Bm9IdrHM6azuVQpRqIO1HdT2ItbL6zHcQNwvdtZSs/xOaaJEREdWtTW6643lQ7TGZTcbg0n2P FGWgGtCyqCLZJMb+xbvR/bgPQlSv9uiB1J/5ZvXpb0kY4NVnXIV1KhLjt3Ms1YR00ebhRZtSnERk bu0rEJbqsL0O8GyGlUt8BpRnPPjezAcJYKQkoiBlMXbGHpZ+Rbst0t5t9Tf1p79NFHCuRtXnNP0R DfWIok3gefhsSlv75kXHS3EFwlKNWRA6EUKmTMRlYRTL8kPvGKTtmHKKr5DOTFQnIi2E21TrENXS Sk9YzW11fbqPTlZWf+arOgD8yLdIRQAzKY9Yqp2i4qY/ShNNSEdUJ7uebWULTXXSORI6QUKVc5eX H3yHZrLJHAlOPc5x+oPvAVpX0GLPePBdSdXOWW6rhWd0P6gHEp7qR75a9cg3InWPfMMCpEUxKUoB OdLixj+aVpqpHha11R43+Nr8SViqzewId6aEqzvTJ5aBattKg20MwHmcAVP9LjC2QkjP2BabldJt 76KtJpgN0j5Ur2KqV576etWpb1aeMngT5KIjRZFgf+qb2Y1PSis9bPYmyJDCqAficYevyZ+Epdqd HQFdJ0XE2ZGtOfCONtQyWuFxAqB6+rZ3SR7klHk2ulgYaanTV6kev/re8avvCt9W1578CjAbOfk1 8GaB5euVQRZGqjN73ZPC89DZm4YWgupmjxOM/uRaXIGwVOt0CHAbzI5wp0zw3AlUq97/tjTRMk0C A3Ae398gLWBfKe1b9FDX8WiiCekWUP11LQOMlOQUZ0XXlI2F654cWtgMsJFCIqo97u81+hMPqt1x ZAs5BpdlsoSZKYE6oBoTftwxZY9TANXTjLwDZfo2pKRM22oVRp3rvNN39kPMc/2940k82urlx78S mFecNIphW3l2FKFakR5SELXVHnf4mvxJWKrXyhwJOxdC5ktgxI0UFZ4+UbXvbZkjYQfgNnucgAFY GFaSoZDusM1FDzhU3zPOk+oVJ74iOckp6V8bi9id0oIGaqvRRJMUNA+OqPa4wdfmT0JTzYPIdkYE DSjLxAlVbNF3lfvekmk/OgDncQbTtjK6gjGnU1PrTLVpqL2pXn7iKxXwLLoqWgSloOF/iOoCQXrj 4FlRW+1xh6/Jn4SlWkeQUyjfq71iL1EdDCgXbfY4gSlb3wXG8bIl1mKzfWbvor7HuHog7U31suNf LTv+pSvolkh2ubUDaVhmNfwBrfTggo1opSmNqPa4wdfmT8JSzUPJOo6MeRFJx5dpvsTSPW+6SPsN vU3ZbKne8s4UlqmSCurQoYBqBrtP4S7huSVU11h0VQHA0DWryqy1fzA8FzQPmrVxUET1tUHU41PD Uu0MHH+nOhQdR1ajUB0MKM/2ceeC6ilb3oYwzFDAtqSkWCNZoPduMdU1x7+oefjLmoeRflHNKWfF gjRGmbkGVKOJBs+QDRHVHvhdoz/JhGrEVZBQIagMaM2YMg8iY5St7jSNtZkxZTHCcvrb8t1vxAwo z94kxwqVzmr8o1A9ZXMAMxjOZ9SnbBbIUfQ2KsRRXTC/MtSxULli46OAOVa+rD4Gy5diBNicpToz 1vxekR44c0NecUPYw0X1r+IVcH8g8rGuJU6XChpXwR0+5rFjGneDUUbc3FJQrQPKMloR98mZZMEq ABaG86GrsJGzRLjYheq7x9XdPZbEw7NXdexS1bEvIEBXUlHEGJfOWP17tNIDZ20gmblhwIwNmZxR VKcVrkB6qhNLaeyYBYNrUGRw2RppoJmEh5hLH3odA8pm9K2Qhio8TifAWHne/FYyI4Hdu2BXgLQ3 1Uc/rzz6edXRLyqPIf2cSf6cdXBOCpWyMn317xXpiGqPm3vt/iSRWzmW9jriDm0HkWNHk80oswwl myJDNY+7yVBF3Edlkp3MDHMKmN/S7OTNb4sRKckmQr0XqOZWmhpqL6orjl0CtJVHCN0ryrT6/wbM wvOAqK3O5Ha2Vp2kVItRex3ud0kz1hZXtGTX6zyaTK20DFW4n5OhDlwFWlLihGEOSje/1atgZ0up PnKp4uiliiOXBGxSjn5OFjaynUthPHJJqBaeB8xY3z/qgWR4U699tUSqEy3ut1hBQ8Z29I2HlXno jY0nv0apjDXDuHjX69JEE9Xs0XU/J0NdSJ606S2IUi1ZsWgRlJ6ziGpqpUlW3TW+NsOjaLWKI58u PXJJBehCp/Qwp6LbCqAafWnmGUhHVOtVbHvFZThVr8P9ljrKJgojHTMYpxUW7XzNtNI8muw3oAyS leFAaU40vilUK9J3jvGi+hBTfZgwLj/8GVIinLNG4Ww5gz21DlQLz5xOX+9eqEhvwyugVEtY1KS9 DvfrLT/xJQQDEzK+RuNukj3+FYbeWAzkC3e8xkNvMvpGfl33czLUJza/NXETEYt0YvObk5opNRZR OCVL85s9Z+2QVvrOsauI6tGh2+ryQ5+WHf4MPLMAbGI7TrTClFW/4yaakO43valfRHWGN/XaVxOq le0rHlDGjjNJF+54VUeTBxXQUMUVPzyxAlEtJKdPmXmmmngW8aC6lKkuO/QZyWFOE3WxHPosH1RP b4IA6b5Ip0VtdeINbBuLUp3h4RMG3XTETUblJEtjcAu2C9Vm6A2+ggwP4VabkIzqCRupxZ7AnEsq 2R6zdijSfm01qC499BmxjfTgpyRksVnoB1ln4+SVv0X7TK30tKa+064O1VjsnKHkVx1yL1Sku1cg 81Za/opG1kRkDE511876/O1/l6E3deq6x81QB7RXkI22wsY3eszccQc31EghHm314kOfLjlIIjwb hS1LGGkthcJUG6RB9QMta6szikfB23bIzh1Y6ZzhNeyE1cJSTaMSZmwiGIOToQodehPs5z34dx56 49E3uHM922qGduMbEwJ509HFbup0Z6oF6TvGrPSl+iKIXXyQ0iUHDOSxOhcdvDip9rfSSj9ASJN4 8+MRjwIrnb0P1+H/MCzVOjYBhmX0DRZwTnYejOPsF0hBtRmkYKT9BpTHN785fuMbJBsIYCjofkA3 RikS48Y3iOrRq1R8qD7w6eIDFxebFEoghHps0aTa33AT3fjANJI+UzypLqwLubmSbEPjFV+lw/Ms J+hBdUXKcTcZszCjcnMffMWMu7FTF04wj0vqUk0wizDkgrohnO2mrR698naWLuF9IIsPfLLowMVF +y8iBcNQKBWdFSq12Ym1vyGepzb2Yek9ZZ3HCVbu/nvmIpuFaTwKj8N1kj8JSzWGJByhITYZp6g4 QrrNkj532ys07kZDycap63FJQfW4DW+M2/A66CWFG2e2UHMNRRptsXSfsZ26H6NXorkG2B5ULwDV +z9ZuB/pRaSsmOyiA6SIhbDff3FC7RPURAvSU9f5US1Rg2J2onmc96ZxIqtQ6eMcX6Uk2IYGobM9 rmcn+ZOwVNNghErSQQpbWgKqZ2wwHt3p6+EB87ikYzeA6tdZmGom3FpeH7ceRWKnOt1m7LideZbU h+p9jK6mojDMCxOME1Y8ESDtS7VuyRFsQyPxVdz03GVsWLOMIlGYqEG0bN9rzb7HLWiPfxKWamdI IskIhVP6WcnWl00rTUiTB8zj+ozd8LoIoB0LhgljUmA0FrFT9o1uM7ZL34Ma6lFebfW+TxaQfOyk mhVFiqjaeKa699RGtNK9pni21YlxVLBsX4yyeYdWqNlv4qsI0hHVaXAKS7WMrJlxikM07pZ8zOLw Z3O2vEwNNfOMQQq8WKX5GqmKxjDAhHGcCNuxxvuZauJZJHy/et6ej+bv+9jIXgJ4PtK91oIi6JLd +/G4FU/0RhPNrTSo7unVr5bQEwg0oYro1kKRKESnSBQlvLUBN9RYPZfqokX2sFQ74xTBIAVGLmjY gscmKOXBi+ItL8m4m3V/NXpcbaI6VmBRiSsC1V2klSaqaz16IKB6nnDrpGqBIrqk45b/WlrpXvnr euU39MwPvWkpLgiIJeGgExSVgsVEohC7NcZGoqC42R7Xs5P8SWiqZYTCDlWQI5ctlPIQBpAWY9Hm l2gomcfdvN25DPBrTipIw8LGJi16bUzTa/dN324b6lo/qktAtcheVpCyzA2yHzP5ZB+7/NdookkY aT+qJeIEFuZzAAravIN1CUlhUimqNGv2aXcDXjoXUZ3yNxqW6iUyPEHoymAEhipUIZ7t+MXF2Zv/ 5iKNF6uUXyJ1AfFM6LJAUVn/2mjVrXLf9AcJZkhe7W15tV1yQs9uAtVzVXYbHRjHGK197DKmOr9B qO7h1VaDYYkAL4qbwo6sCHREotA1+7J0LvVl6+wlYal2BybUo2uM7N0VHU7dwk1/k+EJdX95XGtQ DXpFBGnVhWothUJUA+ZRhLQv1R+U7PlwLnNbsvvDkt0fIcsK67upCFlADv7HLjuPvgeaaAj2T/ej mvY14JDvq09/J7q7Wt+12DX7tKmBLJ3zuJ5xf8LD9OczTOP+NpuzYamGO1e8tZTKwEQSheow1U3i +0IKX4HHdRjdZKgexQ3y6EYmvPG1UU2vQpdUwQbVwnNLqJ6z+0OIJTle0SIoY2rOE88ivlSbQBMc EzuIA2/X7PMSfhMfvnz3m9TxkFjZCFnpFYnCvQUew/Tun2ezHpZqGYlISC8ad664djktaH7RQZp8 BR7XIa/pdaA7qvFVkzLJo0zKRiolvCFdp21Tqm/Nq705pybsEYv3fDDnoQ/TCZi3FUYL1eB5ckP3 yWuRhj0c6us6fV2kj+XMslRfLGove+gNRVoCsXocTv8k7DA9BjTb0XyqsFSzI5e8tQB7gQh0+Hih 7/uYFCna98msjUS18X1NpbcqvaSZK3lNrxHSKSWmtOu0BwGzys3h+9XFD31g5cPih1TUKArspIyu Pk8dD0a6OzaYnrw28/PSmhwKO3Fpc7CuGXHgZQU0VjfTgn1a3WyWguqHhFIymhxYdw4zA2ly4LJT tK0PjWluzWk/86nCU+34bM1oBTt12bULTy/YJn/v3o9nbnxBRyjEVxDq4kvlvHWv5TW+CgHYolC6 zuhktDrsaKsZ6RW35q24NXeFB9WzH/qgaJeRYquohRSuAKShj6p+vMckaqWxZzrkfi+q45Ywp8li dXOwDpTj+3lcz6o9ryxsvpCh5FccJqRpGxQa0+zAVLsOWzMkYb24yEqp2GdsANU04mZ9X15ttaWa 6HUADthW47pX7zVUc3NNVIfugczeSbjO3vU+pTvfJyFdUrZAt8a8qsepiSaksce0J9UUUlijCovu ZiXmMFsW6zpQQprWzXlQTXtR8awSM/8E2TjR0nOXpy87NWruVtkwIhdUF7Wbua9h22ry36pH13hx yYVrPboAmwYykE5f/7w00S1x5+YyzLnr/g4B1Zpl3Vi4iCow1dRKQ27xpPofwLiQuS20AMNiCN/5 fmDc+X5e1TlppZlq7DTt0wMxoYOx6tNGFcZS0EBX44mvsLrZBsqmKKx+K+bAcDDhRDfxSbqzz9nL 05adMkjLdu0dl2ry3FqHbeDFdT26VjdU2xEK9D892pbcBpBMxMZIA2fdFBUamGqLtB/V2GC3cCeE wI6RHW7WVMgVqieula1L75/gQ3UmK0Cljl0HCqRp0RxWGHlcT51boorOOZH5J+4slGk1J3X3Ewz9 tKNNysK21YHLCz5b9YC5urh5d384remvPdmdS74vfqvyuAs5617NsfTmMNuSAnKTbQiUe6duBcwk OZ5tNVG9433ZPB2p6qoUAG9bIbfyHHgW4d1Lfai2QSnjV31yXFZdBBqsAwXPiL8qkf08ric2OgG3 ZpieJp/Q/BNk3VTrTK05GewWUbS541GNuAryj9y5cG2xUzdNCuCnEtV2hIIdBfYzQvyf0/Aq6AXY KmiTVY9T7nGovjlnRe7MqhBH4qqg2uyWzvunK95JlZzKsw7StG9p2MOhfrAOVBd+plDmb39VmmhB GrN8PQ6nG6DwlhA0QC+KmYhCO0eIhdIp1SdMXH3e0nr6gnqPI7ban7i/8UzaaqkjqXhr4QSwCiAn HX4wsbAOx9eHU5r+Kk00OQr4rcr9nAz1iXW/A7ojG14ZufYVpIwx6cKztRjOiWpupZGC6slFFRke RavNW3PcbpuObaaT7pwe7J8+suKsbjCNTR4HTVupn5O5Ios9aVmcDVYpS+TIboy0XA5ZWjFng6/K WozMj6I1Vx14RUfh0ygyWJ9fdQJj9Bj6kdGfooUr9HOyUAlFtUSu1j+Bv4u8tUjZ8SU+LnWCiV0q 5DPV1ktAvi/9kMyVHMszUZ1KpM7aV+6euhUwsyy/OWf59eF9IDO30667JLrNNGdBuLFr0fb3RoBq u8G0bF2a+XlpTRCbSoKVdBzNMm7FHGb56odkrui4PAXSxz4RZ2gna1Zk2wiKtI869WzPrzrO06h4 P2u4ymf5xNXP/LtdxZryo0v6gXh2xCGNauSzjRFygiWRne/nNz4HXy47vtijO3FN0qOkN45IRTI3 3XGc3zUloPomX6p1F+kEBcBjT95g++kRSx8D1cQztnfkNP25JC2VNXF2lZysnvtcVxvJojmpQyvm nLB+fqGiMGoJbjmKPkXON0ID9JLlAPtS4fS3kyqP62gmXOUdgGqhPTFAGbm5RKw7V/y3s9nNGxTt en/yuuesL3fN/ZPorSrpbU1vBNVxApIDyxrSjWXNK0w1tdIQonpYaH/19O1mB17s86hbS2MrXuwx TfuZuvvzbnt3+NLHDNK8vaPHtuk4dwJYY/qRYsL6UTA0KTpi1hzN0bVFHADNbxUG6LUD8bQVuxEJ OR6XPfXNpIqHZRqVjP60d6oTm2hlz/i7xNPFDgH4BMgIj4F6w9gyad2z7M4NvAT6IZkrI1a/MmLN yyPWvjx87cukEMaiwGiKxI4Kd03Zgu4HeCYZ6UP1VKE3s5Sopk147V54Y+szPy+tKWviaD0RVhVx TD+JhGYWGbFR7HZtEQdA41nr+iGZKyb8OG3+y9tYy3C8mxWddweeWPEwb2aNMXqKajuo3fZAkvY6 3ItGDFvXVgrfl3GITWp4tluM42u1+zkZ6sNXvzx8TYwA7DiLZkG18Aykfal+m/YnFcEmvFAkjVN4 A9Nh5Y8K0mbjMC+qgwVEupLIKGZtES0ysmuL0OuQtXJoqDG/N8Nr6FarPcHbWHO4Zh2dl+DMCODM Ft0U+KvxS48Rz2b3PXgUfXry7tFbTXf71al6He6Xge9L3F/k7GI/mFiQxSuV8YCxfWLDM8bxRa9U 1P90PydDPZHqJBaL/Z35V4Fq2ttxC/GMVPd5pGysBdmhZY/q3o4A+24vqmXdUFyq64lcO9YWOasw KGJDhtfQraZxmDVQc9w4plaAHVTz0DyNzrOfvP1RnabX4V4WOAfg+5KUnWDk/oJ/QPxgrn3C2mdc x5c31cO4uUY6bA0JWuZAQRHsUrT6ZaKaW+kbKV3m0a+eyrvdEc8sssOjsxce2WUXPChDyh7V7R1l jwP3QmWoB6swDl7EMqIgi1g6sdnZm2htES3B4CAkfjN7sfVeitFM7IsqwmGceePUceVHZcIJjfvM xNZ77YzqDJHGnYITIN7HFWvRCuNB9QSMTbCXYAL1PzO80W41Inb1S5ZbKEmFwV79Eqi+ceQyFQ+q zYZ3su2d2diR9rxjvHn/u2DDx7eHlBLVur/SnWPr3G+eoR6/8uLAJwCbV2Tw6gwnYJS7CoMmQ3rN V7chbWXU0h3QFD3GMrb8KDfRNDoPD3m/9kZ1oq8j1U0hzwD7BIxinF0Jxm3vjl/zjLgIkN7Lb1Wp PjONHRgPZZKRxilCu9iliNtqQ/UNXm11/iZn8zuCOSZrt8B7RzYRG1J65m7qeNCGHUj9qI5ZfyGB dJyVF6aU7bPsKgydCZnmuqUqqnw42HFPhzVlJAhZKJpCGVN2dCAmnNgwie2O6lQXIdFODq70Yt1f 49b8RXlGQ41mLfHTrmgZUk8wk0BR3bU49jvzNwNmtNVIbxjh0wOZtOlt2n2GNwjDPkqyaxgswJi2 VYqVwaBaNnbkbWjuHOPTVusqjITQOrQKwy2dufFF4lkm91KsBp+ZvZUPB4M+tPueOwbEm+7JOKbY R5cesUjzfgotC2V8xXt9FSu4b4uZfKzxCcAJwDKdXATEObsLYCSnAWW3vTt29Z8Dr9c4f6oJbOE5 TmGjKeWiO5hqQdqbauzWIdsqiYLUFdmnRtJBS05LQ422GkHg7/CiWueoX1GZQaswzGR1WQWcyf2K q0PhEGk/Muy+RyM+oNcM9NBWZbQln2SJ6iOfjyo94sSUQ6Run1mXcV+gdbJhqY5zC4hzwLgIxFFA brF3UW0MUx28T3m11YPrXxpS/zegG6R1mv0baGc7LGS8HVSPoFZaxKNfPYn3oMEWM7IBDaXWYvaj 4SJwjiyoFp5lGxo/qlPOVzeRSWghBsmej7AKQ9ZftCRQg+zTZHZxshERY7J2GAjGvCWHJUyixHXp 3bGpdvwAoJfepCQVvwF0zo6u/3OAND+pPX6nTPVLQxySCWDKGpKNDkvd326fHFB9/fAaD6on8P4y BHBKCfapGbjkEex/hyis3FAjFqtPD8Sdr45ADRSTgeMziN3EJ2H7tKbnpYnWVe0e17Ps8CUz3MPR 5GgMiONuyWCQGfoRy6HPchcfNgHleNCnA1PteAPEJ8AuAn6xYg9Y4CgYVf+0UK2dT4+7MLjupcH1 fxtclyDJjFeFatmwA1THKNinQ7bqcJSBix8xPJvwwj5U2znqH2FaL3TMeGQLsW11Y5/a9LwJ1IBp vTQH0qc/QAM6LDaCnGyCI9vf0HAP2824T+7iQzLow6G3Gjsw1dYPoM6BtxIspmhU3dPqIqA9Pceu 8qQ6EekUFlB9/YgaaqVFws8DIXSxl0GwhYHsbkAbHLjbdkiFAYsekd06NBCrxwnyxF1atC4Kp0YX IyxipJm9vP5Cp0F6HA7bKARBt2zsOHesxy0dueiQ8CwRMDow1c4Oy3Yncft6RS9Z4iVgJW8VqCaX F3c+6X3K4y6grR606sVBdS+iuWaFGm1RkAY6G2+ftFl4/tXwGohHD2ScIG2DvSveFA0+zrjhjf5C tYmYvfK20Ss9TlAWrdOkR47GAAVT03UOJM3s5Xm/sGAOJOarB3MgJ/nMFosZ5eFNE2ItskuIGQwa sfCgxt0i34vXGj2Pa9LyPwn7tug6BNLruaueAs+ENO/p6Uc1eBaqKSVhpJG6dtFXvdhl0iZQLUj7 Uk1hsZ1g70HId7IHAvvr/RedklaaArGOXnlbng/VstS3yK5t16mPwNjqZs375HXPWqT950Au5D0U bPQtE4ZLvOIwQrEpKcMXHtCILnhR7cBUB69RsS9W4hagUmvPXXkBvQ7AbDufPjd9ABM7cNWLKmA7 TlfLbZM2WaSr/ahGWD/gSgGE3fjYKfR+TLWNLYzIfj4nKBMdMZs3mPHIU3zdrOigmuZA6oSxCT5t 9cK9FIYovXCoInKVD1twwLjHOe5rp6DaegnwVhWgzjp6obDk1D7lIE1ba3k8WQastAyrAqpVF8Vm HarRYld79EBANZBGCFZOTehsistqhEKzShEs/Rad5MDCJl7lrV5UY3mvmRJmVkrGZWnCmEySnNjw rLNM0nO22Ly9FJKIRCLMa5x5tTiBu4cu2G/DuVCQzA5MNb80sUPAbIAY8xplX6mowsjaC6aVtj1P H6rrXgTYLC/Y9AVQLTorL1DTTZYXiOphNb8aVn0diw/Vja+6wYTHNBHhJBS70sYchs7k910Iqmtv 4xCsEgbN4wRn8VxHSne8h7QAk8fEsv09mgzJdpkbOYHnQLpryjwOR7Fc3IguGtpF7OwYl3AuqDlk /n71jVOXvuP2q/UF6orKiBUXsJXn7RCzT5zPA1pJBrRWCOBYMZbbJqIHUm2oHurTViPEmUZYRcxV wBxkWXctDyw46QSrRBi00OGygaWZKsbTIGmxZGqhOZCyTJIm1XjOFtMQLhTE2MZ1gRfR+MnJW26D de/+aMi8/YEvEYv1xvv4Ej1+ei3/k7Bvi/zGpO9QgWJ2jnN21Bqx4k9mhzjaeIi2tPD4tv1XvqCi JPevNVSjyDXeOrFZWmnvtjoIU4molSYWKxSru6FZG1/rs+AEqDbBKhFdx4tqO0kMyyFlUSTPE4vX yThOZovZqWJ+82rm7CbHuBGNgOEo4ieHLxHK4Hn71JeILn0HptpsqhW7V4t5w9KXLH69Gr78T7SX lmzUwsHSPamufQEYE9uiaCoWwZ4rxFA9tPoX4f3VuRKjkmP3xYSm5MBoJrjfOhPKss/8EwbpvFqE 1rk11+dne4WpYs5EMpotJq00T6rxo7p4twnoanyGNlwA+Q9ZJ984BxCAg3HQ3H0aGxNR17p23LZa 35v0fYr6nMHLFL1YyQvXsOV/jH2Z8rnpluTnWUGqikIuRkpvncBt9dDq64ZW/3JolSfVEtmvkYL4 STQ/xIlSntloinoT1SamH8eM8jlBmhUWJ7qmjGfUaKmZLWaRxkCARyuhnnB4FFk3gTHZkcgxM42d 3IkDS/aKL1HeUjs01bEbspg3KdMFlW4ncd702rBloDrYz8LvAd2v9oV+tc/HyIrYLJcCadQRqn/J SCP1ozomoF9cfD/JSoS0dX/vPY+odmKg+VBNs8VkKZmkcVnHOMbOq5EZCH5UF+6kyK7kKpQ11HFe xB0m4qt40QfM2YsmGkjLmqYOTLW8PVH/k+Kl2/0s5CVLtrSwb1hDmWrb8/TsdhLVcRgjqxZRbJao JqRFfNrqkY0U1k9EQp9RGhsSTSv0mndcYvpJaJ2bcld4NJ7OvBrME+NZNJhUk2RezTsyr8aZhODT VhfstGtLY0OuifNQ11mL0n/OHov0al4A4jND3uOatPxPwr4tBu9TFCk9JtR/bNGrQ2qetN1O85j2 +Laguu+K5zOUW8Y3U8dDJXy/mkOcmdBnEgaNgkdRJDQjZLSWnky1IM0RSHyolmU1nNJ8A1mn4Bh1 vs3bNK/GLlKg4VqveTXsNpSgarLU1MQVlDhs5Fc0cdhoOWq/4t3sdSHfOLwud3mt0fO46S3/k7BU U8fSDfvvvF7FFK2zVDuhdz2+LVP911iq/9p3uXCudlhIB9WMdPUvhlSRhKd6+JrUcc8Sokj1nHtc I+ogYsONOcs8ThBjsrxI4W2rmDULbCRd7bmYV2MW3ZjhWo/DSewp8h9yaDWTdVae0rJTKX3wvX5F u7mJJi8ipANTbbqdtm9pe6FJokwPrv4faqtt6F20aR534YEVzz+w4q8ky40AaddCPKOIq908fqOh WprrYRVhjzh8zUsUSIfi6nBKumbFwpF2KNjOKz2Yao1A4ke1TDCY1PyWrFPAmCzpvCpBUrKA7ea3 cldiXk0w/QDTBcOeHepP38YuRLhWeCEeYlK5YalIJ6eiWcTXt+gh4VlmFHc8qtGkYx06/kknE71N 8IwepqRBz1O6oPxWNajqf/RNih/Ty+UTQqUja85bnp+3SkB4nMVSTQ31fw2pmlhovnPmR5y48qzG zLmi0r3kYQnUwOmyHhOqMz+Q1pRZ3DLHQCYe8KxXMwlB53ijKBirpencq+A11Q/JXClo+hOvwuO1 ePCxqL+FFuXZLC/Qw4KmB2YT1WaS/Li6aXN9TjDz79aSmuDT/Y1fsQei0ZywDh3/pIeJ0Hb80kQp dztBuOlwas9zYNUfQLXT7VwunxAq7bPi+T7cSiM1soyoFp2UZYF+87iNpu9BVFcOmxbqUFR5Yu1Z jtUQRB2h2CMSP0oCj2gEktUvM9XLgLSu/w19vIoKMIxRWknNcC1PecXcA7YHKajW6dwyCuBxuClY fOf4VXS9XmC0y/RQ1Gf2LiBNnflx9Zh7ObqwxuOIrfYnmVMNpIE9vpj+CUGb0MNMahlQ9QcgTQ9o jnqHu68fkrnSZxlRTegKvaIY/TlTRBWeQwVQjSYaPJMMrvxF+B4IFkJKBBIJxSC6DUIiUUcoldLu c45J7BFd/5v5eWlNGavlkVlMF5SxWjOXG1nXTmO1Y6iJllEAOJf0QzJXNLZJPi/To9AQToQTzprV TLD3LrRUc3/+rtE+R8z8u13Fmmna6qRF3M/k3qbGJjVBHa3Rdkr7V/xeYpPax7TPy1TvZc+JMLeB 7hgJaWRB9U2xVP90UPBjzPCK0WJ2XrpuwjW4ERvULkr9S92Yal38i7mvGR7FrRZMecWArIgO0arC djNWi+kHPJ/Kj2p2s7hRIIyPhZd7iB0pKfDD9CrYqe+n+EG1d6q11+Fef9Hje5vydLaR7txSUC08 Iz6YPKMTP+2Klt41hmTFO4li69w0bgNa6Z8PNuJB9eD6F2W5esyqdneFO+u8tv2l+4uPaSstqxWu eDqJFcycQJoZaOe78hiWzfKMQS7iUS2DtLhMEz/tihZxrdDrpyv8fhpj4dJes3bi/VS6PUi7tOe2 OrHX4V4rfijzs5g7nBJAyT6pTQQ8MfZjqs0zmqMZuJ+ToU5UW2jjFbFz2our3Th2AzoeEAHbk+qE RZHgPG45MNazw3J/8VE01Lqm7DqvtjpuTmCa7NBlTwazXtlfmuE1dKtNbA7WyMvLaZq056wddi4x Tbxsv1Qn7XW4l0V6lcEDWp7RNmgYeJauKSr0XfrfCOFIrZlEUvK66T1rnutV8yygZRFFs2IMikC1 NtRQPKgeWE9rITOU+yzVvACn2o9qO3Sl41miOLMEeV9gVMOolhmoFWdpro+ndDzWztv3U3K2NONF lUXW1LMub68o7T5zBzXU8LdQt2dll/A7aLvktKauGKfpdbjfJ4iVtBoRZohhk3I2KK1/6YGl/60P aGnT3M/JUGeqBWzALOJmXf3Zq0K1WSBJy3uxOpLFLJmkRcHO2skXuxYdDZZJ0joFn361GdKSsa24 lLKYScVzqxpfdf3/4lnK8Bq61cZveJPfSV+nxcXO+mL7ZkouF4i8t3abucPOusT6tdp2R3X6Xod7 WaTbiRgdNs4MhZfRrFE4Ck2f8t+ZGEocx8DvZapH9XM9q5/tWfNsklSMKK0m2pEq1T8bVPmzQRU+ bbWzKFJXRyZReE3ZvbOPcCtdo5O63QuVoW6HsZxtUjEKED/IhdJX1f8vSMOzlOEh3GpjeJIwJlWa N9PY99OYGcUbXr9/xnZqovMIafTkPXbQdg/dmrq01Uhd912aL5Dh0xnVQLX2OeUZneZjUxX1qGGq GV0CO63cMHaD8OxNdf9VdqGNKKtkVYIYOYWFjKQz1Vj2axaUXTekOtVZpLGL29/6/I3bn400yOXa Hf8/7aSA3l2aj01VRC+hNHOYF6y5r6ikq53fW5teu2/6g7YnTzN52h3VqS5Cot19BJuHtcYxkCe1 jWPQu/y3sQ9on5uOtrpH9bM9qp9hgUJgWx1GtZByw5j1PxtcSeLbVvdf9TxwxVxuXWJjFFjsygWx oM69hYdNKy0zur2oDuH/ryT/v3WWYvTHh+rRTa8nvpCauZeYbMmTMDXbddqDpifPE247MNXB+m59 WNsl3sGTmi29yn5LTfSwFj2gDdJVz/SAGLZjdRilqOqZ60H1oAoRdD88eiC8KkEWJuiqhETFVLjH Uo2JgiReVAfb3GBHJ3aQ8uZNpFMRb+0kev/K3+t4FnlKR/hQnUfzh2l+mrylSq9eLGLEFDXKcg// 3mnbzDQeaqh99q9MbBVbx6JvixkezmnE7MOaFg+SLgu9pQL0nqW/obWx8oDm1izDQ7jViOqqZ7rH SpyFqOYKoFpgpnSgD9V93RUKdto21iPIqgRXgU5U61zuoRjT9HkYyW4g5BqNHZonwnmMnvbB4UEB 9pRSE63v4O6FylBH/zxJT57m7SSxy77w2o33WLOf4be66tXCUq3rB0GvPKk1hSIrZ6WoR+lv9DUK dx+z6Ty+fPfKZ+OQTpP9lVANngdW/GTgUo+2Wua40qoEFsxuBb3QZSqsq0C/u+AwrbiR+YE8Uu9x gjL4rgOa4jglBynvG6J2KIGn1DrJPQ7H03iox25F5o1rNkbBDtqmz+O7J5rHN7wqfxKaaloMK4/g VE9qatkgPZY8AaqDlSm+VHer+ku3yr8QzJW20bYK2R3dUr1UqP5x+BHzPjRzG1O1eeY2zdnmSbBs 4emvWkpzX+8qOGSQpoa66udDKj3uSOAaVR+p9ZfqKCexTZ5S41MSN6mfT4k2XW0wW6+m6tJLHczt kb2G7QCxz94NHhfkqvxJWKqlEaNUH9bSsnGbZkq5qPviJ8yqWNuaeXzh+yufAbopRIpshaq//Gr0 eup4DFyKhhriR3Xc7FaTdSZ4a4U7QTUvT6ApVTyg6XGCgU8pxQimVhBPqb6Ao8XwOJx0ZqQDL6l2 7NGflw68ltL+lTTbYbkZR/NyyHt8yZb/SViqY5elPC+LUMjIq1Hc0m6Ln3Cfzpih4fFtk1J9fwrO rxvdJDy3gGqaJSXzA91prmzEFMGgFBZQrVMEZUzT4wSdcK8xQzyAmYeBMPRDCrK9ywKfknTtPA4X M7fB7I9mpimayQ9rNCs7/dmNG7xizLrfsLDufGHd2cK6c+lklSmdsfzUhNL97p+H0sNSrS0VKfyk jrNo1lDttGahvphUBtVg2EgFK5LCGJet/Mt1owzV/zlg6X96tdW9liefTAWGE2dV3THrIHU87LQT KB4naHxKKfxIxq2E0pUv9qK3b4ofSEjzOnqPw5nBX52LyH0b6uHYmQ+BXv8S7bPDE3jkAdGSt8WC +rQwx6KeX3E4r2RrzpytHicofxKWajN1387bl2YtZgq0Lbp/0a9lTYrMdva76fdXgOo/318BicH4 PrFQkdipTkD1wKUA+8f9Qs9EJap10hTPmDIwi1GmxWJSyjKafEJUO0jDT+5xFxJCrrmepRi3OXxK 0kQjlbdUj8OZvRu4t2M2H7E9H5nEBeyt/SXZu4F/SuSe9aY6LNK5c7aOLN48vHCTxwn6UR3fZHHj JjOc44ruW3ieeOYJ/EAaIyMeX/K+imcAMEklpxV/MVkxxqagmlppKz/uVxr2iL1qnrGzTdw5VKKr hQboIbfPPCgNNQ360AmG/hHh65HjSERCUWk2wei+fVPXboiPTyk2yr0z0YX6OUGUe+7/IB74ZkUa VHusbm46f3nx1mcWNl9Y0HwBqUpMdiPZYUGvY/yi3WiiRxRtHja7eUhBc9jbp/XDttWErrZmortZ bs1kil3XheflphPSvjedGF7KPEuqWVVgF6n48y8dqv9jQLlHW92j5hkalHdmmARj9DDG2rvMPMC/ Voz7ENJ+VAcv3fL27b6G6/u4ffuW4R5B2u89BfHAg8EyHUdTxe0IrXyRIyeb+QD0dAj/ttj42OXG s5dNCiVOF4tN52+8kFO8ZUTRpqGFzYMKNg6YtUEpDauEpZqbKXr+2jZNFdOCaYV7FxiqZQjbw3uM c+la/ueuS61UkAKG4yyShf2XedJWl6O59qSahilp8N0OyoviDGs6Y/S3zTigQ/M4u58M8GmrjRdR fInWMc4v3exdNHbyMXZbZN6++RWVvC5h7zXqyxhZTJo4PYDH1FBH4hayb5ajrISnuv7MN/Wnv2X5 ziqSRSoWY199+ts5TX8aXrQJTTS2mR4wY/0D05s8TlD+JCzVQdsVN9HIbcdYv3f+43zTqR2TwT6P L8lUPx1gHCANo9iDUks1kBaqQ/dAdJiSqOYhSxm1lKwMAKkdVP90EM3iNu7EATHLnDM8WX25vqLi vqfIQzDDQ7jVgg5PTFfHHYAIhiEQC0ujBuFH5NFW1x7/asXJr1ecRKoKsiJiFDtZCtc9ObiANpjG dni0H80Un81/5WTDUm0mY8jUC2nTjC6tHKdsuYeoBs/mvsPb5l7eDPWu5U/fu9QI2Da6GLWonMBG 0S/yGtFEG+mPHkhoqrtVxA/0pBnKvHX6fuaZxjEh/+lFta7HFOchOnixFl2V+dx9C3+tLynS88nw GrrVJMKb64BVHWMNqkNB1kSikAXOXqswqo5dkr3Rq499qTukWwvtmS52Saev+QOQxl542Iym55R1 iAPvfvNQeliqk95ladDiiu6ed47aMTyaefzaj+p7yp+GEMxIRWJ1KrViqO5f/h9A2o/qKjumo6M/ dmSzm1qstxxU66nxK6pPW42+HN5TJDXvLOxjoZcXq5j3lAXnxeUiLym4sKFutFSmcEA2XlByxRlv IqoJaTPG5HHE0kO0gSNtXUrpZ0GqWd6xVDY2nbLqd32nNWEnGoSCR7js+yas9ThB+ZOwVHfDfZdb j9tdRQPZMpzNdrLg7ovxLlCtI33sl/D4kncz1cL2FdP/QlsNpNFc+1INl4sM8YiHHKcWeMtZdy23 TNtnW2lxvPhQjTdQvImgX0dpom4tKJL3FH1JwRCqx/XsXfO8PBT4iSARJ/jpYKNPkN0MNj0nq5v1 p+RBNbZMkl3DeJsw7BHmihYZ48Ta32AbGkEakdDuaUFYv9BU25ZK7r7cZaSuCAl3zT0X3HR2IHvc BUv1U3eXUaNts6SLkKXsKdH/K3ed4dmfanaAs4cc7hc4wymttO5EeBfZwQjfOOxCtToS8WvyOEHw 7L6fcjZ4Y5W3GKkgPTq8qoAumRXgczh+Loi/3Twg9KHATnhxcKECHhyytoiPWEkNVPinQ8meD7Bp tZUPExQtImXssvM9Jq9FFFYEn79nXN2dXgG65ZqEpZqIpdtN91pH93CvY+2UvXPuWeptMs/c1/Vp W+4uA89P3V3OorpYJOsYf57bSB0Pg3SZR786cCS6nkPRrf+QPY3E+c1T94mzRVI/qrXbpi+h2p2L U+6e/zjzrN14n+uJdaDyS0HjT4qkVpGnBowAHqU3jOVVGKYb6TOvBvs0IRQ2wmVTuouCY1PKgmDC pCCeti3KqzqHQNlAGkFIsArYb1dWP6r5nsY6kLnhIh5EcPdZuaPkrLRj4pFAK+rRthiqXYBT6z/P XfcjRvpH/ct+1M+H6nvZeZjM5eK4E60f5iZLtfR5fuTVVtOcQ9NjF8VMTaSOHOzcq5fnIPfozMQt +R15XE/rtCS3vHnx12UXuigDRfy+f/1Ynq/Or0U4oof/f+q2t+0WIe+xgjRBeVCM7w1f+hh6HQh9 hh2ysLIM4ew8TtCP6gzvOKox1Y5HwovqO8ueustiDEX0u0q5AS+NLwLVaKgBNpD2o/ruCnaz2NdS ca2oEwaKa7lp6l76wdqnA47rcRekC0dPOhWd6KJPQy6SHp08+7yp1om7+oxIotjJvTIHkh64/Frk 8eybtEliQ1EkKIoHteltCbND2U3Icrxuu2P44NIzCD+C9b+38dIbv8U+flSTwyHWCwEL3Wu129Iu JY/F3PR+Pjf9TkYXGJOAakov3Fl6wepssUU/y1knPLeEau2xG2Vp0IePK7pxyl4gLVT/qB9+TWUe VAfPOH3YpVDQoxOYjTfe60ckcyDxC9JfkyhJU8yBJJ4Hsv8fP97wnlIs/pUQDVi9bmI1cCxB6BKr wTViB20EW0MTjemv14/AzBOfSBSZU62hQtAJj7uzmk18j+sy5zG66Ri5Nu2ndOHDpf3KHiWGS4lk VSSrRrX/LKdBqf5hv7KpxWXhDlZePrZ8zz3ow9unA07KdOmlY1+O11Lq4eP9FOmNU/ZIH146PLfn hj0a1UeDkKHcMfcsv57oJQ19djjc4IrH+Hdk3391Xo2ZZsO9R34pxkuTjGpJ/wpnOq049AnOqj1i Ap4kRvJPsGBPtFtyVmBJJqYI/nJYddcxlZkfD4i6TYr8oWuJ06WCxlVw7rh9j6Nb/LSxCxKc3jbn Ufemg7e4T84ke0fpU8TzEkO1sB2ftRViqO5b+qM+CzI5hFuHGFakr6TckL+Heju2w/PD8E0ZDo1n nLQMwcOO+z8wxlluRyvBTYRtJXyuZ9cwLw6gWn5HfMQyj+uJvRsk3CivR8D6Yl5iLOFGJdy9taBC 97nH0OvAfKpf8vxe9HzcW5NKB5lAWvmUaumpTizFTZfObXD3uQMQZG2F24ofpecyd3ElTfXF0thv L33qjiUXICBZlDssw2oE6mK0VJficD/sW/p/ftIzzScnLaIOjwifhen2SM9Hi/h8UXQ9UU0deJF/ 7VmS9DPTGwVp8luy6xLPAn4Q0DOCisRpWUYuzbhWAg+j9J+ctDT4BeHDU3eu6AdV/rT4//VH9H9/ Hvp6YiYVr3rAggiaE8ixsFiXoFgSZEPWR6x6sWvxUZoZOKQKPnkg/e+95iU9BdcoSLsW0RO5Fbv2 OuL+RJ/+cvcZA2lI0ahyu0odBrBx4ZaiM0I1GjHc93/uNjvuozLJdln8pIFZqTbKnxLtP81pwL3+ YV9C+l+6F2fy+XF17lj8pHkccIcnvf6rybuFZzni/7t1VNynZZKV1iC+oUj2mLi1GM++4Ef0L17X 864lT+IXZJogfcLK4bhzRUXWDk+p/mz9rie83+4ofHodq5uBNLyXP4G/pX/ZP6W9nuAzFbq47EmL 8BOAPa5Vl3tEN9rpD5gGU4zcohoSlgjVdBfAmN8dxxFvKfn1HUsAMMntLKQsjs2S/QJKfzqyAcf6 976lfr8gHO6mwtP4/vJ7CU4TvyNrJIWBRx1QzT8i+gX973+7Xa5P2DTZD4fahET7rcVoJcz1TH/H 03yHLvOfkOaIUnkeldFrS/D2LQ8mTn+WS+8p1ER4/YLwNe6Zd45c4knkOcdo9C4zDgJp9Hn+reec 9NdTmuikfMq5J1KdaHGvkjLmKIKB23iSfnPRGdz0ltxxHPem2afBMAm4pZR1VSRr05+OXAukvX9B ONwvxm/nn4/t7QQPCPkdwU7fQbC/DlT39XwG6SWVj8okvaXotFzP/+X7C6LrWURv39KdC3440kxx Kr9Z+kUvuYAeHZD2/gXhcDdM3iVOHvTnnbdUvKua19Wu8paK0dvKP988bR/cC/96pV+QIK0XMKni Mpyq1+H+oeHKgmSQU8ygWB1AereZesQbCk4Gh5APt58Pexe2SIrsjwdVp/+N68emUn6Suz744ciB 4s5Usnzc6yY91JJfkHyH4Hry78VcPT2KGDl78+zT3m2mnu+NuJ72M+UXqtlAMY/CC7ieLfkF4aA/ H7We+6W2d1omfVTOujr3Xa/P353+F5S+16HnCEWpxk8AeppWXf7qn7qMy1zcA/npmR8LNf0OEfdX YY44Pu5vPbJhDncVTrCVD4cLEuaI6a6nNNFX5FNugVCtbHvcl+hPoitwra+AIJ35UZRqNO9J/5X6 /kv6aZkYfQ9YmsmHJ9bp2IfD+bb3E/RocnHKCnakRFcgC69Ahr2OzFvyqGZ0BdrdFfj/m9zrBgpl bmRzdHJlYW0KZW5kb2JqCjkgMCBvYmoKMTgwNzkKZW5kb2JqCjE5IDAgb2JqCjw8IC9MZW5ndGgg MjAgMCBSIC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggMjQyIC9IZWlnaHQg MjI5IC9Db2xvclNwYWNlCi9EZXZpY2VHcmF5IC9JbnRlcnBvbGF0ZSB0cnVlIC9CaXRzUGVyQ29t cG9uZW50IDggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB7VzNctRGEF7vYvNrHDAh UFAEGwIhgE0CBZUAljCJKUgoCLYxL5FnGJXPeYecU+V3mK0cc8ghVfHrKJqVtJrp6U161jKSZroP tkf7aXq+7q9HY81KvR5bWBGIhOcG0ymHid8Wm4wjmZgHfG+JYew7RZNfaAlmRZv596/FivYvpwaj 4OZoMTT4B9AQSQAkDYrM2AiHlw3OsZdpNUhNneMoNS02um1xY1rGwuSbpr4zlpCw54wji6/vObYz zIx9m7k4x6qs/Z6rOcec4xbPW73eVGsuVjWrmlXdqgjodRxJoikVQyOe2ixMhV5jHJFXERLSzdpx qxL5H4OpGDvcx/WCsdNemw+M6YpWevGAsYOi/WAsE8WDbl3PsZuiVVw6zniKzcVuM04TuppLZLcZ T0G466ouE+fwm3OcZhY7RKxRaLXKdBgG55hz7CCXjw9lVZNiznXMdUwSSlMgrmNS5LmOuY5JQmkK xHVMijzXMdcxSShNgbiOSZH3p44jomGMBfHcRmEqn7qqxZBoaqaCRjy1WRhgLIfqAMUkpJu1Y8qJ bcCMc+yyuegFY6edCR8Yu20udp+xi6JVKXaesZOifWDspujuM5YyUSScrNuqnub1Ad1mnDhlNwcz 4zSzeIrINXLKeM3l4p1zzDl20ctHx7KqSSHnOuY6JgmlKRDXMSnyXMdcxyShNAXiOiZFnuuY65gk lKZAXMekyHMdd7eOqe+9VQyhdeKNuUrBeh3LJKaZhHSzNvVcmodDQpmMHR57whjHqrcu2DjHLlsx dMbwGwEtCEnJWCYOgyEzjlLTpIOTw4LmjB0UrQZCZSxMvmnaGsYuiqYzjuzAtIWxk6LJjCOY4Kzd DsZRmigWLmYnD9mFEW1lnE6xudhtxolLcgssM1b6jWHkhDoKrB11DEdKaEtARDWZcU8gYeEcE/RU OyRfczl2K5H0dVrVUI9WPDxjbC8OPWcc2Yr1mzFUtOLvN2M7w8w4y7hE4hJDJQgE1MbrMTJMVjXn OJcFq7oz62quYxUBOAvzXD3SBdcx1/FICG1bgdj/NY2G6dEPNSNpdwRGOxMYPV9nrvyxp3AYlw/y BcNYlHdfQ2FcPcgXBuNS0WqGCoJxVCo6FMaVogNhDHaPG1E1+C6YivzhmbYCGTlpgHEEfR4eW9Vz 84wFJGz/d1prCBpnLC3CnjO2+SJ3ILzKMTNWEag1pVZnTdcx55hzbInywAdY1aS6kggqhsEXCMi+ s4eAeOYqQgm+nA4DTG53RtVQMjGZIgB2hbGE8veccQT5It+KBKmc2OxEjoVNWL9vM5Ec+kEnGEtm nEUgRhNIOMg5RvRjrwhIKhNIV1OuQEj+COkdQYwcZxd5ZJgpuPZH6B6kgCiBdCUhqEZ/VtfIAUVZ Z6zee4sMM7XeVTs1qMaurEFRDgDGMskOYGQUzjCJoGIDkTUEAmqVqoutGGSYntZx+SBfMIxHila6 DISxtrkYBuNS0cHkeKzoQBhLg3AIdQweTQ2jjpWaS2PGKgJlNMa/JRKXePxp8YdAQK1acxXjRIbJ jGt9TqK+CEONTWqLxPykvhEIpCtWdZ2rWjNzk1ucY0SKPHPxzJXLIoaVwzOXCgzP1TxX5wUC64P2 RJl11oQDfHXKo2z+tIIlzc9HrRiiBALiOuY6zmUB1cJ1jFeRFacJB3jmQqYbn9fVQkqMsYRGAtXY Fc0fHKXdFkromqqznYk4xjq3XkKLkcnONQ0DSROSterzZ3WNHDAZ5489YSOwpgCMTAxRAumqVdfj 4rEnZJh+1vF4ry0UxtWDfIEw1h7kC4LxWNFq7gmBcaXoQBiD996GkGPzOsqMVQTMmGQticQlhiiB gFq1AikGjAyTGXOOc1mwqtv/vUwv6hh+D9qeKY3/j0ecOz1zCTh63xlbhJF9Lp9yDBWt8u13ju0M M+N8ctbu7HV85uIccx0XCw79fjWrWsliZGV0xr9l8YH+Kx5/Wvwh9E+Lv+2rBQJKYU91/nfq0/WY FmFm3OV7mZxjNUPY84apamxlqs7zx9ScqK25Jr73djAY9GdmtBlUIjF4PkJpIIGAhhCE7ggoUL9+ f8VjXRVjmajhIsNM1589Xrl4vF+xkQjql/W1B0unB9VABQL6az1+dOPMbAU6mL/lhSNVVxP9nc39 lVtNJeNiK+YIMsz9nTdPrp7UCA/+QFA7mz/cLvoehaafIKC97Zdfn5+rRtmb5G/pf/192Ny4o/ub mejvqPJXbTUVjPOMzxy7ZA9zb/vHBxePaoTnzv9pofZ3fo6uzw8qGfRP/2qB0t3N57c+0dIy2d8x zd9sDf4KRavx5YzlUP3dn78eWcPc3fz+9hltlP3jn3/3N0Ttbf/08JKu+9lPV3+DoP33bx4bWunP X1uDoCwqmVYMf1e+Rfy9fnjZ8HduBfP3pNBKqWjFUjEuMj67eHdjC4xgf+ft0+VTWsAHCzefvfsH oHa3Nu4uatXZP3750evfAWhv+9X9C7pWZhfvbGwCUOZvjeLvxco5zd/MJH+5NitFF4yLjB+9cP/V 9odd07ZefmOO8tzKi60dE7O78+bpsqHoU8tP374HXSXv1m/qiu7NkfypLNj+1q4Z/k7i/r7M/Qnz 3SEiyRXdOzJ/+dbqPWB3v/jshH6dGJy4cGMFYO6tfnVlQQt4b2ZucekO7Gr19tWzc5pWMn+XEH83 TH/9A/hbKvzpih7lOB2/sQL5NhDyggkSqj5QdNCuZFa2hsWJ5xYbdENs/Av9h3BNCmVuZHN0cmVh bQplbmRvYmoKMjAgMCBvYmoKMjA2MAplbmRvYmoKMTQgMCBvYmoKPDwgL1R5cGUgL0V4dEdTdGF0 ZSAvQUFQTDpBQSB0cnVlID4+CmVuZG9iagoxNSAwIG9iago8PCAvVHlwZSAvRXh0R1N0YXRlIC9j YSAwID4+CmVuZG9iagoxNiAwIG9iago8PCAvVHlwZSAvRXh0R1N0YXRlIC9jYSAxID4+CmVuZG9i agoxNyAwIG9iago8PCAvVHlwZSAvRXh0R1N0YXRlIC9BQVBMOkFBIGZhbHNlID4+CmVuZG9iagoy MSAwIG9iago8PCAvTGVuZ3RoIDIyIDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtIFQRR iUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ39nn t9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmoSMaz 9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi48Sv bPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT0/icTAAwFJlf zOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp5ejIZvrxs1P5YjErlMNN 4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z32zs rC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC03pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivoN/uf gm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TMzAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF6FVR 6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRodV8AfYU5ULhJB8hvPQBDIwMkbj96An3rWxAx Csi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9kciWiLBmj34RswQISkAd0oAo0gS4wAixgDRyA M3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2g2pwANSBetAEToI2cAZcBFfADXALDIBHQAqG wUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQjdBq6 CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AALIVf wpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzhYlZh 1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ4hxw frgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IPIZYg JGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0mPSa9 IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpPvUR9 Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTCPYVJ RZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT6cX0 H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4qfJUi lWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4+mr1w+o9 6pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRmJbOLOaGtru2nLdE+ pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpgi0Gb waihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJjclNU9jU3lRgus+0zwxr5mgm NKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIudFt0WXyztLFMt6ywfWSlZBVhttOqw+sPaxJpr XWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtOu8/2DvYi+yb7MQc9h3iHvQ732HR2KLuEfdUR 6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX1C0YctFx4bgccpEuZC6MX3hwodRV25XjWuv6 zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrPC16Il69XkVevt5L3Yu9q76c+Oj6JPo0+E752 vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzUFgJC /EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdNRXtF l0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZcSoe Gx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnjAk9B teB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFMKHNZ ZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXuaw6t hdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsObMVs FWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle2dCu 4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/fbX/T AY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeoN5Q2 wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBailqh1tzWibak Nml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXxi4kXhzpXdD66tOTSna6w rt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem172296XCz/ZbjrY6+BX3n +l37L972un3ljv+dGwOLBvruLr57/17cPel93v3RB6kPXj/Mejj9aP1j7OOiJwpPKp6qP6391fjX Zqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+tveV 0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk03dp76anit6rvj/2gf2h+2P0x5Hp7E/4T5Wf jT93fAn88ngmbWbm3/eE8/sKZW5kc3RyZWFtCmVuZG9iagoyMiAwIG9iagoyNjEyCmVuZG9iagox MCAwIG9iagpbIC9JQ0NCYXNlZCAyMSAwIFIgXQplbmRvYmoKMjMgMCBvYmoKPDwgL0xlbmd0aCAy NCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBhVXfb9tUFD6Jb1KkFj8gWEeHisWvVVNbuRsarcYGSZOl7UoWpenYKiTkOjeJqRsH 2+m2qk97gTcG/AFA2QMPSDwhDQZie9n2wLRJU4cqqklIe+jEDyEm7QVV4bt2YidTxFz1+ss53znn O+de20Q9X2m1mhlViJarrp3PJJWTpxaUnk2K0rPUSwPUq+lOLZHLzRIuwRX3zuvhHYoIy+2R7v5O 9iO/eovc0YkiT8BuFR19GfgMUczUa7ZLFL8H+/hptwbc8xzw0zYEAqsCl32cEnjRxyc9TiE/CY7Q KusVrQi8Bjy82GYvt2FfAxjIk+FVbhu6ImaRs62SYXLP4S+Pcbcx/w8um3X07F2DWPucpbljuA+J 3iv2VL6JP9e19BzwS7Bfr7lJYX8F+I/60nwCeB9R9KmSfXTe50dfX60U3gbeBXvRcKcLTftqdTF7 HBix0fUl65jIIzjXdWcSs6QXgO9W+LTYY+iRqMhTaeBh4MFKfaqZX5pxVuaE3cuzWpnMAiOPZL+n zeSAB4A/tK28qAXN0jo3M6IW8ktXa26uqUHarppZUQv9Mpk7Xo/IKW27lcKUH8sOunahGcsWSsbR 6SZ/rWZ6ZxHa2AW7nhfakJ/d0ux0Bhh52D+8Oi/mBhzbXdRSYrajwEfoREQjThYtYtWpSjukUJ4y lMS9RjY8JTLIhIXDy2ExIk/SEmzdeTmP48eEjLIXvS2iUaU7x69wv8mxWD9T2QH8H2Kz7DAbZxOk sDfYm+wIS8E6wQ4FCnJtOhUq030o9fO8T3VUFjpOUPL8QH0oiFHO2e8a+s2P/oaasEsr9CNP0DE0 W+0TIAcTaHU30j6na2s/7A48yga7+M7tvmtrdPxx843di23HNrBuxrbC+NivsS38bVICO2B6ipah yvB2wgl4Ix09XAHTJQ3rb+BZ0NpS2rGjper5gdAjJsE/yD7M0rnh0Kr+ov6pbqhfqBfU3ztqhBk7 piR9Kn0r/Sh9J30v/UyKdFm6Iv0kXZW+kS4FObvvvZ8l2HuvX2ET3YpdaNVrnzUnU07Ke+QX5ZT8 vPyyPBuwFLlfHpOn5L3w7An2zQz9Hb0YdAqzak21ey3xBBg0DyUGnQbXxlTFhKt0Flnbn5OmUjbI xtj0I6d2XJzllop4Op6KJ0iJ74tPxMfiMwK3nrz4XvgmsKYD9f6TEzA6OuBtLEwlyDPinTpxVkX0 CnSb0M1dfgbfDqJJq3bWNsoVV9mvqq8pCXzKuDJd1UeHFc00Fc/lKDZ3uL3Ci6MkvoMijuhB3vu+ RXbdDG3uW0SH/8I761ZoW6gTfe0Q9b8a2obwTnzmM6KLB/W6veLno0jkBpFTOrDf+x3pS+LddLfR eID3Vc8nRDsfNxr/rjcaO18i/xbRZfM/WQBxeAplbmRzdHJlYW0KZW5kb2JqCjI0IDAgb2JqCjEw NDcKZW5kb2JqCjcgMCBvYmoKWyAvSUNDQmFzZWQgMjMgMCBSIF0KZW5kb2JqCjE4IDAgb2JqCjw8 IC9MZW5ndGggMjUgMCBSIC9GdW5jdGlvblR5cGUgMCAvQml0c1BlclNhbXBsZSA4IC9TaXplIFsg MTM2NSBdIC9Eb21haW4KWyAwIDEgXSAvUmFuZ2UgWyAwIDEgMCAxIDAgMSBdIC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+CnN0cmVhbQp4AZXCBzsbYQAA4J9WlNqUomatUhQ1a5UKWZIQETLtvffefoCZ 2HvHJvZuc71rcrnv7j7v8yrHXpWgirFX9OirAv2iGAWXj76QHnmR48tGXrDPshGq0pFn6TBsyfAz 8kkybHDoSQJaMPQEdfCpYPAx/y3Fg4/6A49iwAfxADpv4IFq/0MeVtT/QPle1K+f23+v2wdV2HcP eifsBczpvYPdc5eNe5vdQ1rQc2u8+1ZAkt99i7zhd5PvuuEjeV038LO6rtGd11l0uZ3XpDuuuegr bocuBzq744rdTvGS3a7Par8EbLtkgTLbLklqmW0GW7XMVm3mW2a0avVbtBktFxQZLRdUmy8Y2PTm C+x5ejPN383nuk1Q05rOwBvP0ghTG8/gnqY2nP56y5SGU9z60xTck5R6dHL9Cf26k2RkUt0JyeOk OuOJdcfo2uNEugm1x/hHCbXYmqME/J81R5Dja47iq/8/jK+mGld9CFh1GAcaW3UYW3VAv/IgtvIg BrYmplITbbhCE005qkJDtVwTVb7/74/yffiR5fu6ZcB7kWW4EWV74KV7EYThpXuEu+GlhCW74SW7 398yrGQXuxNWTDW0eIdm0U4oNqRoB7kdUkT/W9G2biHMreBCksqtYMIg5RbdzSAlUrH5FXqgYtO4 fDNQfyNQrh8g36Av2whA+ss2QNf9ZYB+snW0dN2Prq903eCar9SgZM3X4BfJGnwfyZpPwd+rML0L VgHzV71BvfJXoIpXvMQrnlCXPcW6Hobzlj3Iu+ctU15yF+l/Fi3BdxMt6eYSL7rlGnfNXQQXLroS uggX8RdchCRzFj5Bd85ZwM475yCz551JOmXP0xfMOyE/CubgOwrm0Pw5R6qzjvxZB4q8WQd8e94s ZbU9D23HU9tlwbbNUgNy1bZcFbENVwWVo7LhqKyNz1hzSFtxZvTZM1bkLdkzBqct2YSsaUvsB9Y0 fAvWtAVryoIJ1Zw5BZ45ZY47aZ45+R5+xqQZ/QmzDF1TYsaEKUkTxgT5cRMGMn3cBPkufRz4D08l Z/IKZW5kc3RyZWFtCmVuZG9iagoyNSAwIG9iago3ODAKZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUg L1BhZ2VzIC9NZWRpYUJveCBbMCAwIDM3OSAyODNdIC9Db3VudCAxIC9LaWRzIFsgMiAwIFIgXSA+ PgplbmRvYmoKMjYgMCBvYmoKPDwgL1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSIC9WZXJzaW9u IC8xLjQgPj4KZW5kb2JqCjEyIDAgb2JqCjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlw ZSAvQmFzZUZvbnQgL0dKUUxVQitDYWxpYnJpIC9Gb250RGVzY3JpcHRvcgoyNyAwIFIgL1RvVW5p Y29kZSAyOCAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgNTUgL1dpZHRocyBbIDUwNyAyMjYg NTA3CjUwNyA1MDcgNTA3IDMzNSA1MjcgMjUyIDUwNyA3MTUgMzA2IDUwNyA1MDcgNDIzIDUyNSA1 MjUgMzA1IDUyNSA3OTkgNDc5IDIyOQozOTEgXSA+PgplbmRvYmoKMjggMCBvYmoKPDwgL0xlbmd0 aCAyOSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBXZLLboMwEEX3fIWX6SLC mDyKhJCqVJFY9KHSfoCxhxSpGMuQBX/fO06aql1cS8czd2bAkx7qx9r1s0hfw2gamkXXOxtoGs/B kGjp1LskU8L2Zr5SvDOD9kkKc7NMMw2160ZRlokQ6Rss0xwWsXqwY0t3fPcSLIXencTq49DEm+bs /RcN5GYhk6oSljqUe9L+WQ8k0mhd1xbxfl7WcP1mvC+eBCaCI7uMZEZLk9eGgnYnSkopq/J4rBJy 9l/oamg786lDUipVIVkWAofFoSQOLaPzmvPfYdihOFlboWT2N7m4DNR210lUVpUsKXMklioHQsAt 4wa4i5gx7oGQlPsN4z0QknLXMRZACN2JUQMhlCoYWyCEaKxsgRCisRQBIeCekzsghMo5EKNFoS97 c8zLQpQb5fhHLOCOEeOzgFwZ5aOAlnELhID8RTk+jgXkIdE8Co3QF6/z85/4oXihbgtgziHg7ePW xbXg5+4d3RbTj54LRH0DtwnEuwplbmRzdHJlYW0KZW5kb2JqCjI5IDAgb2JqCjM3OAplbmRvYmoK MjcgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvR0pRTFVCK0NhbGli cmkgL0ZsYWdzIDQgL0ZvbnRCQm94IFstNTAzIC0zMDcgMTI0MCA5NjRdCi9JdGFsaWNBbmdsZSAw IC9Bc2NlbnQgOTUyIC9EZXNjZW50IC0yNjkgL0NhcEhlaWdodCA2MzIgL1N0ZW1WIDAgL1hIZWln aHQKNDY0IC9BdmdXaWR0aCA1MjEgL01heFdpZHRoIDEzMjggL0ZvbnRGaWxlMiAzMCAwIFIgPj4K ZW5kb2JqCjMwIDAgb2JqCjw8IC9MZW5ndGggMzEgMCBSIC9MZW5ndGgxIDIwNjA4IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AdV8aWBU1Rn2uXf2fZ8sk2QmmUwWJvu+QHLJRhYCCclA EggkJGFfAwFkF1yj1F2rdUHrWlQmA0pQW9FirbWoVau2WovdtCoWrSsK+Z5zzxwWu3w/vj/9hjzz POc9y9zznvcs907C+uGRIWIgO4mC5A2s7F9D5FeRFtQwsGG9j6UDSwhRJSxas3glS0+6hBBd/OIV Fy1i6aIrCPG8tWSof5ClyXfgkiUwsLRQBE5dsnL9JpYu3AtesmL1QDS/qA3pkpX9m6KfT95B2req f+UQGK+2Prz51gwPRfOFLjRnpTn/+WUmREBuvOAjVvJzoiEiOJegRdu1wi6iRC7NV905vuerF20L LJO/IHG024Q8+dHWX1N+/vIHr/r21OmrdB9rHkdShxbYC/U0d57+PSH6vd+eOrVX97HcUjRTpviI TuEbFy85qIsVmiF2c7GLi4u52MnFDi62c7GNi61cbOFiMxcXcbGJi41cbOBihIv1XKzjYi0Xa7hY zcUqLlZysYKL5Vws42IpF0u4WMzFIi6GuBjkYoCLhVz0c9HHxQIu5nPRy8U8LuZy0cNFNxddXMzh YjYXIS46uejgYhYX7Vy0cTGTixlctHIxnYsWLpq5aOKikYtpXDRwUc9FHRe1XNRwMZULiYtqLqq4 mMLFZC4quajgopyLMi5KuSjhopiLIi4KuSjgIp+LPC5yucjhIpuLLC6CXEziIpOLDC7SuUjjIsBF Khd+LlK4SObCx4WXiyQuErlI4MLDRTwXcVzEchHDhZsLFxdOLhxc2LmwcWHlwsKFmQsTF0YuDFzo udBxoeVCw4WaCxUXSi4UXIhcCFyQqBAmuDjDxWkuvuPiWy5OcfENF19z8RUXX3LxBRefc/FPLj7j 4lMuTnLxDy4+4eIEFx9z8REXH3Lxdy4+4OJ9Lv7GxV+5+AsXf+biT1y8x8VxLv7Ixbtc/IGLd7h4 m4vfc/E7Lt7i4k0u3uDit1y8zsVrXLzKxW+4eIWLl7l4iYtjXPyaixe5+BUXL3DxSy6e5+IXXDzH xVEufs7Fs1w8w8URLp7m4mdc/JSLp7h4kosnuDjMxTgXh7h4nIvHuDjIxQEuIlyMcRHmYj8Xj3Lx CBcPc7GPi59w8RAXD3LxABf3c3EfF/dy8WMu7uHibi72cnEXF3dycQcXt3PxIy5u4+JWLn7IxS1c 3MzFTVzcyMUNXFzPxXVcXMvFNVz8gIs9XFzNxVVcjHJxJRdXcHE5F5dxcSkXl3Cxm4tdXFzMxU4u dnCxnYttXGzlYgsXm7m4iItNXGzkYgMXI1ys52IdF8NcrOViDReruVjFxUouVnCxnItlXCzlYgkX i7lYxMUQF4NcDHCxkIt+Lvq4WMDFfC56uZjHxVwuerjo5qKLizlczOYixEUnFx1czOKijYuZXMzg YjoXLVw0c9HERSMX07ho4KKeizouag/Q0zJOzZGkKi/OzJEkF2gXS10cSapAaidL7WC0PZJkhHEb S21ltIXRZkYXRRKnosimSGItaCOjDYxGWN56llrHaJgZ10YSa1BhDaPVjFaxIisZrWC0PJJQj5LL GC1ltITRYkaLIgl1KDLEUoOMBhgtZNTPqI/RAkbzWb1elprHaC6jHkbdjLoYzWE0m1GIUSejDkaz GLUzamM0k9EMRq2MpjNqYdQc8TShD02MGiOeZqSmMWqIeFqQqo94poPqGNUyqmF5U1k9iVE1q1fF aAqjyaxkJaMKVr2cURmjUkYljIpZY0WMClkrBYzyGeWxxnIZ5bB62YyyGAUZTWKUySiDUTprOo1R gLWZysjPKIU1nczIx+p5GSUxSmSUwMjDKD4SPwPOimMUG4mfiVQMIzczuhg5mdHByM7IxvKsjCzM aGZkYmRkeQZGekY6lqdlpGGkjsS14dNVkbh2kJKRghlFlhIYEZmECUZn5CLCaZb6jtG3jE6xvG9Y 6mtGXzH6ktEXkdhO77jweSS2A/RPlvqM0aeMTrK8f7DUJ4xOMPqY5X3E6ENm/DujDxi9z+hvrMhf WeovLPVnlvoTo/cYHWd5f2T0LjP+gdE7jN5m9HtW5Hcs9RajNyMxc9CVNyIxs0G/ZfQ6M77G6FVG v2H0CivyMqOXmPEYo18zepHRr1iRFxj9khmfZ/QLRs8xOsro56zksyz1DKMjjJ5meT9j9FNmfIrR k4yeYHSY0TgreYilHmf0GKODjA5E3NXodCTingsaYxRmtJ/Ro4weYfQwo32MfhJxY9UXHmKtPMjo AZZ3P6P7GN3L6MeM7mF0N6O9jO5ijd3JWrmD0e0s70eMbmN0K6Mfsgq3sNTNjG5idCPLu4G1cj2j 61jetYyuYfQDRnsYXc1KXsVSo4yuZHQFo8sZXRZx9aPvl0ZcC0GXMNodcS1CahejiyOuEFI7Iy5s NsKOiKsEtJ3RNlZ9K6u3hdHmiGsQRS5i1Tcx2shoA6MRRusZrWNND7PqaxmtibgG0Mpq1tgqVnIl oxWMljNaxmgpq7eE0WJ2ZYtY9SFGg6zkAKOFjPoZ9TFawGg+63Qvu7J5jOayTvewprvZB3UxmsMu dzb7oBBrpZNRB6NZjNojTgkda4s4qVtnRpx0ws6IOHeDWiPObNB0VqSFUXPEiYOE0MRSjYymMWND xLkdefUR5+WguohzB6g24twJqonYG0BTGUmMqhlVRew4FwhTWGpyxNaNVCWjioiNzqNyRmUR2zSk SiO2LlBJxNYDKmZ5RYwKI7YsGAtYyfyIjXYsL2KjC1IuoxxWPZt9QhajIGtsEqNM1lgGo3RGaYwC ERv1UiojP2szhbWZzBrzsVa8jJJYvURGCYw8jOIZxUWsvWgzNmKdD4qJWBeA3IxcjJyMHIzsrIKN VbAyo4WRmZGJkZGVNLCSembUMdIy0jBSs5IqVlLJjApGIiOBEZEmLAu9FGcsA97TlkHvd9DfAqeA b2D7GravgC+BL4DPYf8n8BnyPkX6JPAP4BPgBOwfAx8h70Ok/w58ALwP/M282PtX8xLvX4A/A38C 3oPtOPiPwLvAH5B+B/w28Hvgd8BbpuXeN0353jfAvzWt8L5uSvO+BrwK/RtT0PsK8DLwEvKPwfZr 00rvi9C/gn4B+pemZd7nTUu9vzAt8T5nWuw9iro/R3vPAs8A0sQRvD8N/Az4qXGt9ynjsPdJ4zrv E8b13sPAOHAI9seBx5B3EHkHYIsAY0AY2G+4yPuoYbP3EcNW78OGbd59hu3enwAPAQ8CDwD3A/cZ sr33gn8M3IM6d4P3GpZ774K+E/oO4HboH6Gt29DWrWjrh7DdAtwM3ATcCNwAXI9616G9a/UzvNfo Z3p/oF/s3aO/z3u1/gHvpYqA9xJFmXe3UObdFdoZunjfztCO0LbQ9n3bQoZtgmGbZ1vLti3b9m17 e5tkV+u3hjaHtuzbHLootDG0ad/G0BPiZWSReKk0ObRh30hIOeIcWT+i+HxE2Dci1I0IeSOCSEas I74RhXF9aDi0bt9wiAy3De8cDg8rK8PDx4dFMizoxyeOHBj2JDWApa3DJmvD2tDq0Jp9q0OrFq0M LcMFLi1bHFqyb3FoUdlgaGjfYGigbGGov6wvtKCsNzR/X29oXllPaO6+nlB3WVdoDsrPLusMhfZ1 hjrK2kOz9rWHZpbNCM2AvbWsJTR9X0uouawx1LSvMTStrCFUj86TBGuCL0FhpRcwIwFXQjxCTZ5H 8hz3nPQoiSfsOeJR2C3x3ngx0xIn1M6ME1bH7Yi7Jk5hiX05VpRiM7MaLDEvx/wx5h8xSocUk5nT QNxWt8+tcNG+uVs7ad8OuKvrGOcXy31tdfvTGiwuweLyusR6r0sgtuO2kzaF62nry1bRYhEslgmL KFlQ3GL2mkX6NmFWSOb80gaLyWsS6duESeGWTLDQi083tnU2WAxegxiqNsw0iJKhurZBMmTnNRCF 4BPwzY8VpNDSqxFc3oZxgRxwCyphXLh2rLMjGGwZ15JZLWFt29ywcEU40EHfpfaesPqKMAn1zO0a E4QfdI8JYm1n2NnS3sPSl+7ZQ2oSW8KJHV3hvYndLeGdEBIVExAkccxNarqD89eNrAsG18/H2/x1 64PyD1LCCE3hhQz8rFuPNP0HQprQnP/8YsVQbsE6vORmWOv/ucr/BznC/wfX+D9+iWMEIdo1dUK8 hAyKu4FdwMXATmAHsB3YBmwFtgCbgYuATcBGYAMwAqwH1gFrgTXAamAVsBJYASwHlgFLgSXAYmAR MAQMAgPAQqAf6AMWAPOBXmAeMBfoAbqBLmAOMBsIAZ1ABzALaAfagJnADKAVmA60AM1AE9AITAMa gHqgDqgFaoCpgARUA1XAFGAyUAlUAOVAGVAKlADFQBFQCBQA+UAekAvkANlAFhAEJgGZQAaQDqQB ASAV8AMpQDLgA7xAEpAIJAAeIB6IA2KBGMANuAAn4ADsgA2wAhbADJgAI2AA9IAO0AIaQA2oAOXU CbwrABEQAEIGBdiEM8Bp4DvgW+AU8A3wNfAV8CXwBfA58E/gM+BT4CTwD+AT4ATwMfAR8CHwd+AD 4H3gb8Bfgb8Afwb+BLwHHAf+CLwL/AF4B3gb+D3wO+At4E3gDeC3wOvAa8CrwG+AV4CXgZeAY8Cv gReBXwEvAL8Engd+ATwHHAV+DjwLPAMcAZ4Gfgb8FHgKeBJ4AjgMjAOHgMeBx4CDwAEgAowBYWA/ 8CjwCPAwsA/4CfAQ8CDwAHA/cB9wL/Bj4B7gbmAvcBdwJ3AHcDvwI+A24Fbgh8AtwM3ATcCNwA3A 9cB1wLXANcAPgD3A1cBVwChwJXAFcDlwGXApGZy6U7gEajewC7gY2AnsALYD24CtwBZgM3ARsAnY CGwARoD1wDpgGFgLrAFWA6uAlcAKYDmwDFgKLAEWA4uAIWAQGAAWAv1AH7AAmA/0AvOAuUAP0A10 AXOA2UAI6AQ6gFlAGzATmAFMB1qAZqAJaASmAQ1APVAH1JLB//Fl+n/98rr/1y/wf/z6YhfMp78x RMiZG87/JSHSRpaRdWQn/l1G9pAbyNPkbbKQ7Ia6lewl95OHSJg8Q14gb15Q6/8xceYi1UpiVBwi auIgZOLUxIkz9wPjKvN5lhuQcih95ywT1olPvmf75MwNE9Yz42o70ct1TeKraO2fwumJU9hf1cQ0 UULT4uXQFvmTPtXceWb/mQcu6EAbaSc9ZC6ZR3pJH+lH/wfJErIUnllOVpCVZJWcWoW8xdCLkFqA UlhLZH2u1Gqyhqwmw2Q9GSEb8G8N9LpoiuatldMjZCP+bSIXkc1kC9lKtkXfN8qWrcjZLFs3IWc7 2YGRuZjskhVnZtlNLiGXYtQuJ1eQKzFi/zl15dlSo+QqcjXG+QfkGvKf9J4Lcq4l15LryPWIhxvJ TeRm8kPExY/I7d+z3iLbbyN3krsQM7TGTbDcJaubyS3kKfIL8hh5lOwnj8u+HIBvmUe4XxbJnl4D H2xFn3efd8XMmxvPems7vEH7PRrt9yb4b9d5NTZE/Ui9txslqXdGo+NAW9kWtXBPXIueMX2un9RH tA/XXNBPXuP/ZqU9pn66Hf7inqE+uxm22/7Fen6J8/XN5A7MwLvxTr1K1T3QTN0l6/Ptd54tu1fO +zG5l9yHsXiAUMWZWe6H7QHyIOb2T8g+8jD+ndPnK5b7KHlEHrkwGSMRcoAcxEg+Tg6Rcdn+3/L2 Y+34fp0D0bYiZ1s5TJ4gTyJCfkaOYKV5Fv+45aewPR21HpVLsfSz+F3Ko3IpmvssYut5rFC/Ii+S X5OXyXNIvSS//xKpV8ir5DXypmCC+g35O95Pk1dUfyFmMhW/ePkERuN2Mp/Ml6YNLpjfO29uT3dX qLNjVnvbzBmt01uamxqnNdTX1dZMlaqrpkyurCgvKy0pzs3JzspIC6T6U7yxTpvVYjLodVqNWqVU 4GSbVe9v6POF0/rCyjR/Y2M2Tfv7Yeg/z9AX9sHUcGGZsI/W60fWBSUllFz0vZISKymdLSlYfZPJ 5OwsX73fFz5W5/eNCz3tXdB76vzdvvAJWbfKWpkmJ0xIJCejhq8+dkmdLyz0+erDDRuWjNb31WVn CWMGfa2/dkifnUXG9AZIA1Q4w79mTMioEmQhZtRXjIlEa6IfG1YE6vsHw23tXfV1nuTkbtlGauW2 wurasEZuy7c0jGsmV/nGso6MXj1uJQv7gsZB/2D/vK6woh+VRhX1o6OXh23BcKa/Lpy5+S+xcOBQ OMtfVx8O+nFhLbPOfoAQVgWsft/oFwQX7z/xMa76PEt/1KIOWL8gNJN28aybwkI/1wTXhitE/5KT 6bVcNS6RhUiEd7Z3sbSPLPREiJQb7A6LfTTnCM9xhWjOTp5ztnqfH56t99f3RX82LIkN71zoy87C yMo/gbAygHxfWJHWt3BgCeX+oVF/HXoIX5JOPLSpg5D6o86sH8vLRfn+PnRiKXVDe1c4178m7PTX MG/DgEYC9Us7uuQqzFofdtaGSd9AtFY4tx51ESL1o3Rg6AXStvztXYdJ4cTxsSKf50AhKSLd9DrC 7loMSlr9aNfgorC3zzOI+Fzk6/Ikh6VuuK/b3zXUTUfJbw1nHsfH4YUBlGuhb98rzQuj22FNQOvr Ej2KbjpaMPga8OavmYwMa1jNknREayb7ugQP4cXwKdESVF3QDhKKQG0jKoNRtbbRk4zgll//5ZI8 rAO4jLD27DUpcRGqc9fEPuc/XhorTS8o01c/VHfeBV7QKBLyBUZb+/fXKVJfRJ2BS9DS4WykfcjO EqF9yNaGRfRTNtFRjPWFSZuvyz/k7/YjhqS2Ljo41Nfy+LZ0+OmDQXm0o1HSeUGK5ZexvDBJbuns 4gn6zCbcEJTHlQ6rnJ4mp88mG7+X3cSzfaNaf0vHKP1wf7RB4sMMwuCo05r6ryqzF2GyNmCh9Df0 +31WX8No//jEzoWjY5I0uqa+b0kFpsGov2lw1N/RNRljKc/7bZ7N9KPtpEVo6azJzsLaUzPmF65o H5OEKzp6ug7jl/F9V3R2RUQ8FO2r6R5LRV7XYR8hkmwVqZUaaREfTdCWZiGhlct7DkuE7JRzlbJB Tg/guaxsY4VgE8jAuMhsVl5OhE3JbJJs68YLMyx2CYYA63C9b5AOz9buJaN93XRyETeGEj9CWPBX kbDor8KjXLUxrPcP1YQN/hpqr6b2amZXU7vGXxMW3AKcM441abTPj3UKIdeFR+TdiA4rjX4x4Buf mOjsSj7mOdGdjCkxD+jpCuuC2AdUgWaUm0bRB/O08M6BfnodJISpTmdm00A35gJvEEWawjq0oIu2 gBINch0ajqg0gLHBAMr1dyIR3tkd7g7SD+1aSq/I57OGSaO/AsPO2lSl0Q/K7R61+wtoYKNoWB+4 nJIO10bwkFq2eJDEh2HBpT3SGHHlA35kDfT5MAJKMtCBUGdrqZ6OGyxDWBKVaUMy9J5oJqHdUgQM Jn1Yl4MG8UO1IQcN4kfTDafQzsupy6MF8NnWsAFXlHaeK6MV4B1kNdFrwc/luHha9BnaTPs4meXf hKWRXrT8URpkh02Bpn4s/qy+ARZ/Ga+MtrQBaqJtHGVWDe25EX5XBDrHJx7wX0RXAP7KzvLTzYEG JvEcRmCT7tHvG8Jzg9lZ2u9bTbJ5dFRr+vcVmL+0prNMW/HVY68hREn/jOVlQhS/JfMUC0mPsoj0 iWtJAM/GLlUPkluRvlVZRnoUyaRdfJQkI30jnvrdgqe19ajbCDwKDAOLgTxgCBgAZol3kDJxbKJF NU4a0Sn29zCEGHG/VoZ0MonBfZtAnPi7GRux46+EdMRE3CQO5zcHceEvhoxES1QYf/q3NWqiRx36 upvcLbQJ74jrxC8Vq5VtyvdUq9XF6jHNVM2A5jJtufak7lr9JYYmwxnjHabZprtNb5s+Ri0V7o7X KV7FnaQC7ZWTVjKDzH2KmPDIx00qhMcec9XVabM1P8PjHJH48EBISwShVrIoRdOh+Phq/6Fi9R6F rWlcyD5YrdmDR53Vp989/VLu6XdP2MtzTwi5f3jv3fesn75kK88tfO/19/LzBFuyTYbTLGo0TrU/ JUcsTk8rKSwsqBKLi9L8KWZRthWVlFYpCguSRAVKMkuVSNOC4tXvehQzT6vF7f7q2YWqpHiL06RW iQmx9uzJAWvH3MDknESNQqNWqLSajNKalJYV9Sm/19gSXe5Eu1ZrT3S7Em2a02+rzKc+U5m/rVWu +PZGhbpyXnWq4od6rahUq8eTYuMmVSY3zbY4rEqDw2pzazV2mzGjbt7py1wJtI0El4u1dboVbpk3 cUJRrfgVKURwhiWfpcZbk1ujMOhiioxGobXIasJbrIEqi1WYXjQufCWZSXo6BtlIrBahlVSMT5w8 gKLgDw6gtMyoQPkgrVMxLmolpy3mOVJkLRIrjxQJpEgoKsqZOmlc8EiWV1KElBRl4oc5zVPeMbYq SW71iWrq/94TNvq+dn4vRuI9+rTmaHB+b3muVdYF5fl583sDTjUGIS2tuJgyBqMIbi4sLsqB0886 Xkkd79JQi8vpLiwoKVVUWxM88V5z5XXt09a1Z1etf3DpVnf+jPIp/U35Rq1Rp9R4amYvKuq/ojPt 3j11gzXe7rapq6fEGo1qtdHYU90QaFg0dfqa5kBDUVuxJ9GfqLXGWeIS4/2JjqzQ9s6jMdnVmQ0d NXWYBz3wrk/xAikmV44lEPrVoRUuG584Tj0F/uAgPEXSqeuQAT55AD4Ff0JdKttRAPwhrZA+Lhok U65ZMMe975X0pkZv6rggHnQ0Kz7KR9sHdabG/KxxQT2ma0Uovx48Ib8Jub2yy+C/YLAgPy/gNJ9z VkGS2sUC2Z8ClYQoZZGq8IkqTdzklq7c/puHiqeuvbU72F5XHKtTi3aTJX1yqGLjjmSpd3L57Oqg UaPXKO6xxdlMcYFEu7TlwMilT2+utManxJodsfZ0b3JG8qFH5+zuCqYG/VpHIkHU9cEvt+OZUhpm 7VWSt7pSMHjKaayV69HvciucUU6jq5yGXvmT+IaBkFzmtdyos8Cys2RGJdmO0rnjol7SO5IbDOXp HqUZQaaKxDYjcJUHzK2q6aRajq+Y8upoVAVfZ96hEYWAiobN+QFV4I6x0cCiYaRIk2c591Sp4naN LcFJJ9a0W+cOXD0no2DhdQtm7pY0Tm9snM+uu792W111V2mcq2j21OQpUkN6nNaoUSo1Ru3G1tmt u8cWrn/ykmn1taJBY9KoVHg7Xd8xZ/LCrVLdrqEp9km1+XSNDeDp2GWqTWQyGYy4rTR85LDxUA/A Z5TlmQbxJY0b8AcH4ArPuPBNJG9SYHziFclutQnTA/oTJdPi007kNfqmWxvhiuoTBdWYXsGjhZ+y GVZ4FMtc1AnyjHHJ3UaI+G3cNzZMOT7TZLcoxcuUKq1a40rK9ASKfOYXtAadym55Qevwxcb6HNod VqtSa9Tu8DeubPbXpBq1CpXFEWNW6Qy62ML2ioUaW7wj1ffdR1qDVqnEm8LlS3XE2zS98y+fnWmy GB0eGjOXTpwS2lW52EWSydWHqv0z/av9CjftKnwAlrsupx1y+jidUkjLUSLb4RL3k9gJE4iLeQ6/ YiDXAssOAzNPusaFrx/XeyWEIH61qOpgnLVJDp03TgSjYRONmuD5QXM2Shx0SsFHJYUFbqFKa/fF wQ0aDdyBmNA6siorghRxZzt8CQICXTdqhLyKSZnlAB33WydOqV7B2txGPpQ8disu30HnQ5rVYBSm p8fS9zWzhAZHtBdguRfgk7TvMqMHYHn5cKBTUlKSG+5KSirQ05mmp3NOTxvVy+u7HhFzqE2yCa1t VVh1ZOectwrJzSLNVyk5/NKfxJd/BcQqqCMtzViQ1JJpanNVQ3ZZU/b0uOmy26qr7eXldN7xOVf+ elCeddhamQjS2Sf/ysLZKWiTl3G15lzc/ashOitdJfB0khjDNl2X6hW4HK52aJ1ZdTnl6+ppIMYk OzTurNqc8vV1fEDU9oQYd6JVM/2aprLuujxrdnvLtNQ5G5q8ZwdG9JfPr0vtCp2+ig/Vv1oUlyDc FQqdQbsxNDM+d2pGft0kx5RFV05nI6jYixEsIDdKFjaCdBiri4RJ/2aUZHfCLrsdHB1NjJonyUDX RAMdLgNdGA109Ax04AwY1UNEQpIkWan39dnNk+JSm7jr7XC8kMvdzHZP7u3/5usLXetS7GU+tWtj c5ryqrb+qxNvae3ZMj35nOssrd9z3QWOgoP66KymO+S78JCDpJMHpYTqTCHDLmTahDSTkGYU0rRC mkaYpBAyRSGJOgROAMvxB5a3UbC8W8r5cEgS3QCScvWC3hmL4k7qLqcPjnPa4SQn9ZnzCXzzTSaO HLKQ1jUYprhxQYhYmv3YTcdU2DvlSO2NRibfPhGg/MVXSHkVROBpoicOvi0o3q1Y98jw6vtWlZSv e3gduPRRT9WymU1L65I91ctmNi6r8wl/XXX4spaa7QeHwc3grU27FpYXLdjV2ryrv7xo/i5cVvvE CfEl+KaJvCQZc1uqW2a27GjZ36KaSj2ADoHlUJHT6CX4yAEsfnIaXZcZ3Z06LrwjeVMLUguMHhpB Hho8HhpQHhqNHuohzxP46h4ukfRIEKMEuxHNSWlor9q43ygac/5Qqv/I1mbrs62xKUptpTb35Len elSZze4PmM8wx0/Yystzc3utJ6yIud5gMDrNg8jKZYe4IF0xo/5Tcv+x83OOOprGQYRtw+zMlqQW Xyqcv2tG3pz6PLdeqTZoDMHq2WWT6go86VJbqF1Kz5y1ZVZqY0WmS6NQKDR6tS6lpCl3kpTpypBm hTqkdMFcv6I5zRIT50z1OuKtGo/PY/eXBNKKMrwpwarZk4v7m7KMdpfVaHFbbXFWjTvO7fDnJaQX Z/hSJk3upGtx8sQ/xJXKR0gFmXcwk9j82dEolBk+BctjAZajVGY4MZsuusYYU/YJf2Oi6URMYz5O ImMaFmTH6NQsjJ4/jh1lhzOlfJL9l01WdJ2/FeMcyyaouFJr9WXmxDQMSonbLXaV1qTdxjea9+lZ 1m55v3RaTGqCU6vSqZRzE1OsZp060LJuhmhmu+wbGpRS6oyaN9g+fEbfu0Cn16nMsbTfN9KTmuIp rGDX45xWJBjSaQSl0whK16J/6fK+kU7jKB2bx+OEbh7EG41QsOwV8NfyEYUKejShBbjhJDMI30g6 R3ZTukEV14RtRHXuuEY3D75znA2pf3tcO7sD2+SjbEnpWQMOavZEV0yiTd16s7xQaZzscBKT25hX taUeBzZs0nbd2fVrY2jG5MVXLhRT+Op++vOZC2oDXSFxhFuof26Z+Aq/0XAcd7oxY0SNGfM4PKPW KXDQPIaD1TP0vH3eYWBVbtXkHIqV03Jz6gHaRr1wUMwRp+DO2XyQaAwncBOEuDhGT2JqfzI7SCRj mRFz7LYz8+14CfdoTTqV8E16kjctLUlti8dK2oiRel6VjJU0iPNC3PeW0QBfRhGYR6SARWztyxbO WyDpqcBJR9Xpw/A4Y6l6UsTTBOJjAe2LBjxYPk2A5aEFf0D7nOoT8J9WZEs6vY/k4WZSgd9NPSnp sJrk6mfqRUIPoTSFgwZ+BYtehJ4KPcF3Fjio6iOWjgBoTDVbXn9tdoGuGTiV9gZ7re9hLcErunvR JST4X9ZizCB6r5dEb2aUiudzV4Yv3vzAomDeivDOLeCw2ROc3JoXWjbFnTR1qLEsNCUjVieO3vTl WP+ch77ae+NXMj/cf9uGUGlc29VPrbjuxZ0VqbXzhy/FWD2K5yp3qWJIDvmrlJqaJKQmCqkJgt8j pMYLqXFCWqyQFiNkyluY3YcVNo/21ETdnScQ6lqSGV0hwPI+JjO8D5YdCpanSOa4aJPMSbG0UqyB vhtsdMuDD8GvH0CbYPmO8jz7EXoDgDRcjxp78bzCYR8Xqg/4Z2XidKAZU3fCvQXVpxGczKfBY7gx ZMf/4HOyZ0lQ4M7tZXdEyfzeOtmmUatxv43bodJA9LRlo0cvxV1qPW5e5mmMBrVaZ9IK5lP0hK9Q G3TCJKXRHmvH5FJ/qDXrVHV0BdZY4x32eJtO8dZNeqUpKcYWazWqn1YolYJSY1B/e40OIQ1vD8Pb tyOmq3B+MmWWCMEkITNRSEsSJOrWGOpWSXDTbd5tNZqE6W7qJjfC8PHCAP6R8qivy5/Ary4a4Cw4 xwAnSgZ40WArK/f5yhF8OY8XutU5HdbycSGDe4jtZrkgTGMcBY7RcJQDkEYf6aU+ks9P3DmljirF 9x49qNnNE31aROcvuqKz6E4Xm10WjUJvMX47Z2m5PaG4rUh+8KAxaJSiShtb2b28cv6e3hz3tMtW HxMLtRaDqtme4NBprEluZ1JMjEnQz7t+08JgsLUiJSUjRWtPcmHbMrtS/bHF8zbXV225Zv/wGzo7 7pkEshhrwvXwX5egOoyj1hEpgbqsR8jXwmX5dN/Pl/2WT/2WPy4WS/oZHWkzZsRi14eLP5DSUCTN hzcJ1jRJYfbQmuzEINf00Jq44ZRD1gPPP0botoAJjqc/mN/maMiC5WgHH5EcGAZzJb27qpTosOVW CnIow0BZ0lNjpa3S5i4ZFwySvqkj658+n6qpw41kdIWgj+jKrezAQRcJ3JhhhXidDhV92WMwXNSC p0hs2aDDFj144KAh3zBEzx2i/9zDI/lJXs75z4/ODaIrSaG4vmr9T5ZPXdtVYdGqFWaTrrhjdV3N YF1KsOOi1i0YK43aYNatrVnalB5f1F5c0T+9QI+BVYhqraMitFrquWJutq+qp7J2dVu2MNx9zaJS V6LXbHYmulITfAFfSlWooLRLSsH0cDniLJoUqbs0o6nE68/wqywetyXGZnZgnHM6R6ZNWdpebhA1 xW3LsfbnTZxSvKZykklYl76VKgI5Qlq2kJ4lpKYLqWlCIEFI8wh+eYEKxAqBGCHNLaS5hDSnkGYV MMSpKiFVKQQ9grxa2WmM5AnZ7lgIN13EcPcsrzuUD2Hs3Ak5OfiN/++kRJSw0ulnpbFkpUcDK91E rPQ8YH1StOFUr2RrlRIbAJ1+4OOSHtlKZV5uuidHHmBlMNlq1SfP0ofwUAIjay8vPFFQQPcAOoTR E1KwwFZ4jI4tzkl8Bp5bqGRFN8zzHlScnZrCubXKLfiFZMVrTvv1Wie7Lz/9odFqUolqvUZ4VeVI ykpKzk+yXm9znblbPDNXeEBYk5x25iS//xOsamtSrCMpLsaksOOhBh7UmnTf/cIv/v10BZ1xQ5hx N+OJdBV5RjKllwrpJfJNjEJesR6nnpWE0uiqBD550IBQL30CnspA4GfAlRl0XmSYZxasLthRoChI pO5NpO5NlCdcIp1wiU+IhTitf0A3AbqXPoZsIuGWEbc0eOTqcMRi4mRJxqyKz330+aoqqz32gqnT ixM6vfkWrG9EZ8zR3tfZ5GHOpevbudnCzppnp0uKfKKxYRLRZY0+QEy2sVtwxc0NO8dWTF7RWWLB Y22F1qDRT5q2tLF2TXtOevvW2VO60hJivYniFK1Fr3LazyT6m/JW37+6XNi75J7VFba4WLPRFm+3 eWxaPE/11S1urlpQ7TXGB0RLsk+HRTA148xNKrG4fxSeHkDM74enveTNw8SGtUpvSxam2+htDRYR uIbtg/RGSU4j9sBfy7G3HjeYNgEhHK1lpbVoktYCy7dXcraBPmUZwSzB8w1qh/OT4WZ5JJMF6nt6 Twp+S34mJ//RCj7pvCdKcptIH38Mg+VS2fB1w4H4dgON9BMF8qKFLVjeeHGmoeHNSV6tNIJZQR9x l5QK8kkQIyFvJfsVKp36TI7KEpMan5JmE9XCh6dvcDhUerNO/MzsMqiVR+2Jnjjzty8ZLTqF2uQw KZszUh3YR/DUAyvGLMTp/dgZ8kgN+ankyMwRJqmETKWQqRAmpQlpeqEOXcP3AQjYOmwXcCLbKRI3 5wvl+U35S/MVwXwBW0aWpCNmsw+/LkfPeFgm5Ig8fpBGZCXdF1AVfFKy00V9pFIoqWyoXFSpSK0U KsfFoGTODQgB6TOfT1Py+aQORKl2TMOOgHSFpw+vMbPpw/+g/PAfiQLmLYIApZMeUUpvmS64mSw9 7/uAgiTlhffnJYr7nXntWx5aE2yfmuWEcwxaQ8aUWYX9V3VlicU39q24oTu9YNm9w+3b5knptv0p NX3VU+dVJsSV9dS0XC0+0fnwXVctqTRY7XZvvDverLLYLS3b75/nzatcdHXH7B9taMhsXTl6d8PO /SvycmcOFlcurAvgGC2SsolPxSHxZvlJR4pkd5IkvTVOiNtv2eH1C/79ql04mK3Fj5D7zOu4bYhO PvadBmbZhX2oEsWhlIbljU1LarzJdcubZi6X4q+2JpcE/EXJVoe/OCWj0GsSprVu7y7ImbOtrWlr T1HJ3M1NZXMqEhPKOsrq5ha7kio7iDDRMvGOYpWqGE9VMw8TB75EkNcPjD0NZwf9a6fHEN9aq4rk 5iJYsRzn52nOhiRdVt1utSZFZXYmON0eg0KruERldnlcLo9RodXqdBqF1uQwqnRag1qhMTsNZGIC dyrvqNbgM9PxbaEVv+sJVhhwp6EhsfitcvoS8N0h/Z/2CL4jxLeZ05rbp4dqgrX9K5YuHF76fwCa FgSKCmVuZHN0cmVhbQplbmRvYmoKMzEgMCBvYmoKMTA5MjQKZW5kb2JqCjMyIDAgb2JqCihNYWMg T1MgWCAxMC44LjMgUXVhcnR6IFBERkNvbnRleHQpCmVuZG9iagozMyAwIG9iagooRDoyMDEzMDQx NjAxMTQwOVowMCcwMCcpCmVuZG9iagoxIDAgb2JqCjw8IC9Qcm9kdWNlciAzMiAwIFIgL0NyZWF0 aW9uRGF0ZSAzMyAwIFIgL01vZERhdGUgMzMgMCBSID4+CmVuZG9iagp4cmVmCjAgMzQKMDAwMDAw MDAwMCA2NTUzNSBmIAowMDAwMDM5Njk1IDAwMDAwIG4gCjAwMDAwMDEyNDYgMDAwMDAgbiAKMDAw MDAyNzQ1NyAwMDAwMCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDEyMjYgMDAwMDAgbiAK MDAwMDAwMTM1MCAwMDAwMCBuIAowMDAwMDI2NDU4IDAwMDAwIG4gCjAwMDAwMDE3NDYgMDAwMDAg biAKMDAwMDAyMDAyMyAwMDAwMCBuIAowMDAwMDI1MjUwIDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAw MDAgbiAKMDAwMDAyNzYwNCAwMDAwMCBuIAowMDAwMDAxNjA0IDAwMDAwIG4gCjAwMDAwMjIzMTcg MDAwMDAgbiAKMDAwMDAyMjM3MCAwMDAwMCBuIAowMDAwMDIyNDE1IDAwMDAwIG4gCjAwMDAwMjI0 NjAgMDAwMDAgbiAKMDAwMDAyNjQ5NCAwMDAwMCBuIAowMDAwMDIwMDQ0IDAwMDAwIG4gCjAwMDAw MjIyOTYgMDAwMDAgbiAKMDAwMDAyMjUxNCAwMDAwMCBuIAowMDAwMDI1MjI5IDAwMDAwIG4gCjAw MDAwMjUyODcgMDAwMDAgbiAKMDAwMDAyNjQzNyAwMDAwMCBuIAowMDAwMDI3NDM3IDAwMDAwIG4g CjAwMDAwMjc1NDAgMDAwMDAgbiAKMDAwMDAyODMyOSAwMDAwMCBuIAowMDAwMDI3ODU1IDAwMDAw IG4gCjAwMDAwMjgzMDkgMDAwMDAgbiAKMDAwMDAyODU2NCAwMDAwMCBuIAowMDAwMDM5NTc5IDAw MDAwIG4gCjAwMDAwMzk2MDEgMDAwMDAgbiAKMDAwMDAzOTY1MyAwMDAwMCBuIAp0cmFpbGVyCjw8 IC9TaXplIDM0IC9Sb290IDI2IDAgUiAvSW5mbyAxIDAgUiAvSUQgWyA8N2MzYmRiODllMjQ3NzVl NTFkZDVkYzc1NmFmZGNhNjU+Cjw3YzNiZGI4OWUyNDc3NWU1MWRkNWRjNzU2YWZkY2E2NT4gXSA+ PgpzdGFydHhyZWYKMzk3NzAKJSVFT0YK --Apple-Mail=_D583A9FC-C7AE-409E-8B09-7B3F529B3BEE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii


My conclusions from the data and my experience working with the DMARC receivers so far is that they are using the flexibility DMARC provides to override reject policies when they believe it is appropriate for their users.  

Thanks,
Mike

--Apple-Mail=_D583A9FC-C7AE-409E-8B09-7B3F529B3BEE-- --Apple-Mail=_7381CE92-8372-4BCF-84CA-0F2BB86DCB7C-- From sklist@kitterman.com Mon Apr 15 18:53:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6A321E8041 for ; Mon, 15 Apr 2013 18:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axA5Z6IqDWaE for ; Mon, 15 Apr 2013 18:53:08 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6839E21E8039 for ; Mon, 15 Apr 2013 18:53:08 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id E811120E40FE; Mon, 15 Apr 2013 21:53:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366077187; bh=hniy+NfM7IdrIg3yST0QkwFX62bgafxqsysJ/iDv/Mw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YdfTPFVAxcd1mVmLQO5TejjOMMJ57DNcR6C7TWH5daoIb/JqZe5tnzHbwo4UeOnZk MmzjS9uVL37o7mF5TFJ4uyw2ASQNGLlJwxRrfiuXieO8whuRvJ2emkBpWiU2FlAsCK z91rEjAysWTG9Ex/XxCdysAERX43Pmf6ivtmx8aU= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id C753B20E4076; Mon, 15 Apr 2013 21:53:07 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 15 Apr 2013 21:53:03 -0400 Message-ID: <2318531.7g4kKM1V2z@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <20130409164432.68830.qmail@joyce.lan> <51698EB9-2B90-4F2E-919A-67A323941794@eudaemon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 01:53:09 -0000 On Tuesday, April 16, 2013 02:46:25 AM J. Gomez wrote: > On Tuesday, April 16, 2013 2:28 AM [GMT+1=CET], Tim Draegen wrote: > > On Apr 15, 2013, at 8:20 PM, "J. Gomez" wrote: > > > The "l=no" tag means in practical terms that point 2 is no longer > > > required for all email coming from domains with such a tag. How > > > does not that make life easier for the receivers when receiving > > > email from those domains? > > > > There is no "l=no" tag. It's been less than a day since people > > replied to this suggestion with some pretty good reasons why it > > doesn't work. > > > > To summarize: receivers aren't looking for a "l=no" directive to > > reject email. They're looking to work-around the mailing list > > problem so that end-users remain calm while anti-phishing technology > > is installed. > > There is a proposed "l=" tag. You can think of the "l=" tag as implicitly > adjectivized as "proposed" whenever you read about it until you may happen > to see it inside the DMARC draft and/or standard, if at all. > > To answer you last paragraph above, the "l=" tag is all about helping > receivers better "work-around the mailing list problem". So I think the > "l=" tag is totally in line with what you say receivers are looking for. Unless they can usefully process different values of your l= tag differently, then it doesn't help. Scott K From superuser@gmail.com Mon Apr 15 21:01:54 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A730621F955A for ; Mon, 15 Apr 2013 21:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cUqf6N9c298 for ; Mon, 15 Apr 2013 21:01:54 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0019A21F9516 for ; Mon, 15 Apr 2013 21:01:53 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id r6so36483wey.12 for ; Mon, 15 Apr 2013 21:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=UGeJU1azdIFDeqw29RmhbJ4RwTtM88o/uUvIY9sjEjc=; b=YFjKhEg3zCWELfCF4zkbNf8v7iBm4dLlYEJOs9RkDQAcAlYNAEpBVmDKxPi5cJT7Tc kIXpzTdpe5DSvrWtp0BgcUYDaqF5CQNxsJxZm+2e5D6uq/UUn1EuOyyKcqadMEf598NJ NFDnu9v5D3OOBw725F66122Zjg7RpRUzui3x4ANJwDD7UoU1GGyKQCKbEYme1VCzUXqs NKfOLQRQ1DxwV5XHmcVcLc9Z6851rx5Y8RPiK1kz9cE2Gz6Fhz+jrbQm9GFIsrpyORZs Xlv55223HmtGds26q9BmK97DouUy8ktVEpDA4YBMM+X4OZmBsYWitAcTr0k20czSL5Rl dmZA== MIME-Version: 1.0 X-Received: by 10.180.92.229 with SMTP id cp5mr15774052wib.20.1366084913141; Mon, 15 Apr 2013 21:01:53 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 15 Apr 2013 21:01:52 -0700 (PDT) In-Reply-To: <7044732.h21xgsJhV9@scott-latitude-e6320> References: <20130409164432.68830.qmail@joyce.lan> <1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local> <7044732.h21xgsJhV9@scott-latitude-e6320> Date: Mon, 15 Apr 2013 21:01:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d043c094efb216a04da726d8d Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 04:01:54 -0000 --f46d043c094efb216a04da726d8d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 15, 2013 at 4:17 PM, Scott Kitterman wrote: > Perhaps that Gmail uses it's own methods to determine what it thinks is > mail > from a mailing list and then doesn't reject/quarantine those solely due to > DMARC. > > Precisely what I've been saying, yes. --f46d043c094efb216a04da726d8d Content-Type: text/html; charset=ISO-8859-1
On Mon, Apr 15, 2013 at 4:17 PM, Scott Kitterman <sklist@kitterman.com> wrote:
Perhaps that Gmail uses it's own methods to determine what it thinks is mail
from a mailing list and then doesn't reject/quarantine those solely due to
DMARC.


Precisely what I've been saying, yes.
--f46d043c094efb216a04da726d8d-- From superuser@gmail.com Mon Apr 15 21:08:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF4C21F90D9 for ; Mon, 15 Apr 2013 21:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpABEmTZkO5A for ; Mon, 15 Apr 2013 21:08:20 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4321F21F8F29 for ; Mon, 15 Apr 2013 21:08:20 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hn17so44547wib.6 for ; Mon, 15 Apr 2013 21:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LE/KNqEVFvPQfv27+HmV3vTmvNHjky95uo1QdIp7PWU=; b=UBGP35ORWCNCGd1wkNNVoAhyeFTsyWlbsYUxUKMGuLFYtTxMPi9Gl6kKgDneYS78r/ vo3eex4aFzK3lIGFCmtUF9MjKsPtq3EFwX/sCQuDdTJwJ9FwiW6ZxeJmjEW0+zp/YBKq 536PozI8+8pbwA6ICPrTHg+uMTGBu6a80DzxHTc5oR1gubqhedqkTcunRSClfDfcgoN0 KJ1RXmd3ugUm9GIzy5jflPNmx73DsKk9L0TZhnBGBriwWNyXUqD/pUhx26/Wg5QO2fgr vswgsYocy3okb4JqWj1s+2fgi+6EFbR/l32PY9hmLc8184GDqhGDKZSaDZdTBu5D7Siv kJ7A== MIME-Version: 1.0 X-Received: by 10.180.92.229 with SMTP id cp5mr15795273wib.20.1366085299308; Mon, 15 Apr 2013 21:08:19 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Mon, 15 Apr 2013 21:08:19 -0700 (PDT) In-Reply-To: References: <20130409164432.68830.qmail@joyce.lan> <1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local> <7044732.h21xgsJhV9@scott-latitude-e6320> Date: Mon, 15 Apr 2013 21:08:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d043c094eff926a04da7284d6 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 04:08:21 -0000 --f46d043c094eff926a04da7284d6 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 15, 2013 at 4:26 PM, J. Gomez wrote: > So are you saying that Gmail does not follow DMARC's "p=reject" to the > letter, and just uses it as an additional input for its internal scoring > system? > No; Gmail does follow DMARC's "p=reject" to the letter, yet doesn't necessarily enact rejection specifically because the draft allows for local overrides when warranted. > > Then that would take Gmail out of the list of the big four/five mailbox > providers who are following DMARC's "p=reject" to the letter, don't you > think? > No, that's not what I think. Do read the last paragraph of Section 5, and try again. I think this thread has become circular. Absent new information or consensus to change something, we need to drop it. -MSK --f46d043c094eff926a04da7284d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 15, 2013 at 4:26 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
So are you saying that Gmail does not follow= DMARC's "p=3Dreject" to the letter, and just uses it as an a= dditional input for its internal scoring system?

No; Gmail does follow DMARC's "p= =3Dreject" to the letter, yet doesn't necessarily enact rejection = specifically because the draft allows for local overrides when warranted. =A0

Then that would take Gmail out of the list of the big four/five mailbox pro= viders who are following DMARC's "p=3Dreject" to the letter, = don't you think?

No, that's not= what I think.=A0 Do read the last paragraph of Section 5, and try again.
I think this thread has become circular.=A0 Absent new infor= mation or consensus to change something, we need to drop it.
=
-MSK
--f46d043c094eff926a04da7284d6-- From johnl@iecc.com Tue Apr 16 03:08:47 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9139121F9321 for ; Tue, 16 Apr 2013 03:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJZNnXlRlbE2 for ; Tue, 16 Apr 2013 03:08:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B744B21F92FC for ; Tue, 16 Apr 2013 03:08:46 -0700 (PDT) Received: (qmail 1924 invoked from network); 16 Apr 2013 10:10:19 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Apr 2013 10:10:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516d232d.xn--hew.k1304; i=johnl@user.iecc.com; bh=kB0cWbgTgVRYjWzvPK0M9ZRg14lZZgmOuJzqSp6CRfo=; b=cHpiX4st4vTdbxURjScCERMgUt1qYKUD2Z9AVQzq9ASIXj2XJlnimtXmsXGwp1Z7xcC8lieby1mn9oup31U4LVKwlCFFJg2ukHSFDoURmwqtE0xgZrZGnejI1RVinp3E4XARmiqqHazsOot9Ktcz1gdsqciRkKDue7fOzybN2e0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516d232d.xn--hew.k1304; olt=johnl@user.iecc.com; bh=kB0cWbgTgVRYjWzvPK0M9ZRg14lZZgmOuJzqSp6CRfo=; b=Xx75GLSqjCyuXRhRIF5krHhk1OPk3Dn0B/ctkoU8HGrXd5DzFEiw2cJ8ChG3ccHfapErIy2HdpiUm3urxfxNW8i1MVJNVmqLZao3+wjjma6G6UPxRoUrDlijRYvU3yMmURy7VSZDtc377IcfLGYlzAXvacFozM6ix+KgjHYOyog= Date: 16 Apr 2013 10:08:22 -0000 Message-ID: <20130416100822.3446.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 10:08:47 -0000 >No, because the hard part is figuring out what's a valid mailing list, not >what the sending domain thinks about mailing lists. It's not just mailing lists. The number of ways that individual users can send legitimate mail that doesn't come from their home mail server is endless. Here are two well known examples: * Users forward their mail to Y! or gmail, and send mail from there using their home address * Web site send to a friend features Listing them all and defending against bad guys sneaking into the list is hopeless. (It reduces to the general whitelist problem.) If someone wants to "protect" their users against phishing using DMARC, they're also going to protect them against doing lots of the stuff that makes mail useful to those users and cause damage to the services those users try and fail to use. Take your pick. R's, John From tim@eudaemon.net Tue Apr 16 08:29:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067D321F9756 for ; Tue, 16 Apr 2013 08:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42zFTbqvXmyd for ; Tue, 16 Apr 2013 08:29:44 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 77BCF21F9751 for ; Tue, 16 Apr 2013 08:29:44 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id A52D9CB46; Tue, 16 Apr 2013 11:30:21 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_BE4DD5CF-2B56-4E54-BE84-F049F0E1DB58" From: Tim Draegen X-Priority: 3 In-Reply-To: <418B6D2C-4F98-46D8-A22B-84A8882FD2A8@agari.com> Date: Tue, 16 Apr 2013 11:29:44 -0400 Message-Id: <8E3F85FA-5F5A-4844-AF0C-6DE25F7B6BF7@eudaemon.net> References: <20130409164432.68830.qmail@joyce.lan><7044732.h21xgsJhV9@scott-latitude-e6320><2537595.FIN36AxgiW@scott-latitude-e6320> <698db3b3-6f00-4251-a16e-12436f263d75@email.android.com> <2D06963047A04BEEA1D84E8A22B6E2EB@fgsr.local> <51698EB9-2B90-4F2E-919A-67A323941794@eudaemon.net> <418B6D2C-4F98-46D8-A22B-84A8882FD2A8@agari.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: dmarc@ietf.org, "J. Gomez" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 15:29:45 -0000 --Apple-Mail=_BE4DD5CF-2B56-4E54-BE84-F049F0E1DB58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 15, 2013, at 9:29 PM, Mike Jones wrote: > The most common override reason was "forwarded" accounting for roughly = 60%. After that "local policy" accounted for 27% of overrides and = "mailing list" was indicated on about 12% of the overrides. =20 Interesting! Perhaps we should lump together "forwarded" and "mailing = list" and think about this space as simply "transitive trust". =3D- Tim --Apple-Mail=_BE4DD5CF-2B56-4E54-BE84-F049F0E1DB58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii mjones@agari.com> = wrote:
The most common override reason was = "forwarded" accounting for roughly 60%.  After that "local policy" = accounted for 27% of overrides and "mailing list" was indicated on about = 12% of the overrides. =  

Interesting!  Perhaps we = should lump together "forwarded" and "mailing list" and think about this = space as simply "transitive trust".

=3D- = Tim

= --Apple-Mail=_BE4DD5CF-2B56-4E54-BE84-F049F0E1DB58-- From vesely@tana.it Tue Apr 16 10:38:04 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7521F8D94 for ; Tue, 16 Apr 2013 10:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwHmvKYHx6KU for ; Tue, 16 Apr 2013 10:38:03 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id D6E4821F8D28 for ; Tue, 16 Apr 2013 10:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366133855; bh=WKzDUP2g4t/FuxX3vPCAW+78hcJ7UELPBFQ5vssm+oU=; l=1043; h=Date:From:To; b=jizwLhiGvqnvHZC6ByQzHESUS6ZQjJUtTUxNRZ1r09uA+P6Jtvta8D2e4fFBTqOMT 9PqQh/ww8SVeAT04I/4r744NMOQM385unmyZM1s31Rm2n93Z79+k1mhhZ/XAoj35Du E/3RwgDK6n8vu6jMz7F4BpyKse4KdctEJFJ6DBZE= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 16 Apr 2013 19:37:35 +0200 id 00000000005DC042.00000000516D8C5F.000062CD Message-ID: <516D8C5F.5010209@tana.it> Date: Tue, 16 Apr 2013 19:37:35 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [dmarc-ietf] Alignment loose ends (mailing lists and forwarders) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 17:38:04 -0000 I get reports from unknown entities at my rua= address. For example, I receive reports from linkedin.com but I sent no messages to that domain. Looking at the auth_results, I find drkurt.com. I know Kurt is on this list, but I never sent mail to his domain either. I need to investigate the source_ip on that row, and that belongs to Google. The report from Google solves the riddle, although it's buggy[1]: I sent those messages to this list. Two points: * What if Kurt didn't want to disclose his connection with LinkedIn? Should Google drop sensible rows from their reports? * What if some kind of intervention was required? Should I forward the records concerning trusted identities to where they belong to? [1] They report spf=softfail smtp.mailfrom=drkurt.com; instead of spf=pass smtp.mailfrom=ietf.org; they also miss to report the dkim result --this list is being signed, since last week. Presumably, they change envelope sender and strip signatures before forwarding, and run DMARC checks afterwards(?) From kurta@drkurt.com Tue Apr 16 10:59:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B2D21F96E4 for ; Tue, 16 Apr 2013 10:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo0En1hHVyEJ for ; Tue, 16 Apr 2013 10:59:34 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF5821F96E1 for ; Tue, 16 Apr 2013 10:59:33 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so788145wgh.30 for ; Tue, 16 Apr 2013 10:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20110616; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=r9lbIcFrBdVrrva5nZI9r3G5nCw/UIVlZSxIA/OCLKY=; b=aQ/UcCszz47Cr3BB5E2dUnyNmc+mkkXiT5OXmw983T/GHB21IwzECvZjk6tIVrNZAY Cskrz/6Uvn+3wnV47lZD7WuAQBz1gt+rpTo1RYjwLYXeHDlR6QOaiMr01TsMj8tKpTDy jtmARJ3k8pLnTPEEk8a8wWCXIGpu1+NCuPeuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=r9lbIcFrBdVrrva5nZI9r3G5nCw/UIVlZSxIA/OCLKY=; b=H3aLsNOLZjQ0bDLhZvt2TipuQK9Jd8llT3XUGQpL5M7TLu7oGgBeGuYTLyWV8Qxpc5 K64RsYfL0vmZR0J1+DH5ZqK1PmkhHPgeNsHsd+J+Q4nOUpENVqzr5Fpm8lA70H/WC6k2 p2pXWw4Mdk49Omn52f9ae1dyCzJYZIXzLBT3posllRA0yekjG8hu/Z4PGxjCZzz1Y/Pf Y/oHSAote6x2ptBAYQkHlE04OUZ5pVMXOFd4FRVndxxDz/dtFWZLKlgAp399ilHWV7FD Y+Sk9ad4kS8u83AL2bVuvA6nm/e+ZvfJukEfbbnXSN8Vob4ZKvo7G1qrAdSrVba9LWyr /xsQ== MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr5859927wjb.29.1366135173250; Tue, 16 Apr 2013 10:59:33 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.65.98 with HTTP; Tue, 16 Apr 2013 10:59:33 -0700 (PDT) In-Reply-To: References: <516D8C5F.5010209@tana.it> Date: Tue, 16 Apr 2013 10:59:33 -0700 X-Google-Sender-Auth: JNXTDjDZPhTS3qhwGm7wvCthLO0 Message-ID: From: Kurt Andersen To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d456cb7956604da7e2123 X-Gm-Message-State: ALoCoQmdYtF0Cia8qOqzhswscVTaH47XAbWurX6ojV/th/3d5JwrKfcWIYpnIwvl29BzLUZ9cNAN Subject: [dmarc-ietf] Fwd: Alignment loose ends (mailing lists and forwarders) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 17:59:35 -0000 --047d7b5d456cb7956604da7e2123 Content-Type: text/plain; charset=ISO-8859-1 Interesting use case :-) If it helps to decipher the pieces, I am subscribed to the IETF list using an alias on my personal domain (drkurt.comwhich has first stage MX hosted by Google) which directs both to a (local) GMail-hosted mailbox as well as forwarding to my work email address (@ linkedin.com - since we all have been debating the usage of DMARC by LinkedIn :-)). I guess that one could consider it to be a personal mailing list (oh the horror, the horror). (p.s. my first attempt to send this message hung up on the mailman "you're not a member of the list" because I failed to set the right "from" address) On Tue, Apr 16, 2013 at 10:37 AM, Alessandro Vesely wrote: > I get reports from unknown entities at my rua= address. For example, > I receive reports from linkedin.com but I sent no messages to that > domain. Looking at the auth_results, I find drkurt.com. I know Kurt > is on this list, but I never sent mail to his domain either. I need > to investigate the source_ip on that row, and that belongs to Google. > The report from Google solves the riddle, although it's buggy[1]: I > sent those messages to this list. > > Two points: > > * What if Kurt didn't want to disclose his connection with LinkedIn? > Should Google drop sensible rows from their reports? > > * What if some kind of intervention was required? Should I forward > the records concerning trusted identities to where they belong to? > > > [1] They report spf=softfail smtp.mailfrom=drkurt.com; instead of > spf=pass smtp.mailfrom=ietf.org; they also miss to report the dkim > result --this list is being signed, since last week. Presumably, they > change envelope sender and strip signatures before forwarding, and run > DMARC checks afterwards(?) > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --047d7b5d456cb7956604da7e2123 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Inte= resting use case :-)=A0 If it helps to decipher the pieces, I am subscribed= to the IETF list using an alias on my personal domain (drkurt.com which has first stage MX hosted= by Google) which directs both to a (local) GMail-hosted mailbox as well as= forwarding to my work email address (@linkedin.com - since we all have been debating the usage = of DMARC by LinkedIn :-)).

I guess that one could consider it to be a personal mailing list = (oh the horror, the horror).

(p.s. my= first attempt to send this message hung up on the mailman "you're= not a member of the list" because I failed to set the right "fro= m" address)

On Tue, Apr= 16, 2013 at 10:37 AM, Alessandro Vesely <vesely@tana.it> wrote= :
I get reports from unknown entities at my ru= a=3D address. =A0For example,
I receive reports from li= nkedin.com but I sent no messages to that
domain. =A0Looking at the auth_results, I find drkurt.com. =A0I know Kurt
is on this list, but I never sent mail to his domain either. =A0I need
to investigate the source_ip on that row, and that belongs to Google.
=A0The report from Google solves the riddle, although it's buggy[1]: = =A0I
sent those messages to this list.

Two points:

* What if Kurt didn't want to disclose his connection with LinkedIn? =A0 Should Google drop sensible rows from their reports?

* What if some kind of intervention was required? =A0Should I forward
=A0 the records concerning trusted identities to where they belong to?


[1] They report spf=3Dsoftfail smtp.mailfrom=3Ddrkurt.com; instead of
spf=3Dpass smtp.mailfrom=3Die= tf.org; they also miss to report the dkim
result --this list is being signed, since last week. =A0Presumably, they change envelope sender and strip signatures before forwarding, and run
DMARC checks afterwards(?)
_______________________________________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc


--047d7b5d456cb7956604da7e2123-- From jgomez@seryrich.com Tue Apr 16 14:32:52 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEEA21F935A for ; Tue, 16 Apr 2013 14:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_20=-0.74, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b56dPeiqPyX for ; Tue, 16 Apr 2013 14:32:49 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id EEDF421F979D for ; Tue, 16 Apr 2013 14:32:48 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 23:32:46 +0200 Message-ID: <3B8407EF6F7845A7A63CDE746B2A4FC1@fgsr.local> From: "J. Gomez" To: References: <20130416100822.3446.qmail@joyce.lan> Date: Tue, 16 Apr 2013 23:33:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 21:32:52 -0000 On Tuesday, April 16, 2013 12:08 PM [GMT+1=3DCET], John Levine wrote: =20 > If someone wants to "protect" their users against phishing using > DMARC, they're also going to protect them against doing lots of the > stuff that makes mail useful to those users and cause damage to the > services those users try and fail to use. Take your pick. Well, it seems LinkedIn.com is not taking any of the picks you provide, = for it seems they are opting to follow their own merry way (publishing = both "p=3Dreject" and subscribing to mailing lists), and so far it's = working just fine and dandy for them. The fact that there are several people subscribed to this list whose = mailbox is hosted at receivers already using DMARC to filter incoming = email, and yet they ALL are reading Franck's posts to this list, is = proof that the two picks you presented are not the whole panoply of = available picks. This obviously is a vulnerability in DMARC. How long until, given this = reality of implementation of DMARC on the field, spamers and phishers = begin dressing their emails with headers (invisible to the user!) to = make them look like mailing list posts, in order to bypass phished brand = owners' "p=3Dreject" policies and therefore land their phishing emails = on the users' mailboxes? All that voodoo of local policies and heuristics that receivers are = wheel-reinventing separately to work around this problem, will be wasted = time the very moment phishing operators become aware of this = vulnerability of DMARC (*) and exploit it. And because there won't be = any possibility of setting a "l=3Dno" tag in DMARC records in DNS, this = vulnerability will be there forever, or until mailing lists die as we = know them now. (*) The vulnerability is not in the letter of the standard, of course; = but all indications point to the FACT that this vulnerability will be = there in the implementations of DMARC in the field. Regards, J. Gomez From jgomez@seryrich.com Tue Apr 16 14:47:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C23B21F97A3 for ; Tue, 16 Apr 2013 14:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.924 X-Spam-Level: X-Spam-Status: No, score=-3.924 tagged_above=-999 required=5 tests=[AWL=0.675, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5825RB9VlSf for ; Tue, 16 Apr 2013 14:47:15 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id A54F721F970F for ; Tue, 16 Apr 2013 14:47:14 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 16 Apr 2013 23:47:10 +0200 Message-ID: <9623C31B27CB4CC785D82BA7663483F6@fgsr.local> From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local><7044732.h21xgsJhV9@scott-latitude-e6320> Date: Tue, 16 Apr 2013 23:47:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 21:47:15 -0000 Murray S. Kucherawy wrote: > No; Gmail does follow DMARC's "p=3Dreject" to the letter, yet doesn't > necessarily enact rejection specifically because the draft allows for > local overrides when warranted. =20 Excuse me, but you are playing with words here. Gmail may be following = the DMARC's standard to the letter, but certainly Gmail is not following = the sender's "p=3Dreject" policy to the letter. "Reject" is a verb, a = verb is an action, the action is "to reject" not "to think about = rejecting" or some other thing. Was that mail rejected? No. Ergo the = sender's DMARC policy of "p=3Dreject" is not being followed to the = letter. Don't you see a problem here? How widespread do you thing that this not = following DMARC's "p=3Dreject" to the letter could become when DMARC is = (if at all) massively deployed in the field? Don't you see here a = potential vulnerability in DMARC, not in the letter of the standard but = on how it may be implemented in the field, therefore opening a door for = phishing email to sneak past "p=3Dreject"? Regards, J. Gomez From jgomez@seryrich.com Tue Apr 16 15:04:30 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ED421F97AA for ; Tue, 16 Apr 2013 15:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.962 X-Spam-Level: X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oj-O+n11UPR1 for ; Tue, 16 Apr 2013 15:04:30 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id E7A6321F97AE for ; Tue, 16 Apr 2013 15:04:29 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 17 Apr 2013 00:04:28 +0200 Message-ID: From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><51698EB9-2B90-4F2E-919A-67A323941794@eudaemon.net> <2318531.7g4kKM1V2z@scott-latitude-e6320> Date: Wed, 17 Apr 2013 00:05:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 22:04:30 -0000 On Tuesday, April 16, 2013 3:53 AM [GMT+1=3DCET], Scott Kitterman wrote: > On Tuesday, April 16, 2013 02:46:25 AM J. Gomez wrote: > > On Tuesday, April 16, 2013 2:28 AM [GMT+1=3DCET], Tim Draegen wrote: > > > On Apr 15, 2013, at 8:20 PM, "J. Gomez" > > > wrote:=20 > > > > The "l=3Dno" tag means in practical terms that point 2 is no > > > > longer required for all email coming from domains with such a > > > > tag. How does not that make life easier for the receivers when > > > > receiving email from those domains? > > >=20 > > > There is no "l=3Dno" tag. It's been less than a day since people > > > replied to this suggestion with some pretty good reasons why it > > > doesn't work. > > >=20 > > > To summarize: receivers aren't looking for a "l=3Dno" directive to > > > reject email. They're looking to work-around the mailing list > > > problem so that end-users remain calm while anti-phishing > > > technology is installed. > >=20 > > There is a proposed "l=3D" tag. You can think of the "l=3D" tag as > > implicitly adjectivized as "proposed" whenever you read about it > > until you may happen to see it inside the DMARC draft and/or > > standard, if at all.=20 > >=20 > > To answer you last paragraph above, the "l=3D" tag is all about > > helping receivers better "work-around the mailing list problem". So > > I think the "l=3D" tag is totally in line with what you say = receivers > > are looking for.=20 >=20 > Unless they can usefully process different values of your l=3D tag > differently, then it doesn't help. And the receivers indeed can process different values of the "l=3D" tag = differently. For example: "v=3DDMARC1; p=3Dreject; pct=3D100; l=3Dno" could be seen by the = receiver as: "Just reject, do not try at all to outsmart the sender = applying local heuristics/policies searching for mailing list activity = after DMARC processing." "v=3DDMARC1; p=3Dreject; pct=3D100; l=3Ddunno" could be seen by the = receiver as: "Reject, unless post-processing after DMARC finds clear = traces of mailing list activity". "v=3DDMARC1; p=3Dreject; pct=3D100; l=3Dyes" could be seen by the = receiver as: "Reject, unles post-processing after DMARC finds plausible = traces of mailing list activity and also bring in our local whitelist of = known mailing lists". Oh, that evil bit! How convenient could it be! From andrewgwilson@gmail.com Tue Apr 16 15:16:08 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0F21F977C for ; Tue, 16 Apr 2013 15:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FX22w18Lfs76 for ; Tue, 16 Apr 2013 15:16:07 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B54CC21F9794 for ; Tue, 16 Apr 2013 15:16:06 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id q16so496732bkw.41 for ; Tue, 16 Apr 2013 15:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=pf9sdNSepXQabMixAhFl4Nx0dgTwbcCXYedasGHYm/E=; b=dsP3D9wECqSj3EAjcZUizey1gtLQNFOwwpLsjPYUp5Zb4mB6u0bHyuZ8TECP9E1wj3 zVB+P8DzULAFiX7an1CBx73sbpm3IM2TZuEoykI/xPVNuZpvlt0DKWqpnvehqYrHq7nW cM8Em7TMq+sEvYcyEXWFwponllBrYB9MfTYfrfpBCqizaHIdL+NITiOH14bFGbk5V1OP DlAgSpempa71C8oHsh6ca6cakkBxqSXTY0fNK2frCSXtvG2ejpO7xg7xogPfkk6k8l6V LFGAyGhh1eTLxyYaL0aZFyXyRCoznRDKzFnGUGiBsVnjY/8E1eLiMgUqmzaJR0SoM9IG tM0g== MIME-Version: 1.0 X-Received: by 10.205.114.136 with SMTP id fa8mr1307612bkc.48.1366150565645; Tue, 16 Apr 2013 15:16:05 -0700 (PDT) Received: by 10.205.36.70 with HTTP; Tue, 16 Apr 2013 15:16:05 -0700 (PDT) Date: Wed, 17 Apr 2013 10:16:05 +1200 Message-ID: From: Andy Wilson To: dmarc@ietf.org Content-Type: multipart/alternative; boundary=14dae9c09d322d0bb704da81b7ae Subject: [dmarc-ietf] First wave of DMARC-compliant spam? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 22:16:08 -0000 --14dae9c09d322d0bb704da81b7ae Content-Type: text/plain; charset=UTF-8 I got some spam recently with interesting characteristics; it passed DKIM, SPF and DMARC with a reject policy. Authentication-Results: mx.google.com; spf=pass (google.com: domain of bounce@clientbasics.com designates 142.234.235.23 as permitted sender) smtp.mail=bounce@clientbasics.com; dkim=pass header.i=support@clientbasics.com; dmarc=pass (p=REJECT dis=none) d=clientbasics.com It's obvious spam, and ended up in my spam folder (even though AR says dis=none) I wonder if spammers are starting to use DMARC to gather aggregate feedback on policies applied by mailbox providers? I suppose it could be a compromised account, although following the WHOIS points to an email address for mediatraffickers.com which looks spammy to me.. -- Regards Andy --14dae9c09d322d0bb704da81b7ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I got some spam recently with interesting characteristics;= it passed DKIM, SPF and DMARC with a reject policy.

Auth= entication-Results: mx.google.com; spf=3Dpass (google.com: domain of = bounce@clientbasics.com desi= gnates 142.234.235.23 as permitted sender) smtp.mail=3Dbounce@clientbasics.com; dkim=3Dpass header.i=3Ds= upport@clientbasics.com; dmarc=3Dpass (p=3DREJECT dis=3Dnone) d=3Dclientbasics.com
It's obvious spam, and en= ded up in my spam folder (even though AR says dis=3Dnone)
<= br>
I wonder if spammers are starting to use DMARC to gather aggrega= te feedback on policies applied by mailbox providers?

<= /div>
I suppose it could be a compromised account, although follo= wing the WHOIS points to an email address for=C2=A0mediatraffickers.com which looks spammy to me..


--
Regards

Andy
--14dae9c09d322d0bb704da81b7ae-- From superuser@gmail.com Tue Apr 16 15:39:28 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34BD21F9790 for ; Tue, 16 Apr 2013 15:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.765 X-Spam-Level: X-Spam-Status: No, score=-4.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E84syJ678G7a for ; Tue, 16 Apr 2013 15:39:28 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id B2EC721F970F for ; Tue, 16 Apr 2013 15:39:27 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id n12so1025374wgh.7 for ; Tue, 16 Apr 2013 15:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bpLdyTOyAJ2ICnuoLIX928tysNw8Nf6jNNWFZ0dkU4c=; b=sfG1zln9KZVcxQ0juQrKX5SkElYLJ9uVknf+GGJ3BkKHoG4bJHKEvWVTyc5+pqP6bH rJYtrfw9cKmGoCewjpP1VPyMUe955r8Z9xOmADMDZZhLxb9jk0ux8h7DPd2PTLmbEPGU kSWdEAYfu7lkRZIhYHNuah0sZrc40igaek4u3q3rpUcVLnMDM8hQjwMxaOOoNYy96zYk oU3VQVP6Sb+EAdgxmBVb+T7IlS1WKEv+MVS+5litswKHme2CDPudWDjMALqW4IfSik1h CwUf0h/XlQgwcuXqWjVEvJXlTIsUrGGkbN+xd4ooa2bHKs/zOF/uNpZz42wQnH84uqxd EWXA== MIME-Version: 1.0 X-Received: by 10.194.222.100 with SMTP id ql4mr7058055wjc.59.1366151963955; Tue, 16 Apr 2013 15:39:23 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Tue, 16 Apr 2013 15:39:23 -0700 (PDT) In-Reply-To: <9623C31B27CB4CC785D82BA7663483F6@fgsr.local> References: <20130409164432.68830.qmail@joyce.lan> <1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local> <7044732.h21xgsJhV9@scott-latitude-e6320> <9623C31B27CB4CC785D82BA7663483F6@fgsr.local> Date: Tue, 16 Apr 2013 15:39:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=001a11c1b9428558f004da820ab5 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 22:39:29 -0000 --001a11c1b9428558f004da820ab5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 16, 2013 at 2:47 PM, J. Gomez wrote: > Murray S. Kucherawy wrote: > > > No; Gmail does follow DMARC's "p=reject" to the letter, yet doesn't > > necessarily enact rejection specifically because the draft allows for > > local overrides when warranted. > > Excuse me, but you are playing with words here. Gmail may be following the > DMARC's standard to the letter, but certainly Gmail is not following the > sender's "p=reject" policy to the letter. "Reject" is a verb, a verb is an > action, the action is "to reject" not "to think about rejecting" or some > other thing. Was that mail rejected? No. Ergo the sender's DMARC policy of > "p=reject" is not being followed to the letter. > I'm not playing with anything, I'm reading the same spec you keep quoting at me. I don't know what "to the letter" even means given the spec does two things very explicitly: (a) Section 5, final paragraph, makes it clear that the receiver's local policy always overrules what the sender's published policy is in the "p=" portion of the DNS record. (b) Section 6.2, in particular the part that talks about "p=", uses language like "requests" and "wishes". This was not an accident. Exactly how is Gmail or anyone being non-compliant if they do something else? The "p=" is nothing more than a request. It cannot be a demand, nor can you claim (given that language) that a receiver is being non-compliant by ignoring that request if it has other information it decides is better signal about what to do with the message? So yes, Gmail is following DMARC to the letter by doing whatever it wants with the information it has. Any other claim amounts to a selective reading of the draft. > Don't you see a problem here? Yes, but it's not what you think it is. The problem is that you appear to be trying to morph DMARC into the silver bullet that it isn't, nor was it meant to be. To me, that means we might need to add more pedagogy up front to make that point clear, not that either the spec or the implementations got it wrong. > How widespread do you thing that this not following DMARC's "p=reject" to > the letter could become when DMARC is (if at all) massively deployed in the > field? Hopefully every receiver also gets what those sections actually say and not your ultra-strict interpretation. > Don't you see here a potential vulnerability in DMARC, not in the letter > of the standard but on how it may be implemented in the field, therefore > opening a door for phishing email to sneak past "p=reject"? > No. -MSK --001a11c1b9428558f004da820ab5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 16, 2013 at 2:47 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
Murray S. Kucherawy wrote:=

> No; Gmail does follow DMARC's "p=3Dreject" to the letter= , yet doesn't
> necessarily enact rejection specifically because the draft allows for<= br> > local overrides when warranted.

Excuse me, but you are playing with words here. Gmail may be followin= g the DMARC's standard to the letter, but certainly Gmail is not follow= ing the sender's "p=3Dreject" policy to the letter. "Rej= ect" is a verb, a verb is an action, the action is "to reject&quo= t; not "to think about rejecting" or some other thing. Was that m= ail rejected? No. Ergo the sender's DMARC policy of "p=3Dreject&qu= ot; is not being followed to the letter.

I'm not playing with anything, I'm= reading the same spec you keep quoting at me.=A0 I don't know what &qu= ot;to the letter" even means given the spec does two things very expli= citly:

(a) Section 5, final paragraph, makes it clear that the rece= iver's local policy always overrules what the sender's published po= licy is in the "p=3D" portion of the DNS record.

(b) Section 6.2, in particular the part that talks about "p=3D", = uses language like "requests" and "wishes".=A0 This was= not an accident.=A0 Exactly how is Gmail or anyone being non-compliant if = they do something else?=A0 The "p=3D" is nothing more than a requ= est.=A0 It cannot be a demand, nor can you claim (given that language) that= a receiver is being non-compliant by ignoring that request if it has other= information it decides is better signal about what to do with the message?=

So yes, Gmail is following DMARC to the letter by doing what= ever it wants with the information it has.=A0 Any other claim amounts to a = selective reading of the draft.


Don't you see a problem here?

Yes, but = it's not what you think it is.=A0 The problem is that you appear to be = trying to morph DMARC into the silver bullet that it isn't, nor was it = meant to be.=A0 To me, that means we might need to add more pedagogy up fro= nt to make that point clear, not that either the spec or the implementation= s got it wrong.
=A0
How widespread do you thing tha= t this not following DMARC's "p=3Dreject" to the letter could= become when DMARC is (if at all) massively deployed in the field?

Hopefully every receiver also gets what those sections = actually say and not your ultra-strict interpretation.
=A0
Don't you see here a potential vulnerability in DMARC, not in the lette= r of the standard but on how it may be implemented in the field, therefore = opening a door for phishing email to sneak past "p=3Dreject"?

No.

-MSK
--001a11c1b9428558f004da820ab5-- From zwicky@yahoo-inc.com Tue Apr 16 15:46:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0520021F97AA for ; Tue, 16 Apr 2013 15:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.199 X-Spam-Level: X-Spam-Status: No, score=-18.199 tagged_above=-999 required=5 tests=[AWL=-2.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYLJ-vWL4Sv7 for ; Tue, 16 Apr 2013 15:46:50 -0700 (PDT) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id 21AE421F97A5 for ; Tue, 16 Apr 2013 15:46:49 -0700 (PDT) Received: from GQ1-EX10-CAHT01.y.corp.yahoo.com (gq1-ex10-caht01.corp.gq1.yahoo.com [10.73.118.80]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r3GMkYSM086812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Apr 2013 15:46:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1366152396; bh=U5emAD9vIRGu/KDY99YW9IJ5x6OG3Q3+W/jhDG7zaB0=; h=From:To:Subject:Date:Message-ID:In-Reply-To:Content-Type: MIME-Version; b=dEUkJ3lzJIew93Qk8/028P3qcy+KtzpSfMOrz3I9O1L2X79kXKOUx9XBhP4qBoH/P zU1DZWEF+mdutl4mruoJSBgyRsBkFYSbzZBbsBP59NRmttdBbTiXEnV6yBVnqfl8g5 FZPiO8ljYQXVJIKNNHAOi32CP5lT9C8ILtZyahjg= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT01.y.corp.yahoo.com ([fe80::7c21:dcd7:76a1:8f1b%12]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 15:46:34 -0700 From: Elizabeth Zwicky To: Andy Wilson , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] First wave of DMARC-compliant spam? Thread-Index: AQHOOvA3M1iGubtmHEeK17TX+PIKUZjZcpoA Date: Tue, 16 Apr 2013 22:46:33 +0000 Message-ID: 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.2.130206 x-originating-ip: [216.145.54.158] Content-Type: multipart/alternative; boundary="_000_CD9322597DB5Fzwickyyahooinccom_" MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 152396001 Subject: Re: [dmarc-ietf] First wave of DMARC-compliant spam? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 22:46:51 -0000 --_000_CD9322597DB5Fzwickyyahooinccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm afraid it's about a year too late to identify the first wave of DMARC-c= ompliant spam. I love spammers who use DKIM and DMARC. Please, let me be precise about you= r reputation. Elizabeth From: Andy Wilson > Date: Tuesday, April 16, 2013 3:16 PM To: "dmarc@ietf.org" > Subject: [dmarc-ietf] First wave of DMARC-compliant spam? I got some spam recently with interesting characteristics; it passed DKIM, = SPF and DMARC with a reject policy. Authentication-Results: mx.google.com; spf=3Dpass (google.com: domain of bounce@clientba= sics.com designates 142.234.235.23 as permi= tted sender) smtp.mail=3Dbounce@clientbasics.com; dkim=3Dpass header.i=3Dsupport@clientbasics.com; dmarc=3Dpass (p=3DREJECT dis=3Dnone) d=3Dclientbasics.com It's obvious spam, and ended up in my spam folder (even though AR says dis= =3Dnone) I wonder if spammers are starting to use DMARC to gather aggregate feedback= on policies applied by mailbox providers? I suppose it could be a compromised account, although following the WHOIS p= oints to an email address for mediatraffickers.com which looks spammy to me.. -- Regards Andy --_000_CD9322597DB5Fzwickyyahooinccom_ Content-Type: text/html; charset="us-ascii" Content-ID: <12F1D80148CE9644854CF44B039A584D@exchange.corp.yahoo.com> Content-Transfer-Encoding: quoted-printable

I'm afraid it's about a year too late to identify the first wave of DM= ARC-compliant spam.

I love spammers who use DKIM and DMARC. Please, let me be precise abou= t your reputation.

Elizab= eth


From: Andy Wilson <andrewgwilson@gmail.com>
Date: Tuesday, April 16, 2013 3:16 = PM
To: "dmarc@ietf.org" <dma= rc@ietf.org>
Subject: [dmarc-ietf] First wave of= DMARC-compliant spam?

I got some spam recently with interesting characteristics;= it passed DKIM, SPF and DMARC with a reject policy. 

A=
uthentication-Results: mx.google.com;
       spf=3Dpass (google.com: domain of =
bounce@clientbasics.com desi=
gnates 142.234.235.23 as permitted sender) smtp.mail=3Dbounce@clientbasics.com;
       dkim=3Dpass header.i=3Ds=
upport@clientbasics.com;
       dmarc=3Dpass (p=3DREJECT dis=3Dnone) d=3Dclientbasics.com
It's obvious spam, and ended up in my spam folder (even tho= ugh AR says dis=3Dnone)

I wonder if spammers are starting to use DMARC to gather ag= gregate feedback on policies applied by mailbox providers?

I suppose it could be a compromised account, although follo= wing the WHOIS points to an email address for mediatraffickers.com which looks spammy to me..


--
Regards

Andy
--_000_CD9322597DB5Fzwickyyahooinccom_-- From tzink@exchange.microsoft.com Tue Apr 16 15:48:26 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56A421F9768 for ; Tue, 16 Apr 2013 15:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.798 X-Spam-Level: X-Spam-Status: No, score=-101.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-plHFh7xPs8 for ; Tue, 16 Apr 2013 15:48:26 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF8921F9757 for ; Tue, 16 Apr 2013 15:48:26 -0700 (PDT) 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.680.5; Tue, 16 Apr 2013 22:48:22 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.5.149]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.5.149]) with mapi id 15.00.0680.000; Tue, 16 Apr 2013 22:48:22 +0000 From: Terry Zink To: Andy Wilson , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] First wave of DMARC-compliant spam? Thread-Index: AQHOOvABiikwENp6CE+395GVVIGoLJjZcrVA Date: Tue, 16 Apr 2013 22:48:22 +0000 Message-ID: <304a670afcd6477a9e8fbf754bfec209@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.157.4] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2SR01MB609; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: multipart/alternative; boundary="_000_304a670afcd6477a9e8fbf754bfec209BY2SR01MB608namsdf01sdf_" MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] First wave of DMARC-compliant spam? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 16 Apr 2013 22:48:26 -0000 --_000_304a670afcd6477a9e8fbf754bfec209BY2SR01MB608namsdf01sdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9lc27igJl0IHRoaXMgbWFrZSBpdCBlYXN5IHRvIGZpbHRlciBpbiB0aGUgZnV0dXJlPyBKdXN0 IGFkZCDigJxjbGllbnRiYXNpY3MuY29t4oCdIHRvIGEgZG9tYWluIGJsb2NrbGlzdD8NCg0KV2hp bGUgc3BhbW1lcnMgbWF5IGJlIHRyeWluZyB0byBzZWUgaG93IHJlamVjdCBwb2xpY2llcyBhcmUg dXNlZCBjdXJyZW50bHksIHRoZXkgbWF5IGp1c3QgYmUgdHJ5aW5nIHRvIGltaXRhdGUgYSBnb29k IHNlbmRlciBhbmQgYXNzdW1lIHRoYXQgYXV0aGVudGljYXRpbmcgd2l0aCBES0lNIGFuZC9vciBT UEYgbWVhbnMgZWFzaWVyIGRlbGl2ZXJhYmlsaXR5IHRvIHRoZSBpbmJveC4NCg0KLS0gVGVycnkN Cg0KRnJvbTogZG1hcmMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IFdpbHNvbg0KU2VudDogVHVlc2RheSwgQXByaWwgMTYs IDIwMTMgMzoxNiBQTQ0KVG86IGRtYXJjQGlldGYub3JnDQpTdWJqZWN0OiBbZG1hcmMtaWV0Zl0g Rmlyc3Qgd2F2ZSBvZiBETUFSQy1jb21wbGlhbnQgc3BhbT8NCg0KSSBnb3Qgc29tZSBzcGFtIHJl Y2VudGx5IHdpdGggaW50ZXJlc3RpbmcgY2hhcmFjdGVyaXN0aWNzOyBpdCBwYXNzZWQgREtJTSwg U1BGIGFuZCBETUFSQyB3aXRoIGEgcmVqZWN0IHBvbGljeS4NCg0KDQpBdXRoZW50aWNhdGlvbi1S ZXN1bHRzOiBteC5nb29nbGUuY29tPGh0dHA6Ly9teC5nb29nbGUuY29tPjsNCg0KICAgICAgIHNw Zj1wYXNzIChnb29nbGUuY29tPGh0dHA6Ly9nb29nbGUuY29tPjogZG9tYWluIG9mIGJvdW5jZUBj bGllbnRiYXNpY3MuY29tPG1haWx0bzpib3VuY2VAY2xpZW50YmFzaWNzLmNvbT4gZGVzaWduYXRl cyAxNDIuMjM0LjIzNS4yMyBhcyBwZXJtaXR0ZWQgc2VuZGVyKSBzbXRwLm1haWw9Ym91bmNlQGNs aWVudGJhc2ljcy5jb208bWFpbHRvOmJvdW5jZUBjbGllbnRiYXNpY3MuY29tPjsNCg0KICAgICAg IGRraW09cGFzcyBoZWFkZXIuaT1zdXBwb3J0QGNsaWVudGJhc2ljcy5jb208bWFpbHRvOnN1cHBv cnRAY2xpZW50YmFzaWNzLmNvbT47DQoNCiAgICAgICBkbWFyYz1wYXNzIChwPVJFSkVDVCBkaXM9 bm9uZSkgZD1jbGllbnRiYXNpY3MuY29tPGh0dHA6Ly9jbGllbnRiYXNpY3MuY29tPg0KSXQncyBv YnZpb3VzIHNwYW0sIGFuZCBlbmRlZCB1cCBpbiBteSBzcGFtIGZvbGRlciAoZXZlbiB0aG91Z2gg QVIgc2F5cyBkaXM9bm9uZSkNCg0KSSB3b25kZXIgaWYgc3BhbW1lcnMgYXJlIHN0YXJ0aW5nIHRv IHVzZSBETUFSQyB0byBnYXRoZXIgYWdncmVnYXRlIGZlZWRiYWNrIG9uIHBvbGljaWVzIGFwcGxp ZWQgYnkgbWFpbGJveCBwcm92aWRlcnM/DQoNCkkgc3VwcG9zZSBpdCBjb3VsZCBiZSBhIGNvbXBy b21pc2VkIGFjY291bnQsIGFsdGhvdWdoIGZvbGxvd2luZyB0aGUgV0hPSVMgcG9pbnRzIHRvIGFu IGVtYWlsIGFkZHJlc3MgZm9yIG1lZGlhdHJhZmZpY2tlcnMuY29tPGh0dHA6Ly9tZWRpYXRyYWZm aWNrZXJzLmNvbT4gd2hpY2ggbG9va3Mgc3BhbW15IHRvIG1lLi4NCg0KDQotLQ0KUmVnYXJkcw0K DQpBbmR5DQo= --_000_304a670afcd6477a9e8fbf754bfec209BY2SR01MB608namsdf01sdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQt ZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Eb2VzbuKAmXQgdGhpcyBtYWtlIGl0IGVhc3kgdG8gZmlsdGVyIGlu IHRoZSBmdXR1cmU/IEp1c3QgYWRkIOKAnGNsaWVudGJhc2ljcy5jb23igJ0gdG8gYSBkb21haW4g YmxvY2tsaXN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGlsZSBz cGFtbWVycyBtYXkgYmUgdHJ5aW5nIHRvIHNlZSBob3cgcmVqZWN0IHBvbGljaWVzIGFyZSB1c2Vk IGN1cnJlbnRseSwgdGhleSBtYXkganVzdCBiZSB0cnlpbmcgdG8gaW1pdGF0ZSBhIGdvb2Qgc2Vu ZGVyIGFuZCBhc3N1bWUgdGhhdCBhdXRoZW50aWNhdGluZyB3aXRoIERLSU0gYW5kL29yDQogU1BG IG1lYW5zIGVhc2llciBkZWxpdmVyYWJpbGl0eSB0byB0aGUgaW5ib3guPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tIFRlcnJ5PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gZG1hcmMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgV2lsc29uPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEFwcmlsIDE2LCAyMDEzIDM6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IGRtYXJjQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtkbWFyYy1pZXRmXSBGaXJzdCB3YXZlIG9mIERNQVJD LWNvbXBsaWFudCBzcGFtPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg Z290IHNvbWUgc3BhbSByZWNlbnRseSB3aXRoIGludGVyZXN0aW5nIGNoYXJhY3RlcmlzdGljczsg aXQgcGFzc2VkIERLSU0sIFNQRiBhbmQgRE1BUkMgd2l0aCBhIHJlamVjdCBwb2xpY3kuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3aGl0 ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BdXRoZW50aWNhdGlv bi1SZXN1bHRzOiA8YSBocmVmPSJodHRwOi8vbXguZ29vZ2xlLmNvbSI+bXguZ29vZ2xlLmNvbTwv YT47PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwZj1wYXNzICg8YSBocmVm PSJodHRwOi8vZ29vZ2xlLmNvbSI+Z29vZ2xlLmNvbTwvYT46IGRvbWFpbiBvZiA8YSBocmVmPSJt YWlsdG86Ym91bmNlQGNsaWVudGJhc2ljcy5jb20iPmJvdW5jZUBjbGllbnRiYXNpY3MuY29tPC9h PiBkZXNpZ25hdGVzIDE0Mi4yMzQuMjM1LjIzIGFzIHBlcm1pdHRlZCBzZW5kZXIpIHNtdHAubWFp bD08YSBocmVmPSJtYWlsdG86Ym91bmNlQGNsaWVudGJhc2ljcy5jb20iPmJvdW5jZUBjbGllbnRi YXNpY3MuY29tPC9hPjs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGtpbT1w YXNzIGhlYWRlci5pPTxhIGhyZWY9Im1haWx0bzpzdXBwb3J0QGNsaWVudGJhc2ljcy5jb20iPnN1 cHBvcnRAY2xpZW50YmFzaWNzLmNvbTwvYT47PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRtYXJjPXBhc3MgKHA9UkVKRUNUIGRpcz1ub25lKSBkPTxhIGhyZWY9Imh0dHA6Ly9j bGllbnRiYXNpY3MuY29tIj5jbGllbnRiYXNpY3MuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0J3Mgb2J2aW91cyBzcGFtLCBhbmQg ZW5kZWQgdXAgaW4gbXkgc3BhbSBmb2xkZXIgKGV2ZW4gdGhvdWdoIEFSIHNheXMgZGlzPW5vbmUp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg d29uZGVyIGlmIHNwYW1tZXJzIGFyZSBzdGFydGluZyB0byB1c2UgRE1BUkMgdG8gZ2F0aGVyIGFn Z3JlZ2F0ZSBmZWVkYmFjayBvbiBwb2xpY2llcyBhcHBsaWVkIGJ5IG1haWxib3ggcHJvdmlkZXJz PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHN1cHBvc2UgaXQgY291bGQgYmUgYSBjb21wcm9taXNlZCBhY2NvdW50LCBhbHRob3VnaCBmb2xs b3dpbmcgdGhlIFdIT0lTIHBvaW50cyB0byBhbiBlbWFpbCBhZGRyZXNzIGZvciZuYnNwOzxhIGhy ZWY9Imh0dHA6Ly9tZWRpYXRyYWZmaWNrZXJzLmNvbSI+bWVkaWF0cmFmZmlja2Vycy5jb208L2E+ IHdoaWNoIGxvb2tzIHNwYW1teSB0byBtZS4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpSZWdhcmRzPGJyPg0KPGJyPg0KQW5keSA8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_304a670afcd6477a9e8fbf754bfec209BY2SR01MB608namsdf01sdf_-- From MHammer@ag.com Tue Apr 16 19:58:18 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7E21F92C9 for ; Tue, 16 Apr 2013 19:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSbH734BJzJD for ; Tue, 16 Apr 2013 19:58:17 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id AF9A621F92C4 for ; Tue, 16 Apr 2013 19:58:17 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Tue, 16 Apr 2013 22:58:17 -0400 From: "MH Michael Hammer (5304)" To: Josh Aberant Thread-Topic: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies Thread-Index: AQHOOiPqJdYk+5VzI0Sg0Y4eT3VcYJjZuNNw Date: Wed, 17 Apr 2013 02:58:16 +0000 Message-ID: References: <408455A9-C670-487C-80E8-17FCB24E5E3B@eudaemon.net> <20130415113337.8535.qmail@joyce.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 02:58:18 -0000 >From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of = Josh Aberant >Sent: Monday, April 15, 2013 5:55 PM >Cc: dmarc@ietf.org >Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not abou= t outsourcing strategies > >As another stakeholder with a domain that has users and p=3Dreject, it see= ms to me that simply saying the DMARC reject shouldn't be used on domains w= ith users will significantly >limit the potential value of DMARC to the ema= il community.=A0 One of our main goals in deploying DMARC was to protect ou= r users.=A0 Before we deployed p=3Dreject we were seeing >phishing attacks = on our employees (to their work and personal addresses) that were spoofing = our domain. DMARC p=3Dreject made these mostly go away and added a lot of v= alue. >Perhaps, a focus of DMARC should be on protecting domains with users. > >And, yes, I know I'm walking into a land mine here and top posting to boot= ; fire away.... > >Josh=20 Josh, Domains with users CAN implement p=3Dreject as long as the users avoid mail= lists from that domain and it is made clear to users that there are some si= tuations where mail may be lost. The nice thing is that by publishing a pol= icy of p=3Dnone, a domain owner willing to do a little analysis can determi= ne roughly how big of an issue it is for them. There are tradeoffs that nee= d to be considered. So, it can be done but there are constraints to work within. Mike From johnl@iecc.com Wed Apr 17 03:39:43 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6021F8BF8 for ; Wed, 17 Apr 2013 03:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMQItHkD+ZK3 for ; Wed, 17 Apr 2013 03:39:42 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C20AF21F8BD4 for ; Wed, 17 Apr 2013 03:39:41 -0700 (PDT) Received: (qmail 20915 invoked from network); 17 Apr 2013 10:41:15 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Apr 2013 10:41:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516e7bed.xn--3zv.k1304; i=johnl@user.iecc.com; bh=HdvBZ/O02pqvOb7NVljxF+/yjFCkjCvKrPoTgeadD14=; b=lbjPanUmvv5b9TOkbTGZAJwwyitfsEDUX7HV+abDtdlotLvyCNzYZ1WirEFXwKhgW3SLetuhRBXtw3Xg6Uq3pK3sBG9Aul72NAmnpJ7L9WkVwX2Rm8fSJ4FwK2PfgnNKegHhL9xxUYhkE3f+49QOJfw9/tpu3PbeFK6aNyQqERQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=516e7bed.xn--3zv.k1304; olt=johnl@user.iecc.com; bh=HdvBZ/O02pqvOb7NVljxF+/yjFCkjCvKrPoTgeadD14=; b=L1N/cQA9C3SEQEVAd9UQ0haS7ct33NnEUi1CU4zEoRs2Eu4CHcatqa9tcVLkHjvKV89JYHjpYIXfC/vrdZksDLYaT9hXmwyk96rwiW2py45UqttBwDCaUlkzxu59nY13aeoLqwqcg3ODV7uyqQHYFAXjmkjnI9OVVckupDmtdsA= Date: 17 Apr 2013 10:39:18 -0000 Message-ID: <20130417103918.3587.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 10:39:43 -0000 >Domains with users CAN implement p=reject as long as the users avoid maillists from that domain >and it is made clear to users that there are some situations where mail may be lost. Right, and they can't forward mail to gmail or use send to a friend, or any of a zillion other things that human users do. It's pretty clear that publishing a dmarc policy other than p=none will make your users' mail work worse. Let's sure the DMARC documents says people SHOULD call their IT departments and complain when their list subscriptions are cancelled and stuff they send from gmail mysteriously disappears. Perhaps we could try and think more clearly about providing service to actual mail users and less about hypothetical spoofing attacks on people who are not plausible spoof targets. R's, John From MHammer@ag.com Wed Apr 17 05:11:32 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC1521F8E04 for ; Wed, 17 Apr 2013 05:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3jgvSmng3XS for ; Wed, 17 Apr 2013 05:11:32 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) by ietfa.amsl.com (Postfix) with ESMTP id D744021F8771 for ; Wed, 17 Apr 2013 05:11:31 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Wed, 17 Apr 2013 08:11:30 -0400 From: "MH Michael Hammer (5304)" To: John Levine , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness Thread-Index: AQHOO1fgskOTRsgdJU2PZcR13NTSRJjaT5SA Date: Wed, 17 Apr 2013 12:11:30 +0000 Message-ID: References: <20130417103918.3587.qmail@joyce.lan> In-Reply-To: <20130417103918.3587.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.201] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 12:11:32 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of John Levine > Sent: Wednesday, April 17, 2013 6:39 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] making mail not work for your users, was the > endless mailing list silliness >=20 > >Domains with users CAN implement p=3Dreject as long as the users avoid > >maillists from that domain and it is made clear to users that there are = some > situations where mail may be lost. >=20 > Right, and they can't forward mail to gmail or use send to a friend, or a= ny of a > zillion other things that human users do. It's pretty clear that publish= ing a > dmarc policy other than p=3Dnone will make your users' mail work worse. >=20 Perhaps I should have been more specific and added the constraint that I wa= s thinking of b-to-b domains as an example in crafting my comments. As far = as "send to a friend", this may or may not be problematic - Many of the sit= es I work with do "send to a friend" without any DMARC problems whatsoever. > Let's sure the DMARC documents says people SHOULD call their IT > departments and complain when their list subscriptions are cancelled and > stuff they send from gmail mysteriously disappears. >=20 I absolutely agree with you that people should complain if their IT departm= ent doesn't communicate planned changes (of any sort). And if someone compl= ains to their IT department about stuff they are sending from gmail (purpor= ting to come from their company domain) there might be a different discussi= on about company security policies and AUP. > Perhaps we could try and think more clearly about providing service to ac= tual > mail users and less about hypothetical spoofing attacks on people who are > not plausible spoof targets. >=20 This is about risk management. Many want to publish p=3Dreject when there i= s no significant risk. Others who have a real risk are not willing to archi= tect their systems/policies/mailstreams to appropriately leverage DMARC to = mitigate that risk without creating problems for others.=20 Mike From johnl@taugh.com Wed Apr 17 05:15:14 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D5121F8C8C for ; Wed, 17 Apr 2013 05:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSwHARrG6DcQ for ; Wed, 17 Apr 2013 05:15:13 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 6EACE21F8C55 for ; Wed, 17 Apr 2013 05:15:13 -0700 (PDT) Received: (qmail 45281 invoked from network); 17 Apr 2013 12:16:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b0df.516e92ae.k1304; bh=cqf5Dz9P/Sjx5wrGRAib3i0nu1vRj2tIwVAm7Z4srzg=; b=J5f8W5EXh/DUdVUNKUheBUOGR5vy4bh/fWOhQgqqhTkNDmnNfGx+I16bQfdi4OYDFmDYjB0QwSR/FlyeQJ6Hsi0CDdqXAlF5hMjs5Ra7x6UBjBwWFg3fW77syC+wMusMwf0AfgWGvCubwvK+uxJedoV1dZbGhwvmUCVlFRe7D+U= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=b0df.516e92ae.k1304; bh=cqf5Dz9P/Sjx5wrGRAib3i0nu1vRj2tIwVAm7Z4srzg=; b=vkMmbr/7PYnhUMEsQ+dbe/qFMMA436Qb/a+/4qvn79ELgAzJ+clt4318jOenCnd89PrvA8oSkoRmSFlgZyG2LlEVyLYx3TknPEwOrPA/ZAaCseN2/zM30mkRicHdqEz+dViIKLXSUI9UIrrpLq7ipIAMgwL+2ZGsesViskOyIMw= Received: (ofmipd 127.0.0.1); 17 Apr 2013 12:16:24 -0000 Date: 17 Apr 2013 14:15:11 +0200 Message-ID: From: "John R Levine" To: "MH Michael Hammer (5304)" In-Reply-To: References: <20130417103918.3587.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 12:15:14 -0000 > Perhaps I should have been more specific and added the constraint that I > was thinking of b-to-b domains as an example in crafting my comments. As > far as "send to a friend", this may or may not be problematic - Many of > the sites I work with do "send to a friend" without any DMARC problems > whatsoever. That's because very few domains with live users currently publish a DMARC policy. If people use a return address with a p=none or p=quarantine policy, poof, DMARC will keep the message from being delivered. > This is about risk management. Many want to publish p=reject when there > is no significant risk. Others who have a real risk are not willing to > architect their systems/policies/mailstreams to appropriately leverage > DMARC to mitigate that risk without creating problems for others. Entirely agree. R's, John From MHammer@ag.com Wed Apr 17 05:22:26 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E8221F8D28 for ; Wed, 17 Apr 2013 05:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5-+uvoXW4aM for ; Wed, 17 Apr 2013 05:22:24 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6009521F8D29 for ; Wed, 17 Apr 2013 05:22:21 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Wed, 17 Apr 2013 08:22:21 -0400 From: "MH Michael Hammer (5304)" To: John R Levine Thread-Topic: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness Thread-Index: AQHOO2U4gMAmqonNvUWS99nEGNwKVJjaVPzQ Date: Wed, 17 Apr 2013 12:22:20 +0000 Message-ID: References: <20130417103918.3587.qmail@joyce.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.201] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 12:22:26 -0000 > -----Original Message----- > From: John R Levine [mailto:johnl@taugh.com] > Sent: Wednesday, April 17, 2013 8:15 AM > To: MH Michael Hammer (5304) > Cc: dmarc@ietf.org > Subject: RE: [dmarc-ietf] making mail not work for your users, was the > endless mailing list silliness >=20 > > Perhaps I should have been more specific and added the constraint that > > I was thinking of b-to-b domains as an example in crafting my > > comments. As far as "send to a friend", this may or may not be > > problematic - Many of the sites I work with do "send to a friend" > > without any DMARC problems whatsoever. >=20 > That's because very few domains with live users currently publish a DMARC > policy. If people use a return address with a p=3Dnone or p=3Dquarantine= policy, > poof, DMARC will keep the message from being delivered. >=20 Care to bet on that with regard to my sites? It's all in how the "send to a= friend" site architects things. > > This is about risk management. Many want to publish p=3Dreject when > > there is no significant risk. Others who have a real risk are not > > willing to architect their systems/policies/mailstreams to > > appropriately leverage DMARC to mitigate that risk without creating > problems for others. >=20 > Entirely agree. >=20 From olgag@google.com Wed Apr 17 07:06:55 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FBD21F8B15 for ; Wed, 17 Apr 2013 07:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.177 X-Spam-Level: X-Spam-Status: No, score=-100.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJc+QvfAWHip for ; Wed, 17 Apr 2013 07:06:53 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1BC21F8B13 for ; Wed, 17 Apr 2013 07:06:53 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wn14so1475633obc.32 for ; Wed, 17 Apr 2013 07:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2vyzE3exPQM5e7TQDCA5jDekeQwv6MT5A0ofUYEZsq4=; b=ZGj4kSfvKlIjXscpxvQxHvIBmXL4ifVrAT7nqiG91lE7e70L3ONm96Oq77Y5ytH0fL 8cLA5dnxEmj62o6qXJE4LyuXpO/ooGKpsvTGb6BmLfK+FXXz5I8FKveMqAlsSNjeVNCP fSfrgVRbhpmuBcKZ7unTOj76IHdScH5c5DmYu4y1n10ftrfTHjsPXn4CGLFNOQl5n7TP X9hmn0ShH2VXRucK2WP46fH6u/xBBe+6JLGXR4KXlMe6uKFz3bdPb7ITUCw1T8zcwBk7 nS6XGRjTzdPbgxeaxHpN1NjR+w9GtJ+qKeIO0tsduzOH7GCFaSuGHOrBW48/uq5vetkX Pm1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=2vyzE3exPQM5e7TQDCA5jDekeQwv6MT5A0ofUYEZsq4=; b=dtBvIaeq52dtYTUhkurenwkmcVuREn6CNY5StkSXgCUNPjHGf3XPOarOv3FndU5J2L L5GiCm7eGC3R89EabR8g6hX9Hs10CIdqVqT6piv3m9MVCm6Dk8Dq3TMjHb4MPfZ/i7q6 VkbtStBcRRv4KmwS+IgpRu2sxLmdYGIa+H9N6yFQCc1vP0Iwfl8SECvPYfSLYGkJ2j2e /EWxoGCjeLIVz+2panDAwI+jQ4aF+ue4eIMuoIAcU4aKhPvVuNUffCTFXKwMLaHfwCD4 32cKvNMJ53wc2qQd4M+uCybz8iTmDJzGdniTpADMvlW4IwtGzKWc/HTgPmKR1TxCeB0c IwZA== MIME-Version: 1.0 X-Received: by 10.60.179.116 with SMTP id df20mr2582505oec.99.1366207613026; Wed, 17 Apr 2013 07:06:53 -0700 (PDT) Received: by 10.76.144.167 with HTTP; Wed, 17 Apr 2013 07:06:52 -0700 (PDT) In-Reply-To: <304a670afcd6477a9e8fbf754bfec209@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> References: <304a670afcd6477a9e8fbf754bfec209@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> Date: Wed, 17 Apr 2013 07:06:52 -0700 Message-ID: From: Olga Gavrylyako To: Terry Zink Content-Type: multipart/alternative; boundary=089e0115fd3476e22f04da8effe0 X-Gm-Message-State: ALoCoQmeOxrNNPz4GArfM4TjGjFBp/++mCQMdflGXPZJyIbUceUyjxl9Ehrl3eS1CASm4sbssGOIbziarvnVp/8IPe5AFbUNvqO0PNM5k0Jg/dcc0GaojkJ1it2DlFJILoakOGtb9e1LUUguD02i7ahSYiQ7hicGHOiON4fi20IqhTwN0EIS4DZIkwjlQN3deF8hKi/QtGug Cc: "dmarc@ietf.org" , Andy Wilson Subject: Re: [dmarc-ietf] First wave of DMARC-compliant spam? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 14:06:55 -0000 --089e0115fd3476e22f04da8effe0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes... unfortunately nothing new ... Olga On Tue, Apr 16, 2013 at 3:48 PM, Terry Zink w= rote: > Doesn=92t this make it easy to filter in the future? Just add =93 > clientbasics.com=94 to a domain blocklist?**** > > ** ** > > While spammers may be trying to see how reject policies are used > currently, they may just be trying to imitate a good sender and assume th= at > authenticating with DKIM and/or SPF means easier deliverability to the > inbox.**** > > ** ** > > -- Terry**** > > ** ** > > *From:* dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] *On Behalf > Of *Andy Wilson > *Sent:* Tuesday, April 16, 2013 3:16 PM > *To:* dmarc@ietf.org > > *Subject:* [dmarc-ietf] First wave of DMARC-compliant spam?**** > > ** ** > > I got some spam recently with interesting characteristics; it passed DKIM= , > SPF and DMARC with a reject policy.**** > > ** ** > > Authentication-Results: mx.google.com;**** > > spf=3Dpass (google.com: domain of bounce@clientbasics.com designat= es 142.234.235.23 as permitted sender) smtp.mail=3Dbounce@clientbasics.com;= **** > > dkim=3Dpass header.i=3Dsupport@clientbasics.com;**** > > dmarc=3Dpass (p=3DREJECT dis=3Dnone) d=3Dclientbasics.com**** > > It's obvious spam, and ended up in my spam folder (even though AR says > dis=3Dnone)**** > > ** ** > > I wonder if spammers are starting to use DMARC to gather aggregate > feedback on policies applied by mailbox providers?**** > > ** ** > > I suppose it could be a compromised account, although following the WHOIS > points to an email address for mediatraffickers.com which looks spammy to > me..**** > > ** ** > > ** ** > > -- > Regards > > Andy **** > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --089e0115fd3476e22f04da8effe0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yes... unfortunately nothing new ...
Olga
<= /div>


On Tue, = Apr 16, 2013 at 3:48 PM, Terry Zink <tzink@exchange.microsoft.c= om> wrote:

Doesn=92t this make it easy to filter i= n the future? Just add =93clientbasics.com=94 to a domain blocklist?

=A0

While spammers may be trying to see how= reject policies are used currently, they may just be trying to imitate a g= ood sender and assume that authenticating with DKIM and/or SPF means easier deliverability to the inbox.

=A0

-- Terry

=A0

From: dmarc-bounces@ietf.org= [mailto:dm= arc-bounces@ietf.org] On Behalf Of Andy Wilson
Sent: Tuesday, April 16, 2013 3:16 PM
To: dmarc@ietf.o= rg


Subject: [dmarc-ietf] First wave of DMARC-compliant spam?<= /u>

=A0

I got some spam recently with interesting characteri= stics; it passed DKIM, SPF and DMARC with a reject policy.


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


--089e0115fd3476e22f04da8effe0-- From paul.rock@teamaol.com Wed Apr 17 08:07:22 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA46921F85DA for ; Wed, 17 Apr 2013 08:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bySft95KynlA for ; Wed, 17 Apr 2013 08:07:22 -0700 (PDT) Received: from imr-da01.mx.aol.com (imr-da01.mx.aol.com [205.188.105.143]) by ietfa.amsl.com (Postfix) with ESMTP id DCD6A21F85DF for ; Wed, 17 Apr 2013 08:07:21 -0700 (PDT) Received: from AOLDTCMEI34.ad.aol.aoltw.net (aoldtcmei34.office.aol.com [10.180.121.151]) by imr-da01.mx.aol.com (Outbound Mail Relay) with ESMTP id 60D741C000083; Wed, 17 Apr 2013 11:07:21 -0400 (EDT) Received: from AOLMTCMES32.ad.aol.aoltw.net ([169.254.4.217]) by AOLDTCMEI34.ad.aol.aoltw.net ([10.180.121.151]) with mapi id 14.03.0123.003; Wed, 17 Apr 2013 11:07:21 -0400 From: "Rock, Paul" To: Terry Zink Thread-Topic: [dmarc-ietf] First wave of DMARC-compliant spam? Thread-Index: AQHOOvAJmuIS04wEdkKaNtMJNenO6JjZtiwAgAERhQA= Date: Wed, 17 Apr 2013 15:07:19 +0000 Message-ID: <89664ADA-BB50-427C-A33E-A2A94A783674@teamaol.com> References: <304a670afcd6477a9e8fbf754bfec209@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> In-Reply-To: <304a670afcd6477a9e8fbf754bfec209@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.8.193] Content-Type: multipart/alternative; boundary="_000_89664ADABB50427CA33EA2A94A783674teamaolcom_" MIME-Version: 1.0 Cc: "dmarc@ietf.org" , Andy Wilson Subject: Re: [dmarc-ietf] First wave of DMARC-compliant spam? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 15:07:23 -0000 --_000_89664ADABB50427CA33EA2A94A783674teamaolcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes and no. They'll likely abandon that domain in a day or two now that he'= s done his spam run, if they haven't already. Here at AOL we've seen 10+ mi= llion new domains pop up since the first major DMARC press release with rej= ect policies, which tells us that DMARC has been added to whatever scriptin= g tools they're using to setup new domains. Paul Rock Senior Programmer/Analyst | Mail Abuse Operations P: 703-265-5734 | C: 703-980-8380 AIM: PaulSRock 44900 Prentice Drive | Dulles, VA | 20166 On Apr 16, 2013, at 6:48 PM, Terry Zink > wrote: Doesn=92t this make it easy to filter in the future? Just add =93clientbasi= cs.com=94 to a domain blocklist? While spammers may be trying to see how reject policies are used currently,= they may just be trying to imitate a good sender and assume that authentic= ating with DKIM and/or SPF means easier deliverability to the inbox. -- Terry From: dmarc-bounces@ietf.org [mailto:dmarc-b= ounces@ietf.org] On Behalf Of Andy Wilson Sent: Tuesday, April 16, 2013 3:16 PM To: dmarc@ietf.org Subject: [dmarc-ietf] First wave of DMARC-compliant spam? I got some spam recently with interesting characteristics; it passed DKIM, = SPF and DMARC with a reject policy. Authentication-Results: mx.google.com; spf=3Dpass (google.com: domain of bounce@clientba= sics.com designates 142.234.235.23 as permi= tted sender) smtp.mail=3Dbounce@clientbasics.com; dkim=3Dpass header.i=3Dsupport@clientbasics.com; dmarc=3Dpass (p=3DREJECT dis=3Dnone) d=3Dclientbasics.com It's obvious spam, and ended up in my spam folder (even though AR says dis= =3Dnone) I wonder if spammers are starting to use DMARC to gather aggregate feedback= on policies applied by mailbox providers? I suppose it could be a compromised account, although following the WHOIS p= oints to an email address for mediatraffickers.com which looks spammy to me.. -- Regards Andy _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --_000_89664ADABB50427CA33EA2A94A783674teamaolcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9A653ACEEC87D940AA385A5E00CA5773@teamaol.com> Content-Transfer-Encoding: quoted-printable Yes and no. They'll likely abandon that domain in a day or two now that he'= s done his spam run, if they haven't already. Here at AOL we've seen 10+= ; million new domains pop up since the first major DMARC press release with= reject policies, which tells us that DMARC has been added to whatever scripting tools they're using to setup ne= w domains.

Paul Rock
Senior Programmer/Analyst | Mail= Abuse Operations
P: 703-265-5734 | C: 703-980-8380
AIM: PaulSRock
44900 Prentice Drive | Dulles, VA | 20166

On Apr 16, 2013, at 6:48 PM, Terry Zink <tzink@exchange.microsoft.com>
 wrote:

Doesn= =92t this make it easy to filter in the future? Just add =93= clientbasics.com=94 to a domain blocklist?
 <= /span>
While s= pammers may be trying to see how reject policies are used currently, they m= ay just be trying to imitate a good sender and assume that authenticating w= ith DKIM and/or SPF means easier deliverability to the inbox.
 <= /span>
-- Terr= y
 <= /span>
From:=  dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf Of Andy Wilson
Sent: Tuesday, Apr= il 16, 2013 3:16 PM
To: dmarc@ietf.org
Subject: [dmarc-ie= tf] First wave of DMARC-compliant spam?
 
I got some spam recently with interesting characteristics; it passed DKIM, = SPF and DMARC with a reject policy.
 
=
Authentication-Results: mx.google.com;

       spf=3Dpas=
s (google.com: domain of bounce@clientba=
sics.com designates 142.234.235.23 as permitted sender) smtp.mail=3Dbounce@clientbasics.com;


       dkim=3Dpa=
ss header.i=3Dsupport@clientbasics.com;


       dmarc=3Dp=
ass (p=3DREJECT dis=3Dnone) d=3Dclientbasics.com<=
/o:p>





It's obvious spam, and ended up in my spam folder (even though AR says dis=
=3Dnone)







 







I wonder if spammers are starting to use DMARC to gather aggregate feedback=
 on policies applied by mailbox providers?







 







I suppose it could be a compromised account, although following the WHOIS p=
oints to an email address for mediatraffickers.com<=
/a> which
 looks spammy to me..







 







 





-- 

Regards



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

--_000_89664ADABB50427CA33EA2A94A783674teamaolcom_-- From jgomez@seryrich.com Wed Apr 17 13:54:10 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8BF21E809D for ; Wed, 17 Apr 2013 13:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=-1.643, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz7p3Z240a-N for ; Wed, 17 Apr 2013 13:54:09 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFDB21E8089 for ; Wed, 17 Apr 2013 13:54:08 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 17 Apr 2013 22:54:06 +0200 Message-ID: <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> From: "J. Gomez" To: References: <20130417103918.3587.qmail@joyce.lan> Date: Wed, 17 Apr 2013 22:55:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 20:54:10 -0000 On Wednesday, April 17, 2013 12:39 PM [GMT+1=3DCET], John Levine wrote: > Perhaps we could try and think more clearly about providing service to > actual mail users and less about hypothetical spoofing attacks on > people who are not plausible spoof targets. It's pretty clear by now that DMARC is not about protecting actual email = users, but about protecting big brands from email spoofing their brand. Regards, J. Gomez From sweet@secondlook.com Wed Apr 17 14:21:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E120421E8097 for ; Wed, 17 Apr 2013 14:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REvUWgDAxicF for ; Wed, 17 Apr 2013 14:20:59 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id CC3FA21E8096 for ; Wed, 17 Apr 2013 14:20:57 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so1888860vea.1 for ; Wed, 17 Apr 2013 14:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=F83drrG1SD8GexAIJ5ZdXfP/l/lYJ3E66nKvM6SD+So=; b=HKUcjlUfSQ9F75jViKaSmwwunM5QkeSN2mmUIg69jAOVfbe4dq5NiSU6yVgM8mb8q9 y6VJlsXXxi4y3puw/iKOx+qQGypRRFtC5dcxEYdZbg5SceZ3HsxWsX1I94GAzd53PpJE NFWnJRWfJtu6zUJcim28dP7bK6ass+ALkFXDY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:content-type:x-gm-message-state; bh=F83drrG1SD8GexAIJ5ZdXfP/l/lYJ3E66nKvM6SD+So=; b=fCqeOQO/WhDExCFvZbopeOFxqbGEk3vnUmiF/cjDlHUnaMwdz2TQX+MN4WvD8bGTcK fxj75OJBrpE/WvC0mcqdGQhTpciyeRuZroHW/Uouc3Y0t49iUvDwTxAD58oLP+qD9SGJ tblZjk3tjsWpM4L3ddVD3y3buftDfYyfTvLIHxfLz8QRkNGdbrXOGrux9BW0HqI29zif RYX2rPAQVbqS6rL6PunDqxjGY2utIOV+2wp7+iZhCJ/lfppgBa8iIlxg9NeALg4jltMT 1OFBvgri63NVl1BxqfNI/9CfJHn4HomNi/xa1SHqEoDELhDaCLaQtGpQ+KvjmT6pxK4B twMw== X-Received: by 10.58.90.66 with SMTP id bu2mr6274873veb.29.1366233657176; Wed, 17 Apr 2013 14:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.152.71 with HTTP; Wed, 17 Apr 2013 14:20:37 -0700 (PDT) X-Originating-IP: [146.101.57.209] In-Reply-To: <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> From: John Sweet Date: Wed, 17 Apr 2013 14:20:37 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=089e013cc386d1078804da950f96 X-Gm-Message-State: ALoCoQk8p5pF6mmJd2cQ3c7jgMjW1izogO9lzYcufwD3GTOKZ7bERpco+EqMIe+PRZfD2j5bMjmH Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 21:21:07 -0000 --089e013cc386d1078804da950f96 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 17, 2013 at 1:55 PM, J. Gomez wrote: > On Wednesday, April 17, 2013 12:39 PM [GMT+1=CET], John Levine wrote: > > > Perhaps we could try and think more clearly about providing service to > > actual mail users and less about hypothetical spoofing attacks on > > people who are not plausible spoof targets. > > It's pretty clear by now that DMARC is not about protecting actual email > users, but about protecting big brands from email spoofing their brand. > ... except, of course, that when I get a phishing mail purporting to be from my bank, and I respond thinking it's them, and criminals gain access to my accounts because of it, it's not the bank that takes it in the shorts. It's me, the little guy. When I get yet another newspaper article forwarded by my mother, using the paper's website's "Send to a Friend" link, I actually don't particularly care if it's someone pretending to be her. Likewise, when I see your posts here on dmarc-ietf, I really don't care if it's you or someone pretending to be you. Some applications of email just aren't desperately in need of authentication. If my mother writes me personally saying she's stuck in London without her passport and needs me to wire her $1500 immediately, well, that's another matter. But she's unlikely to do that through a mailing list. J -- "Science is like an inoculation against charlatans who would have you believe whatever it is they tell you." (Neil DeGrasse Tyson) --089e013cc386d1078804da950f96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 17, 2013 at 1:55 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
On Wedn= esday, April 17, 2013 12:39 PM [GMT+1=3DCET], John Levine wrote:

> Perhaps we could try and think more clearly about providing service to=
> actual mail users and less about hypothetical spoofing attacks on
> people who are not plausible spoof targets.

It's pretty clear by now that DMARC is not about protecting actua= l email users, but about protecting big brands from email spoofing their br= and.

... except, of course, that when I get = a phishing mail purporting to be=20 from my bank, and I respond thinking it's them, and criminals gain acce= ss to my accounts because of it, it's=20 not the bank that takes it in the shorts. It's me, the little guy.
<= br>
When I get yet another newspaper article forwarded by my mother, using the=20 paper's website's "Send to a Friend" link, I actually don= 't particularly care if it's someone pretending to be her.=A0 Likewise, when I see you= r=20 posts here on dmarc-ietf, I really don't care if it's you or someon= e=20 pretending to be you. Some applications of email just aren't desperatel= y in need of authentication.

If my mother writes me=20 personally saying she's stuck in London without her passport and needs= =20 me to wire her $1500 immediately, well, that's another matter. But she&= #39;s unlikely to do that through a mailing list.

J

--
"Science is like an inoculation against charla= tans who would have you believe whatever it is they tell you." (Neil D= eGrasse Tyson)
--089e013cc386d1078804da950f96-- From MHammer@ag.com Wed Apr 17 15:00:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC241F0D12 for ; Wed, 17 Apr 2013 15:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kECebsuS50ih for ; Wed, 17 Apr 2013 15:00:23 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id ADAD01F0D10 for ; Wed, 17 Apr 2013 15:00:23 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Wed, 17 Apr 2013 18:00:22 -0400 From: "MH Michael Hammer (5304)" To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness Thread-Index: AQHOO1fgskOTRsgdJU2PZcR13NTSRJja5L8dgAAMp6A= Date: Wed, 17 Apr 2013 22:00:21 +0000 Message-ID: References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> In-Reply-To: <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 22:00:24 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of J. Gomez > Sent: Wednesday, April 17, 2013 4:56 PM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] making mail not work for your users, was the > endless mailing list silliness >=20 > On Wednesday, April 17, 2013 12:39 PM [GMT+1=3DCET], John Levine wrote: >=20 > > Perhaps we could try and think more clearly about providing service to > > actual mail users and less about hypothetical spoofing attacks on > > people who are not plausible spoof targets. >=20 > It's pretty clear by now that DMARC is not about protecting actual email > users, but about protecting big brands from email spoofing their brand. >=20 > Regards, >=20 > J. Gomez >=20 Having seen the damage done to individuals clicking on those phishing or ma= lware emails purporting to be from banks and other big brands I strongly di= sagree with your statement which appears somewhat dismissive. The further w= e can push the bad guys from being able to create and deliver fake emails t= hat look like communications from organizations, the better off we all are.= It doesn't necessarily solve the issue of fake emails claiming to be from = individuals at other types of domains but then individuals aren't likely to= have a legitimate reason to ask you to log into "your" bank portal and pro= vide credentials. Using strong email authentication, malicious site takedowns and other appro= aches we have significantly reduced the risk for people who receive email t= hat claims to be from our sites. Do we benefit? Of course we do. But failin= g to recognize the benefit to individual people is extremely short sighted.= I would argue that organizations not making these sorts of efforts are doi= ng a disservice to their customers and the community at large. The fact that SPF/DKIM/DMARC do not address every problem under the sun doe= s not mean that these authentication approaches aren't useful in protecting= endusers. Mike From superuser@gmail.com Wed Apr 17 15:40:54 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB0C21E80E6 for ; Wed, 17 Apr 2013 15:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.973 X-Spam-Level: X-Spam-Status: No, score=-3.973 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cFqVF1AZrBe for ; Wed, 17 Apr 2013 15:40:53 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3A821E80E5 for ; Wed, 17 Apr 2013 15:40:52 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so2197283wgh.24 for ; Wed, 17 Apr 2013 15:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XgitFRiwkptyotgsecCQAsueOuXpWEm1dmH+rTMhfJA=; b=RStbGrnVsmyssn2vWvispJWTDnAN4G7gMQPUrQ5Lp0gG6uMIwNqJcUTSITo/5WSYVu Z1Cd/0PoccC9HyVlhQVLX+z3mCewqZW3VIoOEoXDZJ+gaR9FmmI54HxZApDT4uBhYZok n7i67vB5RF7a9CR6DczUxwXL0IvcxPLkGNGcZroepnDgpapfqv+WxCspohaFDBdXfrOD x08mCymJb14kvCANRsrhpgvg8Bl22DmiWqntW/gpFAsyMFcuyhgpTiel63p0RYIpWpAg 5k6hamGsi7RhGymzFYoBcE4u48KWMxC/UJWNyjS/uCIXCShS/cvHuygdIHV0V34391pB OHsg== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr13978092wiz.14.1366238452256; Wed, 17 Apr 2013 15:40:52 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Wed, 17 Apr 2013 15:40:52 -0700 (PDT) In-Reply-To: References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> Date: Wed, 17 Apr 2013 15:40:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Sweet Content-Type: multipart/alternative; boundary=f46d04427194a0149604da962dda Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 22:40:54 -0000 --f46d04427194a0149604da962dda Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 17, 2013 at 2:20 PM, John Sweet wrote: > ... except, of course, that when I get a phishing mail purporting to be > from my bank, and I respond thinking it's them, and criminals gain access > to my accounts because of it, it's not the bank that takes it in the > shorts. It's me, the little guy. > It's both, really. It happens to the end user to the tune of what they have in the bank, and it happens to the bank to the tune of what their insurers have to cover in the aggregate for fraud claims. Those are relatively painful numbers to both parties. > When I get yet another newspaper article forwarded by my mother, using the > paper's website's "Send to a Friend" link, I actually don't particularly > care if it's someone pretending to be her. Likewise, when I see your posts > here on dmarc-ietf, I really don't care if it's you or someone pretending > to be you. Some applications of email just aren't desperately in need of > authentication. > > If my mother writes me personally saying she's stuck in London without her > passport and needs me to wire her $1500 immediately, well, that's another > matter. But she's unlikely to do that through a mailing list. > +1 to all of that. -MSK --f46d04427194a0149604da962dda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 17, 2013 at 2:20 PM, John Sweet <sweet@sec= ondlook.com> wrote:
... except, of course, that= when I get a phishing mail purporting to be=20 from my bank, and I respond thinking it's them, and criminals gain acce= ss to my accounts because of it, it's=20 not the bank that takes it in the shorts. It's me, the little guy.
<= /div>

It's both, really.=A0 It happens = to the end user to the tune of what they have in the bank, and it happens t= o the bank to the tune of what their insurers have to cover in the aggregat= e for fraud claims.=A0 Those are relatively painful numbers to both parties= .
=A0
When I get yet another newspaper article forwarded by my mother, using the=20 paper's website's "Send to a Friend" link, I actually don= 't particularly care if it's someone pretending to be her.=A0 Likewise, when I see you= r=20 posts here on dmarc-ietf, I really don't care if it's you or someon= e=20 pretending to be you. Some applications of email just aren't desperatel= y in need of authentication.

If my mother writes me=20 personally saying she's stuck in London without her passport and needs= =20 me to wire her $1500 immediately, well, that's another matter. But she&= #39;s unlikely to do that through a mailing list.

<= /div>
+1 to all of that.

-MSK
--f46d04427194a0149604da962dda-- From prvs=78192610fc=madkins@fb.com Wed Apr 17 16:21:49 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBBD21E809F for ; Wed, 17 Apr 2013 16:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGLvZHfAJ8iw for ; Wed, 17 Apr 2013 16:21:48 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) by ietfa.amsl.com (Postfix) with ESMTP id C3A4221E8043 for ; Wed, 17 Apr 2013 16:21:44 -0700 (PDT) Received: from pps.filterd (m0044008 [127.0.0.1]) by m0044008.ppops.net (8.14.5/8.14.5) with SMTP id r3HNHhN5004429; Wed, 17 Apr 2013 16:21:43 -0700 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=Qmfm3huQWzh1gCz/cc4OZ+fNsRX/x0wNwK3Tpi3KVEc=; b=lKhGFFSLQn5UZB7ojl5NayKw46eriLZoSLuTgA3g2IeBIxaOg8W+rg4qKLhmPjQNE8d1 9GGzI49YYIAuj4fbad/q6P26AZ8g72kQEOIAo88pMPj2xL7OIWS8wCvthc1YZsSLbd06 pLYip/lRCzAkeOX3VuAOVLr2gQjG0yHljdk= Received: from prn1-cmdf-dc01-fw1-nat.corp.tfbnw.net (prn1-cmdf-dc01-fw1-nat.corp.tfbnw.net [173.252.71.129] (may be forged)) by mx0a-00082601.pphosted.com with ESMTP id 1bsjnvk9re-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Apr 2013 16:21:43 -0700 Received: from PRN-MBX02-4.TheFacebook.com ([169.254.5.232]) by PRN-CHUB02.TheFacebook.com ([fe80::5de8:34:5a87:6990%12]) with mapi id 14.02.0328.011; Wed, 17 Apr 2013 16:21:42 -0700 From: Michael Adkins To: "J. Gomez" , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness Thread-Index: AQHOO8JR9vRFrwuRH0KvjBBDOAxIKg== Date: Wed, 17 Apr 2013 23:21:41 +0000 Message-ID: In-Reply-To: <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [192.168.16.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-17_08:2013-04-17, 2013-04-17, 1970-01-01 signatures=0 Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 17 Apr 2013 23:21:49 -0000 If your goal is to profit from identity theft by impersonating someone else, your best bet is to cast the widest net possible by impersonating the largest organizations that hold user authentication credentials. DMARC is an open version of products that were designed to combat that problem because it was/is the biggest phishing problem. If there was no value to actual email users, it is unlikely that the largest mailbox providers on the internet would have participated in it's creation or deployed it since there would have been nothing in it for them. If we would like to hear about the value to end users, we could probably get one of them to share some high level data about it. On 4/17/13 1:55 PM, "J. Gomez" wrote: >On Wednesday, April 17, 2013 12:39 PM [GMT+1=3DCET], John Levine wrote: > >> Perhaps we could try and think more clearly about providing service to >> actual mail users and less about hypothetical spoofing attacks on >> people who are not plausible spoof targets. > >It's pretty clear by now that DMARC is not about protecting actual email >users, but about protecting big brands from email spoofing their brand. > >Regards, > >J. Gomez > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From tzink@exchange.microsoft.com Wed Apr 17 17:12:18 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742D221E80AC for ; Wed, 17 Apr 2013 17:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX5C2VtydfZc for ; Wed, 17 Apr 2013 17:12:17 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3CB21E8043 for ; Wed, 17 Apr 2013 17:12:17 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.0.687.1; Thu, 18 Apr 2013 00:12:15 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.223]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.223]) with mapi id 15.00.0687.000; Thu, 18 Apr 2013 00:12:15 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness Thread-Index: AQHOO7F+BNWvrbHKO0mll0Lwoju7pZjbGtgQ Date: Thu, 18 Apr 2013 00:12:15 +0000 Message-ID: <8952faf08749497a831465e00de4785d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.157.4] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 00:12:18 -0000 >>> Likewise, when I see your posts here on dmarc-ietf, I really don't care if = it's you or someone pretending to be you. Some applications of email just a= ren't desperately in need of authentication. <<< So, are we basically on a discussion list that is in charge of moving forwa= rd the DMARC standard, but the discussion list itself can't authenticate wi= th DMARC? -- Terry From vesely@tana.it Thu Apr 18 04:44:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157CC21F8E98 for ; Thu, 18 Apr 2013 04:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WyCJNf3WauF for ; Thu, 18 Apr 2013 04:44:49 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A067721F8D03 for ; Thu, 18 Apr 2013 04:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366285487; bh=1/218BF57troELdRY11b0KPLpiRnlJeQxSwiuENMa7M=; l=1484; h=Date:From:To:References:In-Reply-To; b=bdRqcLOELELk+1WjyaU3t8HY6qPxVDAD0Avb6Cd354WSLui5wB96XQjbLjBHXrHZo rX2PkZKydHDB2RSwQ241YlP4BBtZMrKQr6dqa/XdRifDXmN0nQoAwply+s+9fcjPjx 6c7wYk3RDP365HHr+2j9qI/65sZbTW1zDXgDVDWc= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 18 Apr 2013 13:44:47 +0200 id 00000000005DC02B.00000000516FDCAF.00004142 Message-ID: <516FDCAE.9020106@tana.it> Date: Thu, 18 Apr 2013 13:44:46 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 11:44:51 -0000 On Thu 18/Apr/2013 00:00:21 +0200 MH Michael Hammer (5304) wrote: >> From: dmarc-bounces@ietf.org On Behalf Of J. Gomez >> >> It's pretty clear by now that DMARC is not about protecting actual email >> users, but about protecting big brands from email spoofing their brand. > > Having seen the damage done to individuals clicking on those > phishing or malware emails purporting to be from banks and other > big brands I strongly disagree with your statement which appears > somewhat dismissive. Spoofing a bank's brand can damage the users who become victims of phishing. That's what we aim at protecting from, however we call it. > I would argue that organizations not making these sorts of efforts > are doing a disservice to their customers and the community at > large. If courts argued like that, then phishing victims would be able to claim damages from non-compliant banks. Possibly, victims would need to prove that scam messages would have been blocked if the bank had complied. Therefore they had better choose receivers who enable DMARC rejection. That way, we can extend the argument that mailing list posters need a different email address: We'd need a different email address even for lurking. However, experience with RFC 6109 shows that even if people is compelled by law to get certified email accounts, they tend to forget them and use the ones that work instead.[1] [1] http://www.digitpa.gov.it/pec/statistichepec (in Italian) From barryleiba.mailing.lists@gmail.com Thu Apr 18 08:08:13 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F0821F8EBF for ; Thu, 18 Apr 2013 08:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKJZKb+woLKI for ; Thu, 18 Apr 2013 08:08:12 -0700 (PDT) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id BBC8B21F8E6B for ; Thu, 18 Apr 2013 08:08:05 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id w15so2530785vbf.32 for ; Thu, 18 Apr 2013 08:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=APBhZe0Mxny/2VjGHMLpj+mOt49A+EYkEfto+ryFVyY=; b=kgZpXArGJcuJXXHfYHCZqLZCIdOTENthG49Wz8djrN868JR1BS5jWnklIIyT7jIGe7 H3Ro5ageLCQfEomvbXztzJVKrgdi+Apzm1DwklHHH+66XPRbC4SE/7sXynp9q1Myyx4u PdjHFbGcbFEIcaHCdm7VNTdcpPbZR0D7EIf3VALVr3C2RX90ikGBes/ZKtqVaKP6ASqc k9AvJ+mWriWRLAJJU+LXO42eyrAOu6mgl/c4gChYLHhK6YoftQdxvsqu3+ioBPzuQfKb oIoOpq0L4vbXZlpXC5N4kT2J9eZyNOaVK2UbUpWeH39MbxLJ5QJqc9Kr1JFYIqYbhKaY EKnA== MIME-Version: 1.0 X-Received: by 10.220.110.205 with SMTP id o13mr8614994vcp.22.1366297685107; Thu, 18 Apr 2013 08:08:05 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Thu, 18 Apr 2013 08:08:04 -0700 (PDT) In-Reply-To: <8952faf08749497a831465e00de4785d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> <8952faf08749497a831465e00de4785d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Thu, 18 Apr 2013 11:08:04 -0400 X-Google-Sender-Auth: wLp6V9J-qeLRpIrX080mMtdEYB4 Message-ID: From: Barry Leiba To: Terry Zink Content-Type: text/plain; charset=ISO-8859-1 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 15:08:13 -0000 > So, are we basically on a discussion list that is in charge of moving forward the DMARC > standard, but the discussion list itself can't authenticate with DMARC? It wouldn't be the first time. People didn't post to using S/MIME, and does not use SMTP over TLS to send its messages. Do you really think this is a problem? Barry, just participating From tzink@exchange.microsoft.com Thu Apr 18 09:28:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2093F21F8FDA for ; Thu, 18 Apr 2013 09:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnoYQxZmVcdx for ; Thu, 18 Apr 2013 09:28:14 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0629D21F9003 for ; Thu, 18 Apr 2013 09:28:12 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.687.1; Thu, 18 Apr 2013 16:28:10 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.223]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.223]) with mapi id 15.00.0687.000; Thu, 18 Apr 2013 16:28:10 +0000 From: Terry Zink To: Barry Leiba Thread-Topic: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness Thread-Index: AQHOO7F+BNWvrbHKO0mll0Lwoju7pZjbGtgQgAD60QCAABUp4A== Date: Thu, 18 Apr 2013 16:28:09 +0000 Message-ID: <6a0c7b8baa6b4f59b8706d4c2a697161@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> <8952faf08749497a831465e00de4785d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.77] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-6c178e33-aecb-4786-8220-9afceeddbaf3.exchange.microsoft.com Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 16:28:20 -0000 >> So, are we basically on a discussion list that is in charge of moving=20 >> forward the DMARC standard, but the discussion list itself can't authent= icate with DMARC? > It wouldn't be the first time. People didn't post to us= ing S/MIME, and=20 > does not use SMTP over TLS to send its messages. Do you r= eally think this=20 > is a problem? No, I don't. The DMARC specification has a section that lists items that are out of scop= e (section 3.5). Section 2.2 explicitly that DMARC does not attempt to solv= e problems related to use of Cousin Domains or abuse of the RFC5322.From "d= isplay name." Seems like mailing lists like this are also out-of-scope. -- Terry From steven.m.jones@bankofamerica.com Thu Apr 18 12:14:05 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F89021F91F1 for ; Thu, 18 Apr 2013 12:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOfJwOSao0oC for ; Thu, 18 Apr 2013 12:14:04 -0700 (PDT) Received: from txdmzmailmx08.bankofamerica.com (txmx08.bankofamerica.com [171.161.160.26]) by ietfa.amsl.com (Postfix) with ESMTP id 666ED21F8F75 for ; Thu, 18 Apr 2013 12:14:04 -0700 (PDT) Received: from txdmzmailmx07.bankofamerica.com ([171.180.168.234]) by txdmzmailmx08.bankofamerica.com (8.14.5/8.14.5) with ESMTP id r3IJDZ3v011358; Thu, 18 Apr 2013 19:13:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bankofamerica.com; s=corp1210; t=1366312429; bh=bXci23l4dwAPOPdQ80MvwHs36zpNMRg32kwnCPRdJCY=; h=Date:From:Subject:In-reply-to:To:Message-id:MIME-version: Content-type:Content-transfer-encoding:References; b=uJe/33+MAG9jAv4+ULS65u7fbb7asIhIwmKrBOcq4ob0gg2Sv6CGfxR28WKwGSYXs avfjmZyQmCQ5M8OozdxC58nJp3Bfk9064ISqAp7IhkCMN13CKptrbGaBQvCmOo9iM2 r+0SzizywQIfO6H4A7MQ8pj5HXo/2vNwf2kH3Hm8= Received: from memtx2mta02.bankofamerica.com (memtx2mta02.bankofamerica.com [171.186.232.154]) by txdmzmailmx07.bankofamerica.com (8.14.5/8.14.5) with ESMTP id r3IJDVhC018454; Thu, 18 Apr 2013 19:13:34 GMT Date: Thu, 18 Apr 2013 19:13:31 +0000 From: "Jones, Steven M" In-reply-to: <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> X-Originating-IP: [171.206.135.17] To: "J. Gomez" , "dmarc@ietf.org" Message-id: <7EC008BFD9B40A4183ED77EEC394AB8D0D9A8356@smtp_mail.bankofamerica.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness Thread-index: AQHOO6249oJsk51uqEuNvvz5y1FXaZjcTqSg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-04-18_07:2013-04-18, 2013-04-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 19:14:05 -0000 On Wednesday, April 17, 2013 1:56 PM, J. Gomez wrote: > > On Wednesday, April 17, 2013 12:39 PM [GMT+1=CET], John Levine wrote: > > > Perhaps we could try and think more clearly about providing service to > > actual mail users and less about hypothetical spoofing attacks on > > people who are not plausible spoof targets. > > It's pretty clear by now that DMARC is not about protecting actual email users, but > about protecting big brands from email spoofing their brand. I must disagree. While we want to prevent our brands/domains from being used to exploit consumers, we also want to help prevent our customers from being exploited in general. If that weren't the case we would have been happy using proprietary services rather than promoting an open standard. We share our customers with many thousands of other organizations. Whether a customer is phished through abuse of our brand, or Facebook, or the local tax assessor doesn't really matter if it leads to their BofA accounts being drained and their PII stolen. While the larger brands have been a primary focus because they are most often successfully exploited and have an incentive to make disruptive changes, I have always felt that it was equally important that DMARC be available to protect any domain that needs it, of whatever size or scope. Yes there are some direct expenses when BofA makes good on fraud losses, and because of our scale it's not a small number. But it pales in comparison to the loss of customer confidence and reputational damage, not to mention the outright loss of customers, plus the loss of the Internet as a way to interact with our customers. I don't have survey data handy, but I'm pretty sure 4 out of 5 consumers don't miss having to go into physical bank locations between 10AM and 3PM, Tuesday through Thursday except random obscure holidays, every time they wanted to do something... DMARC is not a panacea, so it does not solve certain issues with mailing lists, any more than it solves display names or cousin domains. But it does provide a solution to a very real set of problems, and it can evolve in future. --Steve. Steven M Jones Messaging Strategy STI End User Computing Bank of America; Concord, California ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. From jgomez@seryrich.com Thu Apr 18 14:15:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BD821F8FD9 for ; Thu, 18 Apr 2013 14:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAn2-ruLJ6Uy for ; Thu, 18 Apr 2013 14:15:15 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id 96A4B21F8FCF for ; Thu, 18 Apr 2013 14:15:13 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 18 Apr 2013 23:15:11 +0200 Message-ID: <627428129C6541E9B6A205C502DA6500@fgsr.local> From: "J. Gomez" To: References: <20130409164432.68830.qmail@joyce.lan><1890B81F63B44F1B8EAA345BA9D71FD5@fgsr.local><7044732.h21xgsJhV9@scott-latitude-e6320><9623C31B27CB4CC785D82BA7663483F6@fgsr.local> Date: Thu, 18 Apr 2013 23:16:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: Re: [dmarc-ietf] the endless mailing list silliness, was not about outsourcing strategies X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 21:15:15 -0000 Murray S. Kucherawy wrote: > On Tue, Apr 16, 2013 at 2:47 PM, J. Gomez wrote: >=20 > > How widespread do you thing that this not following DMARC's > > "p=3Dreject" to the letter could become when DMARC is (if at all) > > massively deployed in the field? =20 >=20 > Hopefully every receiver also gets what those sections actually say > and not your ultra-strict interpretation.=20 >=20 > > Don't you see here a potential vulnerability in DMARC, not in the > > letter of the standard but on how it may be implemented in the = field, > > therefore opening a door for phishing email to sneak past = "p=3Dreject"? >=20 > No. Time will tell. Right now, you can get email that fails DMARC to land into the user's = mailbox in Gmail just by inserting the right amount of list-related fake = headers... Regards, J. Gomez From jgomez@seryrich.com Thu Apr 18 14:48:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103C221F904B for ; Thu, 18 Apr 2013 14:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[AWL=-0.296, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9qZ37Q-Psj9 for ; Thu, 18 Apr 2013 14:48:01 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) by ietfa.amsl.com (Postfix) with ESMTP id A9F1921E803A for ; Thu, 18 Apr 2013 14:48:00 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 18 Apr 2013 23:47:59 +0200 Message-ID: <36F7F4EB73874D229804122178606BB6@fgsr.local> From: "J. Gomez" To: Date: Thu, 18 Apr 2013 23:49:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Subject: [dmarc-ietf] Another minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 21:48:02 -0000 Hello all. The DMARC Requirement #7 in Section 3.4 reads: Message disposition requests via DMARC override those requested by any other public mechanism. The old draft in its pre-IETF track ( = http://dmarc.org/draft-dmarc-base-00-02.txt ) said in the fourth = paragraph in Section 7: DMARC-compliant Mail Receivers MUST disregard any mail directive discovered as part of an authentication mechanism (e.g., ADSP, SPF) where a DMARC policy is also discovered. {R7} However, now the current DMARC draft ( = https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text= =3D1 ) says in that same spot: DMARC-compliant Mail Receivers SHOULD disregard any mail directive discovered as part of an authentication mechanism (e.g., ADSP, SPF) where a DMARC policy is also discovered that specifies a policy other than "none". {R7} It can be argued that both MUST and SHOULD fall into {R7}, but it is = dubious that excepting the policy of "p=3Dnone" from being subjected to = either that MUST or SHOULD makes it also fall into {R7}. The new text = effectively excepts "p=3Dnone" from Requirement #7, but Requirement #7 = does not seem to allow for that. Regards, J. Gomez From sklist@kitterman.com Thu Apr 18 15:34:37 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7421F90FC for ; Thu, 18 Apr 2013 15:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv4IZYmcXFJe for ; Thu, 18 Apr 2013 15:34:36 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5538A21F90BB for ; Thu, 18 Apr 2013 15:34:33 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B644D20E40D4; Thu, 18 Apr 2013 18:34:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366324472; bh=VF0l5KK7wNLL9G98F8LWmUjL57fPVlOrT5AEL/cuWjE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=akj5vK2COhWBXax57QEg8ulyFV8Z7LJgbYTj8LXDk95c4T4xzqI2GNfqPPtc/5LfW sQhpe/oCJYXEUWB9LlpRD0Or96uWA+giMIJa0u2lxdExyvpdILxb7GgzwMNu+tQ0yx xvzJ6zNjkFicu4W5agUW6+C5mXLJPj1BNLCrHeyk= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 9814D20E4090; Thu, 18 Apr 2013 18:34:32 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 18 Apr 2013 18:34:31 -0400 Message-ID: <4572267.kM8dzXsS3G@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: <36F7F4EB73874D229804122178606BB6@fgsr.local> References: <36F7F4EB73874D229804122178606BB6@fgsr.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] Another minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 18 Apr 2013 22:34:37 -0000 On Thursday, April 18, 2013 11:49:35 PM J. Gomez wrote: > Hello all. > > The DMARC Requirement #7 in Section 3.4 reads: > > Message disposition requests via DMARC override those requested > by any other public mechanism. > > The old draft in its pre-IETF track ( > http://dmarc.org/draft-dmarc-base-00-02.txt ) said in the fourth paragraph > in Section 7: > > DMARC-compliant Mail Receivers MUST disregard any mail directive > discovered as part of an authentication mechanism (e.g., ADSP, SPF) > where a DMARC policy is also discovered. {R7} > > However, now the current DMARC draft ( > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 > ) says in that same spot: > > DMARC-compliant Mail Receivers SHOULD disregard any mail directive > discovered as part of an authentication mechanism (e.g., ADSP, SPF) > where a DMARC policy is also discovered that specifies a policy other > than "none". {R7} > > It can be argued that both MUST and SHOULD fall into {R7}, but it is dubious > that excepting the policy of "p=none" from being subjected to either that > MUST or SHOULD makes it also fall into {R7}. The new text effectively > excepts "p=none" from Requirement #7, but Requirement #7 does not seem to > allow for that. If there's no DMARC policy (none), there's nothing to override. The change is a welcome improvement in the spec. Under the old version it wasn't possible to publish DMARC records for testing without affecting existing processing. Scott K From superuser@gmail.com Thu Apr 18 21:36:40 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816BE21F93A6 for ; Thu, 18 Apr 2013 21:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2g+PGm2bOmC for ; Thu, 18 Apr 2013 21:36:40 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E066A21F93BE for ; Thu, 18 Apr 2013 21:36:35 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t57so3005737wey.4 for ; Thu, 18 Apr 2013 21:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=s9tDvKWQ0BNOu2ZiDGany6PfTHi8rubKzA4YpirJyNE=; b=SmVjliwmjLN488uNREA4W+mHne7WEMxaQX3k/8AgAe1JuI1VhfxolLNqbZHXS9jzoA vWfDd6EbRLSGK5G4+1Kb74jecVRYbH3034KF0RqR/0carH8qR9yUYB8FaAxc7kA7VZtm QiWbF8Gf7tOtUKf5ak3FV4tof5BvZHyp+JqxK2A+ZF8Ey3coA1EiyLW78f5z4O4LmDbx gut8L0SUb/Abt4QLON/jc1xsjxIzzz5OuV41TA7YD1wJAVgCJS68IQa17zBbcSC4z76K 8xKc8RjMk83bg3jsDTnBkJP3KmCANi21xv0fm/dcvNRFUugIUCUug/eXpa+Vrph06Kdk AlbQ== MIME-Version: 1.0 X-Received: by 10.180.80.3 with SMTP id n3mr302922wix.20.1366346195081; Thu, 18 Apr 2013 21:36:35 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Thu, 18 Apr 2013 21:36:34 -0700 (PDT) In-Reply-To: <4572267.kM8dzXsS3G@scott-latitude-e6320> References: <36F7F4EB73874D229804122178606BB6@fgsr.local> <4572267.kM8dzXsS3G@scott-latitude-e6320> Date: Thu, 18 Apr 2013 21:36:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d041825389920f404daaf438e Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Another minor contradiction in the draft specification X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 19 Apr 2013 04:36:40 -0000 --f46d041825389920f404daaf438e Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 18, 2013 at 3:34 PM, Scott Kitterman wrote: > If there's no DMARC policy (none), there's nothing to override. The > change is > a welcome improvement in the spec. Under the old version it wasn't > possible > to publish DMARC records for testing without affecting existing processing. > +1. Moreover, as was pointed out on another thread, we did decide along the way that some of our requirements were not exactly what we needed in the end. Maybe this is another one we should update or simply remove. -MSK --f46d041825389920f404daaf438e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 18, 2013 at 3:34 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
If there's no DMARC policy (none), there= 's nothing to override. =A0The change is
a welcome improvement in the spec. =A0Under the old version it wasn't p= ossible
to publish DMARC records for testing without affecting existing processing.=

+1.

Moreover, as was pointed ou= t on another thread, we did decide along the way that some of our requireme= nts were not exactly what we needed in the end.=A0 Maybe this is another on= e we should update or simply remove.

-MSK

--f46d041825389920f404daaf438e-- From MHammer@ag.com Fri Apr 19 07:38:00 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FC121F955A for ; Fri, 19 Apr 2013 07:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl4huU68SoIC for ; Fri, 19 Apr 2013 07:37:56 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7343321F9530 for ; Fri, 19 Apr 2013 07:37:56 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Fri, 19 Apr 2013 10:37:55 -0400 From: "MH Michael Hammer (5304)" To: Alessandro Vesely , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness Thread-Index: AQHOPColntZYBGA1EUeqGPZtSdMvy5jdngVQ Date: Fri, 19 Apr 2013 14:37:55 +0000 Message-ID: References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> <516FDCAE.9020106@tana.it> In-Reply-To: <516FDCAE.9020106@tana.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.254.232] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 19 Apr 2013 14:38:00 -0000 > -----Original Message----- > From: dmarc-bounces@ietf.org [mailto:dmarc-bounces@ietf.org] On Behalf > Of Alessandro Vesely > Sent: Thursday, April 18, 2013 7:45 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] making mail not work for your users, was the > endless mailing list silliness >=20 > On Thu 18/Apr/2013 00:00:21 +0200 MH Michael Hammer (5304) wrote: > >> From: dmarc-bounces@ietf.org On Behalf Of J. Gomez > >> > >> It's pretty clear by now that DMARC is not about protecting actual > >> email users, but about protecting big brands from email spoofing their > brand. > > > > Having seen the damage done to individuals clicking on those phishing > > or malware emails purporting to be from banks and other big brands I > > strongly disagree with your statement which appears somewhat > > dismissive. >=20 > Spoofing a bank's brand can damage the users who become victims of > phishing. That's what we aim at protecting from, however we call it. >=20 > > I would argue that organizations not making these sorts of efforts are > > doing a disservice to their customers and the community at large. >=20 > If courts argued like that, then phishing victims would be able to claim > damages from non-compliant banks. Possibly, victims would need to prove > that scam messages would have been blocked if the bank had complied. > Therefore they had better choose receivers who enable DMARC rejection. >=20 Ethics !=3D law.=20 > That way, we can extend the argument that mailing list posters need a > different email address: We'd need a different email address even for > lurking. However, experience with RFC 6109 shows that even if people is > compelled by law to get certified email accounts, they tend to forget the= m > and use the ones that work instead.[1] >=20 > [1] http://www.digitpa.gov.it/pec/statistichepec (in Italian) > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From tim@eudaemon.net Sat Apr 20 05:57:09 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FA621F9057 for ; Sat, 20 Apr 2013 05:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5weU-A08Bc1l for ; Sat, 20 Apr 2013 05:57:07 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id D249F21F9019 for ; Sat, 20 Apr 2013 05:57:07 -0700 (PDT) Received: from [10.0.1.7] (sctv-72-100.mounet.com [216.145.72.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 14683CB46 for ; Sat, 20 Apr 2013 08:57:45 -0400 (EDT) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8598319F-D23B-4A5D-9896-0D2CF5D27F94@eudaemon.net> Date: Sat, 20 Apr 2013 08:57:07 -0400 To: "dmarc@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [dmarc-ietf] hints for receivers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 12:57:09 -0000 I like the spirit J. Gomez's "l=3D{yes,no,dunno}" proposal, but have = been struggling 'cause I don't think it would be effective in the wild. While grinding up a batch of coffee beans, it struck me that = "l=3D{yes,no,dunno}" is part of a larger category of "hints for = receivers". As such, would receivers make use of high-level = sender-provided descriptors of email category? For example, "l=3D{yes,no,dunno}" could be realized with a = "category=3D{transactional,newsletter,organization/corporate}" type of = tag. In this way, receivers would use the hint = "category=3Dtransactional", see that the message came over a mailing = list (transactional email shouldn't come through a mailing list, = right?), and act appropriately. =3D- Tim PS. The "l=3D{yes,no,dunno}" tag attempts to prescribe whether or not a = domain is excepted to arrive through a "list". =46rom the receiver PoV, = is a description of the content of the email more generally useful? From superuser@gmail.com Sat Apr 20 10:08:23 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7745A21F8759 for ; Sat, 20 Apr 2013 10:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFNDpIlxFJ7V for ; Sat, 20 Apr 2013 10:08:18 -0700 (PDT) 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 4A5D021F86F2 for ; Sat, 20 Apr 2013 10:08:18 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id p43so1601501wea.28 for ; Sat, 20 Apr 2013 10:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IWGhpxzHmZ18+lRG5NloOemjMlg9N20+y+56lyAAPzo=; b=ZnPEBckABM65QZTPAnhW1iVMpvlFTfx+sxenGlS3nvt+zuviH306MLOnFrVTLCAodG XitJCunBj14A+QAfxmz+B7fFuwv57rwjMjBJhs6Gko0DvNECv9qM8UQ4W7bqpque+cuC Ka3lFEzkMEh1++bKjwTc3RHVQbaNjuic0/okOk7mrLza0riffyH2nMBcxGQcBaj+2x1h ahWP6ic34jbpEXsGaQjzcxFUaKsUS+m58O3AzQBR0NoTvhbpBiyN/ojBFgD5Om2ELS1P 7LCQ2TZZjWRfRlh8SEzC4zb4sEbI+Q/Z/e/WM5AmbWa3UAMUX4xKWSTvkcJ00OE4DXNI R+Zw== MIME-Version: 1.0 X-Received: by 10.180.79.69 with SMTP id h5mr14289054wix.14.1366477697452; Sat, 20 Apr 2013 10:08:17 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sat, 20 Apr 2013 10:08:17 -0700 (PDT) In-Reply-To: <8598319F-D23B-4A5D-9896-0D2CF5D27F94@eudaemon.net> References: <8598319F-D23B-4A5D-9896-0D2CF5D27F94@eudaemon.net> Date: Sat, 20 Apr 2013 10:08:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tim Draegen Content-Type: multipart/alternative; boundary=f46d043c062ec0115804dacde1e8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] hints for receivers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 17:08:24 -0000 --f46d043c062ec0115804dacde1e8 Content-Type: text/plain; charset=ISO-8859-1 This is reminiscent of VBR (RFC5518). It would be interesting to find out how much uptake of that there's been. Either way, I don't see this as something that could go in the base spec. However, DMARC was made extensible, so if there can be shown a demand for this among both senders and receivers, which is to say (as you asked) if there are receivers willing to make use of it, then it could be developed as an extension. I imagine, though, that if such receivers existed, we'd have heard from them by now. The preferred practice appears to be for receivers to identify lists using their own methods. -MSK On Sat, Apr 20, 2013 at 5:57 AM, Tim Draegen wrote: > I like the spirit J. Gomez's "l={yes,no,dunno}" proposal, but have been > struggling 'cause I don't think it would be effective in the wild. > > While grinding up a batch of coffee beans, it struck me that > "l={yes,no,dunno}" is part of a larger category of "hints for receivers". > As such, would receivers make use of high-level sender-provided > descriptors of email category? > > For example, "l={yes,no,dunno}" could be realized with a > "category={transactional,newsletter,organization/corporate}" type of tag. > In this way, receivers would use the hint "category=transactional", see > that the message came over a mailing list (transactional email shouldn't > come through a mailing list, right?), and act appropriately. > > =- Tim > > PS. The "l={yes,no,dunno}" tag attempts to prescribe whether or not a > domain is excepted to arrive through a "list". From the receiver PoV, is a > description of the content of the email more generally useful? > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --f46d043c062ec0115804dacde1e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is reminiscent of VBR (RFC5518).=A0 It woul= d be interesting to find out how much uptake of that there's been.
<= br>
Either way, I don't see this as something that could go in the= base spec.=A0 However, DMARC was made extensible, so if there can be shown= a demand for this among both senders and receivers, which is to say (as yo= u asked) if there are receivers willing to make use of it, then it could be= developed as an extension.

I imagine, though, that if such receivers existed, we'd have heard = from them by now.=A0 The preferred practice appears to be for receivers to = identify lists using their own methods.

-MSK


On Sat, Apr 20, 2013 at 5:57 AM, Tim Dra= egen <tim@eudaemon.net> wrote:
I like the spirit J. Gomez's "l=3D{yes,no,dunno}" proposal, b= ut have been struggling 'cause I don't think it would be effective = in the wild.

While grinding up a batch of coffee beans, it struck me that "l=3D{yes= ,no,dunno}" is part of a larger category of "hints for receivers&= quot;. =A0As such, would receivers make use of high-level sender-provided d= escriptors of email category?

For example, "l=3D{yes,no,dunno}" could be realized with a "= category=3D{transactional,newsletter,organization/corporate}" type of = tag. =A0In this way, receivers would use the hint "category=3Dtransact= ional", see that the message came over a mailing list (transactional e= mail shouldn't come through a mailing list, right?), and act appropriat= ely.

=3D- Tim

PS. =A0The "l=3D{yes,no,dunno}" tag attempts to prescribe whether= or not a domain is excepted to arrive through a "list". =A0From = the receiver PoV, is a description of the content of the email more general= ly useful?

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

--f46d043c062ec0115804dacde1e8-- From sklist@kitterman.com Sat Apr 20 10:21:45 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3769D21F8F5D for ; Sat, 20 Apr 2013 10:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+V6z1YCjrYb for ; Sat, 20 Apr 2013 10:21:44 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6221D21F8F4A for ; Sat, 20 Apr 2013 10:21:44 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DE4D120E40D2; Sat, 20 Apr 2013 13:21:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366478503; bh=miz3Jq8Ki6VmYf9CLoJ8I2lGjanGsvUkGmVQ5NKtio0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=bpPzGB5Pd924/1pM8gR2RZf9xbIIFdK8xf/DQnNNRnCV/FC16XgO85PRb3ZxionHh IsdHeZp3CfHLjUW09A5bM5VbtQFZL5zZvYCAbmipLnqT5vaihFFlOUrI/1G4ztJwN8 b2g5AuQ8qllXH1lfO3rh7Jq+ltFGwBeXJhoWJlBg= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id C1AC220E409E; Sat, 20 Apr 2013 13:21:43 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 20 Apr 2013 13:21:42 -0400 Message-ID: <1581179.AB75fythCq@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <8598319F-D23B-4A5D-9896-0D2CF5D27F94@eudaemon.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] hints for receivers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 17:21:45 -0000 Most of the current deployment is at large providers that can do significant data analysis to effectively identify lists. As a small domain, there's no way I can do the same. If there were a protocol method to share this information, either among trusted receivers or via 'hints', it could be useful to smaller providers that don't have the scale to mine the data themselves. Scott K On Saturday, April 20, 2013 10:08:17 AM Murray S. Kucherawy wrote: > This is reminiscent of VBR (RFC5518). It would be interesting to find out > how much uptake of that there's been. > > Either way, I don't see this as something that could go in the base spec. > However, DMARC was made extensible, so if there can be shown a demand for > this among both senders and receivers, which is to say (as you asked) if > there are receivers willing to make use of it, then it could be developed > as an extension. > > I imagine, though, that if such receivers existed, we'd have heard from > them by now. The preferred practice appears to be for receivers to > identify lists using their own methods. > > -MSK > > On Sat, Apr 20, 2013 at 5:57 AM, Tim Draegen wrote: > > I like the spirit J. Gomez's "l={yes,no,dunno}" proposal, but have been > > struggling 'cause I don't think it would be effective in the wild. > > > > While grinding up a batch of coffee beans, it struck me that > > "l={yes,no,dunno}" is part of a larger category of "hints for receivers". > > > > As such, would receivers make use of high-level sender-provided > > > > descriptors of email category? > > > > For example, "l={yes,no,dunno}" could be realized with a > > "category={transactional,newsletter,organization/corporate}" type of tag. > > > > In this way, receivers would use the hint "category=transactional", see > > > > that the message came over a mailing list (transactional email shouldn't > > come through a mailing list, right?), and act appropriately. > > > > =- Tim > > > > PS. The "l={yes,no,dunno}" tag attempts to prescribe whether or not a > > domain is excepted to arrive through a "list". From the receiver PoV, is > > a > > description of the content of the email more generally useful? > > > > _______________________________________________ > > dmarc mailing list > > dmarc@ietf.org > > https://www.ietf.org/mailman/listinfo/dmarc From superuser@gmail.com Sat Apr 20 10:49:15 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DFF21F8521 for ; Sat, 20 Apr 2013 10:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZjIG48js+5v for ; Sat, 20 Apr 2013 10:49:14 -0700 (PDT) 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 0638121F81FF for ; Sat, 20 Apr 2013 10:49:02 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id l13so2588207wie.1 for ; Sat, 20 Apr 2013 10:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=m5VYDNUZCQjWvLjkzdo2ix3Ferxc5qeeuM6O+oBXr1s=; b=xQZKn8D93IPJiCqVv74Zt2gHapd7xfM8k2CP5mv2vJzYV1IiUtFHYLjuzqPEOekEY4 CpLzYLsK8YQCin7CoEmvaI7OXGOdLsvX6lAMV/dioHsrXEqtGkNn8sddUZtOf9wuqwsi mQkdTMH625fhjy/kgzEhg+mrwVgfYKSMKsC0aE8kluS7AkMq4KqQOPC3Fpv9cizl/0PK Y6Aaz5XC2JuYhEFejwpsfGC50dF5RLwgYgVfy8iOJnEcBUFJU8k+d1KKU3wwWfPDqKuE 39JLnG3V/5JTJoWyXOr5Ag4+WeazW3rYEwW447lHZoYQ+x5xc2/6lYupvUuU2adaQ5TX gNyw== MIME-Version: 1.0 X-Received: by 10.180.84.162 with SMTP id a2mr35553232wiz.14.1366480140894; Sat, 20 Apr 2013 10:49:00 -0700 (PDT) Received: by 10.180.36.176 with HTTP; Sat, 20 Apr 2013 10:49:00 -0700 (PDT) In-Reply-To: <1581179.AB75fythCq@scott-latitude-e6320> References: <8598319F-D23B-4A5D-9896-0D2CF5D27F94@eudaemon.net> <1581179.AB75fythCq@scott-latitude-e6320> Date: Sat, 20 Apr 2013 10:49:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d044271946436d004dace7373 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] hints for receivers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 17:49:15 -0000 --f46d044271946436d004dace7373 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 20, 2013 at 10:21 AM, Scott Kitterman wrote: > Most of the current deployment is at large providers that can do > significant > data analysis to effectively identify lists. As a small domain, there's > no way > I can do the same. > > If there were a protocol method to share this information, either among > trusted receivers or via 'hints', it could be useful to smaller providers > that > don't have the scale to mine the data themselves. > Why would you, as a small-scale receiver, believe what an unfamiliar sender claims about whether its traffic transits lists, ultimately meaning "don't be so strict with this message"? That seems a big loophole with little benefit to me, regardless of your size, given the nature of the problem space; malicious senders will always use it, and good senders that use it will be spoofed more easily. --f46d044271946436d004dace7373 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 20, 2013 at 10:21 AM, Scott Kitterman <skl= ist@kitterman.com> wrote:
Most of the current deployment is at large p= roviders that can do significant
data analysis to effectively identify lists. =A0As a small domain, there= 9;s no way
I can do the same.

If there were a protocol method to share this information, either among
trusted receivers or via 'hints', it could be useful to smaller pro= viders that
don't have the scale to mine the data themselves.
=
Why would you, as a small-scale receiver, believe what an un= familiar sender claims about whether its traffic transits lists, ultimately= meaning "don't be so strict with this message"?=A0 That seem= s a big loophole with little benefit to me, regardless of your size, given = the nature of the problem space; malicious senders will always use it, and = good senders that use it will be spoofed more easily.

--f46d044271946436d004dace7373-- From dcrocker@gmail.com Sat Apr 20 11:03:16 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A68621F8B5F for ; Sat, 20 Apr 2013 11:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-1.377, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaIht23Pk6fn for ; Sat, 20 Apr 2013 11:03:15 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6EACC21F859D for ; Sat, 20 Apr 2013 11:03:15 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wc20so1396505obb.19 for ; Sat, 20 Apr 2013 11:03:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Iq/p1C4fdrZyDjQ1vS1ydwaWTviKmh9lwJ10XPBeIBs=; b=DB3duHpAkYY+Wy0tT2Zcmw7qVZ3fAvVgmpTajoWnF9E+GDJfp0q39RznFgDS71Ayib z9NzmLiNCvlB8r05ATirFL3jAiYc7oVa9QFBIpSqBFgrJeCkkt8L4tAn0AEGO4hyKOaD LsJeXEgb/q+/pSebGbIB4OhBFnyllpOHZRnsqSI3guSCb0EXYqhIlKxtxVrYr27n1nYL Y2BdThy3kN3uIEFG+aiMgTT5Tv9FpCkCW1MDFX012KfOTrGPupFtZsRn9m4gWTO4qPm/ zm8MNRvIhnu3mF9LLwotVw1W47x1dtig387ZKPPtLuum9X9Ty36xVlB7HZ8Bn39GOVPp uKiQ== X-Received: by 10.182.92.133 with SMTP id cm5mr6383312obb.73.1366480994938; Sat, 20 Apr 2013 11:03:14 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id dt3sm10728511obb.12.2013.04.20.11.03.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 11:03:14 -0700 (PDT) Message-ID: <5172D859.1090101@gmail.com> Date: Sat, 20 Apr 2013 11:03:05 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Tim Draegen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally inform receivers about mailing list activity X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 18:03:16 -0000 On 4/14/2013 7:08 PM, Tim Draegen wrote: > On Apr 12, 2013, at 5:35 PM, J. Gomez wrote: >> 4. (Uselessness problem) This proposition achieves nothing. >> >> --> True. It's not the intent of the "l=" tag to achieve anything nor to convey policy from Sender to Receiver. The "l=" tag merely conveys additional information from Sender to Receiver, and the Receiver is free to consume it as he wishes or to disregard it altogether. > > > This here. If the tag doesn't achieve anything and could very well be wrong ('cause there is no measurable impact to getting it right), it'll just add noise to a receiver's decision making, and therefore {all of your other counter-arguments}. > > To game this out, *IF* this tag existed and was accurately used, as a receiver I'd still have to figure out what sources are mailing lists in order to make the extra "l={yes,no,dunno}" tag useful. Let's say I have perfect mailing list knowledge, what then am I supposed to do with email coming through a mailing list from a domain with the "l=no" tag? If the answer is "nothing", then why is this tag even there for me to look at? > > I guess I'm left with "How does this make anything better?" > > IMO Michael Adkins wrote it best: > >> 7. Operational Issue >> This problem is better solved by making data about legitimate mailing >> lists publicially available so everyone can apply local policy overrides >> consistently. Anything that smacks of hints, heuristics, guessing and statistics invites more noise into the system. As a rule, that's not good for standards-based activities and are best left to outside processes. The underlying issue here seems to be a) message handling by non-transparent intermediaries, and b) their not necessarily playing in the dmarc sandbox. I think there is nothing useful that can be done in terms of DMARC standards for the latter. If they break stuff and won't help fix it, the topic is done. For the former, it sounds like a case of wanting some kind of transitive trust, which moves us back to having the mediator do inbound dmarc validation, record it into the A-R header field(?) and then ensure SPF and DKIM authentication and maybe dmarc publishing, too. It might also make sense to add some sort of "I am a mediator who processed this message and assert the following truths..." and then include that field in the dkim signature hash. That is, to define some additional authentication semantics for mediators, if they wish to play in this sandbox. The presence of this extra header field asserts a set of semantics and the dkim signature validates its presence (depending upon the reputation of the signing mediator's domain, of course.) This provides a kind of authenticated audit trail, but of course still leaves open the question of how it would be handled by receivers. d/ -- Dave Crocker bbiw.net From sklist@kitterman.com Sat Apr 20 11:20:19 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFCD21F8C69 for ; Sat, 20 Apr 2013 11:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfWstsx423xq for ; Sat, 20 Apr 2013 11:20:17 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id BCBCB21F8E36 for ; Sat, 20 Apr 2013 11:20:15 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 420BB20E40D2; Sat, 20 Apr 2013 14:20:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366482015; bh=EXgbJbFBUXaLpLZ3UdTK5+PjyRWkei+QHqfpIM7960E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mLEQQcvpebX4arg7SKFj+YP4nQgNBdRYSMTPodSsoLPOanKpTweziauJ3yx59PwhA TyhURabIjRlS0sBfZyMlIkLT3Uh1u2Bz/mwUPDanXCdi8GjjlTgdhXiVcnNczalrtL kAKUM1a4LYyWB/njhWJXoc8pO9g3peZOlihz6LWw= 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 mailout02.controlledmail.com (Postfix) with ESMTPSA id 262BA20E409E; Sat, 20 Apr 2013 14:20:04 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 20 Apr 2013 14:20:03 -0400 Message-ID: <5757433.jhuOLl2NjA@scott-latitude-e6320> User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; ) In-Reply-To: References: <8598319F-D23B-4A5D-9896-0D2CF5D27F94@eudaemon.net> <1581179.AB75fythCq@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [dmarc-ietf] hints for receivers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 18:20:19 -0000 On Saturday, April 20, 2013 10:49:00 AM Murray S. Kucherawy wrote: > On Sat, Apr 20, 2013 at 10:21 AM, Scott Kitterman wrote: > > Most of the current deployment is at large providers that can do > > significant > > data analysis to effectively identify lists. As a small domain, there's > > no way > > I can do the same. > > > > If there were a protocol method to share this information, either among > > trusted receivers or via 'hints', it could be useful to smaller providers > > that > > don't have the scale to mine the data themselves. > > Why would you, as a small-scale receiver, believe what an unfamiliar sender > claims about whether its traffic transits lists, ultimately meaning "don't > be so strict with this message"? That seems a big loophole with little > benefit to me, regardless of your size, given the nature of the problem > space; malicious senders will always use it, and good senders that use it > will be spoofed more easily. I probably wouldn't. My point wasn't to advance a particular solution, but to suggest that the experience base with how large providers with extensive data mining capability prefer to do things probably isn't universally applicable. I solution involving receiver collaboration is more likely to be useful. Scott K From sweet@secondlook.com Sat Apr 20 12:54:20 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB3F21F85CB for ; Sat, 20 Apr 2013 12:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBtB0rQRYqPu for ; Sat, 20 Apr 2013 12:54:18 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 035DB21F85C9 for ; Sat, 20 Apr 2013 12:54:17 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hr11so4991369vcb.36 for ; Sat, 20 Apr 2013 12:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=hbmWGNXVoma6jhqrueXWWLbO0afrD4UaQP2QErtwg+g=; b=bw0j9D0Oc+9nTTx18GHAdbTbycjI42V3eeB0meV/a9zsaO8sORX0E7+j0PRHBFDzi2 76h2uOyvMnvusc5ZIzyh7gkir9luKUtXIyRntBQm4xtj10aLXL82NCUnnCtDEL6NXn2P KFjtIrlLCanfS6MDCh2d3676q+VrgO3i+bX38= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:content-type:x-gm-message-state; bh=hbmWGNXVoma6jhqrueXWWLbO0afrD4UaQP2QErtwg+g=; b=JanZfJJfyVNpBRW4jQ+u5Xs6M+jA3ygYyTP7fGiK8ZQytxIgbJdHWaU/hLXaWv59be rjAIHJEz1ad3M+0wok4fTV5pBlGlzPUEHcl5zwlWzRUXMRXgZgJCmamXWZ3OCnGe5tmY BvU0LKTbhfNjfTsvzd1mwL1qUdGBZGhyyDYB70AoAAI6MEXOuuB285+3NrASiiM9L3e2 +FiGkkb6kCne57tCbNoV4PgzXqhkT9IIiNh94vrAEjUflKBWR6OUJ0Hz933g4Hu7CM82 sv016kmvzrUzwGCdb+yG4sEGcqzF58o9ceH/IdWYnT6XTFvu6fhrhbMfJypBivU9G57A 5dSQ== X-Received: by 10.52.164.166 with SMTP id yr6mr12909712vdb.37.1366487654127; Sat, 20 Apr 2013 12:54:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.250.6 with HTTP; Sat, 20 Apr 2013 12:53:54 -0700 (PDT) X-Originating-IP: [50.0.158.23] In-Reply-To: <8952faf08749497a831465e00de4785d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20130417103918.3587.qmail@joyce.lan> <7BF5EC3D91FA4D6DA7902A1387BCFB60@fgsr.local> <8952faf08749497a831465e00de4785d@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> From: John Sweet Date: Sat, 20 Apr 2013 12:53:54 -0700 Message-ID: To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c187e0371a4404dad03389 X-Gm-Message-State: ALoCoQnXd75XgSIukTddtzrkOac+cbkkrSOTT5v9WBzZTwL00CHZ2jNavjHe9OXbG9MuU8oN+n+T Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 19:54:20 -0000 --001a11c187e0371a4404dad03389 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 17, 2013 at 5:12 PM, Terry Zink wrote: > >>> > Likewise, when I see your posts here on dmarc-ietf, I really don't care if > it's you or someone pretending to be you. Some applications of email just > aren't desperately in need of authentication. > <<< > > So, are we basically on a discussion list that is in charge of moving > forward the DMARC standard, but the discussion list itself can't > authenticate with DMARC? > I have no problem with mailing lists representing posts as being from the list, not from the original posters. I didn't subscribe to the individual posters, I subscribed to the list. I do expect the list to authenticate posters (especially since only certain addresses are allowed to post). I don't expect the list to transport their authentication info through to me to verify for myself. Once I can tell the message is verifiably from dmarc@ietf.org, I'm done caring. I don't consider the mailing list convention of preserving the From: of the original poster to be a useful or necessary feature. Digests don't do it: they're always from the list. If this means you can't post to some mailing lists from an address protected by a DMARC reject policy, or that some mailing lists only send digests, or always rewrite the From:, or even only rewrite the From: when they can see the poster has a reject policy in effect, I'm fine with that. If a list materially misrepresents the contents of a post, or identity of a poster (same thing really), it will rapidly lose all its posters and subscribers and cease to exist. This isn't a current scam profile, and I can't see it ever becoming one. This isn't a problem that needs solving, let alone by DMARC. J --001a11c187e0371a4404dad03389 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 17, 2013 at 5:12 PM, Terry Zink <tzink@exchange.m= icrosoft.com> wrote:
>>>
Likewise, when I see your posts here on dmarc-ietf, I really don't care= if it's you or someone pretending to be you. Some applications of emai= l just aren't desperately in need of authentication.
<<<

So, are we basically on a discussion list that is in charge of moving= forward the DMARC standard, but the discussion list itself can't authe= nticate with DMARC?

I have no problem with mailing lists representing posts as being from the l= ist, not from the original posters. I didn't subscribe to the individua= l posters, I subscribed to the list. I do expect the list to authenticate p= osters (especially since only certain addresses are allowed to post). I don= 't expect the list to transport their authentication info through to me= to verify for myself.

Once I can tell the message is verifiably from dmarc@ietf.org, I'm done caring. I don't consider the= mailing list convention of preserving the From: of the original poster to = be a useful or necessary feature. Digests don't do it: they're alwa= ys from the list.

If this means you can't post to some mailing lists from an address = protected by a DMARC reject policy, or that some mailing lists only send di= gests, or always rewrite the From:, or even only rewrite the From: when the= y can see the poster has a reject policy in effect, I'm fine with that.=

If a list materially misrepresents the contents of a post, or identity = of a poster (same thing really), it will rapidly lose all its posters and s= ubscribers and cease to exist. This isn't a current scam profile, and I= can't see it ever becoming one.=A0 This isn't a problem that needs= solving, let alone by DMARC.

J
--001a11c187e0371a4404dad03389-- From johnl@iecc.com Sat Apr 20 13:09:58 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CE921F874E for ; Sat, 20 Apr 2013 13:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeaF5FsdZMeC for ; Sat, 20 Apr 2013 13:09:58 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C95FA21F86FA for ; Sat, 20 Apr 2013 13:09:57 -0700 (PDT) Received: (qmail 60841 invoked from network); 20 Apr 2013 20:11:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2013 20:11:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5172f615.xn--i8sz2z.k1304; i=johnl@user.iecc.com; bh=1sEhRxkgGpyJV8bqYL4CGCzRC7SDbwhzm06OLEBmxtg=; b=gam/tL8CKeLTZndQzTHjA/fa9qpM3x2VNz7OKLv8vr7RcOpVdjl7+RssNwlDacd7rLqcQde3JHFQTLHyzHswo/gN9op+vzJe6pXVoBkHQBZTotVWYfIcB6rrB/DqtLpLIooXud1gYA4VdKKScZ5Kl/c0R6KEJ+Fe/cyewlKNjdI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5172f615.xn--i8sz2z.k1304; olt=johnl@user.iecc.com; bh=1sEhRxkgGpyJV8bqYL4CGCzRC7SDbwhzm06OLEBmxtg=; b=l5Z8lVYRvlG0UqSDM5QT/GN6UdNblRiaLvcsYdCabB2RMxDjz0hHOA3bm4faP+cAaf7xzCPZGMCLu6Op3zozWod4Be/jIobDUsW+rx7PbmP443bsxRju/zSi8YNmh3B0VlmuBW6wankH+0BYX/tvQHBIma/8c0rxtOlxPmZ3UTM= Date: 20 Apr 2013 20:09:35 -0000 Message-ID: <20130420200935.46303.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] no hints for receivers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 20:09:59 -0000 >This is reminiscent of VBR (RFC5518). It would be interesting to find out >how much uptake of that there's been. It's not really like VBR, which is for third party whitelists, with the type tags being for auditing. In any event the current usage of VBR is approximately zero. I don't know of any publisher of VBR other than the vestigial Spamhaus whitelist. My advice for senders who want to publish extra hints for receivers is this: don't bother. For a sender we don't know, we're going to ignore the hint since there is no reason to believe it. For a sender we do know, we're probably going to accept your mail anyway and the hint won't help. There might be some use for sender assertions in mail like the ones in VBR to help audit and diagnose authentication screwups, but if they're useful, they'll be useful on their own and not as part of DMARC. R's, John From dcrocker@gmail.com Sat Apr 20 13:12:21 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3B521F9335 for ; Sat, 20 Apr 2013 13:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhPm5X9DDLZi for ; Sat, 20 Apr 2013 13:12:20 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 32C9821F930B for ; Sat, 20 Apr 2013 13:12:20 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id n9so4794834oag.6 for ; Sat, 20 Apr 2013 13:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nLX8pl27EZ7MftX7jA8lQOW8LvXP2N6Ik9HtR61TmiM=; b=FlObnJGkgYc5oMl+JWANOnUlfOyf+8Iofp9rGKIOWXyeAjGeYXhQayeyWBFbdMWgUa 8z9gboaIyXwq753SQpqBFxaDF4dncrn16ap7iW2cywej/0MSCcijA/rldlPRL5XOv40z WS0lwThxsJ+Z0VMK45VQUX4N6Gd0GYEII3uyab+D/dkqjEbWheFsp3WrgxrD5JLgKYQv lBqsJxRSePGVrTXnXD2NVkavZTvVyRIWCo2ckwBfsH4ER1MF1Mua/fTjgkLvtfgeL4Co YqO3x9QUMmwMyEz07DDLEp/Fiex3S0PdCyc8ea2KCS4nyPyOxg+GnmY0AIp04/jAlcHZ 4jkA== X-Received: by 10.182.64.74 with SMTP id m10mr6318547obs.61.1366488739844; Sat, 20 Apr 2013 13:12:19 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id sb6sm11382174obb.11.2013.04.20.13.12.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 13:12:19 -0700 (PDT) Message-ID: <5172F69A.5040903@gmail.com> Date: Sat, 20 Apr 2013 13:12:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Levine References: <20130420200935.46303.qmail@joyce.lan> In-Reply-To: <20130420200935.46303.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] no hints for receivers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 20:12:21 -0000 On 4/20/2013 1:09 PM, John Levine wrote: > My advice for senders who want to publish extra hints for receivers is > this: don't bother. > > For a sender we don't know, we're going to ignore the hint since there > is no reason to believe it. For a sender we do know, we're probably > going to accept your mail anyway and the hint won't help. We need to produce an online placard that quotes the above and is cited for all discussions about improving email abuse-related handling... d/ -- Dave Crocker bbiw.net From johnl@iecc.com Sat Apr 20 13:15:07 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE06D21F8619 for ; Sat, 20 Apr 2013 13:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAPRZ2eP3xUX for ; Sat, 20 Apr 2013 13:15:06 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8C721F8C06 for ; Sat, 20 Apr 2013 13:15:06 -0700 (PDT) Received: (qmail 62392 invoked from network); 20 Apr 2013 20:16:39 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2013 20:16:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5172f749.xn--3zv.k1304; i=johnl@user.iecc.com; bh=RZBhtQqDU3ofBs9Srk80pVi/2Nj4BrI2mHfGCdjFdKE=; b=H2RzHi6K8EgbICfHYtxx5tVsKGmhoJ9vcOZ3FOLrcj7l6ZzGQYrRxnZAjkbNzdJhKD+mva45hXOB1FCvMWUDk9QQ2ZPuFT9bv8YOzGaXlNnWIXxciovgE429Nma3e229WCtE7eahr4hXQNp+jnKC03BCVzgTOXaFrgS3MLQ8wqI= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5172f749.xn--3zv.k1304; olt=johnl@user.iecc.com; bh=RZBhtQqDU3ofBs9Srk80pVi/2Nj4BrI2mHfGCdjFdKE=; b=XXr1chPEQOkJhSUrjGPLoFZhbsaTudGtWN5J8eWTzDtw9qF/OGcniAWQmqNroyhBcGnbDNbgkEFs8LHiysonC4SmPFPqwDa8l3V1lW/TrWgr5TVIp/BdwtcQb9Zc9PGlNEafY+YYSGiszm7Scc9xJkxaHrbzHu5s22XU4xITqB4= Date: 20 Apr 2013 20:14:43 -0000 Message-ID: <20130420201443.46371.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <1581179.AB75fythCq@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] what's a list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 20:15:07 -0000 >Most of the current deployment is at large providers that can do significant >data analysis to effectively identify lists. As a small domain, there's no way >I can do the same. > >If there were a protocol method to share this information, either among >trusted receivers or via 'hints', it could be useful to smaller providers that >don't have the scale to mine the data themselves. That's the kind of thing that VBR is intended for. A trusted party publishes a list of certified domains in the DNS. When you get a message, you look up the authenticated domain (DKIM valid d= or SPF mail from pass) in the VBR list, and if it's there, it's certified. The mechanism is trivial. The hard parts are collecting the set of trustworthy sending domains, and arranging for someone credible to publish it. From johnl@iecc.com Sat Apr 20 13:17:36 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D021F8C06 for ; Sat, 20 Apr 2013 13:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g14KhelHMx8O for ; Sat, 20 Apr 2013 13:17:35 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 89F5021F8619 for ; Sat, 20 Apr 2013 13:17:35 -0700 (PDT) Received: (qmail 63370 invoked from network); 20 Apr 2013 20:19:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Apr 2013 20:19:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5172f7de.xn--30v786c.k1304; i=johnl@user.iecc.com; bh=ifBuAwyyzjKfd6yT/gFPeKMyR7XO6hZ5G9BHp3ryUss=; b=m3X0yDsTOKPPq0BqnHBR6AYhhrzbZNbbFi3yjDORdpfGpTQlnjb19rCAxIb/PCIo6EJwDWiazt7rQdpzGU2LSh7e6DRS25leDkrZnQG3neUJMr4pgAQ7C69KsFqS6+bVuHb7X2wUIQLmhwXAJwHynMtfZK45Hq3Lt51gf+XDkWA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5172f7de.xn--30v786c.k1304; olt=johnl@user.iecc.com; bh=ifBuAwyyzjKfd6yT/gFPeKMyR7XO6hZ5G9BHp3ryUss=; b=xqlhiqOxUbE39kd0EmLKBlXtY5+AA6VKEpfQYx2aKPd9Blm0lcm7QEApagQe9sfOUo5I4gdFLZ1oAPhHr0aS8MDaIxO1TGyG9XQc/WHI8pFHz4CDZSMMsdEoRL2Dtn73Yw5A5sgWduSdmYj10vFYyDV9q1xxxfzKos4Udc7yk4w= Date: 20 Apr 2013 20:17:12 -0000 Message-ID: <20130420201712.46418.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: sweet@secondlook.com Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 20:17:36 -0000 >Once I can tell the message is verifiably from dmarc@ietf.org, I'm done >caring. It's got an ietf.org DKIM signature. What more do you need? R's, John From dcrocker@gmail.com Sat Apr 20 13:51:46 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B2221F8A4E for ; Sat, 20 Apr 2013 13:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=-0.918, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USgM4kN8cIUi for ; Sat, 20 Apr 2013 13:51:45 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 63C5521F8E36 for ; Sat, 20 Apr 2013 13:51:31 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wn14so4503167obc.32 for ; Sat, 20 Apr 2013 13:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=B3m8VloCYpD4p4YkV7Fw8aH7ys5YOXpT3AC1GHn5Pbk=; b=r31sadrD9RsX2DYOTwJHaPEc2Lg5Ey4nRExwr2fvMb7fBL1RvCkB+bcd3XxIP4eb/K iXW1PgZaWIKSF+pITdpmATjTOIQ0BRLANPXpPz1C+z7sLATXn60osYngX5hNx53veMl2 y3AxLnSkg1ngNnk9zD9x5spJD6v2PymYXDtYH7RxoHLrKVE2HMYDkY+XvQYaSrqkoVyt JZslnxWbCoTSIMvWwqHUMjW42X763i0CUPvefXlUcS/GrDbMw6TWFYV0S7vND+XmzRyb VWSXrhyZWWwbkNLmEREQPBneA6IgIJnUlcrAf5t4lIZ/gtCB4/jZFRhg1nIJsEkOgUPD x7cQ== X-Received: by 10.182.204.5 with SMTP id ku5mr6500763obc.22.1366491090980; Sat, 20 Apr 2013 13:51:30 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id t9sm11524971obk.13.2013.04.20.13.51.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 13:51:29 -0700 (PDT) Message-ID: <5172FFC9.2020609@gmail.com> Date: Sat, 20 Apr 2013 13:51:21 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John Levine References: <20130420201712.46418.qmail@joyce.lan> In-Reply-To: <20130420201712.46418.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sweet@secondlook.com, dmarc@ietf.org Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 20:51:46 -0000 On 4/20/2013 1:17 PM, John Levine wrote: >> Once I can tell the message is verifiably from dmarc@ietf.org, I'm done >> caring. > > It's got an ietf.org DKIM signature. What more do you need? ietf.org signs all sorts of stuff, including messages that turn out to be spam. d/ -- Dave Crocker bbiw.net From johnl@taugh.com Sat Apr 20 14:01:50 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A774421F8E66 for ; Sat, 20 Apr 2013 14:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-ZOlR9BuKnh for ; Sat, 20 Apr 2013 14:01:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BA5FA21F84AE for ; Sat, 20 Apr 2013 14:01:49 -0700 (PDT) Received: (qmail 74026 invoked from network); 20 Apr 2013 21:03:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12128.5173029b.k1304; bh=Hwe0rw4hfQF4fhDHQ629LOQMo61ArFJpD9IOPi7uz4k=; b=JoElV1n7lgEOH9l0vmObGuf+znhMAT0TME/UXjktd3H0lp5GEkxE53aelZ44wEcdIcxTuC+HEg2R/5xNbJOhRsCny970Czosm+4IqnBMyKid6sPHXp4+I4sSGbseGcaAtn7518t0DMqcrcl7tqYoW8bXeBWiNi1QmKT6desUI1k= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12128.5173029b.k1304; bh=Hwe0rw4hfQF4fhDHQ629LOQMo61ArFJpD9IOPi7uz4k=; b=2kWfgkwCIaqOks6X8rZEc4qCq1V9lK0+DvmfcBNtaRXYjpFSScctJIdXFM6XEzKxsRl5dzbmDpspZ9iFZbvimSy2CvGo3dvZNS/WhIHTxKgFvNYDVbGiTRi2JsuDh4xMUWq7gmHF2bBbr3tJeYvOiIZLUzytrNKP2BIcaRWynHU= Received: (ofmipd 127.0.0.1); 20 Apr 2013 21:03:01 -0000 Date: 20 Apr 2013 17:01:48 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <5172FFC9.2020609@gmail.com> References: <20130420201712.46418.qmail@joyce.lan> <5172FFC9.2020609@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-2001364640-1366491709=:46524" Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 21:01:50 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-2001364640-1366491709=:46524 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >>> Once I can tell the message is verifiably from dmarc@ietf.org, I'm done >>> caring. >> >> It's got an ietf.org DKIM signature. What more do you need? > > ietf.org signs all sorts of stuff, including messages that turn out to be > spam. True. It's got an ietf.org signature on a List-ID header, which is somewhat more specific to this list. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. --3825401791-2001364640-1366491709=:46524 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8 oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1 BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0 cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0 cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0 Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb 2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE 6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNDIwMjEwMTQ5WjAjBgkqhkiG 9w0BCQQxFgQUBMbOWGYYx4CLH2WXOOgRugV5U9sweQYJKoZIhvcNAQkPMWww ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAVl/AABODrTLT wRcRli57XgyVxBpUVn1nQ8C46uz6HnxkW7Z+uqaZ9IkMHUNRF1VEdrffOB5a kzsJepu2uzfnmIMl9BXUUjncD12bh98KFmlSo4bMuwJ3tVBkWgI618HEoqW2 f9sOs6vEgdBvkx3fo3H4+EDY60jh1uNgF+CXUrgyROXE/ZT6LSbJC4CYAPe1 kEZWCL4IYvB/FgQqB4PFfLPMG1ka5kgFo8t4riEAqRsOYgAe7VlKdUpXs1nI zaSO63RKrEHOjQSy+CLP3g1v1uSkQCIGsDJG6AcThmkLe3ScXJyxZUC2WhZo a3ej/BXKvZ2G7CLwoPrU6WikNhH50A== --3825401791-2001364640-1366491709=:46524-- From dcrocker@gmail.com Sat Apr 20 14:12:02 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D121F8759 for ; Sat, 20 Apr 2013 14:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eh4JHgdGHNH for ; Sat, 20 Apr 2013 14:12:02 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id AC21821F86C3 for ; Sat, 20 Apr 2013 14:12:01 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i10so53596oag.15 for ; Sat, 20 Apr 2013 14:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rl/NIDdp0vFHof3DJNIFROgr/5Oi0IO0MWqVQKyET4o=; b=dM0MvwnlaB+3tHKTmlmHOOsefAudpG86fOBFbUgkeDqboeokYbmzMNKK24VpV0Tfbu Cjujr3bgLof4UBIFnCGUXqt0Vn96L3TS+eq7s6KBcxDLJ/MdHX/4ithNfVJmbXfwI1Aw ony+wnPY5lulxS4ELeIUSlTm3AKMHGBdNbh7a6+3wGLtWI7kqEpTvj+qtcDgOD9MtLc0 z3CiVrkWaSTzf7LkQaGCrm5GLOcAPB+bIVmsWqkCxzoJjtsrDn/Jq/5FZxYuaGh0dCjI InSb38z4EukH4uCEZTde8qLc15tWkCeXjrNBrRqyVZW1W7+yubJLJGCe4kCM3hc8ACWt XJ0w== X-Received: by 10.60.30.131 with SMTP id s3mr7283614oeh.106.1366492321252; Sat, 20 Apr 2013 14:12:01 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPS id a4sm11363647oek.1.2013.04.20.14.11.59 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 14:12:00 -0700 (PDT) Message-ID: <51730498.1020200@gmail.com> Date: Sat, 20 Apr 2013 14:11:52 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: John R Levine References: <20130420201712.46418.qmail@joyce.lan> <5172FFC9.2020609@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 20 Apr 2013 21:12:02 -0000 On 4/20/2013 2:01 PM, John R Levine wrote: >>>> Once I can tell the message is verifiably from dmarc@ietf.org, I'm done >>>> caring. >>> >>> It's got an ietf.org DKIM signature. What more do you need? >> >> ietf.org signs all sorts of stuff, including messages that turn out to >> be spam. > > True. It's got an ietf.org signature on a List-ID header, which is > somewhat more specific to this list. that sounds suspicious like claiming that including it in the hash equates to validating it contents... anyhow, the spam that the ietf sends goes /through/ its lists... d/ -- Dave Crocker bbiw.net From R.E.Sonneveld@sonnection.nl Sat Apr 20 14:47:35 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC79C21F9104 for ; Sat, 20 Apr 2013 14:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAAFjkUQTcDh for ; Sat, 20 Apr 2013 14:47:34 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id A071621F90A1 for ; Sat, 20 Apr 2013 14:47:34 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx20.mailtransaction.com (Postfix) with ESMTP id 6208E8C00F8; Sat, 20 Apr 2013 23:47:32 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 351678C00F7; Sat, 20 Apr 2013 23:47:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id F30F6123035; Sat, 20 Apr 2013 23:47:31 +0200 (CEST) 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 k7qyaRAOu-5J; Sat, 20 Apr 2013 23:47:29 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id E9308123000; Sat, 20 Apr 2013 23:47:28 +0200 (CEST) Message-ID: <51730CF1.8010209@sonnection.nl> Date: Sat, 20 Apr 2013 23:47:29 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Dave Crocker References: <20130420201712.46418.qmail@joyce.lan> <5172FFC9.2020609@gmail.com> <51730498.1020200@gmail.com> In-Reply-To: <51730498.1020200@gmail.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=1366494452; bh=yTbdKJ3eTwCa8SkXFKEhD6UMh+Np4UYiycQiWSGg2eI=; h=Message-ID:Date:From:To:Subject:From; b=WeOtFg0MpKAlqcS0SelPawJihV+5a7lPqjxQ7rBR+jCMQj+snw6kXu4HwWe89Vzy8 vdN45OmzVoIj5nSUryi0s5upkeP36F/Xm1+eo2buiclJW1vzgofMnpOs9mRPqWd5Xs tuKElI2Zj41AUbEl3t3TSAtD/sGpcte9n5pasPUs= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 6208E8C00F8 Cc: dmarc@ietf.org, John R Levine Subject: Re: [dmarc-ietf] making mail not work for your users, was the endless mailing list silliness X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 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, 20 Apr 2013 21:47:36 -0000 On 04/20/2013 11:11 PM, Dave Crocker wrote: > > > On 4/20/2013 2:01 PM, John R Levine wrote: >>>>> Once I can tell the message is verifiably from dmarc@ietf.org, I'm >>>>> done >>>>> caring. >>>> >>>> It's got an ietf.org DKIM signature. What more do you need? >>> >>> ietf.org signs all sorts of stuff, including messages that turn out to >>> be spam. >> >> True. It's got an ietf.org signature on a List-ID header, which is >> somewhat more specific to this list. > > that sounds suspicious like claiming that including it in the hash > equates to validating it contents... > > anyhow, the spam that the ietf sends goes /through/ its lists... well, nobody claims that DKIM-signed messages never can be spam. The keyword here again is: reputation. If ietf.org is redistributing+signing too much spam messages this will have impact on the reputation of d=ietf.org... /rolf From vesely@tana.it Mon Apr 22 08:05:51 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6431821F910E for ; Mon, 22 Apr 2013 08:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrRxy7dQL3fP for ; Mon, 22 Apr 2013 08:05:50 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7756E21F90EE for ; Mon, 22 Apr 2013 08:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1366643140; bh=WRW6LdRkEDxwifgCd+Ngo85RTfgM6c516bT0T4r19Aw=; l=1134; h=Date:From:To:References:In-Reply-To; b=oWqZsVqTk4Yfkn8aw05NDgJ60I9V8oFALcBWcT98gRwO2ART+bC+wfxEYKDxlByhX ec+u65pkPQGj3zYa+UVOwFIPKWvQFv4zmpQXLQYvqVZ+R+raJ083cyublLi1k/9GWQ v6ojOPKESmfNiCI1Wcy0fPSOT9dcExCY1I+xrjyA= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.101] (pcale.tana [172.25.197.101]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 22 Apr 2013 17:05:40 +0200 id 00000000005DC039.00000000517551C4.00003CCA Message-ID: <517551C4.2060108@tana.it> Date: Mon, 22 Apr 2013 17:05:40 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130420200935.46303.qmail@joyce.lan> In-Reply-To: <20130420200935.46303.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [dmarc-ietf] no public hints for receivers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 Apr 2013 15:05:51 -0000 On Sat 20/Apr/2013 22:09:35 +0200 John Levine wrote: > > I don't know of any publisher of VBR other than the vestigial > Spamhaus whitelist. Heck, "vestigial"!? No further thoughts on it? Maybe it was just the sunrise campaign parading a dot-com approach without further disclosure of the business model, or some other marketing detail... > My advice for senders who want to publish extra hints for receivers > is this: don't bother. That leaves another possibility: Tell those extra hints privately. If you recall my smtp-request/dns-reply sketch[1], augmenting the possibilities of replying could make sense. Each row in an aggregate report identifies a message stream characterized by some identities. A receiver could let the recipients of aggregate reports manually whitelist the rows that would cause rejection if the relevant policy was stronger, e.g. using a purposely designed web form. That semi-automated cooperation can be valuable whether or not a domain is going to strengthen their policies. It's feedback on feedback. [1] http://www.ietf.org/mail-archive/web/dmarc/current/msg00188.html From johnl@iecc.com Mon Apr 22 11:01:05 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8EC21F93F6 for ; Mon, 22 Apr 2013 11:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 239CsXdPmr3Y for ; Mon, 22 Apr 2013 11:01:04 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3496E21F843F for ; Mon, 22 Apr 2013 11:01:04 -0700 (PDT) Received: (qmail 18236 invoked from network); 22 Apr 2013 18:00:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 22 Apr 2013 18:00:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51757ada.xn--btvx9d.k1304; i=johnl@user.iecc.com; bh=tzkihB7fShD+jsl6KiAyy59i4RfgFhvaKBKm2zshzWo=; b=gaCHjtrj9ABAnaKZMlJQ+sWjL4W3nzYtK9QGRJQUsZqIKW6zTWISZ4oNpmeBMilSmGlAgsCoAXYWrmYtiJEexG1ERdvcs1XXvRlouRez6ma3pgbxvo5nvKgoj5B2USIrg9R8R6UuRMS754R6yf/jE6rEALFokcAm8ksz4GRxPZA= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51757ada.xn--btvx9d.k1304; olt=johnl@user.iecc.com; bh=tzkihB7fShD+jsl6KiAyy59i4RfgFhvaKBKm2zshzWo=; b=pR2+2EPMD07VfS+Sj+QBIQeWAHcdZAnKzg1CjCccDo9YeUQxBoq8OZTkN57v67hZ+U92tV4+BlRo391CQLuYaAMGhBcWnsZW50ou8R1qMs5rXwhb113pYjjh0t5fo6ECCKUNWfDUTIQmgR8Wk6jTvzBh6ClJsDvQ9eFY6YqCdFg= Date: 22 Apr 2013 18:00:36 -0000 Message-ID: <20130422180036.19116.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <517551C4.2060108@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [dmarc-ietf] no public hints for receivers X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 22 Apr 2013 18:01:05 -0000 >> My advice for senders who want to publish extra hints for receivers >> is this: don't bother. > >That leaves another possibility: Tell those extra hints privately. You can make whatever private arrangements you want. That's not what standards are about. R's, John From dcrocker@gmail.com Mon Apr 29 20:04:24 2013 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F1C21F9B1A for ; Mon, 29 Apr 2013 20:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ktuMznB78jsY for ; Mon, 29 Apr 2013 20:04:20 -0700 (PDT) Received: from mail-gh0-f178.google.com (mail-gh0-f178.google.com [209.85.160.178]) by ietfa.amsl.com (Postfix) with ESMTP id 269DB21F9AA5 for ; Mon, 29 Apr 2013 20:04:16 -0700 (PDT) Received: by mail-gh0-f178.google.com with SMTP id g24so14536ghb.9 for ; Mon, 29 Apr 2013 20:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=EMWmPIv9pOh+Qkg+VfO1EqdwYmg0yptbtDZZ7QilMuI=; b=tyzr1K5pIgC7zQN389yRD/OiO50dEisNPTnKCLpdFzxTU4/FM/7sfb4pyicrhAEPiG ORe9+WwbnHzAtqibZ5p0U/Hmlgx1+efzGsZL7f+8RCdvJH+IoQgMEWomtFEv+su+dnoT chFw9t5ic9ax2z1IIGqsrlPDQWB/yy0hbGmXKUQkhBVZcwEaFao6zpKYJNG83Zwz+f3I /zOB6+IRxQRMoMmWLCesTUQ8o+N/ULq3opOitzCWO/GPBQBmOcLEIiSpz67IipO6n6SO nHXYGMNBmVGVl5LFl/9jRVdNS/ZsQA/VvKq+QvLqFYFxr0A/E2IP9mK8xvNut3FelvpD juqA== X-Received: by 10.236.208.34 with SMTP id p22mr34440510yho.114.1367291056348; Mon, 29 Apr 2013 20:04:16 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id c67sm36056589yhh.16.2013.04.29.20.04.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 20:04:15 -0700 (PDT) Message-ID: <517F34A8.1060706@gmail.com> Date: Mon, 29 Apr 2013 20:04:08 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: dmarc@ietf.org References: <20130429211648.14233.26491.idtracker@ietfa.amsl.com> In-Reply-To: <20130429211648.14233.26491.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-bcp-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list 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, 30 Apr 2013 03:04:24 -0000 Folks, G'day. This draft contains raw text being submitted into the hoped-for working group effort that will develop a BCP on DMARC usage. I should underscore what the word 'raw' means: intended to prime the public discussion pump. All of the contributors made serious efforts to formulate useful text -- and by my own reading did an excellent job -- but the text is neither reviewed nor refined. So while my own opinion it's quite a nice start for the document, no aspect of it is 'firm'... d/ -------- Original Message -------- Subject: New Version Notification for draft-crocker-dmarc-bcp-02.txt Date: Mon, 29 Apr 2013 14:16:48 -0700 From: internet-drafts@ietf.org To: Dave Crocker A new version of I-D, draft-crocker-dmarc-bcp-02.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Filename: draft-crocker-dmarc-bcp Revision: 02 Title: Using DMARC Creation date: 2013-04-29 Group: Individual Submission Number of pages: 35 URL: http://www.ietf.org/internet-drafts/draft-crocker-dmarc-bcp-02.txt Status: http://datatracker.ietf.org/doc/draft-crocker-dmarc-bcp Htmlized: http://tools.ietf.org/html/draft-crocker-dmarc-bcp-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-crocker-dmarc-bcp-02 Abstract: Email abuse often relies on unauthorized use of a domain name, such as one belonging to a well-known company (brand). SPF and DKIM provide basic domain name authentication methods for email. A recent industry effort built an additional authentication-based layer, called Domain-based Message Authentication, Reporting & Conformance (DMARC). It allows a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes; it also provides a reporting mechanism, from receivers back to domain owners. Such capabilities over the public Internet are unusual and their use is not yet well-understood. This document formulates a set of best practices for the use of DMARC. The IETF Secretariat -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net