From nobody Fri May 2 17:36:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B271A6FEE for ; Fri, 2 May 2014 17:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.402 X-Spam-Level: X-Spam-Status: No, score=-101.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5GnhNt8HWGD for ; Fri, 2 May 2014 17:36:06 -0700 (PDT) Received: from mail.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E28491A6FF1 for ; Fri, 2 May 2014 17:36:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4203; t=1399077343; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BNu77auucKQeaPzA0raKMW92tFU=; b=gKpy+tj4xrKmndEHvs4R LvUkx0CiFMTA4tqaWmqfznh42GiGcpAcIsf/HZGlyT359AArru6aRs7nwmbwfxjK lMAfm1qWIyRjfG+4cf3LU6hcINwokOHQAYg1vAkmC7CFfIY0Tr2JYeMUvxlwDRIP fwwDBkKAnw7/zlYR8M/40is= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 02 May 2014 20:35:43 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2185902311.1816.2564; Fri, 02 May 2014 20:35:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4203; t=1399077246; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=SrkdyGk qvvnC8V7cQKZL/utUQsGo82LpjaZCRzvuCtQ=; b=VfH3pUK6qpcmgsQKeIrpQow uJWi6/HrE1X/xRCWqdKOk7TwMhBm/zV1WqPFpWY4ilV4GJbUlC4kOmIOcHc5ltXC j7h+cFvzJTZdPrYoDcc1vdt+NBYiolFzdKEQaYBigVnOrQXOd306Yhl0hSIB1TrK pemYXCulfik5tCsnvSHc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 02 May 2014 20:34:06 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2205421890.9.15592; Fri, 02 May 2014 20:34:05 -0400 Message-ID: <536439E1.1040601@isdg.net> Date: Fri, 02 May 2014 20:35:45 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , IETF References: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> In-Reply-To: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UUlzaGLnsxChNLmS_9_mCotaiH4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 03 May 2014 00:36:08 -0000 Hi Fred, We have already did all this. Over the last 9 years, we have produced all these DKIM related documents: RFC4686 Analysis of Threats Motivating DKIM RFC4870 DomainKeys RFC4871 DKIM (RFC5672.TXT, RFC6376.TXT) RFC5016 Requirements for a DKIM Signing Practices Protocol RFC5451 Message Header Field for Indicating Message Authentication Status RFC5518 Vouch By Reference RFC5585 DKIM Service Overview RFC5617 DKIM Author Domain Signing Practices (ADSP) RFC5863 DKIM Development, Deployment, and Operations RFC5965 An Extensible Format for Email Feedback Reports RFC6376 DomainKeys Identified Mail (DKIM) Signatures RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists RFC6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures and that all doesn't include all the draft I-D produced by myself, Doug Otis and others. We are well pass the hypothetical, theory, proof of concepts, etc. Mailing list Software with DKIM+POLICY support exists, at least ours does. This is an issue of getting IETF endorsement to support the DKIM POLICY framework. The IETF just made ADSP RFC5617 historic earlier this year. DMARC snuck in with large domains enabling the strong handing mode of operations. That surprised the IETF and left the network not ready to handle this long known 9 year old DKIM+POLICY design/change requirement situation. Other MLS software/operators need to adjust and so far, the IETF is not willing to accept a DKIM+POLICY framework the industry wishes to go with. Overall, the two key changes are: 1) MLS checks/deny/notify new subscribers using restrictive policy domains. 2) MLS checks/deny/notify new submissions from restrictive policy domains list members. Those two basic changes are needed in principle to honor the security policy first. The hard part was how to scale author domain authorized 3rd party signers for author domain policies that allow resigning and this was pretty much where it was all left at, with 3rd party authorization proposals that piggy backed off the ADSP record with ATPS (RFC6541), my ASL (Authorized Signer List) proposal and Doug's TPA proposal. This is also where Levine's Whitelist suggestion can play a role, but it still needs to be author domain authorized. I don't see us going anywhere unless a fundamental IETF acceptance for DKIM+POLICY occurs and that means honoring the security policy first, not ignore it and continuing to forward unauthorized resigned mail. Unless the ADSP status can be reversed, and DMARC is here to stay, the IETF needs to update the DMARC document for 3rd party support. Finally point, the example email attachment you had from owen@delong.com, keep in mind it does not have a DMARC policy, but it does a ADSP "dkim=all" which says that only the first party signer was expected in all mail. But there is o reject/discard handling semantics as it would be for a "dkim=discardable" ADSP policy. -- HLS On 5/2/2014 2:05 PM, Fred Baker (fred) wrote: > We have been having a fairly extended discussion, much of which seems hypothetical - �I don�t like DEMARC because I am worried that ... with mailing lists�. I wonder if we could take a moment to try it and see what happens? > > As an example of the case that comes to mind, see attached. It is a message sent to v6ops@ietf.org yesterday. The sender signed it using DKIM, the IETF changed the message (added some trailing text) before forwarding it, the receiver (e.g., Cisco IT) attempted to validate the DKIM signature - and failed. > > It seems to me that we should not approve a procedure that has that effect, at least without some guidance for mail relay administrators. I could imagine two forms of guidance: �obey the end-to-end principle; don�t change the message the originator sent�, or �if you change a signed message, first validate the message you received and discard if that fails, change it, and then sign it yourself, so that a receiver can see who changed it and validate the outcome�. > > Could we actually try such guidance in a sandbox, and document appropriate procedures for mailing lists? > > > > From nobody Sat May 3 09:43:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD0E1A0103 for ; Sat, 3 May 2014 09:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAMOO0ZEjPwa for ; Sat, 3 May 2014 09:43:06 -0700 (PDT) Received: from groups.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CF2C91A00E6 for ; Sat, 3 May 2014 09:43:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4239; t=1399135375; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=XoO49fPixMDIRTZv5F36+u9oR3g=; b=CbVsw69pslFr4Gd64EUI 0hcfE6WrshnjkGX61vX/E2LwLIim2OvL/JE5YkYUoEXLSHQd1+O+LKDVmYVsCEma 4Irm+4++XHK24e82vckfRkNquj/IUPHMkJvpxUX1JIaUrMz61KNNGkn94+70qggi L+OAF9eL5Noio+5KVvAynh0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 03 May 2014 12:42:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2243933294.3325.912; Sat, 03 May 2014 12:42:53 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4239; t=1399135275; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JA+Cas3 V6tOE041IJ0kceadS8nHkX2YdW6cNaCO50BE=; b=2S4sxawKjXM3bPAXmzyNYjs HkPXCPWSW67pta9glIWAAEzJXmGNzW08QHrIch5XiJJsvfAsnDb6zos7kxZiH9/U scdN2FnBsPr4iRdfr2rrhPxtSivNX3UkrbtvYIseKyS8+lxHvX11r/8d43p4reB8 DxxSnplY3Er7/Mtcp3m8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 03 May 2014 12:41:15 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2263451406.9.14260; Sat, 03 May 2014 12:41:14 -0400 Message-ID: <53651C91.70501@isdg.net> Date: Sat, 03 May 2014 12:42:57 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Douglas Otis References: <20140501195449.68225.qmail@joyce.lan> <5363ACA6.1010203@qti.qualcomm.com> <5363CB57.4030505@isdg.net> <465A7B8E-7E37-4B0D-BF6C-FA49CB7C0DA9@gmail.com> In-Reply-To: <465A7B8E-7E37-4B0D-BF6C-FA49CB7C0DA9@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/aXOgK5CRt-xcvN6apGbhNGcQb3k Cc: ietf-822@ietf.org, "dmarc@ietf.org" Subject: Re: [dmarc-ietf] [ietf-822] one can re-sign without a permission to re-sign header X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 03 May 2014 16:43:08 -0000 On 5/2/2014 1:09 PM, Douglas Otis wrote: > Dear Hector, > > I hope you are willing to review a TPA draft. Doug, I did go over your drafts in 2009 when it was rev3. I see I even explored compiling your C code under Windows to create labels: Directory of M:\rfc\dkim 10/12/2009 10:45 PM 39,185 draft-otis-dkim-tpa-label-03.txt 10/17/2009 08:44 AM 7,175 tpa3.cpp 10/17/2009 08:44 AM 16,384 tpa3.exe I don't know how much rev6 changed, but as I recalled mentioning to you in 2009, there was too much details to follow but it was definitely a much wider scope and coverage. But we all had the same basic idea and fundamental problem of an authorized 3rd party (re)signer need, whether it was with: SSP Sender Signer Practices ADSP Author Domain Signer Practices (RFC5617) ASL ADSP extension for 3rd party (smaller scale) ATPS ADSP extension for 3rd party (RFC6541) (larger scale) TPA ADSP extension for 3rd party (wider scope, large scale) The technical problem was how to best do this via DNS, the scaling and optimization with a plug and play DKIM security policy layer as it was originally envisioned. The practical problem was to how convince publishers and verifiers, especially resigners, to support and also enforce the stronger, restrictive policies as a deterministic mail filter. It was made a harder problem with the interest of the 3rd party resigner became more important than the interest of the originating author domain. This was burned in RFC5016 Section 5.3 Item 10 functional requirements. IMO, that needs to be corrected and not carried over to any future signing practice requirements or specifications doc. That is not to suggest local policy does not prevail in any situation, but it would be the first security protocol principle to support the highest domain protection payoff value a security protocol has to offer over all any other modes of operations. You can't just intentionally ignore it knowing full well what the purpose of the security policy protocol was designed to do. So I think we need to revisit the functional requirements for a DKIM Sender/Author Signing Practice protocol. I believe this will help update DMARC or any other "improved DMARC" that comes down the road. We need to revisit the basic process model DKIM framework for both POLICY and TRUST where a: - Message comes in, - Verifier Check Author Domain Policy, - Verifier Check Signer Trust Policy. Just like the RFC5585 DKIM Service Overview illustrates and outlines in Figure 1: | |- RFC5322 Message V +--------+ +--------------------------------+ | Private| | ORIGINATING OR RELAYING ADMD | | Key +...>| Sign Message with SDID | | Store | +---------------+----------------+ +--------+ | (paired) [Internet] +--------+ | +-----------+ | Public | +--------------------------------+ | Remote | | Key | | RELAYING OR DELIVERING ADMD | | Sender | | Store | | Message Signed? | | Practices | +----+---+ +-----+--------------------+-----+ +-----+-----+ . |yes |no . . V | . . +-------------+ | . +.......>| Verify +--------+ | . | Signature | | | . +------+------+ | | . pass| fail| | . V | | . +-------------+ | | . | | | | . +.......>| Assessments | | | . . | | V V . . +-----+--+----+ +-------+ . . | | / Check \<............+ . | +-------->/ Signing \ . | / Practices \<..........+ . | +-------+-------+ . . | | . . | V . +----+--------+ | +-----------+ +------+-----+ |Reputation/ | | | Message | | Local Info | |Accreditation| +----------->| Filtering | | on Sender | |Info | | Engine | | Practices | +-------------+ +-----------+ +------------+ Figure 1: DKIM Service Architecture So the framework was laid out. We just need to get folks to support the Check Signing Practice (CSP) module and also honor the policy. The "Local Info On Sender Practices" module is what John Levine wants people to do, including a whitelist. Thats fine, but it wouldn't be a consistent and persistent result across SMTP receiver sites unless they had the same local information. Even if this WhiteList was centralized, it should still check and honor how restrictive the domain policy is. -- HLS From nobody Sat May 3 11:09:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868A01A010B for ; Sat, 3 May 2014 11:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.202 X-Spam-Level: X-Spam-Status: No, score=-97.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGxooLYsWCdW for ; Sat, 3 May 2014 11:08:54 -0700 (PDT) Received: from listserv.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B45B31A0102 for ; Sat, 3 May 2014 11:08:53 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1912; t=1399140529; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=A9sGp0uHJ5rha1pw5grLRmGlSHM=; b=WzDph8j+7U3jgoodiUkl S6fnJ07nWNTyBRUZw1DVU0NILBVctB9TwI8AFWEexqsSuZF+qpWkttuCPkYVxRoZ UfYf22rh2n7J8vohuv0MCQJPkHEOiYmQR62gpSzuc4eO/3vsUcdhCYl0iyhpote0 pXw/3FouLIxur3Sw1zv8zkI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 03 May 2014 14:08:49 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2249088581.3325.3636; Sat, 03 May 2014 14:08:49 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1912; t=1399140428; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=jDOU/QK z35E5xLNLQ/ODm5nCayfS+nTD1nuX1THiMSE=; b=hRZcduvNS0w5PmMrah4ttkr qcwzqYBcfpJw6Hec8ZvmIljA6f+qdkXfMdgM+2PHHfNrtH8b5OYU4OPYvKe1WCCi qeAAZYOClbjVUns/7yWOoG0st3NDnHf+GQcgI7GErjIsjO5G3K5v1EOQ/xdtr4qq Fcozc11QjbpR+jcPFC9o= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 03 May 2014 14:07:08 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2268604796.9.15084; Sat, 03 May 2014 14:07:08 -0400 Message-ID: <536530B3.8050804@isdg.net> Date: Sat, 03 May 2014 14:08:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, "Fred Baker (fred)" , IETF References: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> <536517EE.6050800@dcrocker.net> In-Reply-To: <536517EE.6050800@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vNJOVXm9HnNRFMZ1H--3seNyUG4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 03 May 2014 18:08:59 -0000 On 5/3/2014 12:23 PM, Dave Crocker wrote: > On 5/2/2014 1:05 PM, Fred Baker (fred) wrote: > 3. The limitations of DMARC have been well understood, including > by both Yahoo and AOL. There is never any way for the IETF community > to protect against an organization's choosing to apply a protocol in a > way that is known to have damaging effects. I find this philosophy quite concerning since the protocol is by design, offering strong deterministic policies, options and features to select from to both publish and honor -- its part of the protocol logic. Its not there just to "look good" or for show. Its there to be used. Even if only a "small use" case was the purpose, the receivers still had to be ready for it. The problem here is not applying the same protocol principles equally and across all would-be compliant domains. Let me ask, what if a fedex.com employee use this email domain for subscribing to the IETF list? Fedex.com exposes their DKIM signing practice very clearly with both an ADSP "dkim=discardable" and a DMARC "p=reject" policy. They wanted to cover a wider net of either ADSP/DMARC receivers. So why would you treat yahoo.com or facebook.com "p=reject" policy any different than Fedex.com? Facebook.com assigns facebook.com email address now for your account. So its technically possible to use it on a list. At what point do you adjust to a new DKIM+POLICY layered world? > 4. There is, in fact, a draft BCP about DMARC use that was > posted and awaits pursuit, preferably in the IETF.[1] Working on it > got stalled by the gyrations of trying to decide how to process the > DMARC base specification. Perhaps we should focus our energies into > firing up an IETF engine to develop and progress the BCP? Repeating, highlighting, emphasizing in a BCP not to publish restrictive DMARC policies isn't going to solve the problem. -- HLS From nobody Mon May 5 10:55:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835051A00E6; Sat, 3 May 2014 09:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V24GWTYTiZjO; Sat, 3 May 2014 09:23:27 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 487F91A0097; Sat, 3 May 2014 09:23:27 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s43GNIGx012895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 3 May 2014 09:23:21 -0700 Message-ID: <536517EE.6050800@dcrocker.net> Date: Sat, 03 May 2014 09:23:10 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , IETF References: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> In-Reply-To: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 03 May 2014 09:23:22 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-FhAUKzvXMrt2hSYNe--M4nALuE X-Mailman-Approved-At: Mon, 05 May 2014 10:55:13 -0700 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 May 2014 16:23:28 -0000 On 5/2/2014 1:05 PM, Fred Baker (fred) wrote: > As an example of the case that comes to mind, see attached. It is a > message sent to v6ops@ietf.org yesterday. The sender signed it > using DKIM, the IETF changed the message (added some trailing text) > before forwarding it, the receiver (e.g., Cisco IT) attempted to > validate the DKIM signature - and failed. > > It seems to me that we should not approve a procedure that has that > effect, at least without some guidance for mail relay > administrators. I could imagine two forms of guidance: “obey the > end-to-end principle; don’t change the message the originator > sent”, or “if you change a signed message, first validate the > message you received and discard if that fails, change it, and then > sign it yourself, so that a receiver can see who changed it and > validate the outcome”. Fred, Your comments are consonant with the recurring comments of others, so it's worth repeating several fundamental points about them: 1. The so-called "end to end principle" was actually labeled end to end /arguments/. It is a guidance about a design approach that then needs to be tailored to the specifics of the situation. For example, the definition of 'end' varies according to the scenario. With direct, person-to-person email the mailbox is an end point. For EDI over email, it isn't, since there is a further processing sequence after email delivery. So we need to be rather careful when asserting the 'principle'. In the IETF, we've grown fond of tossing out the label as if its mere statement is useful. However it's actual utility only happens as part of a tailored design discussion. Like a protocol, its utility requires being set into motion. 2. In terms of basic email architecture, a mailing list is an end-point. The author specifies the mailing list explicitly. The mail gets /delivered/ to it. A mailing list is not an MTA that is relaying mail; it is an end-user application that /re-/posts it. So a mailing list is really a value-add mechanism that sits above the basic email service. In architectural terms, this is identical to your choosing to forward this note to someone you think should see it. DKIM is meant for transit protection, starting somewhere near the (original) author and ending somewhere near the mailbox of the specified (initial) recipient. In the case of a mailing list, that mailbox belongs to the mailing list. Should a DKIM signature survive your manual forwarding of a message? While it's certainly acceptable for it to survive, it's not reasonable to expect it. Then why should we expect the re-posting by a mailing list to preserve a DKIM signature? Depending upon the policies of a specific mailing list, there are many very good reasons for the changes that are made to the original message. Some of those happen to break a DKIM signature. 3. The limitations of DMARC have been well understood, including by both Yahoo and AOL. There is never any way for the IETF community to protect against an organization's choosing to apply a protocol in a way that is known to have damaging effects. 4. There is, in fact, a draft BCP about DMARC use that was posted and awaits pursuit, preferably in the IETF.[1] Working on it got stalled by the gyrations of trying to decide how to process the DMARC base specification. Perhaps we should focus our energies into firing up an IETF engine to develop and progress the BCP? d/ [1] Using DMARC, https://datatracker.ietf.org/doc/draft-crocker-dmarc-bcp/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon May 5 10:55:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7BA1A08CA; Fri, 2 May 2014 11:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6x8a-NEPAaM; Fri, 2 May 2014 11:49:00 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E6C531A0312; Fri, 2 May 2014 11:48:59 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id lj1so3083417pab.14 for ; Fri, 02 May 2014 11:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MqZdgAQX8idepVTkekPvpo3qA/APtHHA/uawxPBefg8=; b=nPdtwLufNdqBtr6c3+2TpLZLlj9aLCVND4iWWbNBQXqv8qLn6TfVnjJQSf9eD6YnZG /5kCrhx9vMb/g8XW4alQi2m6v0Q3emIEwmnNTVOOnEj3SFkDr0j/mDI33jjSv08wIDwU RYysATbKanZxYDPmUAKjTV3eYjPTreplWfU5g0TroAzmFKahQNisFWoFibVUV5+1aurD 3YXWWCbDfTSaCzv75vKBtmxFIS/s0QxS6ijvWFY8BeoMnmKsz6Lbw+Yylk7WoRJraybI RRPp+uAQCcanlzx8MaDPRjliBz9/xvJwGAewJqoIkXFG4qssF+WB8SEjqrZfUbvyR4ie dcAA== X-Received: by 10.66.119.136 with SMTP id ku8mr37896130pab.121.1399056537588; Fri, 02 May 2014 11:48:57 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id f5sm188208136pat.11.2014.05.02.11.48.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 02 May 2014 11:48:56 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Douglas Otis In-Reply-To: Date: Fri, 2 May 2014 11:48:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <94FD47D7-FA17-425F-8C48-1E8541FEB4D3@gmail.com> References: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/bkx1ldqEteK0EWJtHXikadKnD_A X-Mailman-Approved-At: Mon, 05 May 2014 10:55:32 -0700 Cc: "dmarc@ietf.org" , "Fred Baker \(fred\)" , IETF Subject: Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 May 2014 18:49:01 -0000 On May 2, 2014, at 11:22 AM, Christopher Morrow = wrote: > On Fri, May 2, 2014 at 2:05 PM, Fred Baker (fred) = wrote: >> We have been having a fairly extended discussion, much of which seems = hypothetical - =93I don=92t like DEMARC because I am worried that ... = with mailing lists=94. I wonder if we could take a moment to try it and = see what happens? >>=20 >> As an example of the case that comes to mind, see attached. It is a = message sent to v6ops@ietf.org yesterday. The sender signed it using = DKIM, the IETF changed the message (added some trailing text) before = forwarding it, the receiver (e.g., Cisco IT) attempted to validate the = DKIM signature - and failed. >>=20 >=20 > dkim !=3D dmarc (but maybe that wasn't your point) >=20 >> It seems to me that we should not approve a procedure that has that = effect, at least without some guidance for mail relay administrators. I = could imagine two forms of guidance: =93obey the end-to-end principle; = don=92t change the message the originator sent=94, or =93if you change a = signed message, first validate the message you received and discard if = that fails, change it, and then sign it yourself, so that a receiver can = see who changed it and validate the outcome=94. >>=20 >> Could we actually try such guidance in a sandbox, and document = appropriate procedures for mailing lists? >>=20 >=20 > which mailing list software? or did you mean test a general solution > and document the general solution? Dear Chris and Fred, There is a TPA (third-party authorization using hash labels) draft being = revised aimed specifically at solving this problem without introducing = new demands on mailing-list and other third-party services, or requiring = per destination signatures. The goal is to mitigate disruptions caused = by strict policy requests as possible with DMARC while still allowing = trusted domains (author domains) a means to effectively delist any = authorized source when abuse is detected. Delisting should only occur = after third-party administrators have been allowed to correct the issue. This approach allows author domains fine grain control over third-party = conveyance of initial messages, even over multiple services as can occur = with mailing-lists. It will not increase message size. It can scale to = massive levels having little overhead. Much less overhead than that = required to support SPF or DKIM, the basis of DMARC. Regards, Douglas Otis =20= From nobody Mon May 5 10:55:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03741A6FBE; Fri, 2 May 2014 11:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMjTp-fh_Ldw; Fri, 2 May 2014 11:06:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8511A6FA9; Fri, 2 May 2014 11:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6751; q=dns/txt; s=iport; t=1399053962; x=1400263562; h=from:to:cc:subject:date:message-id:mime-version; bh=sdt4T73+bjbbGvHcnZ52jV/+I3faOVDwFZxEHO42fNA=; b=XhVMIzol0jgzff2o+h+goOR3TBIzO79lNpvLkbDMjTyOFWwAO8gxd+hP AeZekatvVcCYOQl+UhRITWsDhwlyoatAF9SqiFznmnVAv1EfWMqESDAAV MEi0N2M/nzIHciXu7sId0EDtJhq3mlzIAi6/XX6MW1kFHtoNphmY3BoB5 E=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAFbeY1OtJV2Y/2dsb2JhbABagwaBJ8RMgREWdIIlAQEBAwFuCwUNAYEAJwQOBQ4IiCMIyj8XjgEBAU+DK4EVBJEegTmGWZJvgzSBbwcXBhw X-IronPort-AV: E=Sophos;i="4.97,973,1389744000"; d="asc'?eml'208?scan'208,208";a="322031666" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 02 May 2014 18:05:38 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s42I5cm2030832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 May 2014 18:05:38 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.100]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 2 May 2014 13:05:38 -0500 From: "Fred Baker (fred)" To: IETF Thread-Topic: Suggestion: can we test DEMARC deployment with a mailing list? Thread-Index: AQHPZjEeOHoDyq9mZ0azxe/jQ5CmNA== Date: Fri, 2 May 2014 18:05:37 +0000 Message-ID: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.118] Content-Type: multipart/signed; boundary="Apple-Mail=_14DE2FCF-48B6-4191-9AE8-4DE4DDCAA026"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/h8ZvIhhfnlodMKLtY4IaDKw0Y-g X-Mailman-Approved-At: Mon, 05 May 2014 10:55:45 -0700 Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 May 2014 18:06:05 -0000 --Apple-Mail=_14DE2FCF-48B6-4191-9AE8-4DE4DDCAA026 Content-Type: multipart/mixed; boundary="Apple-Mail=_B1EDC711-C498-4E54-8809-16873BFE286C" --Apple-Mail=_B1EDC711-C498-4E54-8809-16873BFE286C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We have been having a fairly extended discussion, much of which seems = hypothetical - =93I don=92t like DEMARC because I am worried that ... = with mailing lists=94. I wonder if we could take a moment to try it and = see what happens? As an example of the case that comes to mind, see attached. It is a = message sent to v6ops@ietf.org yesterday. The sender signed it using = DKIM, the IETF changed the message (added some trailing text) before = forwarding it, the receiver (e.g., Cisco IT) attempted to validate the = DKIM signature - and failed. It seems to me that we should not approve a procedure that has that = effect, at least without some guidance for mail relay administrators. I = could imagine two forms of guidance: =93obey the end-to-end principle; = don=92t change the message the originator sent=94, or =93if you change a = signed message, first validate the message you received and discard if = that fails, change it, and then sign it yourself, so that a receiver can = see who changed it and validate the outcome=94. Could we actually try such guidance in a sandbox, and document = appropriate procedures for mailing lists? --Apple-Mail=_B1EDC711-C498-4E54-8809-16873BFE286C Content-Disposition: attachment; filename="Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01.eml" Content-Type: message/rfc822; x-mac-hide-extension=yes; name="Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01.eml" Content-Transfer-Encoding: 7bit Received: from alln-iport-6.cisco.com (173.37.142.93) by mail.cisco.com (173.37.183.86) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 May 2014 23:02:58 -0500 Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 02 May 2014 04:02:57 +0000 Received: from alln-inbound-g.cisco.com (alln-inbound-g.cisco.com [173.37.147.237]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4242lAq032588 for ; Fri, 2 May 2014 04:02:57 GMT Received-SPF: Pass (alln-inbound-g.cisco.com: domain of owen@delong.com designates 2620:0:930::200:2 as permitted sender) identity=mailfrom; client-ip=2620:0:930::200:2; receiver=alln-inbound-g.cisco.com; envelope-from="owen@delong.com"; x-sender="owen@delong.com"; x-conformance=spf_only; x-record-type="v=spf1" Received-SPF: None (alln-inbound-g.cisco.com: no sender authenticity information available from domain of postmaster@owen.delong.com) identity=helo; client-ip=2620:0:930::200:2; receiver=alln-inbound-g.cisco.com; envelope-from="owen@delong.com"; x-sender="postmaster@owen.delong.com"; x-conformance=spf_only Authentication-Results: alln-inbound-g.cisco.com; dkim=permerror (signature did not verify [final] [TEST]) header.i=@delong.com X-from-outside-Cisco: 2620:0:930::200:2 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A8DhAQCXF2NTlwAAICbJwIAAAJCAgAJagmXGIYETFg4BAQEBAQgWBzyCJQEBAgIBQDkBBAsLRlcGKYgjCAGlHoRboBgRBo4fMweDJIEVigqPKYZij2A X-IronPort-AV: E=Sophos;i="4.97,969,1389744000"; d="scan'208";a="47440180" Received: from owen.delong.com ([IPv6:2620:0:930::200:2]) by alln-inbound-g.cisco.com with ESMTP; 02 May 2014 04:02:56 +0000 Received: from [10.5.16.141] (adsl-69-228-81-237.dsl.pltn13.pacbell.net [69.228.81.237]) (authenticated bits=0) by owen.delong.com (8.14.2/8.14.2) with ESMTP id s423w0ph005146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 1 May 2014 20:58:12 -0700 X-DKIM: Sendmail DKIM Filter v2.8.3 owen.delong.com s423w0ph005146 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=delong.com; s=mail; t=1399003094; bh=3BmcdZ38OhNl5JmDlqOXfEG8pbc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=BYJML+yUEmajx3e9NfYJa3IjBchGe9nNtctRNGU3WuNfijDYPOUqKYY5HSGqX+aSA 52RqRUv/6AlIstCKub+iXF9a+qGdxskOFZ8AmnwUDAFz+r2pzBFU8QXnSe2B6d8TfP QLklDGACNmqaQmeASoPB3FI9q3+8bZO6HhDC+avU= Content-Type: text/plain; charset="windows-1252" Subject: Re: [v6ops] Thoughts on draft-byrne-v6ops-clatip-01 From: Owen DeLong In-Reply-To: <5362CFFC.2040609@bogus.com> Date: Thu, 1 May 2014 20:57:57 -0700 CC: Lorenzo Colitti , "Fred Baker (fred)" , V6 Ops List , "Byrne, Cameron" Content-Transfer-Encoding: quoted-printable Message-ID: References: <40C41DA9-3513-4BC3-B6C9-7A1EEF98BBC7@cisco.com> <5361DBFA.3010403@bogus.com> <5362CFFC.2040609@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (owen.delong.com [192.159.10.2]); Thu, 01 May 2014 20:58:14 -0700 (PDT) Return-Path: owen@delong.com X-MS-Exchange-Organization-AuthSource: xhc-rcd-x12.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 MIME-Version: 1.0 > fec0::/10 was reserved way back in rfc 1884 >=20 > 3879 and 4193 are contemporaneous activities. meany people on this list > were present for them. >=20 > The fact that we did a bad job at something 20 years ago doesn't mean > the problem that we were attempting to address went away. I agree=85 People wanting to do NAT rather than learn how to do things bett= er without it is an education problem which continues to persist to this da= y. Owen --Apple-Mail=_B1EDC711-C498-4E54-8809-16873BFE286C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_B1EDC711-C498-4E54-8809-16873BFE286C-- --Apple-Mail=_14DE2FCF-48B6-4191-9AE8-4DE4DDCAA026 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTY95vbjEdbHIsm0MRAhXbAKCGXe2xmDxXY5hI04hBREL7FG1iFgCfc3EO tG9Phvu/mLgnR/5q2TwtFeo= =SRfU -----END PGP SIGNATURE----- --Apple-Mail=_14DE2FCF-48B6-4191-9AE8-4DE4DDCAA026-- From nobody Mon May 5 10:56:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558DD1A092E; Fri, 2 May 2014 11:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2XDs-VzUYlC; Fri, 2 May 2014 11:22:28 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CF8AB1A0911; Fri, 2 May 2014 11:22:27 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id u14so974599lbd.18 for ; Fri, 02 May 2014 11:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=T7HNnMaUAXs8ZttvrCl2X4d+wT10rQu4jn/fvRkZX5c=; b=bcwLOZpCveBuxTv/CsLnr0/2/UoMRazMOngNMkq6SDNLOiZo1leVS6MhjkXCxV4MCC +IsPk4C+ykdDB+NUuYbSd5CKM4d6Txhkhsy2X2k4MpzkZCHcCGRHPX+QqC5/x7ns9rO1 NkTPuOjnaJr4scjsZdS5IkOr0O6ifv/Qe4jJsNZZ++r4SgPqVKAGJRf1VWmf7A9J3+3c LdSQZpFKqx9O8H+uO/+6Q7mRlHl6MKquzbzGLa33Z3PwdId9xFZjoYQdAX7AJ4xRzdb6 jMvYEcYG/CxGg/RZc1BBmEsPO7WjjV6Tp5Jl0t3TdoHhlTVKBeehHXZ0/XQ9i4gXnmjs bRzA== MIME-Version: 1.0 X-Received: by 10.112.100.231 with SMTP id fb7mr1323587lbb.56.1399054944722; Fri, 02 May 2014 11:22:24 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.114.95.74 with HTTP; Fri, 2 May 2014 11:22:24 -0700 (PDT) In-Reply-To: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> References: <28671EE8-A8B9-40D1-9268-527A8FFC34AD@cisco.com> Date: Fri, 2 May 2014 14:22:24 -0400 X-Google-Sender-Auth: eWe6S61EkJB_DVeWSVuQR0vBeZo Message-ID: From: Christopher Morrow To: "Fred Baker (fred)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/pA4f4N2dZuE3gAo3RcNNKwCUPeA X-Mailman-Approved-At: Mon, 05 May 2014 10:56:06 -0700 Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Suggestion: can we test DEMARC deployment with a mailing list? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 02 May 2014 18:22:29 -0000 On Fri, May 2, 2014 at 2:05 PM, Fred Baker (fred) wrote: > We have been having a fairly extended discussion, much of which seems hyp= othetical - =E2=80=9CI don=E2=80=99t like DEMARC because I am worried that = ... with mailing lists=E2=80=9D. I wonder if we could take a moment to try = it and see what happens? > > As an example of the case that comes to mind, see attached. It is a messa= ge sent to v6ops@ietf.org yesterday. The sender signed it using DKIM, the I= ETF changed the message (added some trailing text) before forwarding it, th= e receiver (e.g., Cisco IT) attempted to validate the DKIM signature - and = failed. > dkim !=3D dmarc (but maybe that wasn't your point) > It seems to me that we should not approve a procedure that has that effec= t, at least without some guidance for mail relay administrators. I could im= agine two forms of guidance: =E2=80=9Cobey the end-to-end principle; don=E2= =80=99t change the message the originator sent=E2=80=9D, or =E2=80=9Cif you= change a signed message, first validate the message you received and disca= rd if that fails, change it, and then sign it yourself, so that a receiver = can see who changed it and validate the outcome=E2=80=9D. > > Could we actually try such guidance in a sandbox, and document appropriat= e procedures for mailing lists? > which mailing list software? or did you mean test a general solution and document the general solution? > > > From jazzme48912@yahoo.com Sun May 11 04:48:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324121A0318 for ; Sun, 11 May 2014 04:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laeIZpHO8iZJ for ; Sun, 11 May 2014 04:48:33 -0700 (PDT) Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) by ietfa.amsl.com (Postfix) with ESMTP id 673A11A031B for ; Sun, 11 May 2014 04:48:33 -0700 (PDT) Received: from [98.139.215.143] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 11 May 2014 11:48:27 -0000 Received: from [98.139.212.228] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 11 May 2014 11:48:27 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 11 May 2014 11:48:27 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 544043.39105.bm@omp1037.mail.bf1.yahoo.com Received: (qmail 67425 invoked by uid 60001); 11 May 2014 11:48:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1399808907; bh=RWuBXmbuuRT/+Bx9nK6mupqxd+BkzlrXoqUOnSs9fzQ=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=y0K0nR22SRX0iDLTHgkShWL1QLaW9F0zCX+vK0qgl3t86VMNpWSURdFElFlE3EH8bAuQP5qk1EXDNt8M1S/TCNpZTpToCyCLudu/CQbpjDNZFPjMiZiqG0s2/8YsB5a+IvRgqwyoRMnjp//A3xxMk5cmxSkJ8w5zLxr/i0gqe0s= X-YMail-OSG: bRYJsrUVM1laQ2Y0dCoheoNglBxtvip0aCcI2PhpafDXAWr LJG2RRcpC7HWNZYKFMVttbygA5e2UdBv4MDRuixPYC9PKKFH.F1aIOSdqOv5 TAfbfSQ1zF6srBRvUXqHv_Lo1T3KJbQ75BzOloPWHc8fWSvvNnQTt_ZZzjnK 21z4dgBbYbhZswKCUg8Ug45AFTu7NPSgCkbMF0BjVM4.hfdm8jVKxwyvmm2Y ZuN5.qHayEGwbGwKDvGhCQ3b2LVb4mmX3CH2SCfT2U6ryZ75xJ7ltsOAVEFV FcBzTDQ1JXY2r5rprSzvKtqk.cN5j4O.KZt6HtwfsR47OOVolIHaT2i2vDgT 7zwIkqJmr9kIB66rw2Rnn0RqDYwa7i3ph_uS_rIRcvYAaEQAZMG.FSCEmh4z NZQ_pp7WfxC4SK9gkhU_xMDfFrDFAnEFMDb36HsvS3LXl1wyAqo2lyR3unpR aJxJDHAQzOmBBdkcVddnjNLG90vc0jBchKxCYFvsKYzHxUYE6J0SNYqjW_dG EkWVLbeLu6yzcGW__sXbEnXl_ye3Pj4XBn2tY0pnEoNlxmNU- Received: from [75.7.194.174] by web160503.mail.bf1.yahoo.com via HTTP; Sun, 11 May 2014 04:48:27 PDT X-Rocket-MIMEInfo: 002.001, VGhlIGluZGlmZmVyZW5jZSBvZiBZYWhvbyB0byB0aGUgY29uc2VxdWVuY2VzIG9mIHRoaXMgYXJlIHN0YWdnZXJpbmcgLSBhbmQgJ1lhaG9vIHNwYW0nIGhhcyBpbmNyZWFzZWQgZXhwb25lbnRpYWxseSBzaW5jZSB0aGVuLiBTb21lICdpbXByb3ZlbWVudC4nICBBTllPTkUgaGF2ZSBhbnkgc3VnZ2VzdGlvbnMgb24gd2hhdCBJIGNhbiBkbyBzbyB0aGF0IEkgZG9uJ3QgaGF2ZSB0byBrZWVwICdyZS1zaWduaW5nJyB1cCB3aXRoIGEgZGlmZmVyZW50IGVtYWlsIGFjY291bnQgZXZlcnkgMyBvciA0IGRheXMgdG8BMAEBAQE- X-Mailer: YahooMailClassic/567 YahooMailWebService/0.8.188.663 Message-ID: <1399808907.24204.YahooMailBasic@web160503.mail.bf1.yahoo.com> Date: Sun, 11 May 2014 04:48:27 -0700 (PDT) From: eugene hayhoe To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hA-gxhvKza_UljUa_EblkWXqBSo Subject: [dmarc-ietf] Anyone have any clue how I can use my email list memberships without spending years learning computer programming? X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 11 May 2014 11:56:16 -0000 The indifference of Yahoo to the consequences of this are staggering - and 'Yahoo spam' has increased exponentially since then. Some 'improvement.' ANYONE have any suggestions on what I can do so that I don't have to keep 're-signing' up with a different email account every 3 or 4 days to stay on the list? Thanks, Gene From giovino@people.ops-trust.net Sun May 11 12:48:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378201A0340 for ; Sun, 11 May 2014 12:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KH3tXbpd1wEv for ; Sun, 11 May 2014 12:48:02 -0700 (PDT) Received: from people.ops-trust.net (people.usa5.ops-trust.net [199.168.91.182]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7F1A033D for ; Sun, 11 May 2014 12:48:02 -0700 (PDT) Received: from MBP.local (c-71-227-241-5.hsd1.wa.comcast.net [71.227.241.5]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: giovino) by people.ops-trust.net (Postfix) with ESMTPSA id 49E021468139 for ; Sun, 11 May 2014 19:47:56 +0000 (UTC) Message-ID: <536FD3EB.7090104@people.ops-trust.net> Date: Sun, 11 May 2014 12:47:55 -0700 From: Gabriel Iovino User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/n4tOn9AgEAEEKvJYRBjgYQgJCL4 X-Mailman-Approved-At: Mon, 12 May 2014 08:53:15 -0700 Subject: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2014 19:49:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, Last week I was having a conversation with a familiar person on this mailing list and I was expressing my disappointment with the negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was encouraged to share these thoughts on this list. I believe email is already broken[3][4][5][6] and DMARC "p=reject" moves us towards a position where email is "less" broken. Will there be some bumps[7] along the road? Sure but a few bumps are no reason to leave email in it's current state. I applaud Yahoo and AOL for taking the first few punches and I look forward to the day when Google and Microsoft follow their lead. Thank you for all the hard work you have done to improve the state of email! Gabriel Iovino [1] Yahoo DMARC policy https://help.yahoo.com/kb/postmaster/yahoo-dmarc-policy-sln24050.html [2] AOL Mail updates DMARC policy to 'reject' http://postmaster-blog.aol.com/2014/04/22/aol-mail-updates-dmarc-policy-to-reject/ [3] Identifying fraudulent "phishing" email http://support.apple.com/kb/ht4933 [4] How to Find Out Where a Link Will Take You in iPhone Mail http://email.about.com/od/iphonemailtips/qt/et_see_url.htm [5] Obtaining Email Headers for Spam/Phishing Notification https://community.shaw.ca/docs/DOC-1132 [6] Check It Before You Click It - Phishing, Malicious Links & Spoofed Headers http://grok.lsu.edu/article.aspx?articleId=17107 [7] Mailman April 2014 Archives by thread http://lists.dmarc.org/pipermail/dmarc-discuss/2014-April/thread.html -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlNv0+cACgkQwqygxIz+pTuVqQCeNYB4Uhtgd7Q8YqQKQTfcFkDX a20An0rQ6xmBzGP6tcHAjcs/Mzv1JWWx =0UWT -----END PGP SIGNATURE----- From nobody Mon May 12 12:16:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1630F1A0774 for ; Mon, 12 May 2014 12:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv6OwBABuh5D for ; Mon, 12 May 2014 12:16:18 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 85B131A0772 for ; Mon, 12 May 2014 12:16:18 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kp14so9141220pab.26 for ; Mon, 12 May 2014 12:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E07xpU38yYPnSNKktCF9qrWN9nPKXrz+EyQJIJJwanQ=; b=gtdNAp8z3/kTmrm4MMRgbTz9P/74NTcsRUQ5Im7AbZoeXdYGMxnp3ap0TAy5FK5TMO faiYcQa3NN51cHzONCssOzg5OMoi6XcBmZSq6xXWlI9vff9i8hSPSt3lAMZckRGmGRiw iING6k4+at5O3IRva4LlWn5ln3rUW3oTDDN1TYKeG5lOBaZVtNtf/42ZhIaZHVwtpAnU Tc0JMeoNddEDehzcPSFFAgFKjCU4/DMIuGy/8QjOTJmxH0w4BHoIGXwLZicSM93Rqhmj 08+ITCz5lQtWsPQIvG2llS4ywzHCYgfcKi2fimi23ujYZTj6N0R4UjK5EFFgSPpu+CuY kVNw== X-Received: by 10.66.192.225 with SMTP id hj1mr59447307pac.142.1399922172580; Mon, 12 May 2014 12:16:12 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id xz7sm51817060pac.3.2014.05.12.12.16.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 May 2014 12:16:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Douglas Otis In-Reply-To: <536FD3EB.7090104@people.ops-trust.net> Date: Mon, 12 May 2014 12:16:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> References: <536FD3EB.7090104@people.ops-trust.net> To: Gabriel Iovino X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Olu-hhi1EfctWKI6033ZpgJ25mM Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 19:16:20 -0000 On May 11, 2014, at 12:47 PM, Gabriel Iovino = wrote: > Greetings, >=20 > Last week I was having a conversation with a familiar person on this > mailing list and I was expressing my disappointment with the > negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was > encouraged to share these thoughts on this list. >=20 > I believe email is already broken[3][4][5][6] and DMARC "p=3Dreject" > moves us towards a position where email is "less" broken. Will there > be some bumps[7] along the road? Sure but a few bumps are no reason to > leave email in it's current state. >=20 > I applaud Yahoo and AOL for taking the first few punches and I look > forward to the day when Google and Microsoft follow their lead. >=20 > Thank you for all the hard work you have done to improve the state of > email! >=20 > Gabriel Iovino Dear Gabriel, While email is generally abused, DMARC's intent was to better protect = transactional email which Yahoo may put in jeopardy. There will be a = forthcoming draft to allow Author-Domains a means to request restrictive = policies against normal user email accounts without disrupting very = legitimate communications. The draft places the burden of mitigating = disruption on those making the requests. Otherwise, it won't be too = much longer before even DMARC is ignored when misapplied against user = accounts.=20 Yahoo has suffered from a lack of security permitting millions of their = users accounts to be compromised. A better approach would not use = DMARC, but would federate third-party services they can see their = customers employ. The federation of email, much like that of XMPP, = would be an effective means to exclude bad actors without breaking = mailing-list and other third-party email services. As it is now, it = seems Yahoo only protects their own mailing-list operations which really = does not warrant a basis for applauding such efforts. Regards, Douglas Otis= From nobody Mon May 12 12:31:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3CE1A07CD for ; Mon, 12 May 2014 12:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxiQGNgRyvdD for ; Mon, 12 May 2014 12:30:59 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C2B411A07CF for ; Mon, 12 May 2014 12:30:59 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id s7so7623735qap.34 for ; Mon, 12 May 2014 12:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q0ULXcPPX+J+F6ifytr19qW/zIRfCHDFOXHFS7sFxF0=; b=kwblW/q9WqrnWbFsXww3Z0IWb/2bvul7iZlhZqn5WESZrHGCBxFpu5CD/EQOE0wudY DJLqw1DZP9B/WRoMUw6peut8EnKbgfwcLvUtnyPLqCYpTeqG7WqU4NU+q6CbMqe3vR1f n3MQxblSvy/Gaxm+82VYBHe4ljqjt5zm1mz1KbI8m6KeENLgHmhCwbFETWX/t8mxiVJU ramDwJ+gPt2yATm/g95EDlVt/d1iTnEEmg4BWYiFayd1BskBawAEPAuLpLg+Nm8OoF+R IjGaLAY4el/jy4Bm9G4tvIPt/UCLHspC9zrqpRnFIO85JK2xwqFWGzS2l58bFwCamXN/ zlEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q0ULXcPPX+J+F6ifytr19qW/zIRfCHDFOXHFS7sFxF0=; b=HWDX6aTVUnCcKAyLxvCL98/FnaEEXk0zGGuRcz0hcdoUjEMKiwcG6HKW4HdLJZQER/ wbRQfkqclI+t7yUYFjblxBrw23Wy4u/qCrYg72AbCYjdVS0rca50JoaEMFVJruFNYF6G Ab/6OQD83mB8i0OJrgtxXDa4LhJMHVy79VAw7EsheXM08dofOrZlI5qdAbYoIKx8ns6a c+p/fyhCxs7DI1TIUAk17JbwJUKB749SuHmxPUaIjcGy3MN/I0PsoJC4IjsxqS9p2AYk jQa/f4HuwthU2WQS1VMKlI0NXCkhOLRj0EE/7IT75aBFZEbF0p1T5oU4pTJ7Co2BQHr4 TppQ== X-Gm-Message-State: ALoCoQnQqv0WNGqF/Volp+3aCURptN0RF30/byivOQtkQoT5DSwwf1cSMKdWCR4We09sUCibVY6K MIME-Version: 1.0 X-Received: by 10.224.167.209 with SMTP id r17mr32309737qay.1.1399923053584; Mon, 12 May 2014 12:30:53 -0700 (PDT) Received: by 10.229.36.200 with HTTP; Mon, 12 May 2014 12:30:53 -0700 (PDT) In-Reply-To: <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> Date: Mon, 12 May 2014 12:30:53 -0700 Message-ID: From: Brandon Long To: Douglas Otis Content-Type: multipart/alternative; boundary=089e0149cd7452dc9104f938fc39 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GsMQGfYxl84jv7O1ip3eEoMDBhw Cc: Gabriel Iovino , dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 19:31:01 -0000 --089e0149cd7452dc9104f938fc39 Content-Type: text/plain; charset=UTF-8 On Mon, May 12, 2014 at 12:16 PM, Douglas Otis wrote: > > On May 11, 2014, at 12:47 PM, Gabriel Iovino > wrote: > > > Greetings, > > > > Last week I was having a conversation with a familiar person on this > > mailing list and I was expressing my disappointment with the > > negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was > > encouraged to share these thoughts on this list. > > > > I believe email is already broken[3][4][5][6] and DMARC "p=reject" > > moves us towards a position where email is "less" broken. Will there > > be some bumps[7] along the road? Sure but a few bumps are no reason to > > leave email in it's current state. > > > > I applaud Yahoo and AOL for taking the first few punches and I look > > forward to the day when Google and Microsoft follow their lead. > > > > Thank you for all the hard work you have done to improve the state of > > email! > > > > Gabriel Iovino > > Dear Gabriel, > > While email is generally abused, DMARC's intent was to better protect > transactional email which Yahoo may put in jeopardy. There will be a > forthcoming draft to allow Author-Domains a means to request restrictive > policies against normal user email accounts without disrupting very > legitimate communications. The draft places the burden of mitigating > disruption on those making the requests. Otherwise, it won't be too much > longer before even DMARC is ignored when misapplied against user accounts. > Where can we learn more about this? Yahoo has suffered from a lack of security permitting millions of their > users accounts to be compromised. A better approach would not use DMARC, > but would federate third-party services they can see their customers > employ. The federation of email, much like that of XMPP, would be an > effective means to exclude bad actors without breaking mailing-list and > other third-party email services. As it is now, it seems Yahoo only > protects their own mailing-list operations which really does not warrant a > basis for applauding such efforts. > I feel that there is a theory that has gone around as to why AOL and Yahoo! have done this, but I don't know as there has been any proof of that or acknowledgement. For one, the level of hijacking we see, and the level of spam I personally receive that has at least a From name of someone I know, lead me to question that theory. Also, unless you know otherwise, my understanding was that Yahoo Groups didn't have any mitigation of DMARC policies until recently, and they implemented the same (and only currently useful) mitigation of re-writing the From header, and did so well after yahoo.com went to REJECT. Also... federation across millions of servers? That seems... unlikely. Brandon --089e0149cd7452dc9104f938fc39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, May 12, 2014 at 12:16 PM, Douglas Otis &l= t;doug.mtview@gm= ail.com> wrote:

On May 11, 2014, at 12:47 PM, Gabriel Iovino <giovino@people.ops-trust.net> wrote:

> Greetings,
>
> Last week I was having a conversation with a familiar person on this > mailing list and I was expressing my disappointment with the
> negativity towards Yahoo[1] and AOL[2] for "breaking" email.= I was
> encouraged to share these thoughts on this list.
>
> I believe email is already broken[3][4][5][6] and DMARC "p=3Dreje= ct"
> moves us towards a position where email is "less" broken. Wi= ll there
> be some bumps[7] along the road? Sure but a few bumps are no reason to=
> leave email in it's current state.
>
> I applaud Yahoo and AOL for taking the first few punches and I look > forward to the day when Google and Microsoft follow their lead.
>
> Thank you for all the hard work you have done to improve the state of<= br> > email!
>
> Gabriel Iovino

Dear Gabriel,

While email is generally abused, DMARC's intent was to better protect t= ransactional email which Yahoo may put in jeopardy. =C2=A0There will be a f= orthcoming draft to allow Author-Domains a means to request restrictive pol= icies against normal user email accounts without disrupting very legitimate= communications. =C2=A0The draft places the burden of mitigating disruption= on those making the requests. =C2=A0Otherwise, it won't be too much lo= nger before even DMARC is ignored when misapplied against user accounts.

Where can we learn more about this?=C2=A0<= /div>

Yahoo has suffered from a lack of security permitting millions of their use= rs accounts to be compromised. =C2=A0A better approach would not use DMARC,= but would federate third-party services they can see their customers emplo= y. =C2=A0The federation of email, much like that of XMPP, would be an effec= tive means to exclude bad actors without breaking mailing-list and other th= ird-party email services. =C2=A0As it is now, it seems Yahoo only protects = their own mailing-list operations which really does not warrant a basis for= applauding such efforts.

I feel that there is a theory that has gon= e around as to why AOL and Yahoo! have done this, but I don't know as t= here has been any proof of that or acknowledgement. =C2=A0For one, the leve= l of hijacking we see, and the level of spam I personally receive that has = at least a From name of someone I know, lead me to question that theory.

Also, unless you know otherwise, my understanding was t= hat Yahoo Groups didn't have any mitigation of DMARC policies until rec= ently, and they implemented the same (and only currently useful) mitigation= of re-writing the From header, and did so well after yahoo.com went to REJECT.

Also... federation across millions of servers? =C2=A0Th= at seems... unlikely.

Brandon
--089e0149cd7452dc9104f938fc39-- From nobody Tue May 13 16:38:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506121A076E for ; Mon, 12 May 2014 13:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sacjCljX2zO7 for ; Mon, 12 May 2014 13:44:27 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4E31A033A for ; Mon, 12 May 2014 13:44:27 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.234.87]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4CKi50D009147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2014 13:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1399927456; bh=qT1AP8ogV+l7vwUONkGmprHVJfEYVhhnnH45AyL/wDI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2O6LAueRIhnZXZKd55LuRATXL5WB4ygmebrtQZMquZlCKXeksX61r1jbK5yR6gjsY Zcqienwy+Gz0xYpMpcTqKXpgwavs5E82zc73vMXsFSd4HI87b5RhvO/0UORHMlB+RZ 9ZK/xrFlhfDsqVYU5Iv0EyzHs0lnobeiGkfTwhYw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1399927456; i=@elandsys.com; bh=qT1AP8ogV+l7vwUONkGmprHVJfEYVhhnnH45AyL/wDI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=w0NcSs55/yjCNP51/SbcuiS2FFhXVny4BV2hGEqCqg/a6YZRGYfTJ4T+WmcdqSPHX u/v5D9A6edJodHJuvlWb+wPFOKhAyIWi/8Fhdonbt9xVxM/YYt++3Ad/J36jsTdiID 1q3uJ4gju99V8sxZoy7LGfWcXlsk603XDrPoUpsw= Message-Id: <6.2.5.6.2.20140512131712.0b86a730@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 12 May 2014 13:38:37 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ul5JVkFTplRxyJpaWLl3diNM5AY X-Mailman-Approved-At: Tue, 13 May 2014 16:38:39 -0700 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 20:44:28 -0000 Hi Doug, At 12:16 12-05-2014, Douglas Otis wrote: >be compromised. A better approach would not use DMARC, but would >federate third-party services they can see their customers >employ. The federation of email, much like that of XMPP, would be >an effective means to exclude bad actors without breaking >mailing-list and other third-party email services. As it is now, it >seems Yahoo only protects their own Is federation effective in excluding bad stuff? Bad stuff also occurs in closed systems (see https://support.twitter.com/groups/56-policies-violations/topics/238-report-a-violation/articles/64986-reporting-spam-on-twitter ). XMPP has been mentioned previously. There wasn't any information provided to assess whether it does exclude bad stuff. Regards, S. Moonesamy From nobody Thu May 22 13:21:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA0B1A02F2 for ; Thu, 22 May 2014 13:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTmvGW9VvNAL for ; Thu, 22 May 2014 13:21:50 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA6C1A030F for ; Thu, 22 May 2014 13:21:50 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so6728334qgd.1 for ; Thu, 22 May 2014 13:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=CCRxxL9LnFYFFXvUT/ksNTc0f0bI5ZVxdg6YZOvW0Pw=; b=JAZ4EWm1IXZAoT+dGxGtlGljJaosZr1LovLGzK8J6Nh7ru7ZLMkFzorS/9CUuJ2aTI H0Li/70nMU0ozebrLnNoSBG2v71ErU3jZQKOCloFzgYiqJnyDWFQUAa6nK3VhNjovWrE 96gkYpBXHg+r9TzCnpAtxnpiMZO5VXnW3yRGJb54aEAuanJsucivszaIDoj3qpSGRczR rEzhvDlbL0h2T/4WC4VOevhr0VSGiHn6wpL/GRP64T/30tPgqTGCasgnzvDMghTkXj65 UiIGndpsxhd+Y44JFoX2HkxKjOdBAgAdT9dm9p5f25hyd0SxV2nX1u9/Dpba8iBZP7WW 3RpA== X-Received: by 10.224.129.135 with SMTP id o7mr288248qas.18.1400790108659; Thu, 22 May 2014 13:21:48 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id c90sm537515qgd.3.2014.05.22.13.21.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 13:21:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7CB085A5-3895-4027-AD99-AB48AC211D20" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Thu, 22 May 2014 13:21:46 -0700 Message-Id: <5EC0167B-FBC2-4C8E-A1FC-88E0E5537352@gmail.com> References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> To: Brandon Long X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jp-7My3rKmVvmAaO65egEncZVCc Cc: Gabriel Iovino , dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 20:21:53 -0000 --Apple-Mail=_7CB085A5-3895-4027-AD99-AB48AC211D20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Brandon,=20 See comments inline: On May 12, 2014, at 12:30 PM, Brandon Long wrote: > On Mon, May 12, 2014 at 12:16 PM, Douglas Otis = wrote: >=20 > On May 11, 2014, at 12:47 PM, Gabriel Iovino = wrote: >=20 > > Greetings, > > > > Last week I was having a conversation with a familiar person on this > > mailing list and I was expressing my disappointment with the > > negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was > > encouraged to share these thoughts on this list. > > > > I believe email is already broken[3][4][5][6] and DMARC "p=3Dreject" > > moves us towards a position where email is "less" broken. Will there > > be some bumps[7] along the road? Sure but a few bumps are no reason = to > > leave email in it's current state. > > > > I applaud Yahoo and AOL for taking the first few punches and I look > > forward to the day when Google and Microsoft follow their lead. > > > > Thank you for all the hard work you have done to improve the state = of > > email! > > > > Gabriel Iovino >=20 > Dear Gabriel, >=20 > While email is generally abused, DMARC's intent was to better protect = transactional email which Yahoo may put in jeopardy. There will be a = forthcoming draft to allow Author-Domains a means to request restrictive = policies against normal user email accounts without disrupting very = legitimate communications. The draft places the burden of mitigating = disruption on those making the requests. Otherwise, it won't be too = much longer before even DMARC is ignored when misapplied against user = accounts. >=20 > Where can we learn more about this? An update is pending recovery of xml.resource.org/public/rfc/bibxml/. = You don't miss it until it is gone. :^( I should have been more = proactive about transferring reference content. > Yahoo has suffered from a lack of security permitting millions of = their users accounts to be compromised. A better approach would not use = DMARC, but would federate third-party services they can see their = customers employ. The federation of email, much like that of XMPP, = would be an effective means to exclude bad actors without breaking = mailing-list and other third-party email services. As it is now, it = seems Yahoo only protects their own mailing-list operations which really = does not warrant a basis for applauding such efforts. >=20 > I feel that there is a theory that has gone around as to why AOL and = Yahoo! have done this, but I don't know as there has been any proof of = that or acknowledgement. For one, the level of hijacking we see, and = the level of spam I personally receive that has at least a =46rom name = of someone I know, lead me to question that theory. I have notified several friends that their accounts were compromised. = Most did not like having to change their password.=20 > Also, unless you know otherwise, my understanding was that Yahoo = Groups didn't have any mitigation of DMARC policies until recently, and = they implemented the same (and only currently useful) mitigation of = re-writing the =46rom header, and did so well after yahoo.com went to = REJECT. Rewriting the =46rom header field in itself is disruptive. This = prevents review of prior conversations from an individual. Often you = might remember who said something without recalling some of the details. > Also... federation across millions of servers? That seems... = unlikely. Federation simply means sending servers authenticate their domain and = allow receivers to decide whether they wish to disallow messaging from = unknown domains. That feature is sorely missing from SMTP. In this = case, it only comes into play for third-party servers used by users of = the Author-Domain asserting a DMARC policy request. The scale of this = is likely to be in the area of about 30K. The exception list is = something the Author-Domain feedback processing should be able to handle = with negligible effort. DMARC Author-Domain responding to a single DNS transaction for = non-aligned domains provides two important benefits. TPA helps curb the = growth of "abuse" feedback that cooperating receivers might wish to = provide. Secondly, TPA also prevents disrupting the tens of thousands = of legitimate services that might be sending on behalf of their client = and properly indicate their relationship in the Sender header field. Of = course, TPA is also able to check the List-ID to better ensure the = origination of the message. In any case, only sources that authenticate = will be granted exceptions. This could be described as a type of = federation. Think of this as circling the wagons in response to = overwhelming problems.=20 Regards, Douglas Otis= --Apple-Mail=_7CB085A5-3895-4027-AD99-AB48AC211D20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Brandon, 
See comments = inline:

On May 12, 2014, at 12:30 PM, = Brandon Long <blong@google.com> = wrote:

On Mon, May 12, 2014 at = 12:16 PM, Douglas Otis <doug.mtview@gmail.com> wrote:

On May 11, 2014, at 12:47 PM, Gabriel Iovino <giovino@people.ops-trust.net<= /a>> wrote:

> Greetings,
>
> Last week I was having a conversation with a familiar person on = this
> mailing list and I was expressing my disappointment with the
> negativity towards Yahoo[1] and AOL[2] for "breaking" email. I = was
> encouraged to share these thoughts on this list.
>
> I believe email is already broken[3][4][5][6] and DMARC = "p=3Dreject"
> moves us towards a position where email is "less" broken. Will = there
> be some bumps[7] along the road? Sure but a few bumps are no reason = to
> leave email in it's current state.
>
> I applaud Yahoo and AOL for taking the first few punches and I = look
> forward to the day when Google and Microsoft follow their lead.
>
> Thank you for all the hard work you have done to improve the state = of
> email!
>
> Gabriel Iovino

Dear Gabriel,

While email is generally abused, DMARC's intent was to better protect = transactional email which Yahoo may put in jeopardy.  There will be = a forthcoming draft to allow Author-Domains a means to request = restrictive policies against normal user email accounts without = disrupting very legitimate communications.  The draft places the = burden of mitigating disruption on those making the requests. =  Otherwise, it won't be too much longer before even DMARC is = ignored when misapplied against user accounts.


An update = is pending recovery of xml.resource.org/publi= c/rfc/bibxml/. You don't miss it until it is gone. :^(  I = should have been more proactive about transferring reference = content.

Yahoo has suffered from a lack of security permitting millions of their = users accounts to be compromised.  A better approach would not use = DMARC, but would federate third-party services they can see their = customers employ.  The federation of email, much like that of XMPP, = would be an effective means to exclude bad actors without breaking = mailing-list and other third-party email services.  As it is now, = it seems Yahoo only protects their own mailing-list operations which = really does not warrant a basis for applauding such efforts.

I feel that there is a theory that has = gone around as to why AOL and Yahoo! have done this, but I don't know as = there has been any proof of that or acknowledgement.  For one, the = level of hijacking we see, and the level of spam I personally receive = that has at least a =46rom name of someone I know, lead me to question = that theory.

I = have notified several friends that their accounts were compromised. =  Most did not like having to change their = password. 

Also, unless you know otherwise, my understanding was that Yahoo = Groups didn't have any mitigation of DMARC policies until recently, and = they implemented the same (and only currently useful) mitigation of = re-writing the =46rom header, and did so well after yahoo.com went to = REJECT.

Rewriting = the =46rom header field in itself is disruptive.  This prevents = review of prior conversations from an individual.  Often you might = remember who said something without recalling some of the = details.

Also... federation across millions of = servers?  That seems... = unlikely.

Federation = simply means sending servers authenticate their domain and allow = receivers to decide whether they wish to disallow messaging from unknown = domains.  That feature is sorely missing from SMTP.  In this = case, it only comes into play for third-party servers used by users of = the Author-Domain asserting a DMARC policy request.  The scale of = this is likely to be in the area of about 30K.  The exception list = is something the Author-Domain feedback processing should be able to = handle with negligible effort.

DMARC = Author-Domain responding to a single DNS transaction for non-aligned = domains provides two important benefits.  TPA helps curb the growth = of "abuse" feedback that cooperating receivers might wish to provide. =  Secondly, TPA also prevents disrupting the tens of thousands of = legitimate services that might be sending on behalf of their client and = properly indicate their relationship in the Sender header field. =  Of course, TPA is also able to check the List-ID to better ensure = the origination of the message. In any case, only sources that = authenticate will be granted exceptions.  This could be described = as a type of federation.  Think of this as circling the wagons in = response to overwhelming = problems. 

Regards,
Douglas = Otis
= --Apple-Mail=_7CB085A5-3895-4027-AD99-AB48AC211D20-- From nobody Thu May 22 14:03:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA0E1A02DE for ; Thu, 22 May 2014 14:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA6f1JjLbxLb for ; Thu, 22 May 2014 14:03:53 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0FD1A0283 for ; Thu, 22 May 2014 14:03:52 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3gZNbl2dvXz5Mhcw; Thu, 22 May 2014 23:03:47 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3gZNbl124Zz5Mh9k; Thu, 22 May 2014 23:03:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id B555A12329B; Thu, 22 May 2014 23:03:46 +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 uSezI7d3KPdK; Thu, 22 May 2014 23:03:41 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id CAD9C122E9C; Thu, 22 May 2014 23:03:40 +0200 (CEST) Message-ID: <537E662C.8060706@sonnection.nl> Date: Thu, 22 May 2014 23:03:40 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Douglas Otis , Brandon Long References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> <5EC0167B-FBC2-4C8E-A1FC-88E0E5537352@gmail.com> In-Reply-To: <5EC0167B-FBC2-4C8E-A1FC-88E0E5537352@gmail.com> Content-Type: multipart/alternative; boundary="------------080402000407060701020601" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1400792627; bh=F2FRk4i01e8rhklwhb5lmuaaWNS8seKkQSo1KOcvec8=; h=Message-ID:Date:From:To:Subject:From; b=Y81mCUOtDySaeJJT8WUZL9QiFZrM1ZE8UHwFWLhpdr/wND4z+N+e6CybF5Zr9qn5y Gyq9Jlo+J6FZzYg77StizaasiCEQJWv/Roi7zxp8YORzVv1J8qvAKz2TDUvb4d8Sj5 Cos4Myn582c5YYE9UgplVYN3QmJl6bN6V7mGmuJs= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3gZNbl2dvXz5Mhcw Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/g13ln_0CoWrOZDKrWREUEIg2MGY Cc: Gabriel Iovino , dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 21:03:56 -0000 This is a multi-part message in MIME format. --------------080402000407060701020601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Doug, On 05/22/2014 10:21 PM, Douglas Otis wrote: > Dear Brandon, > See comments inline: > > On May 12, 2014, at 12:30 PM, Brandon Long > wrote: > >> On Mon, May 12, 2014 at 12:16 PM, Douglas Otis > > wrote: >> >> >> On May 11, 2014, at 12:47 PM, Gabriel Iovino >> > > wrote: >> >> > Greetings, >> > >> > Last week I was having a conversation with a familiar person on >> this >> > mailing list and I was expressing my disappointment with the >> > negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was >> > encouraged to share these thoughts on this list. >> > >> > I believe email is already broken[3][4][5][6] and DMARC "p=reject" >> > moves us towards a position where email is "less" broken. Will >> there >> > be some bumps[7] along the road? Sure but a few bumps are no >> reason to >> > leave email in it's current state. >> > >> > I applaud Yahoo and AOL for taking the first few punches and I look >> > forward to the day when Google and Microsoft follow their lead. >> > >> > Thank you for all the hard work you have done to improve the >> state of >> > email! >> > >> > Gabriel Iovino >> >> Dear Gabriel, >> >> While email is generally abused, DMARC's intent was to better >> protect transactional email which Yahoo may put in jeopardy. >> There will be a forthcoming draft to allow Author-Domains a >> means to request restrictive policies against normal user email >> accounts without disrupting very legitimate communications. The >> draft places the burden of mitigating disruption on those making >> the requests. Otherwise, it won't be too much longer before even >> DMARC is ignored when misapplied against user accounts. >> >> >> Where can we learn more about this? > > An update is pending recovery of xml.resource.org/public/rfc/bibxml/ > . You don't miss it until > it is gone. :^( I should have been more proactive about transferring > reference content. > >> Yahoo has suffered from a lack of security permitting millions of >> their users accounts to be compromised. A better approach would >> not use DMARC, but would federate third-party services they can >> see their customers employ. The federation of email, much like >> that of XMPP, would be an effective means to exclude bad actors >> without breaking mailing-list and other third-party email >> services. As it is now, it seems Yahoo only protects their own >> mailing-list operations which really does not warrant a basis for >> applauding such efforts. >> >> >> I feel that there is a theory that has gone around as to why AOL and >> Yahoo! have done this, but I don't know as there has been any proof >> of that or acknowledgement. For one, the level of hijacking we see, >> and the level of spam I personally receive that has at least a From >> name of someone I know, lead me to question that theory. > > I have notified several friends that their accounts were compromised. > Most did not like having to change their password. > >> Also, unless you know otherwise, my understanding was that Yahoo >> Groups didn't have any mitigation of DMARC policies until recently, >> and they implemented the same (and only currently useful) mitigation >> of re-writing the From header, and did so well after yahoo.com >> went to REJECT. > > Rewriting the From header field in itself is disruptive. This > prevents review of prior conversations from an individual. Often you > might remember who said something without recalling some of the details. > >> Also... federation across millions of servers? That seems... unlikely. > > Federation simply means sending servers authenticate their domain and > allow receivers to decide whether they wish to disallow messaging from > unknown domains. That feature is sorely missing from SMTP. In this > case, it only comes into play for third-party servers used by users of > the Author-Domain asserting a DMARC policy request. The scale of this > is likely to be in the area of about 30K. This number of 30K has been first mentioned by Yahoo! and after that it has been mentioned a couple of times by various people, but I have yet to see any proof that this figure is correct. Apart from this, quoting your own mail, you mention "[...] tens of thousands of legitimate services that might be sending on behalf of their client [...]". Although I think TPA may have its use for specific author/sender combinations [1], it definitely is not the answer to the current problems, introduced by Yahoo! and AOL, when they activated 'p=reject'. It simply will not scale enough and it remains to be seen that the too-big-to-ignore ESPs will spend time and money on the use of TPA, as they have their own mailing-list-like fora, which provide them revenues. Not to mention the privacy aspects of TPA... /rolf [1] My company DKIM-signs mail on behalf of some customers, a proper TPA standard that is implemented by many/most/all verifiers, would make this kind of setup more transparant. --------------080402000407060701020601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi, Doug,

On 05/22/2014 10:21 PM, Douglas Otis wrote:
Dear Brandon, 
See comments inline:

On May 12, 2014, at 12:30 PM, Brandon Long <blong@google.com> wrote:

On Mon, May 12, 2014 at 12:16 PM, Douglas Otis <doug.mtview@gmail.com> wrote:

On May 11, 2014, at 12:47 PM, Gabriel Iovino <giovino@people.ops-trust.net> wrote:

> Greetings,
>
> Last week I was having a conversation with a familiar person on this
> mailing list and I was expressing my disappointment with the
> negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was
> encouraged to share these thoughts on this list.
>
> I believe email is already broken[3][4][5][6] and DMARC "p=reject"
> moves us towards a position where email is "less" broken. Will there
> be some bumps[7] along the road? Sure but a few bumps are no reason to
> leave email in it's current state.
>
> I applaud Yahoo and AOL for taking the first few punches and I look
> forward to the day when Google and Microsoft follow their lead.
>
> Thank you for all the hard work you have done to improve the state of
> email!
>
> Gabriel Iovino

Dear Gabriel,

While email is generally abused, DMARC's intent was to better protect transactional email which Yahoo may put in jeopardy.  There will be a forthcoming draft to allow Author-Domains a means to request restrictive policies against normal user email accounts without disrupting very legitimate communications.  The draft places the burden of mitigating disruption on those making the requests.  Otherwise, it won't be too much longer before even DMARC is ignored when misapplied against user accounts.

Where can we learn more about this?

An update is pending recovery of xml.resource.org/public/rfc/bibxml/. You don't miss it until it is gone. :^(  I should have been more proactive about transferring reference content.

Yahoo has suffered from a lack of security permitting millions of their users accounts to be compromised.  A better approach would not use DMARC, but would federate third-party services they can see their customers employ.  The federation of email, much like that of XMPP, would be an effective means to exclude bad actors without breaking mailing-list and other third-party email services.  As it is now, it seems Yahoo only protects their own mailing-list operations which really does not warrant a basis for applauding such efforts.

I feel that there is a theory that has gone around as to why AOL and Yahoo! have done this, but I don't know as there has been any proof of that or acknowledgement.  For one, the level of hijacking we see, and the level of spam I personally receive that has at least a From name of someone I know, lead me to question that theory.

I have notified several friends that their accounts were compromised.  Most did not like having to change their password. 

Also, unless you know otherwise, my understanding was that Yahoo Groups didn't have any mitigation of DMARC policies until recently, and they implemented the same (and only currently useful) mitigation of re-writing the From header, and did so well after yahoo.com went to REJECT.

Rewriting the From header field in itself is disruptive.  This prevents review of prior conversations from an individual.  Often you might remember who said something without recalling some of the details.

Also... federation across millions of servers?  That seems... unlikely.

Federation simply means sending servers authenticate their domain and allow receivers to decide whether they wish to disallow messaging from unknown domains.  That feature is sorely missing from SMTP.  In this case, it only comes into play for third-party servers used by users of the Author-Domain asserting a DMARC policy request.  The scale of this is likely to be in the area of about 30K.

This number of 30K has been first mentioned by Yahoo! and after that it has been mentioned a couple of times by various people, but I have yet to see any proof that this figure is correct. Apart from this, quoting your own mail, you mention "[...] tens of thousands of legitimate services that might be sending on behalf of their client [...]". Although I think TPA may have its use for specific author/sender combinations [1], it definitely is not the answer to the current problems, introduced by Yahoo! and AOL, when they activated 'p=reject'. It simply will not scale enough and it remains to be seen that the too-big-to-ignore ESPs will spend time and money on the use of TPA, as they have their own mailing-list-like fora, which provide them revenues. Not to mention the privacy aspects of TPA...

/rolf

[1] My company DKIM-signs mail on behalf of some customers, a proper TPA standard that is implemented by many/most/all verifiers, would make this kind of setup more transparant.

--------------080402000407060701020601-- From nobody Thu May 22 14:32:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F581A037E for ; Thu, 22 May 2014 14:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sme0lIMipIci for ; Thu, 22 May 2014 14:32:05 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B241A0283 for ; Thu, 22 May 2014 14:32:04 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id q107so6734933qgd.10 for ; Thu, 22 May 2014 14:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GR2CA1wnkVnz5XHdGJYUeyoL0h3TAovtfWQ3dEpviRQ=; b=RtNsnDK7wOQGeCpm4fvAPFq1HDqe1WR2kYAhSGZD+Yux0gxdFzV66sxvBloBanfir/ jtCVBaY0+cnOKj4Skb19JdjMXqsJ6buewM7I75BGomZ4kEoLhfTk92PKVBlXteGHiIMc 2ztNImtVTRUK7Q3E3tKd5SCBsey8tIC9wiSUGaCkHxtFp4C4Fxs/OV/JFxn1uW/hq7tj pPMIfiqHp17VG3H4LSzRYqKukqNGC7cQzOBMZqORNtKpQ2Qncy+uT1vCnrV65xhe0v9D Sg/e5GUMJNM+PY7gL096nerGCcNvyRgeA33FwSuwVZFQi/FDT2qR1DQwUZ+cmipo7Y7E 9q5Q== X-Received: by 10.140.46.53 with SMTP id j50mr518920qga.27.1400794322960; Thu, 22 May 2014 14:32:02 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id u77sm634618qga.46.2014.05.22.14.32.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 14:32:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <6.2.5.6.2.20140512131712.0b86a730@resistor.net> Date: Thu, 22 May 2014 14:32:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B10F111-B781-4473-88A4-F6EAD4E8EAFE@gmail.com> References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> <6.2.5.6.2.20140512131712.0b86a730@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2FXmd-XW_6y4BQD_JEqbUhKDxbU Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 21:32:07 -0000 On May 12, 2014, at 1:38 PM, S Moonesamy wrote: > Hi Doug, > At 12:16 12-05-2014, Douglas Otis wrote: >> be compromised. A better approach would not use DMARC, but would = federate third-party services they can see their customers employ. The = federation of email, much like that of XMPP, would be an effective means = to exclude bad actors without breaking mailing-list and other = third-party email services. As it is now, it seems Yahoo only protects = their own >=20 > Is federation effective in excluding bad stuff? Bad stuff also occurs = in closed systems (see = https://support.twitter.com/groups/56-policies-violations/topics/238-repor= t-a-violation/articles/64986-reporting-spam-on-twitter ). XMPP has been = mentioned previously. There wasn't any information provided to assess = whether it does exclude bad stuff. Dear SM, The goal of federated services is to prevent inclusion of unknown = servers. It does not in itself exclude bad stuff. When bad stuff is = noted, federation enables blocking future exchanges. Direct tweets are = possible, although messaging constrained to 140 characters is difficult = to take seriously since it is nearly impossible to know whether a tweet = is being auto-generated. Much of it is. The way this would relate to = DMARC is in the handling of non-aligned messages. When sources are = identified, and feedback is generated for all known exceptions, it = should not be difficult to then invert "block" logic into "accept" = logic.=20 Imagine your domain supporting millions of users had their accounts = exposed along with their address-books. This can easily get ugly in = respect to the harm this would allow. Yahoo likely considered DMARC the = closest approximation of server federation that could be enabled. After = all, there are no other email policy layers reliably acted upon. What = is missing is a minor amount of feedback needed to communicate what the = Author-Domain knows to be legitimate sources. Doing so should represent = a negligible amount of effort.=20 I supported a system that reported on _all_ identified bad IPv4 = addresses. To do this, it required careful exclusion of those randomly = assigned addresses. We would then apply about 15 million updates every = 5 minutes for the entire IPv4 address space orchestrated by two = redundant servers. This information then supported several very large = ISPs. The larger ISPs wanted to do zone transfers, but a DMARC = exception rate for an Author Domain will be several orders of magnitude = lower in scale. I'll admit this was all done using C code that avoided = SQL or Hadoop. Judy is your friend. :^). Regards, Douglas Otis =20 From nobody Thu May 22 14:56:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70E51A037F for ; Thu, 22 May 2014 14:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR2SO3y2eNN5 for ; Thu, 22 May 2014 14:56:17 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17AA41A037E for ; Thu, 22 May 2014 14:56:17 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so6794564qgd.15 for ; Thu, 22 May 2014 14:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=nsV3+tgumkG3VDpaGmdgbQhgk5hMrmjKVpRrNSM6sng=; b=kwdhC7VCr5Unvm0JNWZREBA2H3UDe3kbDB61TBuQNx0KXF+OVNlLlE9y5RHidofXcR yrb7OJ76x64rTUeYCpRBu7zxz3zKOQz7W9LfC5KHglzC0xG+NHhncttp1PRmLVU9WrH4 48ILje0xFSlHZfk0QfJ+0eKd+52gqQ+1B7oVWdaEPYCoXjgMGwfa60tDRd/+aGtVLedi fzVA3KvR8wQG/j4RLKg2EbGDnAQsrc91VVpYvyrfjkLBZvNUalSD4m7vb7NceMVBP5T6 aW9XMmYC2bYRCuOOAknMqGf7RHJw3wMQmVk1FQvLAjuQNI2xUu5CY/ZfidqOOdycdWp5 6fXw== X-Received: by 10.140.50.2 with SMTP id r2mr793412qga.96.1400795775248; Thu, 22 May 2014 14:56:15 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id f38sm670927qgd.49.2014.05.22.14.56.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 14:56:14 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EFBF39FE-41F5-4332-B359-948C47BAEF0B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <537E662C.8060706@sonnection.nl> Date: Thu, 22 May 2014 14:56:12 -0700 Message-Id: <0E5C57CC-08AA-45C1-A70D-64E2AA8C1840@gmail.com> References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> <5EC0167B-FBC2-4C8E-A1FC-88E0E5537352@gmail.com> <537E662C.8060706@sonnection.nl> To: R.E.Sonneveld@sonnection.nl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wfHTGVYAfmmsvwsvKsDQP3k5Nas Cc: Brandon Long , Gabriel Iovino , dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 21:56:20 -0000 --Apple-Mail=_EFBF39FE-41F5-4332-B359-948C47BAEF0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 22, 2014, at 2:03 PM, Rolf E. Sonneveld = wrote: > Hi, Doug, >=20 > On 05/22/2014 10:21 PM, Douglas Otis wrote: >> Dear Brandon,=20 >> See comments inline: >>=20 >> On May 12, 2014, at 12:30 PM, Brandon Long wrote: >>=20 >>> On Mon, May 12, 2014 at 12:16 PM, Douglas Otis = wrote: >>>=20 >>> On May 11, 2014, at 12:47 PM, Gabriel Iovino = wrote: >>>=20 >>> > Greetings, >>> > >>> > Last week I was having a conversation with a familiar person on = this >>> > mailing list and I was expressing my disappointment with the >>> > negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was >>> > encouraged to share these thoughts on this list. >>> > >>> > I believe email is already broken[3][4][5][6] and DMARC "p=3Dreject"= >>> > moves us towards a position where email is "less" broken. Will = there >>> > be some bumps[7] along the road? Sure but a few bumps are no = reason to >>> > leave email in it's current state. >>> > >>> > I applaud Yahoo and AOL for taking the first few punches and I = look >>> > forward to the day when Google and Microsoft follow their lead. >>> > >>> > Thank you for all the hard work you have done to improve the state = of >>> > email! >>> > >>> > Gabriel Iovino >>>=20 >>> Dear Gabriel, >>>=20 >>> While email is generally abused, DMARC's intent was to better = protect transactional email which Yahoo may put in jeopardy. There will = be a forthcoming draft to allow Author-Domains a means to request = restrictive policies against normal user email accounts without = disrupting very legitimate communications. The draft places the burden = of mitigating disruption on those making the requests. Otherwise, it = won't be too much longer before even DMARC is ignored when misapplied = against user accounts. >>>=20 >>> Where can we learn more about this? >>=20 >> An update is pending recovery of xml.resource.org/public/rfc/bibxml/. = You don't miss it until it is gone. :^( I should have been more = proactive about transferring reference content. >>=20 >>> Yahoo has suffered from a lack of security permitting millions of = their users accounts to be compromised. A better approach would not use = DMARC, but would federate third-party services they can see their = customers employ. The federation of email, much like that of XMPP, = would be an effective means to exclude bad actors without breaking = mailing-list and other third-party email services. As it is now, it = seems Yahoo only protects their own mailing-list operations which really = does not warrant a basis for applauding such efforts. >>>=20 >>> I feel that there is a theory that has gone around as to why AOL and = Yahoo! have done this, but I don't know as there has been any proof of = that or acknowledgement. For one, the level of hijacking we see, and = the level of spam I personally receive that has at least a =46rom name = of someone I know, lead me to question that theory. >>=20 >> I have notified several friends that their accounts were compromised. = Most did not like having to change their password.=20 >>=20 >>> Also, unless you know otherwise, my understanding was that Yahoo = Groups didn't have any mitigation of DMARC policies until recently, and = they implemented the same (and only currently useful) mitigation of = re-writing the =46rom header, and did so well after yahoo.com went to = REJECT. >>=20 >> Rewriting the =46rom header field in itself is disruptive. This = prevents review of prior conversations from an individual. Often you = might remember who said something without recalling some of the details. >>=20 >>> Also... federation across millions of servers? That seems... = unlikely. >>=20 >> Federation simply means sending servers authenticate their domain and = allow receivers to decide whether they wish to disallow messaging from = unknown domains. That feature is sorely missing from SMTP. In this = case, it only comes into play for third-party servers used by users of = the Author-Domain asserting a DMARC policy request. The scale of this = is likely to be in the area of about 30K. >=20 > This number of 30K has been first mentioned by Yahoo! and after that = it has been mentioned a couple of times by various people, but I have = yet to see any proof that this figure is correct. Apart from this, = quoting your own mail, you mention "[...] tens of thousands of = legitimate services that might be sending on behalf of their client = [...]". Although I think TPA may have its use for specific author/sender = combinations [1], it definitely is not the answer to the current = problems, introduced by Yahoo! and AOL, when they activated 'p=3Dreject'. = It simply will not scale enough and it remains to be seen that the = too-big-to-ignore ESPs will spend time and money on the use of TPA, as = they have their own mailing-list-like fora, which provide them revenues. = Not to mention the privacy aspects of TPA... Dear Rolf, I strongly disagree with the assumption TPA does not scale to levels = needed by AOL or Yahoo. Not having TPA declare the exceptions needed, = both receiving and then offering feedback will likely to involve greater = levels of network resources. TPA is structured to ensure it can be = supported by a single DNS transaction. This allows for effective = caching so perhaps only one out of 10 queries sees an authoritative = response. Can that be said for any other email protocol? DMARC is = looking only at alignments from whatever method is used to validated the = domain? Imagine a future where SMTP is federated using DANE. ;-) > /rolf >=20 > [1] My company DKIM-signs mail on behalf of some customers, a proper = TPA standard that is implemented by many/most/all verifiers, would make = this kind of setup more transparent. I fully agree. Proper TPA implementations would enable major = improvements to email integrity and reliability. Received good feedback indicating the draft needs major improvement. = sigh. One comment was on the improvement to abstract, where I am told = it now needs to be much shorter. :-( Regards, Douglas Otis --Apple-Mail=_EFBF39FE-41F5-4332-B359-948C47BAEF0B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On May 22, 2014, at 2:03 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:

Hi, Doug,

On 05/22/2014 10:21 PM, Douglas Otis wrote:
Dear Brandon, 
See comments inline:

On May 12, 2014, at 12:30 PM, Brandon Long <blong@google.com> wrote:

On Mon, May 12, 2014 at 12:16 PM, Douglas Otis <doug.mtview@gmail.com> wrote:

On May 11, 2014, at 12:47 PM, Gabriel Iovino <giovino@people.ops-trust.net> wrote:

> Greetings,
>
> Last week I was having a conversation with a familiar person on this
> mailing list and I was expressing my disappointment with the
> negativity towards Yahoo[1] and AOL[2] for "breaking" email. I was
> encouraged to share these thoughts on this list.
>
> I believe email is already broken[3][4][5][6] and DMARC "p=reject"
> moves us towards a position where email is "less" broken. Will there
> be some bumps[7] along the road? Sure but a few bumps are no reason to
> leave email in it's current state.
>
> I applaud Yahoo and AOL for taking the first few punches and I look
> forward to the day when Google and Microsoft follow their lead.
>
> Thank you for all the hard work you have done to improve the state of
> email!
>
> Gabriel Iovino

Dear Gabriel,

While email is generally abused, DMARC's intent was to better protect transactional email which Yahoo may put in jeopardy.  There will be a forthcoming draft to allow Author-Domains a means to request restrictive policies against normal user email accounts without disrupting very legitimate communications.  The draft places the burden of mitigating disruption on those making the requests.  Otherwise, it won't be too much longer before even DMARC is ignored when misapplied against user accounts.

Where can we learn more about this?

An update is pending recovery of xml.resource.org/public/rfc/bibxml/. You don't miss it until it is gone. :^(  I should have been more proactive about transferring reference content.

Yahoo has suffered from a lack of security permitting millions of their users accounts to be compromised.  A better approach would not use DMARC, but would federate third-party services they can see their customers employ.  The federation of email, much like that of XMPP, would be an effective means to exclude bad actors without breaking mailing-list and other third-party email services.  As it is now, it seems Yahoo only protects their own mailing-list operations which really does not warrant a basis for applauding such efforts.

I feel that there is a theory that has gone around as to why AOL and Yahoo! have done this, but I don't know as there has been any proof of that or acknowledgement.  For one, the level of hijacking we see, and the level of spam I personally receive that has at least a From name of someone I know, lead me to question that theory.

I have notified several friends that their accounts were compromised.  Most did not like having to change their password. 

Also, unless you know otherwise, my understanding was that Yahoo Groups didn't have any mitigation of DMARC policies until recently, and they implemented the same (and only currently useful) mitigation of re-writing the From header, and did so well after yahoo.com went to REJECT.

Rewriting the From header field in itself is disruptive.  This prevents review of prior conversations from an individual.  Often you might remember who said something without recalling some of the details.

Also... federation across millions of servers?  That seems... unlikely.

Federation simply means sending servers authenticate their domain and allow receivers to decide whether they wish to disallow messaging from unknown domains.  That feature is sorely missing from SMTP.  In this case, it only comes into play for third-party servers used by users of the Author-Domain asserting a DMARC policy request.  The scale of this is likely to be in the area of about 30K.

This number of 30K has been first mentioned by Yahoo! and after that it has been mentioned a couple of times by various people, but I have yet to see any proof that this figure is correct. Apart from this, quoting your own mail, you mention "[...] tens of thousands of legitimate services that might be sending on behalf of their client [...]". Although I think TPA may have its use for specific author/sender combinations [1], it definitely is not the answer to the current problems, introduced by Yahoo! and AOL, when they activated 'p=reject'. It simply will not scale enough and it remains to be seen that the too-big-to-ignore ESPs will spend time and money on the use of TPA, as they have their own mailing-list-like fora, which provide them revenues. Not to mention the privacy aspects of TPA...

Dear Rolf,

I strongly disagree with the assumption TPA does not scale to levels needed by AOL or Yahoo. Not having TPA declare the exceptions needed, both receiving and then offering feedback will likely to involve greater levels of network resources.  TPA is structured to ensure it can be supported by a single DNS transaction.  This allows for effective caching so perhaps only one out of 10 queries sees an authoritative response.  Can that be said for any other email protocol?  DMARC is looking only at alignments from whatever method is used to validated the domain? Imagine a future where SMTP is federated using DANE. ;-)

/rolf

[1] My company DKIM-signs mail on behalf of some customers, a proper TPA standard that is implemented by many/most/all verifiers, would make this kind of setup more transparent.

I fully agree.   Proper TPA implementations would enable major improvements to email integrity and reliability.

Received good feedback indicating the draft needs major improvement. sigh.  One comment was on the improvement to abstract, where I am told it now needs to be much shorter. :-(

Regards,
Douglas Otis




--Apple-Mail=_EFBF39FE-41F5-4332-B359-948C47BAEF0B-- From nobody Thu May 22 15:34:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306EA1A0292 for ; Thu, 22 May 2014 15:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARJjeC91RuWb for ; Thu, 22 May 2014 15:34:49 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB351A0226 for ; Thu, 22 May 2014 15:34:48 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3gZQcg038mz1L8f5; Fri, 23 May 2014 00:34:43 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3gZQcf5jCfz5Mh9k; Fri, 23 May 2014 00:34:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 822A612329B; Fri, 23 May 2014 00:34:41 +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 RxkVoIqOpN4N; Fri, 23 May 2014 00:34:31 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id B6196122E9C; Fri, 23 May 2014 00:34:31 +0200 (CEST) Message-ID: <537E7B77.2030904@sonnection.nl> Date: Fri, 23 May 2014 00:34:31 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Douglas Otis References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> <5EC0167B-FBC2-4C8E-A1FC-88E0E5537352@gmail.com> <537E662C.8060706@sonnection.nl> <0E5C57CC-08AA-45C1-A70D-64E2AA8C1840@gmail.com> In-Reply-To: <0E5C57CC-08AA-45C1-A70D-64E2AA8C1840@gmail.com> Content-Type: multipart/alternative; boundary="------------000901000703070803010300" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1400798083; bh=jy2jP5ZFxBaDaWRcMgIy7AaOJLtBKZrvRV3i1VkPYD8=; h=Message-ID:Date:From:To:Subject:From; b=g8CuB7RDqPn39CyPYTQsNdTTaGyF3cZW5e1H5qw6V5p+nXqWtPxBmjy63oNLQy1RV 3jg5bA6JlgVwsbSlYJfLbdD18MpIG7MiC42Q7qcXC1yTdDFURmMrPKsBZousnVTf85 U0J1EsAnlsK9xpQWqwjpouMRo6OUepQdz3ZKjzlA= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3gZQcg038mz1L8f5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nWuxuelvIVq5JhYkhGAsgnagog4 Cc: Brandon Long , Gabriel Iovino , dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 22:34:51 -0000 This is a multi-part message in MIME format. --------------000901000703070803010300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Doug, On 05/22/2014 11:56 PM, Douglas Otis wrote: [...] > > >> This number of 30K has been first mentioned by Yahoo! and after that >> it has been mentioned a couple of times by various people, but I have >> yet to see any proof that this figure is correct. Apart from this, >> quoting your own mail, you mention "[...] tens of thousands of >> legitimate services that might be sending on behalf of their client >> [...]". Although I think TPA may have its use for specific >> author/sender combinations [1], it definitely is not the answer to >> the current problems, introduced by Yahoo! and AOL, when they >> activated 'p=reject'. It simply will not scale enough and it remains >> to be seen that the too-big-to-ignore ESPs will spend time and money >> on the use of TPA, as they have their own mailing-list-like fora, >> which provide them revenues. Not to mention the privacy aspects of TPA... > > Dear Rolf, > > I strongly disagree with the assumption TPA does not scale to levels > needed by AOL or Yahoo. Not having TPA declare the exceptions needed, > both receiving and then offering feedback will likely to involve > greater levels of network resources. TPA is structured to ensure it > can be supported by a single DNS transaction. This allows for > effective caching so perhaps only one out of 10 queries sees an > authoritative response. Can that be said for any other email protocol? I'm not talking about that type of scaling. What I mean is, that it will take a massive amount of work to gather the right information about who is subscribed where to what list, to update this information on a continuous basis and to get this (changing information) in DNS. But maybe I misunderstand what will be in the draft, I'd better wait for the draft. /rolf --------------000901000703070803010300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi, Doug,

On 05/22/2014 11:56 PM, Douglas Otis wrote:

[...]


This number of 30K has been first mentioned by Yahoo! and after that it has been mentioned a couple of times by various people, but I have yet to see any proof that this figure is correct. Apart from this, quoting your own mail, you mention "[...] tens of thousands of legitimate services that might be sending on behalf of their client [...]". Although I think TPA may have its use for specific author/sender combinations [1], it definitely is not the answer to the current problems, introduced by Yahoo! and AOL, when they activated 'p=reject'. It simply will not scale enough and it remains to be seen that the too-big-to-ignore ESPs will spend time and money on the use of TPA, as they have their own mailing-list-like fora, which provide them revenues. Not to mention the privacy aspects of TPA...

Dear Rolf,

I strongly disagree with the assumption TPA does not scale to levels needed by AOL or Yahoo. Not having TPA declare the exceptions needed, both receiving and then offering feedback will likely to involve greater levels of network resources.  TPA is structured to ensure it can be supported by a single DNS transaction.  This allows for effective caching so perhaps only one out of 10 queries sees an authoritative response.  Can that be said for any other email protocol?

I'm not talking about that type of scaling. What I mean is, that it will take a massive amount of work to gather the right information about who is subscribed where to what list, to update this information on a continuous basis and to get this (changing information) in DNS. But maybe I misunderstand what will be in the draft, I'd better wait for the draft.

/rolf

--------------000901000703070803010300-- From nobody Fri May 23 11:47:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374EA1A00F2 for ; Fri, 23 May 2014 00:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48YyxYVGob0V for ; Fri, 23 May 2014 00:48:45 -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 7FD581A00E8 for ; Fri, 23 May 2014 00:48:45 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.142.195]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4N7mKXE012796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2014 00:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400831312; bh=vex8j0QByxhxUczA8BY2Mf0s8clJhvPGoIDWHb7jnDo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=npqqBUgLLpmhDbAIdXXOe73EUoM7/8spYsSvTKeWZI57+H6/LrqlRwRgeW7dcpjvx vi730FlZjAva5xmEU5U6uVaGCQdrcS7FHzCStthNzywozGnb/Qo0ak+e9q5lFPx27/ vIKwhzT+69xe2SH6Q8yKk1FusEYwIayryWbpWPOI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1400831312; i=@elandsys.com; bh=vex8j0QByxhxUczA8BY2Mf0s8clJhvPGoIDWHb7jnDo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wk/tb69+uAxmD6wMJepXFX7csEHp8z4+5CqzvmRDyQ0vjBu30JDJpbbBmZy7SUCEL enl17kYsRSMHnJhJrFv3HfeSkRbJFFPK/ITnVVQ3aOU6RL910MoFwYyxmokqmk+P8i U47ItFI3/S4jp4FhH3gUcrccseyEbDSY3Z6rbrTY= Message-Id: <6.2.5.6.2.20140522223431.0bc90500@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 22 May 2014 23:19:31 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: <3B10F111-B781-4473-88A4-F6EAD4E8EAFE@gmail.com> References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> <6.2.5.6.2.20140512131712.0b86a730@resistor.net> <3B10F111-B781-4473-88A4-F6EAD4E8EAFE@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/I1W1buZO_daTZB4t8TFqyCxU-64 X-Mailman-Approved-At: Fri, 23 May 2014 11:47:45 -0700 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 07:48:47 -0000 Hi Doug, At 14:32 22-05-2014, Douglas Otis wrote: >The goal of federated services is to prevent inclusion of unknown >servers. It does not in itself exclude bad stuff. When bad stuff >is noted, federation enables blocking future exchanges. Direct >tweets are possible, although messaging constrained to 140 >characters is difficult to take seriously since it is nearly >impossible to know whether a tweet is being auto-generated. Much of >it is. The way this would relate to DMARC is in the handling of >non-aligned messages. When sources are identified, and feedback is >generated for all known exceptions, it should not be difficult to >then invert "block" logic into "accept" logic. The question I asked was: is federation effective in excluding bad stuff? The reason I asked that question is to be able to form an opinion about the idea of an email federation. The above explains that the email federation is about preventing the inclusion of unknown servers. That does not help me in forming an opinion about the idea (see the question I asked). I used tweeter as an example of a closed system. The argument was that bad stuff can happen in a system in which the owner has full control. >Imagine your domain supporting millions of users had their accounts >exposed along with their address-books. This can easily get ugly in >respect to the harm this would allow. I read that "information security and customer data protection are of paramount importance". My interpretation of that is that the importance is ranked higher than money. My interpretation would be incorrect if my domain had millions of accounts exposed. Someone might also point me to http://www.dilbert.com/strips/comic/2014-05-19/ >I supported a system that reported on _all_ identified bad IPv4 >addresses. To do this, it required careful exclusion of those >randomly assigned addresses. We would then apply about 15 million >updates every 5 minutes for the entire IPv4 address space >orchestrated by two redundant servers. This information then >supported several very large ISPs. The larger ISPs wanted to do >zone transfers, but a DMARC exception rate for an Author Domain will >be several orders of magnitude lower in scale. I'll admit this was >all done using C code that avoided SQL or Hadoop. Judy is your friend. :^). I'll make this a little complicated for you. Could that system also be used for IPv6 addresses? Regards, S. Moonesamy From nobody Fri May 23 17:07:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7241A024D for ; Fri, 23 May 2014 17:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIyIHe33F7wQ for ; Fri, 23 May 2014 17:07:36 -0700 (PDT) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF481A0246 for ; Fri, 23 May 2014 17:07:35 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id l6so9231634qcy.9 for ; Fri, 23 May 2014 17:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Xj7hDlEX/Zm105HhOBG+oNdZmNDNqCdIs5dI2UwOe8A=; b=jYpYsWiLdIA/KJhDv+hblxHa9ylM5CAs45YaLD0IQWbKyOAIiBq1LAvdvxM7M3ixSB 9LYhSfDMCWRhKKCwew1+LlPYgwzEz9TZfyPx416fZVbC+TW10o1t7fLxO/bPbLVxX1UA 4zG4jX6xBgoRovz7bphzGyTXqfQVT/RxocTJzTIWfykpmIonvprblhnjDzGct9UMZEOJ 3z0PmENAT8JPP37CXjfqm+QHOri/yOEEL5NDMzlzrAY0EQRIEqHZbLRi0f/VlPVEfrNW asJYu5GlJuaMidozlqwBD3oth5Zt9BLKW6n/2YaAY5uJ7xWMPu6OHQWS5R5wf3mmaGBT r5gQ== X-Received: by 10.140.87.5 with SMTP id q5mr11194844qgd.43.1400890053653; Fri, 23 May 2014 17:07:33 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id o2sm7213854qag.47.2014.05.23.17.07.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 17:07:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <6.2.5.6.2.20140522223431.0bc90500@elandnews.com> Date: Fri, 23 May 2014 17:07:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> <6.2.5.6.2.20140512131712.0b86a730@resistor.net> <3B10F111-B781-4473-88A4-F6EAD4E8EAFE@gmail.com> <6.2.5.6.2.20140522223431.0bc90500@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NqZouGT3sEKe0KM_mWU7lbk-tr4 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 00:07:39 -0000 Dear SM, Thank you for your thoughtful questions. See comments inline: On May 22, 2014, at 11:19 PM, S Moonesamy wrote: > Hi Doug, > At 14:32 22-05-2014, Douglas Otis wrote: >> The goal of federated services is to prevent inclusion of unknown = servers. It does not in itself exclude bad stuff. When bad stuff is = noted, federation enables blocking future exchanges. Direct tweets are = possible, although messaging constrained to 140 characters is difficult = to take seriously since it is nearly impossible to know whether a tweet = is being auto-generated. Much of it is. The way this would relate to = DMARC is in the handling of non-aligned messages. When sources are = identified, and feedback is generated for all known exceptions, it = should not be difficult to then invert "block" logic into "accept" = logic. >=20 > The question I asked was: is federation effective in excluding bad = stuff? The reason I asked that question is to be able to form an = opinion about the idea of an email federation. The above explains that = the email federation is about preventing the inclusion of unknown = servers. That does not help me in forming an opinion about the idea = (see the question I asked). I used tweeter as an example of a closed = system. The argument was that bad stuff can happen in a system in which = the owner has full control. I have been asked nearly the same question by others. A section will be = added to explain the how and why and its impact on privacy. Senders and = receivers desire a scheme that improves protection of the =46rom header = field. The business aspects of this became extremely clear to PayPal by = effects on their customers then obligated to sift through massive = amounts of email abuse. The benefit of timely out-of-band notification = instead caused an exodus of customers. To staunch customer loss, direct = appeals to major ESPs to reject non-aligned PayPal messages helped, and = helped everyone. Unfortunately, direct appeal does not scale. Hence we = have a limited stop-gap scheme. As has become extremely clear, although there was early evidence, DMARC = did not fully consider important "corner cases". It seemed okay to = leave these issues for receivers to sort out. Now AOL and Yahoo! have = made it evident receiver cooperation is in jeopardy. If you are like = most others, you have had malicious and socially engineered messages = from someone you know prompting you to click a link or call a number, = etc. Resorting to the only functional policy scheme able to reject = messages is understandable, but this came at a dear cost. As John = Levine describes, "a death by a thousand cuts". Asserting whether all messages must have From/Source domain alignment is = somewhat analogous to the type of federation supporting single-sign-on = schemes. A federation has the purpose of protecting identifiers. In = other words using laissez faire protocols where the strategy of "block = on event" is inverted to become "accept on event". In the case of DMARC = + TPA, "accept on event" is derived from DMARC feedback/log review = accurately determining which domains require exception. Further review = can even characterize how domains authenticate and which header elements = confirm or narrow authorization. TPA uses DNS to signal "trust" based on hash labels. DNS is used = because it is ubiquitously relied upon by MTAs, offers low latency and = low overhead from legitimate domains. DNS is also able to handily = support this scheme at massive scales. >> Imagine your domain supporting millions of users had their accounts = exposed along with their address-books. This can easily get ugly in = respect to the harm this would allow. >=20 > I read that "information security and customer data protection are of = paramount importance". My interpretation of that is that the importance = is ranked higher than money. My interpretation would be incorrect if my = domain had millions of accounts exposed. Someone might also point me to = http://www.dilbert.com/strips/comic/2014-05-19/ Cute comic. It is not really the information protected by a federation = scheme. It is not even the exclusion of bad stuff. It is protection of = federated identities by receivers implementing DMARC + TPA. By using = this scheme, associated identities can be protected while also avoiding = disruption of legitimate messages. Even Eliot Lear's mother becomes = safer. (I hope this is the right example as it was discussed many years = ago.) >> I supported a system that reported on _all_ identified bad IPv4 = addresses. To do this, it required careful exclusion of those randomly = assigned addresses. We would then apply about 15 million updates every = 5 minutes for the entire IPv4 address space orchestrated by two = redundant servers. This information then supported several very large = ISPs. The larger ISPs wanted to do zone transfers, but a DMARC = exception rate for an Author Domain will be several orders of magnitude = lower in scale. I'll admit this was all done using C code that avoided = SQL or Hadoop. Judy is your friend. :^). >=20 > I'll make this a little complicated for you. Could that system also = be used for IPv6 addresses? Unfortunately, that approach now only works for authenticated domains. = :^( Dane anyone? Regards, Douglas Otis From nobody Sat May 24 12:50:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B051A00E9 for ; Sat, 24 May 2014 12:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.502 X-Spam-Level: X-Spam-Status: No, score=-97.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYwrh_hTu4vy for ; Sat, 24 May 2014 12:50:46 -0700 (PDT) Received: from mail.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AE5CB1A0020 for ; Sat, 24 May 2014 12:50:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3199; t=1400961039; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=cjOHthCF+U06qW8KTsAsO8rWwSo=; b=o1PJcPG+dtznIe3yU/YG YXN1yo2roBU6NNDT3foEp3zcOQacGxOVb2SlDet4bJfqqGAMODQIg9JT7NVbi5iL DyZ/YvFS2c3HbTZldIYE0Je1nEVvNUnZSc/EagpEcnZ1C5AecECYT03tjV8fBqxX bwIW7aG2sJKvL/E2uevlhvM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 May 2014 15:50:39 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 441178533.10159.2280; Sat, 24 May 2014 15:50:38 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3199; t=1400960902; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pReE3dT 52kS6UpPwukdgIKZnLSZmBHqRSnZPkWE2Oew=; b=ZWEW5v5BsJi+7c8hTPjM0jJ 8cpS9+z2Gn4u2eSVQlCyUnUAti7peJZvZAN+CBmA6/Bw1Klr8m4e3yys9+DqtI6r uwwV51A/XsZ8YsauGDjY+NOtUToQk2x082L8+QDTtJ6ykNzqqNf36cG5crBB9o3s HZqz0evesk2+MWUcUeSY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 May 2014 15:48:21 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 457549078.9.216; Sat, 24 May 2014 15:48:21 -0400 Message-ID: <5380F812.9070809@isdg.net> Date: Sat, 24 May 2014 15:50:42 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/M1ch3ouv27uOLnodLIHcU8-N4vY Subject: [dmarc-ietf] Supporting and Updating the IETF DMARC I-D draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 19:50:48 -0000 I've begun looking at adding DMARC support into our existing DKIM, ADSP, ATPS, ASL framework. To explore all this, I converted our public ADSP/ATPS/ASL Zone Record Creator web-based wizard to use DMARC with the ATPS/ASL extensions at: DMARC Policy Zone Record Generator and Test Simulator v3.0 http://www.winserver.com/public/wcdmarc Testers are welcome to send comments, suggestions to me. Off hand, I think the DMARC draft needs to be updated for two basic fundamental parts: 1) Separate Policy Handling and Reporting. If I read the draft right, reporting is mandatory. Reporting should not be mandatory to DMARC receivers. Not all receivers will want to add this huge overhead component just to support the most important part; the security policy portion of the protocol. Reporting is bound to be ignored and the DMARC draft should recognize this reality by not making essential nor necessary. 2) To address the critical 3rd party Resigner concerns and policy semantics, at a minimum, add a new "tps=" tag that says Third Party Signers (tps) are allowed with/out an IETF registered authorization mechanism. See the tps= proposal below for this. With these two basic considerations, we gain lower barriers to adoption, faster migration for all segments of the mail system that for the most part has took the IETF opponents of the DKIM author domain policy framework by surprise. It didn't surprise any of the IETF proponents of this DKIM author domain framework, but we were on the losing side of the 3rd party vs 1st party signer policy extremely rough consensus debates. This does not suggest that the YAHOOs will begin to allow 3rd party signers, but when the proper protocol options available, which are not there now, it opens the doors (and eyes) to the possibility to have a smoother transition and integration. It creates the synergism to address all parties in the integrated mail network. About the "tps=" tag, a quick summary of the idea, this tag describes a DMARC policy which allows 3rd party signers w/o authorization depending on the value of "tps=": missing --> fallback to 1st party DMARC only tps= --> same as missing tps=y --> any 3rd party allowed tps=methods --> registered method(s) available by the domain. Examples of registered methods: tps=atps rfc6541 DKIM Authorized Third-Party Signatures tps=vbr rfc5518 Vouch By Reference tps=tpa Otis's TPA draft with multiples allowed: tps=vbr,atps,tpa This says, the domain has records for each VBR, ATPS, and TPA method. The receiver should use the first known negotiated method among the list. If no method is known by the receiver, it falls back to missing as the fail-safer approach. However, it can be overwritten by adding "y" to the end of the methods. I personally, would like to add additional "asl=" allowed signer list tag since it will be more optimal for the majority of domains in the market who are bot now interested in having many 3rd party signers, but a short list of domains: asl=domain-list comma delimited list of domains But it may be asking for too much to get "asl=" into the total picture. -- HLS From nobody Sat May 24 13:10:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139CA1A0029 for ; Sat, 24 May 2014 13:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCIynTg8ctOt for ; Sat, 24 May 2014 13:10:46 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [208.75.177.101]) by ietfa.amsl.com (Postfix) with SMTP id E0E0D1A026C for ; Sat, 24 May 2014 13:10:44 -0700 (PDT) Received: (qmail 92743 invoked by uid 89); 24 May 2014 20:10:41 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 24 May 2014 20:10:41 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=[10.0.1.141]; envelope-from= Received: from [10.0.1.141] (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0alpha2) with ESMTPSA id 43799798-11BA-443E-B989-DF4B4AB8A430.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Sat, 24 May 2014 16:10:39 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson In-Reply-To: <5380F812.9070809@isdg.net> Date: Sat, 24 May 2014 13:10:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5380F812.9070809@isdg.net> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="iOS iPhone or iPad" link_type="Ethernet or modem" distance=11 total_conn=1 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2705km X-Haraka-GeoIP-Received: X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-ASN-ROUTEVIEWS: asn=7922 net=50.128.0.0/9 X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: MGTINTERNET: spamassassin.tnpi.net 1170; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-2988-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-2988-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 10.0.1.141, Ugly c=0.343385 p=-0.5 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-2988-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 4, history: 277, total_connects: 297, neighbors: -601, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=hMWQZUaSzRPehWF3W0fXjCGShOhIRYNh/mcKiHPhoVk=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=CDpGniibykk0KBnDGUCN2WgbsRNzpAYVDFqoyE0ulFIzBZi20uFA9drn8XKPhvp2ugZbHzDCJSbp7tU3C/77ZTbqe/I6j9VT9rNJYmmDTqiaR8k66Vm+d7ajTx/LYn821IEl8r1Udt1tEzsNrgW2CQnKzCMtwMhfXPQHMYvS9BdZdBR8BAojqfPKt/gN07yUOxY7OT/MxpcgjaEq6AcSMq11BMGEHrlWA56j+TOZ49ScUiRL9fmNoId/1pVDvr2F58Y1/trdvFCO20hz+TbCw24HB/ad+prIw/NSPC8RiEpsemOVV2A63+54yzyZOPVu7VwANdjAGd6XGmV+3SghvQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nN1i9W-7tzBX836bnYB4EFslo3U Subject: Re: [dmarc-ietf] Supporting and Updating the IETF DMARC I-D draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 20:10:48 -0000 On May 24, 2014, at 12:50 PM, Hector Santos wrote: > Off hand, I think the DMARC draft needs to be updated for two basic = fundamental parts: >=20 > 1) Separate Policy Handling and Reporting. If I read the draft right, = reporting is mandatory. Reporting should not be mandatory to DMARC = receivers. Not all receivers will want to add this huge overhead = component just to support the most important part; the security policy = portion of the protocol. Reporting is bound to be ignored and the DMARC = draft should recognize this reality by not making essential nor = necessary. Could you point to the areas within the draft that led you to believe = that reporting is mandatory?=20 Matt From nobody Sat May 24 15:46:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D831A0107 for ; Sat, 24 May 2014 15:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dGbNjOD5IaS for ; Sat, 24 May 2014 15:46:28 -0700 (PDT) Received: from mail1.altn.com (mail1.altn.com [65.99.242.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0031A00C2 for ; Sat, 24 May 2014 15:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=altn.com; s=mail1; l=6479; t=1400971585; x=1401576385; q=dns/txt; h=DomainKey-Signature: Received:VBR-Info:Message-ID:Date:From:User-Agent:MIME-Version: To:Subject:Content-Type:Content-Transfer-Encoding; bh=B2l9AW5bnY vyea6luvacoFWpdhTDkHCjqRDq0l9W1Ss=; b=QGiG40FKgm0HsITzhxbrbPZIRA FGm/lhPtoU8GuJQPyvxvyttg415fdojcxADTt3hl89V685Qe1Jzwu5hG5SL2tDt9 K7YgMc8C99cusg10PCG7Yiz/v64r1bWiDv+L2Yy8A1DhEUpKDH/bYRUIAU0jl3cf pRt+koV2OHDryCEFM= DomainKey-Signature: a=rsa-sha1; s=mail1; d=altn.com; c=nofws; q=dns; h=message-id:from; b=kVfGtlS0W0ILLK3zpWYluEY/oZX/OYpyZs2qHTXrOv0o4opABUz1cKnabQxm 3BxL/EjG/o9wUDLgJ1tNpz1qODcXZviCHI7AOHiOxKk3+JKm/guRDCxbz frPwLpLHsolKTOsimlaX3ddGGi+YkLHVdSnBk7lz3Omskc1OwilHRc=; X-MDAV-Processed: mail1.altn.com, Sat, 24 May 2014 17:46:25 -0500 Received: from [10.20.90.134] by altn.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v14.0.2) with ESMTP id 16-md50000107255.msg for ; Sat, 24 May 2014 17:46:24 -0500 VBR-Info: md=altn.com; mc=all; mv=dwl.spamhaus.org:vbr.emailcertification.org; X-Spam-Processed: mail1.altn.com, Sat, 24 May 2014 17:46:24 -0500 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: arvel.hathcock@altn.com X-HashCash: 1:21:140524:md50000107255::CLPayk2sR6vEKAZE:00001+9/ X-Return-Path: prvs=1221557bbb=arvel.hathcock@altn.com X-Envelope-From: arvel.hathcock@altn.com X-MDaemon-Deliver-To: dmarc@ietf.org X-CAV-Result: clean Message-ID: <5381213B.20101@altn.com> Date: Sat, 24 May 2014 17:46:19 -0500 From: Arvel Hathcock User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5HpVALy-yTApXIezCDWpzBWeiy0 Subject: [dmarc-ietf] DMARC spec feedback X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 22:46:30 -0000 Hi all! Long time no talk :) I'm using base-04 and BCP-03 for the following feedback. I just finished my DMARC implementation for the next major rev of our mail server/list server and took some notes along the way to pass back to the community. Having just looked at this for the first time very recently (mostly due to Yahoo p=reject) I want to say that this was a treat to code and I thought the spec was well written. I had a lot of fun with this (yes, I'm a nerd). The BCP doc was also extremely helpful in explaining many of the XML nodes and providing guidance. Please don't give up on that as old programmers like me need to understand with as many examples as possible what proper XML construction should look like as validation that the more formal schema (like Appendix C of the base document) has been understood correctly. I've looked over the archive but forgive me if I'm dredging up old issues already resolved. 1. Sec 2.4 - This section states "This first version of DMARC supports only a single reporting format." But DMARC has XML, AFRF, and IODEF. Aren't these all reporting formats? 2. Sec 4 - This section talks about domain owners who don't want (for example) to have SPF results considered as part of a DMARC check. "If the results of path authorization checks ought not be considered...then the Domain Owner does not publish an SPF policy record that can produce an SPF pass result." Since it would be silly (I assume but maybe not?) to publish an SPF record that intentionally fails this amounts to saying "just don't use SPF" doesn't it? Is that OK and what you want to say? Why doesn't DMARC have its own tag/value to indicate that SPF results should not be considered? 3. Sec 7.1 - This section has a SHOULD that must be changed to a MUST IMO :) Otherwise there's an abuse vector there. The mechanism described in this section works as far as I can tell so I don't get why this is a SHOULD. 4. Sec 7.1 - OK this is somewhat a personal preference. I wish that step 8 would add some text to state that a new rua= / ruf= must have only one URI in it. It makes sense to me to replace a single old URI with a single new URI. But to replace a single old URI with multiple new ones is more complicated for implementers (who cares I know :) In the case of mailto URI's anyway a single email address can reference a mailing list and get as many as you want that way. But, I would like to hear what others think on this (besides the fact that I'm a lazy programmer ha ha). 5. Sec 11.2.1 - This section states "In the case of a "mailto" URI, the Mail Receiver MUST communicate reports using the method described in [STARTTLS] whenever it is offered by a Report Receiver. I think this should be a SHOULD because just as Report Receivers might not offer STARTTLS, some Mail Receivers might not support it either and for the same reasons. And its not enforceable. If the Report Receiver offers STARTTLS and the Mail Receiver ignores it what is the Report Receiver supposed to do? Refuse the reports? And is the Mail Receiver supposed to drop the connection when it sees a STARTTLS to which it knows it can not (for whatever reason) comply? Just something to think about. 6. Sec 11.2.1 - "...or "xml.gz" for an XML file compressed using GZIP" - in practice nobody that I've seen so far is doing this. So far, of all the reports I've received the filename is nearly always just ".ZIP" and the media type also varies. In fact the only one I've not seen is "application/gzip" which the spec calls for. Being as this is all over the map maybe we should at least reduce the MUST to a SHOULD for the extension. 7. 14.1 - Just to point out - the aggregate reports contain IP addresses and during my implementation and before I white-listed internal IP ranges some of my management team saw sample reports which included local internal IP addresses and assumed that these would be sent outside the org. Unfortunately, many suffer from the Earth-Sea Trilogy syndrome that Ned talked about in which its believed that knowing the name of a thing somehow confers power over the thing named. Many believe (I don't know if its true so I don't fight back on it) that publishing internal IP topography to those outside your org is dangerous. Anyway, I don't know if something needs to be mentioned on that or not. What is best advice on this? There's a single line in BCP section 12 which just says "IP Addresses in reports." 8. Sec 16.1 (or likely the BCP) should explain better how Authentication-Results is used with plenty of use-case examples. I'm still not sure I'm doing it right. For example, what does an AR look like when the pct= causes a sampled_out situation? Does AR need to indicate anything along the lines of policyoverrides like the aggregate report does? Basically, I'm not crystal clear on what this is documenting/communicating so I'm unsure that I have it right. 9. Appendix C - it looks like the "fo" tag is required by my reading there. But I don't think this is necessary. The type of reporting to which that tag is related is entirely optional. So this reduces to just a check to make sure your parser pulled out the correct value. I know there are other optional tags which are required by the schema but each of those have more relevance. Its fine to require it but it will always just be the default if the DMARC record publisher fails to specify otherwise or a value that means nothing if the report generator ignores ruf= type of reports. I'm not sure I'm understanding this point correctly. Thanks for reading and please don't blast me now that my ignorance is on full display - anyway, that's my wife's job. Would be nice to see you all and catch up :) Hope everyone is well. Arvel Alt-N Technologies, Ltd http://www.altn.com Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From nobody Sat May 24 18:31:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C145F1A01B4 for ; Sat, 24 May 2014 18:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLsRWQ4v1CMJ for ; Sat, 24 May 2014 18:31:27 -0700 (PDT) Received: from pop3.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B890A1A01A5 for ; Sat, 24 May 2014 18:31:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4753; t=1400981480; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=oGV9iYK+dedOYISzKOJ3o+n8SwE=; b=u5SbJe+QDJQJD4NxpvWa Ke+BadTIE0FY1TFBVL6sHzBuV6Ttq0mDFTSDgyZ+/HrduHEb2Z3Mt+FEx4xdEsm9 gJdCvHlPFWSejSUBX/0gKFEDA1In7fHGnFss062YMNL7BW6QZw2nlZAHLRb5ylWp 8cus4SaHJ4wv8gWQPlehRxs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 May 2014 21:31:20 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 461619095.10159.2180; Sat, 24 May 2014 21:31:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4753; t=1400981340; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JsGx6Pu Q3kXfU/vwk96XS/wjeBHq+GxmcBW5KJkPXjs=; b=OZmSpIv0dFJYfJfbKCcKZjR dd2nGEtECjJ9G4QRFVODRr+P4/ilgZWiZZlwd8aV730alZ0KGfjhUfx3SzfL77fG Vh9nhHT7NCFtiKEX58zFsfNtVdexDbv9w6VTroovyLHznyBNBcaMIuHon8YYn8HJ DiJjidgPw2iqmWOuhiXo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 24 May 2014 21:29:00 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 477987468.9.3244; Sat, 24 May 2014 21:28:59 -0400 Message-ID: <538147E9.9010809@isdg.net> Date: Sat, 24 May 2014 21:31:21 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Matt Simerson , dmarc@ietf.org References: <5380F812.9070809@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kAzXxeNufME1FLDRo4j871G9PJ8 Subject: Re: [dmarc-ietf] Supporting and Updating the IETF DMARC I-D draft X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 01:31:29 -0000 On 5/24/2014 4:10 PM, Matt Simerson wrote: > > On May 24, 2014, at 12:50 PM, Hector Santos wrote: > >> Off hand, I think the DMARC draft needs to be updated for two basic fundamental parts: >> >> 1) Separate Policy Handling and Reporting. If I read the draft right, reporting is mandatory. Reporting should not be mandatory to DMARC receivers. Not all receivers will want to add this huge overhead component just to support the most important part; the security policy portion of the protocol. Reporting is bound to be ignored and the DMARC draft should recognize this reality by not making essential nor necessary. > > Could you point to the areas within the draft that led you to believe that reporting is mandatory? > In Section 5.1. ... A report is to be sent to each listed URI. Mail Receivers MAY impose a limit on the number of URIs that receive reports, but MUST support at least two. In section 5.2. General Record Format ri: .... DMARC implementations MUST be able to provide daily reports and SHOULD be able to provide hourly reports when requested. However, anything other than a daily report is understood to be accommodated on a best-effort basis. rua: .... A Mail Receiver MUST implement support for a "mailto:" URI, i.e. the ability to send a DMARC report via electronic mail. If not provided, Mail Receivers MUST NOT generate aggregate feedback reports. Same with ruf. In section 6, Policy Enforcement Considerations Mail Receivers are only obligated to report reject or quarantine policy actions in aggregate feedback reports that are due to DMARC policy. They are not required to report reject or quarantine actions that are the result of local policy. If local policy information is exposed, abusers can gain insight into the effectiveness and delivery rates of spam campaigns. .... Mail Receivers SHOULD also implement reporting instructions of DMARC in place of any extensions to SPF or DKIM that might enable such reporting. The draft makes it clear that having a feedback, reporting mechanism allows for systems to learn how to best use the protocol. In section 7, "DMARC Feedback" it says: Providing Domain Owners with visibility into how Mail Receivers implement and enforce the DMARC mechanism in the form of feedback is critical to establishing and maintaining accurate authentication deployments. When Domain Owners can see what effect their policies and practices are having, they are better willing and able to use quarantine and reject policies. Also see section 11 "Feedback Mechanism." And so on Matt, the implementation requirement for reporting is peppered all over the document. Do you not think this is the case? Is there explicit statement that says reporting is optional? Do you know of any existing DMARC receiver which does not implement reporting but does handle the policy part? You have to keep in mind, that while DMARC does bring reporting structure, the idea of reporting was considered for other author domains protocols but came as an option and with suggestions to impose local policy limits. The anonymous domain DMARC policy SHOULD NOT mandate this reporting overhead on receivers. I would suggest the DMARC work came from these early discussions. The 2006 DSAP I-D was among the first to begin making it an option: http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.5 4.5. DSAP Tag: r= This tag is optional. If not defined, the default is no abuse- address is available. is either the user-part or a FQDN email address to optional send abuse reports. Examples: r=abuse r=abuse@example.com If only the user-part is defined, then the full address is established by using the originating address domain. DKIM verifiers have the option to honor or not honor this reporting address. DKIM signers MUST be aware this reporting address may not be utilized by verifiers. Verifiers should be aware this reporting address can be a source of an report attack vector (Section 7.4). One possible implementation considerations would to limit the report to one report only and to track the reception and/or response of the reporting. I have to admit that I am surprise in how popular this feature appears to be and underestimated it. Enabling DMARC myself, I am starting to get interesting reports. Not sure what it all means with the eventual redundancy in reporting that needs to be turned off. All I expected all along was for compliant receivers to handle the strict policies. Its guess its good to know that our domains are being protected at DMARC sites. -- HLS From nobody Tue May 27 19:49:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C0E1A02E6 for ; Tue, 27 May 2014 19:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RERnXYfTCnHV for ; Tue, 27 May 2014 19:49:32 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC331A02D9 for ; Tue, 27 May 2014 19:49:31 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id j107so15873196qga.20 for ; Tue, 27 May 2014 19:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=lnZyg3cxD40V+sSGKVNoA0W+tOmszFATzYwI3xt+0dQ=; b=fPAJOm7WFq6c3O0eVAGQAa0sNh2tMU7SmxV3TbwBDMitN/QdrTcOwGZw/KHJmoeEiZ cenjL24v0sRSAvNs5g+6w/HtCGNJ8ASjhWEpE1f9ypGYmKBayEbUiRuVZifMGbaGTsXz mLSAmDoB8YnaiC2LQwW4xdfFTdg5Uj9yiezIo9rMJ4u+HyQ+/XPart7Ia6BD6bwix4+1 Oe5PILuHOyNUqDBSfnX1xkXO1MEjIFcdfMtp6aOZC0f9RcMHwlqa4oSWVfS1bferXrnF JAPS5pkvgokDfWsxZ3slqjDLzSlRSc/LVXP9TJhWRXZR4KC4GZ2rzqII6ddrh79KlZDa QMGQ== X-Received: by 10.224.21.1 with SMTP id h1mr21322274qab.103.1401245368086; Tue, 27 May 2014 19:49:28 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id z33sm11238224qgd.31.2014.05.27.19.49.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 19:49:27 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_9EB47684-96E5-4341-BCCF-DD7630E77012" Message-Id: <05A66F17-6CCB-454B-AED2-B4F56187CB77@gmail.com> Date: Tue, 27 May 2014 19:49:26 -0700 To: dmarc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MQN88KGMKYs9pWUeBZsK4w4R8eU Subject: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 02:49:33 -0000 --Apple-Mail=_9EB47684-96E5-4341-BCCF-DD7630E77012 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear DMARC WG, A draft has been submitted for review. It covers past failures while = also providing a path forward. I have experience with similar systems operating at much higher scale = without difficulty or using much in the way of resources. Serving = several very large ISPs worth of users making queries against every = received message that then returned about 2 billion unique resource = responses. Originally, the service was free. In the wake of a massive compromise of accounts, some fairly large ISPs = are doing perhaps the only thing that is not (yet) ignored, DMARC. However, this new scheme only needs to sustain queries against already = validated third-party domains, but that then fail DMARC alignment = assertions. The number of resource records likely needed by large ISPs = will be in the 10s of thousands. For smaller domains, this will likely = only be a hand-full. Domains asserting DMARC alignment practices are = receiving cooperative feedback from many receivers who are also acting = on behalf of these domains to either reject or quarantine non-aligned = messages. Comparing this feedback against their own outbound logs = should permit fairly automatic alignment exception list creation that = can then be kindly offered to their cooperative receivers. These record = permit several mitigation strategies in the case of trouble. This scheme = should reduce the amount of feedback collected or support required to = deal with broken services. This can be done by creating an informal = federation of third-party providers. Perhaps one of the requirements = for being included in the federation would be to provide normal DMARC = feedback. ;^) http://tools.ietf.org/pdf/draft-otis-tpa-label-00.pdf Regards, Douglas Otis --Apple-Mail=_9EB47684-96E5-4341-BCCF-DD7630E77012 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = DMARC WG,

A draft has been submitted for review. =  It covers past failures while also providing a path = forward.

I have experience with similar systems = operating at much higher scale without difficulty or using much in the = way of resources.  Serving several very large ISPs worth of users = making queries against every received message that then returned about 2 = billion unique resource responses. Originally, the service was = free.

In the wake of a massive compromise of = accounts, some fairly large ISPs are doing perhaps the only thing that = is not (yet) ignored, DMARC.

However, this new = scheme only needs to sustain queries against already validated = third-party domains, but that then fail DMARC alignment assertions. The = number of resource records likely needed by large ISPs will be in the = 10s of thousands.  For smaller domains, this will likely only be a = hand-full.  Domains asserting DMARC alignment practices are = receiving cooperative feedback from many receivers who are also acting = on behalf of these domains to either reject or quarantine non-aligned = messages.  Comparing this feedback against their own outbound logs = should permit fairly automatic alignment exception list creation that = can then be kindly offered to their cooperative receivers.  These = record permit several mitigation strategies in the case of trouble. This = scheme should reduce the amount of feedback collected or support = required to deal with broken services.  This can be done by = creating an informal federation of third-party providers.  Perhaps = one of the requirements for being included in the federation would be to = provide normal DMARC feedback. ;^)

= --Apple-Mail=_9EB47684-96E5-4341-BCCF-DD7630E77012-- From nobody Wed May 28 00:08:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A34F1A0546 for ; Wed, 28 May 2014 00:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu1FOWhVS2C0 for ; Wed, 28 May 2014 00:07:53 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478E21A0384 for ; Wed, 28 May 2014 00:07:53 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id at1so9924605iec.15 for ; Wed, 28 May 2014 00:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9eMRHF7NwDHBCRIvnypJi1RwdJWQI5uwRruRqXv9Lec=; b=BWBKBsA5rpAMTk5Hk5raTTQ4rMH17cSY9118MLeS0+IxeMuGKy1xdd9DmxYgCyQSR8 x6Pw8sNcZ3NV1B1oK1DqQRGpi5NoU4zNCWTDiSk7XrCRFX8GyP7GDgWFK2Ljb0zc9qwe r+kZkwYKXwBbr59aG/cqyE2Di5P6N9fILaP1XkGFn3K4lXWDdW/wb2TVqCYHlsaeVTxn rSEML1kXw29Ae4zGvLYtwIOwGbdpAdFjnBnBlnRj98KX4EZpLf/zmqasO1vk34P2mnhl zhLalgpYjppLJ1ijLO2AJRDNXPtwEIzV/nHYZ9zF9EHC2XOgY6y1iYW4HXxuTqL4SdFp 00uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9eMRHF7NwDHBCRIvnypJi1RwdJWQI5uwRruRqXv9Lec=; b=I0HuLc/RrAYciMKYVUgbTh9rCI6+GORyDvn0YpufUKm3LUOJCL689rZHhrWtoN6NjF 5yb3icRDq2NMjFAT0TjkNUflb68yeqK2nXiBflH+BFfIy20rLaDxz821x3n2vVh5879C upZuyrqxJCA5hqN5uipNYvqVu0BtZK9Td4YYPhXJCnug4vcmloQeD4vSgxaG2Ug4BO91 N/th4W/rFMKLgpgozJjZpb84lh3lM7UM3mAm8xJFivz2j+6tud2WSGW+kO2PPoWx2o6I IGJsjNfmm5L6EgY+xhmXoJmtTj9Dplw3h/JN2AP6F40ofadFhftT0n/2eUoanwWw3Wk0 /TRw== X-Gm-Message-State: ALoCoQk0CISsuZrQ9+YcQFVzKNQ6Ls20BISw2HlE5VdAKt5HV3KUqhVIT9x474YFxJUcMSEzmYmk MIME-Version: 1.0 X-Received: by 10.42.152.70 with SMTP id h6mr25584760icw.3.1401260869539; Wed, 28 May 2014 00:07:49 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Wed, 28 May 2014 00:07:49 -0700 (PDT) In-Reply-To: <05A66F17-6CCB-454B-AED2-B4F56187CB77@gmail.com> References: <05A66F17-6CCB-454B-AED2-B4F56187CB77@gmail.com> Date: Wed, 28 May 2014 00:07:49 -0700 Message-ID: From: Brandon Long To: Douglas Otis Content-Type: multipart/alternative; boundary=90e6ba6e8f285e0ef404fa7078a9 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_kM9Z46a1ZFuE2GP5c3ksl29DCE Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 07:08:03 -0000 --90e6ba6e8f285e0ef404fa7078a9 Content-Type: text/plain; charset=UTF-8 So... I think this buries the lede a bit more than the OAR suggestion does. I could imagine something like this for broadcasting who a service trusts the OAR header from. This basically would require someone like Yahoo/Gmail to host some 30k DNS records granting any one of those third party services the ability to send mail for yahoo.com/gmail.com. For a service at this scale, you'd need to only do this for places where you "trust" their Authentication-Results header. There is a potential issue of conflicting AR headers, which is one benefit of the OAR. Its not clear to me that gmail.com needs to tell another service to trust the OAR from a given third party, the choice to trust that service could easily be up to the receiving service. Finally, doesn't this imply a potentially large number of DNS queries? Given the various mechanisms for finding the domain, and given that you have to look up the tpa record to know whether that mechanism is supported, it would seem you would need to look up tpa records for up to 7 possible domains, and potentially more with sub-domain checking. Brandon On Tue, May 27, 2014 at 7:49 PM, Douglas Otis wrote: > Dear DMARC WG, > > A draft has been submitted for review. It covers past failures while also > providing a path forward. > > I have experience with similar systems operating at much higher scale > without difficulty or using much in the way of resources. Serving several > very large ISPs worth of users making queries against every received > message that then returned about 2 billion unique resource responses. > Originally, the service was free. > > In the wake of a massive compromise of accounts, some fairly large ISPs > are doing perhaps the only thing that is not (yet) ignored, DMARC. > > However, this new scheme only needs to sustain queries against already > validated third-party domains, but that then fail DMARC alignment > assertions. The number of resource records likely needed by large ISPs will > be in the 10s of thousands. For smaller domains, this will likely only be > a hand-full. Domains asserting DMARC alignment practices are receiving > cooperative feedback from many receivers who are also acting on behalf of > these domains to either reject or quarantine non-aligned messages. > Comparing this feedback against their own outbound logs should permit > fairly automatic alignment exception list creation that can then be kindly > offered to their cooperative receivers. These record permit several > mitigation strategies in the case of trouble. This scheme should reduce the > amount of feedback collected or support required to deal with broken > services. This can be done by creating an informal federation of > third-party providers. Perhaps one of the requirements for being included > in the federation would be to provide normal DMARC feedback. ;^) > > http://tools.ietf.org/pdf/draft-otis-tpa-label-00.pdf > > Regards, > Douglas Otis > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --90e6ba6e8f285e0ef404fa7078a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So...=C2=A0

I think this buries the led= e a bit more than the OAR suggestion does. =C2=A0I could imagine something = like this for broadcasting who a service trusts the OAR header from.

This basically would require someone like Yahoo/Gmail to host some 30k= DNS records granting any one of those third party services the ability to = send mail for yahoo.com/gmail.com.

For a service at this scale, you'd need to only do = this for places where you "trust" their Authentication-Results he= ader. =C2=A0There is a potential issue of conflicting AR headers, which is = one benefit of the OAR.

Its not clear to me that gmail.com needs to tell another service to trust the OAR from a gi= ven third party, the choice to trust that service could easily be up to the= receiving service.

Finally, doesn't this imply a potentially large num= ber of DNS queries? =C2=A0Given the various mechanisms for finding the doma= in, and given that you have to look up the tpa record to know whether that = mechanism is supported, it would seem you would need to look up tpa records= for up to 7 possible domains, and potentially more with sub-domain checkin= g.

Brandon


<= div class=3D"gmail_quote">On Tue, May 27, 2014 at 7:49 PM, Douglas Otis <doug.mtview@gmail.com> wrote:
Dear DMA= RC WG,

A draft has been submitted for review. =C2=A0It c= overs past failures while also providing a path forward.

I have experience with similar systems operating at muc= h higher scale without difficulty or using much in the way of resources. = =C2=A0Serving several very large ISPs worth of users making queries against= every received message that then returned about 2 billion unique resource = responses. Originally, the service was free.

In the wake of a massive compromise of accounts, some f= airly large ISPs are doing perhaps the only thing that is not (yet) ignored= , DMARC.

However, this new scheme only needs to su= stain queries against already validated third-party domains, but that then = fail DMARC alignment assertions. The number of resource records likely need= ed by large ISPs will be in the 10s of thousands. =C2=A0For smaller domains= , this will likely only be a hand-full. =C2=A0Domains asserting DMARC align= ment practices are receiving cooperative feedback from many receivers who a= re also acting on behalf of these domains to either reject or quarantine no= n-aligned messages. =C2=A0Comparing this feedback against their own outboun= d logs should permit fairly automatic alignment exception list creation tha= t can then be kindly offered to their cooperative receivers. =C2=A0These re= cord permit several mitigation strategies in the case of trouble. This sche= me should reduce the amount of feedback collected or support required to de= al with broken services. =C2=A0This can be done by creating an informal fed= eration of third-party providers. =C2=A0Perhaps one of the requirements for= being included in the federation would be to provide normal DMARC feedback= . ;^)


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


--90e6ba6e8f285e0ef404fa7078a9-- From nobody Wed May 28 09:38:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8ABD1A0450 for ; Wed, 28 May 2014 09:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdL4sDtmOe99 for ; Wed, 28 May 2014 09:37:54 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA75D1A044A for ; Wed, 28 May 2014 09:37:53 -0700 (PDT) Received: (qmail 97798 invoked from network); 28 May 2014 16:37:46 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 28 May 2014 16:37: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:mime-version:content-type:content-transfer-encoding; s=f975.538610da.k1405; i=johnl@user.iecc.com; bh=EnuxEIwnB7fNMTA/jBPRvu8aX4ZKmrRYOCo4DdX5Xkw=; b=fB84xPBzAxCLOWNOZcXZKUxwcu0G69vBqbg4eTj9rzqzTLDqLw6GlxQmluQsKQifsw6SJzg5GfwgV9bYBkJemFytIeYx7ZMBZmslD/UU0qfvoCNNue4vy3SMTlGjBQJDgwRKhRf4iuMIww6i9n8h7FXxUocyoTHFlL0a2qe0I2SfD2Z/SDlyzDW7BZNdLLyEMW330mjUgdqG1EB1/7EVpZD+rUQw0bzIlm/VjEsCuSSvLi/qtC7KgktGrTcKvPr8 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=f975.538610da.k1405; olt=johnl@user.iecc.com; bh=EnuxEIwnB7fNMTA/jBPRvu8aX4ZKmrRYOCo4DdX5Xkw=; b=qSEytjdcmmEZRkoVRwgzMSz7hS/q41/Sv/jBiWq6aWqHzde6W1oq/D97CyCg6nVKCHLLzUi6IEDjpn/t2v3eaQ2mQkM9iQdZK1xtMQR8fNJcYeenLvoSkIA/IGW6y4YnnkCwogy2Qy3UteCICxaZDQuWLNamRbpd5/8rVr3USRut89//3JOXTOu3g48teaTPd9ZzdZwexU/Rj7euDW6gZe524seWontS9oyA59X9ntCorlYow71yybnchjrVRE2u Date: 28 May 2014 16:37:23 -0000 Message-ID: <20140528163723.63860.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: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ny0Qjr53rCoiB0m_0rdXKJjWbXE Cc: blong@google.com Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 16:37:55 -0000 >For a service at this scale, you'd need to only do this for places where >you "trust" their Authentication-Results header. There is a potential >issue of conflicting AR headers, which is one benefit of the OAR. > >Its not clear to me that gmail.com needs to tell another service to trust >the OAR from a given third party, the choice to trust that service could >easily be up to the receiving service. Good point. That's why I keep saying that one or a few shared DMARC-bypass whitelists would work a lot better than anything per-sender. The set of senders where it makes sense to skip DMARC checks for Yahoo or AOL or Gmail addresses are likely to be the same. Also, considering the complete lack of interest that two large mail providers have shown in mitigating the costs of their DMARC policy decisions, it seems pretty unlikely that they'd implement anything like this for their own domains. >Finally, doesn't this imply a potentially large number of DNS queries? For per-user lists, hard to say. For a shared list, it should be insignificant, no more than one per message. R's, John From nobody Wed May 28 11:20:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45171A04AA for ; Wed, 28 May 2014 11:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3gqkJ4uBjvK for ; Wed, 28 May 2014 11:20:34 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8181A04F6 for ; Wed, 28 May 2014 11:20:33 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id i50so18743643qgf.17 for ; Wed, 28 May 2014 11:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1jLDQLCU9ZGawDOiVJw388IzvcsHdwZ4ycOIEUX+htQ=; b=OF+QsY7c5wb/Z+Pxkd/pTHUTuao1kvqIAhX9ureBaT3u4or97pe6YV9qBgxg0f2W0M 3ovLnTUKHJQpytfAPje1cRqa5hB1pJRORWVJCqv129I8f2KaRjaZPqpWM/XY74c9i+Ef KXUJRL/0Xct3cJYkBtAx46v59AZhp63QjTXpP4sFrXLSS2r6ox1V8y6TDZXxDdo3YXzP KnR3MffWjqoNV7cI55hE1xqyMRqdXMmLdthgdLYHYar632QwGjrCSp+t1WPslF82MVOi i/PjTR28xPTiAuZ02RVARUZAFry+q6fviYxFcOz+7KE3y6ND9xHVPOpo9TtxuA0mSK50 +4pw== X-Received: by 10.224.37.130 with SMTP id x2mr2206769qad.36.1401301229820; Wed, 28 May 2014 11:20:29 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 6sm31627615qam.44.2014.05.28.11.20.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 11:20:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E40DBF92-C857-4ADD-A2B0-585ED7B34B7F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Wed, 28 May 2014 11:20:28 -0700 Message-Id: <817C1A47-A547-462B-9094-CEBF76B4DDE7@gmail.com> References: <05A66F17-6CCB-454B-AED2-B4F56187CB77@gmail.com> To: Brandon Long X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TvdmZa1zI42VaqclGfePqbzsz9M Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 18:20:36 -0000 --Apple-Mail=_E40DBF92-C857-4ADD-A2B0-585ED7B34B7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 28, 2014, at 12:07 AM, Brandon Long wrote: > So...=20 >=20 > I think this buries the lede a bit more than the OAR suggestion does. = I could imagine something like this for broadcasting who a service = trusts the OAR header from. >=20 > This basically would require someone like Yahoo/Gmail to host some 30k = DNS records granting any one of those third party services the ability = to send mail for yahoo.com/gmail.com. >=20 > For a service at this scale, you'd need to only do this for places = where you "trust" their Authentication-Results header. There is a = potential issue of conflicting AR headers, which is one benefit of the = OAR. >=20 > Its not clear to me that gmail.com needs to tell another service to = trust the OAR from a given third party, the choice to trust that service = could easily be up to the receiving service. >=20 > Finally, doesn't this imply a potentially large number of DNS queries? = Given the various mechanisms for finding the domain, and given that you = have to look up the tpa record to know whether that mechanism is = supported, it would seem you would need to look up tpa records for up to = 7 possible domains, and potentially more with sub-domain checking. Dear Brandon, http://tools.ietf.org/html/draft-kucherawy-original-authres-00 You'll see statements in the TPA-Label draft about including = authentication-results and indeed this new header should be referenced = as well. Sorry about the omission. When there is a problem, the DMARC = domain is still unable to respond to what might cause expensive damage = when misplaced trust leads to customer attrition whenever uncontrolled = sources are allowed to flood inboxes spoofing their identity. The = TPA-Label draft permits an effective response in minutes. TPA-Label does not imply a large number of DNS transactions, unlike SPF = or even DKIM. TPA-Label is a single transaction directed toward a DMARC = domain. There should only be one DMARC domain recognized per message. = Of course, as with any DNS transaction, this can be redirected to other = domains. It is still a single transaction, unlike SPF which can result = in more than 100 transactions with any number of additional redirections = involving other domains completely unrelated to domains seen in the = exchange. The TPA-Label can assert which validation methods should be = used to help further reduce the number of DNS transactions needed.=20 A shared DMARC-bypass whitelists would remove control away from the = DMARC domain that has an incentive to ensure protection. Community = white-lists would make responding to any abuse impractical, to say the = least. In today's environment, an ability to respond should not be = overlooked. A TPA-Label authorization would not be granting anyone the ability to = send email for a domain. This authorization simply permits alignment = exceptions for specific third-party services that must still permit the = validation of their own domain. The authorization can also stipulate = third-party domains must include their domain in a Sender or a List-ID. = If a problem is seen by any of their messages, the DMARC domain can = retract authorization in minutes. Those who apply DMARC alignment = checks would be able to make exceptions for these third-party messages = based on advice given directly from the DMARC domain. TPA-Labels as a disruption remedy can be done fairly rapidly since this = would involve only those implementing DMARC. Changing 30K mailing lists = where one might be running in the basement of a local church should be = expected to take much longer. Google already provides free recursive DNS for anyone to use. It seems = possible, Google could even get the ball rolling by offering a = "_smtp._tpa.gmail.com" zone that others might wish to reference. This = would allow an easy and immediate solution for any DMARC domain willing = to allow Google to manage their third-party services. TPA-Labels will = require the support of some large ISP before is likely to gain adoption. = I'll update the draft to include draft-kucherawy-original-authres-00. Regards, Douglas Otis=20 > On Tue, May 27, 2014 at 7:49 PM, Douglas Otis = wrote: > Dear DMARC WG, >=20 > A draft has been submitted for review. It covers past failures while = also providing a path forward. >=20 > I have experience with similar systems operating at much higher scale = without difficulty or using much in the way of resources. Serving = several very large ISPs worth of users making queries against every = received message that then returned about 2 billion unique resource = responses. Originally, the service was free. >=20 > In the wake of a massive compromise of accounts, some fairly large = ISPs are doing perhaps the only thing that is not (yet) ignored, DMARC. >=20 > However, this new scheme only needs to sustain queries against already = validated third-party domains, but that then fail DMARC alignment = assertions. The number of resource records likely needed by large ISPs = will be in the 10s of thousands. For smaller domains, this will likely = only be a hand-full. Domains asserting DMARC alignment practices are = receiving cooperative feedback from many receivers who are also acting = on behalf of these domains to either reject or quarantine non-aligned = messages. Comparing this feedback against their own outbound logs = should permit fairly automatic alignment exception list creation that = can then be kindly offered to their cooperative receivers. These record = permit several mitigation strategies in the case of trouble. This scheme = should reduce the amount of feedback collected or support required to = deal with broken services. This can be done by creating an informal = federation of third-party providers. Perhaps one of the requirements = for being included in the federation would be to provide normal DMARC = feedback. ;^) >=20 > http://tools.ietf.org/pdf/draft-otis-tpa-label-00.pdf >=20 > Regards, > Douglas Otis --Apple-Mail=_E40DBF92-C857-4ADD-A2B0-585ED7B34B7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 28, 2014, at 12:07 AM, Brandon = Long <blong@google.com> = wrote:

So... 

I think = this buries the lede a bit more than the OAR suggestion does.  I = could imagine something like this for broadcasting who a service trusts = the OAR header from.

This basically would require someone like Yahoo/Gmail to host some = 30k DNS records granting any one of those third party services the = ability to send mail for yahoo.com/gmail.com.

For a service at this scale, you'd need to only do = this for places where you "trust" their Authentication-Results header. =  There is a potential issue of conflicting AR headers, which is one = benefit of the OAR.

Its not clear to me that gmail.com needs to tell another service = to trust the OAR from a given third party, the choice to trust that = service could easily be up to the receiving service.

Finally, doesn't this imply a potentially large = number of DNS queries?  Given the various mechanisms for finding = the domain, and given that you have to look up the tpa record to know = whether that mechanism is supported, it would seem you would need to = look up tpa records for up to 7 possible domains, and potentially more = with sub-domain checking.

Dear = Brandon,


You'll see statements in the TPA-Label draft about = including authentication-results and indeed this new header should be = referenced as well.  Sorry about the omission. When there is a = problem, the DMARC domain is still unable to respond to what might cause = expensive damage when misplaced trust leads to customer attrition = whenever uncontrolled sources are allowed to flood inboxes spoofing = their identity.  The TPA-Label draft permits an effective response = in minutes.

TPA-Label does not imply a = large number of DNS transactions, unlike SPF or even DKIM. =  TPA-Label is a single transaction directed toward a DMARC domain. = There should only be one DMARC domain recognized per message.  Of = course, as with any DNS transaction, this can be redirected to other = domains.  It is still a single transaction, unlike SPF which can = result in more than 100 transactions with any number of additional = redirections involving other domains completely unrelated to domains = seen in the exchange.  The TPA-Label can assert which validation = methods should be used to help further reduce the number of DNS = transactions needed. 

A shared = DMARC-bypass whitelists would remove control away from the DMARC domain = that has an incentive to ensure protection.  Community white-lists = would make responding to any abuse impractical, to say the least. =  In today's environment, an ability to respond should not be = overlooked.

A TPA-Label authorization would not = be granting anyone the ability to send email for a domain.  This = authorization simply permits alignment exceptions for specific = third-party services that must still permit the validation of their own = domain.  The authorization can also stipulate third-party domains = must include their domain in a Sender or a List-ID.  If a problem = is seen by any of their messages, the DMARC domain can retract = authorization in minutes.  Those who apply DMARC alignment checks = would be able to make exceptions for these third-party messages based on = advice given directly from the DMARC = domain.

TPA-Labels as a disruption remedy can = be done fairly rapidly since this would involve only those implementing = DMARC.  Changing 30K mailing lists where one might be running in = the basement of a local church should be expected to take much = longer.

Google already provides free recursive = DNS for anyone to use.  It seems possible, Google could even get = the ball rolling by offering a "_smtp._tpa.gmail.com" zone that others might = wish to reference.  This would allow an easy and immediate solution = for any DMARC domain willing to allow Google to manage their third-party = services.  TPA-Labels will require the support of some large ISP = before is likely to gain adoption.  I'll update the draft to = include dr= aft-kucherawy-original-authres-00.

Regards,
Douglas Otis 

On = Tue, May 27, 2014 at 7:49 PM, Douglas Otis <doug.mtview@gmail.com> wrote:
Dear DMARC = WG,

A draft has been submitted for review.  It = covers past failures while also providing a path forward.

I have experience with similar systems operating at = much higher scale without difficulty or using much in the way of = resources.  Serving several very large ISPs worth of users making = queries against every received message that then returned about 2 = billion unique resource responses. Originally, the service was = free.

In the wake of a massive compromise of accounts, = some fairly large ISPs are doing perhaps the only thing that is not = (yet) ignored, DMARC.

However, this new scheme = only needs to sustain queries against already validated third-party = domains, but that then fail DMARC alignment assertions. The number of = resource records likely needed by large ISPs will be in the 10s of = thousands.  For smaller domains, this will likely only be a = hand-full.  Domains asserting DMARC alignment practices are = receiving cooperative feedback from many receivers who are also acting = on behalf of these domains to either reject or quarantine non-aligned = messages.  Comparing this feedback against their own outbound logs = should permit fairly automatic alignment exception list creation that = can then be kindly offered to their cooperative receivers.  These = record permit several mitigation strategies in the case of trouble. This = scheme should reduce the amount of feedback collected or support = required to deal with broken services.  This can be done by = creating an informal federation of third-party providers.  Perhaps = one of the requirements for being included in the federation would be to = provide normal DMARC feedback. ;^)



= --Apple-Mail=_E40DBF92-C857-4ADD-A2B0-585ED7B34B7F-- From nobody Wed May 28 12:51:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E6C1A0386 for ; Wed, 28 May 2014 12:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.153 X-Spam-Level: X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4--S_N5ipsh for ; Wed, 28 May 2014 12:51:22 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id E9DE31A068C for ; Wed, 28 May 2014 12:51:21 -0700 (PDT) Received: from [192.168.2.109] (24-240-160-218.static.hckr.nc.charter.com [24.240.160.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id E5FC4CB46; Wed, 28 May 2014 15:51:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Draegen In-Reply-To: <20140528163723.63860.qmail@joyce.lan> Date: Wed, 28 May 2014 15:51:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140528163723.63860.qmail@joyce.lan> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BEaycK0sdVl5omD4F7Pu-7Co56Q Cc: blong@google.com, John Levine Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 19:51:23 -0000 On May 28, 2014, at 12:37 PM, John Levine wrote: > Also, considering the complete lack of interest that two large mail > providers have shown in mitigating the costs of their DMARC policy > decisions, it seems pretty unlikely that they'd implement anything > like this for their own domains. We (the people behind the machines) need to stop the above = misinformation. Yahoo posted this: = http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-wha= t-should-senders-do .. it includes an open invite to support developers. The problem that = Yahoo has now is that not enough people know about their efforts to fix = things. *OR*, people might not know how to fix things. There's that, too. =3D- Tim From nobody Wed May 28 13:14:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B381A029F for ; Wed, 28 May 2014 13:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L75exMrAzMw for ; Wed, 28 May 2014 13:14:02 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 045D11A0051 for ; Wed, 28 May 2014 13:14:02 -0700 (PDT) Received: from [192.168.2.109] (24-240-160-218.static.hckr.nc.charter.com [24.240.160.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id D6917CB46 for ; Wed, 28 May 2014 16:14:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Draegen In-Reply-To: <20140528163723.63860.qmail@joyce.lan> Date: Wed, 28 May 2014 16:13:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> References: <20140528163723.63860.qmail@joyce.lan> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6EOXZ87fjsgF4mTPKqUv2JN2DEE Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 20:14:04 -0000 On May 28, 2014, at 12:37 PM, John Levine wrote: >> Its not clear to me that gmail.com needs to tell another service to = trust >> the OAR from a given third party, the choice to trust that service = could >> easily be up to the receiving service. >=20 > Good point. That's why I keep saying that one or a few shared > DMARC-bypass whitelists would work a lot better than anything > per-sender. The set of senders where it makes sense to skip DMARC > checks for Yahoo or AOL or Gmail addresses are likely to be the same. Doug, I read through the spec, and it is clear a lot of work went into it. I = think I echo Brandon and John's above opinions. =46rom my PoV, there exists an immense pile of work to get through = before the draft under discussion becomes a solution. Aside from = support, tooling, getting senders to deploy accurately and getting = receivers to perform additional checks.. what is missing is the = justification for the additional work. DMARC is a tradeoff between keeping things as simple as possible (as = unnecessary complexity acts as a giant barrier to adoption), building on = existing technologies (as new code/libraries in the world of email means = tacking on additional calendar years), and solving a problem that hurts = enough to warrant doing anything at all. I don't believe TPA-Label hits the mark between "solving a big hurt" and = "simple". IOW, it's too complicated for the amount of pain it would = resolve. Just my opinion, take care, =3D- Tim From nobody Wed May 28 13:33:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EC41A0383 for ; Wed, 28 May 2014 13:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga9HrQthujLH for ; Wed, 28 May 2014 13:33:47 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03221A024B for ; Wed, 28 May 2014 13:33:46 -0700 (PDT) Received: (qmail 64391 invoked from network); 28 May 2014 20:33:38 -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=fb86.53864822.k1405; bh=QsoBUS3zq2RmSNrjcw1u2GjHBmkAxCfqoLoKDFcAuIc=; b=dJfMHoNi+hnI93dcidvyEm/XlT8+M5PgMgZU/tN2foJfbuXd7vc34rjeur8Q3TkuUkibBCq/nRTcI8R/e2Ul1jv4aigUhjjUJmlKWx98wI/lDZSFU0T8b/BShUQYuy8pxXFFTQBlUcEdY7/c2ekAPX3KnI4+wUTc76lpv8dQH3ZwndjgQ06tLqCfYv2WmkVz2IgGKOpVxKLXbOXcJ/lX41jUPYR5/BbqfkmCAqFInQqObufIioiW2llHJCkpqHYd 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=fb86.53864822.k1405; bh=QsoBUS3zq2RmSNrjcw1u2GjHBmkAxCfqoLoKDFcAuIc=; b=ru+GMQY+PPXWRiCRt+NN6usHbZsnPmGtAZjxWvP2c9sWUWoGAVK8caX0f2iJ/ANU5QBCtxDoD52WL2PqTLTIViQ25YDu4K0LF7niEVYhiXX+SPUVujlNgEEJ8GRmlEx6uyAwmopG2jLDUJi8WLbhJhYRRLQq/9OoTbpe2MpGrUfx/+bbVooJSYbFr6/dSWF1HcfV9NeOWkCyLg5Aa1fHvUUYJZwUPBFCOlFXDVnmeS4Ovs7ydoyV/D7PrOi6TdVn Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 28 May 2014 20:33:38 -0000 Date: 28 May 2014 16:33:36 -0400 Message-ID: From: "John R Levine" To: "Tim Draegen" In-Reply-To: References: <20140528163723.63860.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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GqWv0Fr03p5CQYSg3t_OmgIs4xY Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 20:33:48 -0000 > On May 28, 2014, at 12:37 PM, John Levine wrote: >> Also, considering the complete lack of interest that two large mail >> providers have shown in mitigating the costs of their DMARC policy >> decisions, it seems pretty unlikely that they'd implement anything >> like this for their own domains. > > We (the people behind the machines) need to stop the above misinformation. Yahoo posted this: > > http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what-should-senders-do > > .. it includes an open invite to support developers. The problem that Yahoo has now is that not enough people know about their efforts to fix things. Hi, Tim. That page is an excellent example of the large mail providers' complete lack of interest in mitigating the costs of their DMARC policy. That web page is full of suggestions about how other people can spend their time and money to make changes to their existing software that make the software work worse and break features that their users depend on, solely to work around DMARC. If the providers were interested in mitigating the damage, that would involve spending their own time and money so the people who they've hurt don't have to. > *OR*, people might not know how to fix things. There's that, too. I have been in extensive correspondence with the people who develop and maintain the Mailman discussion list software, and can only find that suggestion gratuitously insulting. They know as much about e-mail as anyone, they've been tearing their hair out trying to figure out how to deal with the problems that the two mail providers have created, they've implemented and tested all sorts of workarounds including several not on that web page, and they agree that they all stink. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed May 28 14:07:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A258B1A069A for ; Wed, 28 May 2014 14:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8af01r5RRRos for ; Wed, 28 May 2014 14:07:48 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7209A1A068F for ; Wed, 28 May 2014 14:07:48 -0700 (PDT) Received: from [192.168.2.109] (24-240-160-218.static.hckr.nc.charter.com [24.240.160.218]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 812EFCB46; Wed, 28 May 2014 17:08:04 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Draegen In-Reply-To: Date: Wed, 28 May 2014 17:07:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140528163723.63860.qmail@joyce.lan> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tEPCBdp51vFgp1ywi-AFiNuHVX8 Cc: John R Levine Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 21:07:51 -0000 On May 28, 2014, at 4:33 PM, John R Levine wrote: >> We (the people behind the machines) need to stop the above = misinformation. Yahoo posted this: >>=20 >> = http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-wha= t-should-senders-do >>=20 >> .. it includes an open invite to support developers. The problem = that Yahoo has now is that not enough people know about their efforts to = fix things. >=20 > Hi, Tim. That page is an excellent example of the large mail = providers' complete lack of interest in mitigating the costs of their = DMARC policy. That web page is full of suggestions about how other = people can spend their time and money to make changes to their existing = software that make the software work worse and break features that their = users depend on, solely to work around DMARC. If the providers were = interested in mitigating the damage, that would involve spending their = own time and money so the people who they've hurt don't have to. Hello John, what you're missing -- and its easy to miss -- is that Yahoo = has an outstanding offer to help developers (this means $!) fix things. = This is not as clear as it should be, which is why I point it out to = people as much as a I can. To be clear, this is a counter point to the = "complete lack of interest in mitigating the costs of their DMARC = policy" theme. It's just not true. A sentiment like "Large mail providers aren't doing enough to mitigate = the costs of their DMARC policy" is something I'd agree with. That's an = interesting discussion, which might even be fruitful. Complaining about = the inability for large mail providers to "fix email" isn't something = I'm interested in -- decentralized email is worth keeping around, even = if it means sometimes having to change stuff. >=20 >> *OR*, people might not know how to fix things. There's that, too. >=20 > I have been in extensive correspondence with the people who develop = and maintain the Mailman discussion list software, and can only find = that suggestion gratuitously insulting. John, you are very difficult to communicate with, maybe because you're = easily insulted, even when there is no insult. I too have been in = correspondence with mailing list developers, and also developers behind = businesses that rely on email, and also a slew of decision makers... and = they're all trying to understand how they can fix things without going = backwards. Figuring out how to make email slightly less capable of = harming people is a big deal. > They know as much about e-mail as anyone, they've been tearing their = hair out trying to figure out how to deal with the problems that the two = mail providers have created, they've implemented and tested all sorts of = workarounds including several not on that web page, and they agree that = they all stink. Tell the people you're communicating with to post their finding to = either this list or the dmarc-discuss list. There is no reason why = their findings should be frustrating -- others are meeting the = challenge, and others still would likely benefit from their learnings. =3D- Tim From nobody Wed May 28 14:12:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054BB1A069A for ; Wed, 28 May 2014 14:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1we_zqLCBkq0 for ; Wed, 28 May 2014 14:12:21 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B172B1A069C for ; Wed, 28 May 2014 14:12:21 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 9so8811572ykp.13 for ; Wed, 28 May 2014 14:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=vHiOcwFfDF3q1+VF1RGj3DgrG1SReelVOz+xqXJc18k=; b=n411yU+MyvJj0qPbstemqGFk5WKhPumx537iXZlAN5gaY5ib/Imd5mUJy/KqFPs0EO qPQS0bcCkTEiF+/1wDzWlteWlV8Jg3G/KxvVclWia16LEKN+3+1OtYtATPyBPCw6gdVV 7PxYepIFnF0Tx06F8Ad5rU0g9QDVwvubsDkHeS7oCeJsK0tUKAtDFVfvTB1iCG0Ln3+h MiadxjjUyP38VIqn3SWCPpARedqVUpbPVPSRx8aifdr2yKjXW9bNMma745mnr0SAE8OT HHOUz5pH6g+iCPFoB+eW0oc8ZSXT8X+5EfMuJenh+D7L8vRtg0N+znQwVIZ9LscTu7aO eFBg== X-Received: by 10.236.206.97 with SMTP id k61mr2741562yho.107.1401311537799; Wed, 28 May 2014 14:12:17 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id c26sm2338959yha.4.2014.05.28.14.12.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 14:12:16 -0700 (PDT) Message-ID: <53865108.80207@gmail.com> Date: Wed, 28 May 2014 14:11:36 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Tim Draegen , dmarc@ietf.org, John R Levine References: <20140528163723.63860.qmail@joyce.lan> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-6-iyJkw9_UA-x2Ev0ljDz71TRk Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 21:12:23 -0000 On 5/28/2014 2:07 PM, Tim Draegen wrote: >> > I have been in extensive correspondence with the people who develop and maintain the Mailman discussion list software, and can only find that suggestion gratuitously insulting. > John, you are very difficult to communicate with, maybe because you're easily insulted, even when there is no insult. I too have been in correspondence with mailing list developers, and also developers behind businesses that rely on email, and also a slew of decision makers... and they're all trying to understand how they can fix things without going backwards. All these background technical discussions sound like they are fascinating. Given that this list is supposed to be for technical discussion of matters relating to DMARC -- with an eye towards possible standardization -- and given that specification of methods for interworking with mailing lists is such an extremely salient issue, perhaps folks could consider moving presentation and review of design choices into this forum? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 28 14:32:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB571A0195 for ; Wed, 28 May 2014 14:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETueIrx-jnUK for ; Wed, 28 May 2014 14:32:01 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id 709161A065F for ; Wed, 28 May 2014 14:32:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 152B3A0473; Wed, 28 May 2014 16:31:57 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF83fkQ8Iyjj; Wed, 28 May 2014 16:31:57 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E58D2A04C3; Wed, 28 May 2014 16:31:56 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id CDB17A04BD; Wed, 28 May 2014 16:31:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id S865mcL5ZRq9; Wed, 28 May 2014 16:31:56 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id AEBF1A0473; Wed, 28 May 2014 16:31:56 -0500 (CDT) Date: Wed, 28 May 2014 16:31:55 -0500 (CDT) From: Franck Martin To: John R Levine Message-ID: <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Solution for DMARC disruption of normal email use while still offering its normal protection Thread-Index: btmv20oBkkKbW31xGL4iMFjsiHkm5g== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cw6tNrQgfSkwypQsH8trVFMjl2A Cc: dmarc@ietf.org, Tim Draegen Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 21:32:04 -0000 ----- Original Message ----- > From: "John R Levine" > To: "Tim Draegen" > Cc: dmarc@ietf.org > Sent: Wednesday, May 28, 2014 1:33:36 PM > Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal > protection > > > On May 28, 2014, at 12:37 PM, John Levine wrote: > >> Also, considering the complete lack of interest that two large mail > >> providers have shown in mitigating the costs of their DMARC policy > >> decisions, it seems pretty unlikely that they'd implement anything > >> like this for their own domains. > > > > We (the people behind the machines) need to stop the above misinformation. > > Yahoo posted this: > > > > http://yahoomail.tumblr.com/post/82426900353/yahoo-dmarc-policy-change-what-should-senders-do > > > > .. it includes an open invite to support developers. The problem that > > Yahoo has now is that not enough people know about their efforts to fix > > things. > > Hi, Tim. That page is an excellent example of the large mail providers' > complete lack of interest in mitigating the costs of their DMARC policy. > That web page is full of suggestions about how other people can spend > their time and money to make changes to their existing software that make > the software work worse and break features that their users depend on, > solely to work around DMARC. If the providers were interested in > mitigating the damage, that would involve spending their own time and > money so the people who they've hurt don't have to. > > > *OR*, people might not know how to fix things. There's that, too. > > I have been in extensive correspondence with the people who develop and > maintain the Mailman discussion list software, and can only find that > suggestion gratuitously insulting. They know as much about e-mail as > anyone, they've been tearing their hair out trying to figure out how to > deal with the problems that the two mail providers have created, they've > implemented and tested all sorts of workarounds including several not on > that web page, and they agree that they all stink. > Pushing your version of things, does not make it more true... The changes in mailman to handle DMARC came from people involved with DMARC.org. So we cared. I recall clearly, you did not want to see any change happening so you could reinforce your conspiracy theory. While the mailman developers are not happy on the current solutions and are looking for better solutions, they are at the same time happy to had one, when yahoo did the DMARC policy change, and quickly extended on the possibilities based on the experience they had before Yahoo did the policy change. Now, while mailman has some solutions, it is in the recent versions and many people are still running old versions of mailman and upgrading or patching for them is difficult. So saying people do not know how to fix things is perfectly valid too. Time to stop these non-technical threads and focus on making email more secure by providing solutions for people to choose from. From nobody Wed May 28 14:52:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CD91A02F5 for ; Wed, 28 May 2014 14:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjiyZeW27sQS for ; Wed, 28 May 2014 14:52:14 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9330F1A0282 for ; Wed, 28 May 2014 14:52:14 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 19E6BD04623; Wed, 28 May 2014 17:52:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401313930; bh=060UJCJO0oDE0cxDtkvAxqElCG81eJdYq8zCO3MvVjw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wA9vKjI98bqBb/smvaqo7czkEeQH0IOGdCYdo72P0VBWznSSe5qK6jASWPsG8+pqg 3A8o+NsMlBmXuW7jWQathchOKT7sv2fjzwoYa3it/omJSQ1yhRfTY+H8mql9K7Gz1X h2BAxmLHpEdmk8w2NLdaBCYtFejLNe2KbDJUHqu4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DA538D04622; Wed, 28 May 2014 17:52:09 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 28 May 2014 17:52:08 -0400 Message-ID: <1444962.yn6TflRTra@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: <53865108.80207@gmail.com> References: <20140528163723.63860.qmail@joyce.lan> <53865108.80207@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/qpVz6M_-Sh4M3qkPCAF3_f4ruvk Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 21:52:17 -0000 On Wednesday, May 28, 2014 14:11:36 Dave Crocker wrote: > On 5/28/2014 2:07 PM, Tim Draegen wrote: > >> > I have been in extensive correspondence with the people who develop and > >> > maintain the Mailman discussion list software, and can only find that > >> > suggestion gratuitously insulting.> > > John, you are very difficult to communicate with, maybe because you're > > easily insulted, even when there is no insult. I too have been in > > correspondence with mailing list developers, and also developers behind > > businesses that rely on email, and also a slew of decision makers... and > > they're all trying to understand how they can fix things without going > > backwards. > All these background technical discussions sound like they are fascinating. > > Given that this list is supposed to be for technical discussion of > matters relating to DMARC -- with an eye towards possible > standardization -- and given that specification of methods for > interworking with mailing lists is such an extremely salient issue, > perhaps folks could consider moving presentation and review of design > choices into this forum? This may sound like a flip question, but it's a serious one: Since, as I understand it, DMARC will not be an IETF specification, what is the IETF work here? Is there a clear boundary between the independent submission's requirements and what the IETF should be doing? It feels like the demarcation (pun intended) is DMARC is immovably what's currently deployed by a number of large providers that invested in it and the IETF work is to clean up the side effects. Now that's not a very pretty way to put it, but I don't think it's completely wrong either. How do we define the scope of work for this list? Scott K From nobody Wed May 28 14:55:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02841A0272 for ; Wed, 28 May 2014 14:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8gGjTPJa2hV for ; Wed, 28 May 2014 14:55:44 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB04D1A028E for ; Wed, 28 May 2014 14:55:43 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so9348934yha.40 for ; Wed, 28 May 2014 14:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=0IuPF5g/q6h1CHXkCoJabAEkNqQJRsqP3zkC1ncgNKQ=; b=gl0xEuIcbektncykavNLluWK3LhwwYkIj7UtbJXJ8Q/XWTAsF1CTXjvVz54YInVGg6 M0WSQbTM4n0BKEtVvhD/ehX0ub6EtWAJh7NJb9Q76CxeSO2g+xrkkd7JTIXFRuYwR4sq s87p00TiJyimom0zGNNRAmxVSeWTZpBDcwyt083uRVyYY940tthSfApwVp8iVkWS2KC6 0gjwWXEqSk+blkvh3UWRees7Khoz/tWT2Vpl3vowydeedqETu5yZYHD7UVb3mkeTLcsb joaEpRni8vVAigx5JuNLYH1lz+LA3m5g7lXZ708Om7ha0cw2pGgubEe610FupGKiTWZE JDLA== X-Received: by 10.236.90.225 with SMTP id e61mr3174231yhf.15.1401314139932; Wed, 28 May 2014 14:55:39 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id k65sm29587767yhl.43.2014.05.28.14.55.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 14:55:39 -0700 (PDT) Message-ID: <53865B33.9030506@gmail.com> Date: Wed, 28 May 2014 14:54:59 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Scott Kitterman , dmarc@ietf.org References: <20140528163723.63860.qmail@joyce.lan> <53865108.80207@gmail.com> <1444962.yn6TflRTra@scott-latitude-e6320> In-Reply-To: <1444962.yn6TflRTra@scott-latitude-e6320> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1vPM-zW6b0E8QJPYhU7AIr0ShmQ Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 21:55:45 -0000 On 5/28/2014 2:52 PM, Scott Kitterman wrote: > How do we define the scope of work for this list? Merely as an example, one line of effort could be towards methods of DKIM signature survival through mailing lists. It's not a new topic and it's not an easy one, and it doesn't even have the string D-M-A-R-C in it, but any real progress for this could be quite helpful in mitigating collateral damage with especially aggressive DMARC use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 28 15:18:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230601A0698 for ; Wed, 28 May 2014 15:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-rD1aah1UOh for ; Wed, 28 May 2014 15:18:15 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914841A04B6 for ; Wed, 28 May 2014 15:18:15 -0700 (PDT) Received: from ipad.att.net (107-214-150-206.lightspeed.sntcca.sbcglobal.net [107.214.150.206]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s4SMIAUZ016517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 28 May 2014 15:18:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1401315491; bh=qRIIjKY0aKgr7nenqksbK8NUr6vMEwcF1wIlPZXDhZs=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=M8XWk5pg82OdfjECddefEckSoqW1es9WpT4IWcbnbbTsYK1VJvF0KlWhfl4gFMxiw 93im9gGzpXXvnGBPBZpB1jKPpgQSf7+lDxA9O9m+Ut29bWU32mghaS55HYl59kLwO0 Z+nVrIHL9paRgIC0NcNphz9WolWVTi3ho3LTXJfw= Message-ID: <5386609C.5020506@bluepopcorn.net> Date: Wed, 28 May 2014 15:18:04 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140528163723.63860.qmail@joyce.lan> <53865108.80207@gmail.com> <1444962.yn6TflRTra@scott-latitude-e6320> <53865B33.9030506@gmail.com> In-Reply-To: <53865B33.9030506@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/uhCEanCLlsGNEL9VlJUCLIbc3No Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:18:17 -0000 On 5/28/14 2:54 PM, Dave Crocker wrote: > On 5/28/2014 2:52 PM, Scott Kitterman wrote: >> How do we define the scope of work for this list? > > Merely as an example, one line of effort could be towards methods of > DKIM signature survival through mailing lists. > > It's not a new topic and it's not an easy one, and it doesn't even have > the string D-M-A-R-C in it, but any real progress for this could be > quite helpful in mitigating collateral damage with especially aggressive > DMARC use. Since you don't mention it, what about the "mail this article to a friend" use case that has also been mentioned? Is that a problem that should be addressed here? I want to make sure that isn't forgotten just because it doesn't affect IETF directly. -Jim From nobody Wed May 28 15:28:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6851A06FB for ; Wed, 28 May 2014 15:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XkXbjqQP5ME for ; Wed, 28 May 2014 15:28:07 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id DCA4E1A0301 for ; Wed, 28 May 2014 15:28:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 50F7560677; Wed, 28 May 2014 17:28:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZorvLhKNYBfK; Wed, 28 May 2014 17:28:03 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 294F260670; Wed, 28 May 2014 17:28:03 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 10CD260677; Wed, 28 May 2014 17:28:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rD7FdPMp6kiX; Wed, 28 May 2014 17:28:02 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id EBB9660670; Wed, 28 May 2014 17:28:02 -0500 (CDT) Date: Wed, 28 May 2014 17:28:02 -0500 (CDT) From: Franck Martin To: Jim Fenton Message-ID: <695969678.67071.1401316082355.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> <53865108.80207@gmail.com> <1444962.yn6TflRTra@scott-latitude-e6320> <53865B33.9030506@gmail.com> <5386609C.5020506@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Solution for DMARC disruption of normal email use while still offering its normal protection Thread-Index: +XEiblhkX6W9owW+m2BB9AGPZvDs9g== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZHzQC6xMQWqoC7Jch2lQl_fwDtg Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:28:09 -0000 ----- Original Message ----- > From: "Jim Fenton" > To: dmarc@ietf.org > Sent: Wednesday, May 28, 2014 3:18:04 PM > Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal > protection > > On 5/28/14 2:54 PM, Dave Crocker wrote: > > On 5/28/2014 2:52 PM, Scott Kitterman wrote: > >> How do we define the scope of work for this list? > > > > Merely as an example, one line of effort could be towards methods of > > DKIM signature survival through mailing lists. > > > > It's not a new topic and it's not an easy one, and it doesn't even have > > the string D-M-A-R-C in it, but any real progress for this could be > > quite helpful in mitigating collateral damage with especially aggressive > > DMARC use. > > Since you don't mention it, what about the "mail this article to a > friend" use case that has also been mentioned? Is that a problem that > should be addressed here? > > I want to make sure that isn't forgotten just because it doesn't affect > IETF directly. > It should not be forgotten. There are also all the use cases on how you get third parties sending emails on your behalf to become compliant. There are so many options available. The question, I have, is if the format of an RFC is the proper format to give implementation advice to "webmasters". Will they read it? or should it be a nice glossy email marketer style blog/white paper? From nobody Wed May 28 15:30:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139BB1A06F8 for ; Wed, 28 May 2014 15:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5H8pzncQuTeA for ; Wed, 28 May 2014 15:30:15 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4951A0301 for ; Wed, 28 May 2014 15:30:14 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id 131so8873350ykp.26 for ; Wed, 28 May 2014 15:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=emt8b5X1WozOzaOR7aJRO+uBp6mQ4H6UpuYmgQRl7WU=; b=Y03vM03y07vpztDdTRfWdEHdaDO67Ftp8xVenuIq53spygufsaDFmnLbZMo160Hadb Iz4+q4sO+FFMY9GY43UupqwGjJPC5qVzGZPIwsaKikG7rfHPwDZrDVgxObXZNNr8Zi+c cilqnz0RlvHj4AtkCUCV/cPOuXbfVzemSsnew6umqIgsa6sYSJgWgYvnJ2zc6tSO/MZy zm1ZkeaA98qyNfoEShzflqY/p12EZ9EXu96IW5ZF2XuArnfnMbo49Wyj6eLm9dp970O+ ++SZaevlmtbOeXm0MC7T67dxSOy1+jhqSsOPDVHH4gkgaWGY98i8rwdWgUZL++rNzUXP NoGg== X-Received: by 10.236.114.2 with SMTP id b2mr3645526yhh.92.1401316210888; Wed, 28 May 2014 15:30:10 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id i1sm29741659yhq.12.2014.05.28.15.30.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 15:30:10 -0700 (PDT) Message-ID: <5386634A.4040208@gmail.com> Date: Wed, 28 May 2014 15:29:30 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Franck Martin References: <20140528163723.63860.qmail@joyce.lan> <53865108.80207@gmail.com> <1444962.yn6TflRTra@scott-latitude-e6320> <53865B33.9030506@gmail.com> <5386609C.5020506@bluepopcorn.net> <695969678.67071.1401316082355.JavaMail.zimbra@peachymango.org> In-Reply-To: <695969678.67071.1401316082355.JavaMail.zimbra@peachymango.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ENRr3MOLP2JKlHBTLRGpBsTQsaI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:30:16 -0000 On 5/28/2014 3:28 PM, Franck Martin wrote: > how you get third parties sending emails on your behalf to become compliant. Please clarify what that means. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 28 15:34:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41A11A070F for ; Wed, 28 May 2014 15:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeU5hJxPoiie for ; Wed, 28 May 2014 15:34:01 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215601A070B for ; Wed, 28 May 2014 15:34:01 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id c1so3096652igq.7 for ; Wed, 28 May 2014 15:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=JrOHHyVUSzQAB6fVXqwy0abRycVjShd5g6MdXRBTPRk=; b=gdj37fufwBFJ3RMPmikOroffygPdsjAzljb+YW/LB+naBsbVZgkUMKBBlBL3FHBVfM QSn6naDk4MIabTQSZESiHcTCQGoiomvnd5y4jcdQhFRMY/xJXa/VO2U/387JlHq8vQZZ 7KgNS8zgEGMMjGzC1QbBdpvuj1n/zaorko+UL5GiXccD8dxUrHQWkaKtKR9Ls55jVT4I /9O4QDbxfUKgn0pywJ1zejM19v8nHigcoxFGWIFVV9K4wLRsVLA9gaAa3FXLou2O7mlQ I9ZrG01JGMKdE4Mu1rRQukeS/GSZtIPsOsoKiSgIO0Pzd0J9ifIDdqkPrlwWUT+frLJJ sh4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=JrOHHyVUSzQAB6fVXqwy0abRycVjShd5g6MdXRBTPRk=; b=KfmVWITkncqK2j7aX87PJ9U/Sy/9pNS1r7NMdQg3ihaUA/A2eOAZ+uIPmPo7UIuZ+s gqB9vwSW4gazGMU46h913wVKNVEidA+Nl92WXYoOFDz8rjUlS220TOSpZYTxmtvNhlCR 6Li2n1m+j7GK/X/WYiXt5Xa+9/Qx8NihljImklCZr9Qe3hhQ48qw8r9agA/zAcv1LeVc sanG41nRcmU7cyjBRHeXmiSPQvdRlnKwFSyXGc3cZsPiQckha3GlDIHxIX1pqQDfJArW jqzzT3WCffhHXvhLX+g08YToKTjv/PirI+hzaHqtgDjooeyIzlL2DUBySJgxS8I0ELuf qTgA== X-Gm-Message-State: ALoCoQn60+U2bqJxkaBXlwQDIZBb1Cilv1ncX3xYzu5CnzdPVIMWWhDBBZcL+k7M8Cum91zGiNcT MIME-Version: 1.0 X-Received: by 10.50.2.8 with SMTP id 8mr5385927igq.32.1401316437191; Wed, 28 May 2014 15:33:57 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Wed, 28 May 2014 15:33:57 -0700 (PDT) Date: Wed, 28 May 2014 15:33:57 -0700 Message-ID: From: Brandon Long To: Dave Crocker Content-Type: multipart/alternative; boundary=089e0115ff7075195304fa7d6854 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/naWfi6yUBS-Fmt_bfsT2Ao7QyW4 Cc: dmarc@ietf.org, Scott Kitterman Subject: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:34:03 -0000 --089e0115ff7075195304fa7d6854 Content-Type: text/plain; charset=UTF-8 We could attempt to define a dkim canonicalization that would pass through a mailing list. It should include the subject, but have rules for stripping "standard" subject prefixes. It should obviously include other headers, but not List-* headers (since the RFC for those says the mailing list should strip the existing ones). The body is challenging. We could have it specify a length... that does allow for some weirdness with html positioning. We could require no-html part. We could optionally require footers to be added as separate parts, and have the canonicalization be for "first text part". Of course, footers are 99% unnecessary. Take this list, the name/address/archive are already in the List-* headers. We have other issues, ie recent anti-spam legislation may require an unsubscribe link in the footer, depending on interpretation, especially if anyone on the list was subscribed "directly" and not double opt-in. Is the above possible? Probably. Are the holes too big? I do prefer this over many of the alternatives, as long as we can figure out something that the majority of lists won't break. That puts the onus on the providers who are honoring dmarc to sign their mail with the new canonicalization and support it when checking signatures. Brandon On Wed, May 28, 2014 at 2:54 PM, Dave Crocker wrote: > On 5/28/2014 2:52 PM, Scott Kitterman wrote: > > How do we define the scope of work for this list? > > > Merely as an example, one line of effort could be towards methods of > DKIM signature survival through mailing lists. > > It's not a new topic and it's not an easy one, and it doesn't even have > the string D-M-A-R-C in it, but any real progress for this could be > quite helpful in mitigating collateral damage with especially aggressive > DMARC use. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --089e0115ff7075195304fa7d6854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We could attempt to define a dkim canonicalization that wo= uld pass through a mailing list.

It should include the s= ubject, but have rules for stripping "standard" subject prefixes.= =C2=A0It should obviously include other headers, but not List-* headers (s= ince the RFC for those says the mailing list should strip the existing ones= ).

The body is challenging. =C2=A0We could have it specify= a length... that does allow for some weirdness with html positioning. =C2= =A0We could require no-html part.

We could optiona= lly require footers to be added as separate parts, and have the canonicaliz= ation be for "first text part".

Of course, footers are 99% unnecessary. =C2=A0 Take thi= s list, the name/address/archive are already in the List-* headers. =C2=A0W= e have other issues, ie recent anti-spam legislation may require an unsubsc= ribe link in the footer, depending on interpretation, especially if anyone = on the list was subscribed "directly" and not double opt-in.

Is the above possible? =C2=A0Probably. =C2=A0Are the ho= les too big?

I do prefer this over many of the alt= ernatives, as long as we can figure out something that the majority of list= s won't break. =C2=A0That puts the onus on the providers who are honori= ng dmarc to sign their mail with the new canonicalization and support it wh= en checking signatures.

Brandon

On Wed, May 28, 2014 at 2:54 PM, Dave Crocker &= lt;dcrocker@gmail.c= om> wrote:
On 5/28/2014 2:52 PM, Scott = Kitterman wrote:
> How do we define the scope of work for this list?


Merely as an example, one line of effort could be towards methods of<= br> DKIM signature survival through mailing lists.

It's not a new topic and it's not an easy one, and it doesn't e= ven have
the string D-M-A-R-C in it, but any real progress for this could be
quite helpful in mitigating collateral damage with especially aggressive DMARC use.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

--089e0115ff7075195304fa7d6854-- From nobody Wed May 28 15:45:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899831A0708 for ; Wed, 28 May 2014 15:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kihyEmTaGPEn for ; Wed, 28 May 2014 15:45:49 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id E04DA1A0272 for ; Wed, 28 May 2014 15:45:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 51BBCA055C; Wed, 28 May 2014 17:45:45 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMVvsHNvHVOM; Wed, 28 May 2014 17:45:45 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 2F97BA06D4; Wed, 28 May 2014 17:45:45 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 18AF9A055C; Wed, 28 May 2014 17:45:45 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7ikJw84L8gWx; Wed, 28 May 2014 17:45:45 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id EDB3EA06D6; Wed, 28 May 2014 17:45:44 -0500 (CDT) Date: Wed, 28 May 2014 17:45:44 -0500 (CDT) From: Franck Martin To: Dave Crocker Message-ID: <927381906.67404.1401317144602.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> <1444962.yn6TflRTra@scott-latitude-e6320> <53865B33.9030506@gmail.com> <5386609C.5020506@bluepopcorn.net> <695969678.67071.1401316082355.JavaMail.zimbra@peachymango.org> <5386634A.4040208@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Solution for DMARC disruption of normal email use while still offering its normal protection Thread-Index: YlBa//sGXz/XsEanf4ceOlOvEMRVww== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xJ-BTbN_Qg_FdloPoihCYK04HLE Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:45:49 -0000 ----- Original Message ----- > From: "Dave Crocker" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Wednesday, May 28, 2014 3:29:30 PM > Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal > protection > > On 5/28/2014 3:28 PM, Franck Martin wrote: > > how you get third parties sending emails on your behalf to become > > compliant. > > > Please clarify what that means. Before one can move to p=reject, it needs to take control of all the email streams. Here are a few use cases: -sending marketing emails via an ESP -sending surveys to employees and non-employees -contracting a third party helpdesk -contracting a third party Customer Relation Manager -contracting a third party travel system -Apps in the cloud and their notifications system -mobile phones using the telecom provider email system -service providers sending email to employees (HR, health, insurance, retirement,...) to their employee address or personal address -sending emails to interns/contractors, who like to forward everything to their primary email account -.... Some solutions: add to spf/give dkim key, delegate a subdomain, delegate records in a subdomain, use the third party domain. From nobody Wed May 28 15:46:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E001A072B for ; Wed, 28 May 2014 15:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHkoV6bAGQMc for ; Wed, 28 May 2014 15:46:45 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472661A071D for ; Wed, 28 May 2014 15:46:45 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id pa12so13384478veb.12 for ; Wed, 28 May 2014 15:46:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Fvb+jHhgGHahS53TNtnOUEFNPSMWWe6ZtTcEmS1l5R8=; b=mx20CchjErtyrvR2Rw00r34Sl6Kc8sesn+dK/Np+Cbpm3UBtuPQhN1dXh+Qzbf0tgI JhIXshte73boWdXHZ1wM20Kmbw8s4OBI+obPnCUfZ36KBc5F3PHS11ANl8qzjzlVx68d Seg4brOJINTZHDKujHsYlgdb1ND1m6bvTDVqpJx48Ct7h/Lg/f5ORy5N+HkavGsYfnW2 t2PMy8CUqclVvwsKvGpFa00Kbo2TrwJwkDUUZkkgd72vg42Xz9obm8eAcTiwl/VrQV+1 SoXgtJj/qpcDhNzyGEhsQdv8HH59whGY+vuy97s9XKZ/BPIg1WBV5TcTBomCkxhpmfOO c9UQ== MIME-Version: 1.0 X-Received: by 10.52.173.165 with SMTP id bl5mr2402292vdc.13.1401317201132; Wed, 28 May 2014 15:46:41 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Wed, 28 May 2014 15:46:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 May 2014 18:46:41 -0400 X-Google-Sender-Auth: Mg60V35Zmjy7GFl6RELx8iL-QlQ Message-ID: From: Barry Leiba To: Brandon Long Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CKygSckLVPtJceTFeyncKt_Mmi0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:46:46 -0000 > We could attempt to define a dkim canonicalization that would pass through a > mailing list. This was beaten pretty severely during the DKIM work, and we couldn't come up with anything that was workable. > It should include the subject, but have rules for stripping "standard" > subject prefixes. It should obviously include other headers, but not List-* > headers (since the RFC for those says the mailing list should strip the > existing ones). > > The body is challenging. We could have it specify a length... that does > allow for some weirdness with html positioning. We could require no-html > part. > > We could optionally require footers to be added as separate parts, and have > the canonicalization be for "first text part". Anything that requires mailing list software to change won't work. If mailing list software is changed, the right answer is for the mailing list to re-sign the message. That doesn't help the DMARC situation now, but DMARC could be given other options once that happens. We discussed using l= at (um...) length, and no one liked that approach. There were too many holes, yes: allowing arbitrary amounts of data to be added to the message text, having it fail anyway if text isn't added at the end (such as for multipart messages), and so on. Heuristics involved in tweaking the subject are problematic. Some of this could perhaps work if we had a canonicalization that was *specific* to mailing list posts... but then how would the signing domain know that the message it was signing was going to a mailing list? I really think this isn't a useful approach, but perhaps someone might come up with the necessary "aha" to make it work. Barry From nobody Wed May 28 15:47:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E371A0716 for ; Wed, 28 May 2014 15:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts5WnGhD53I6 for ; Wed, 28 May 2014 15:47:02 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC6301A0272 for ; Wed, 28 May 2014 15:47:01 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id hl10so2881126igb.2 for ; Wed, 28 May 2014 15:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GlQfBdnsRT1xNgRdlP3S3X2CXhc2D4/nxSU90oKbad0=; b=DTyuaU+VeaYfiy9KY5G28GB4cCdqp4mZKigGNYwrXWUMRhkwiFsHIypT8GGsi+EXDH 8ue1UqcrOAxeU8pTW6e83GSGjFAgRqxTi4NpjabVErK6AccZEhtxIGGUJxLUWoq2WM/3 43kyq6zObhF2eIs1MiZjXqkltoU9coRplz4yFUEXGxTLSNmfmP5AvS7RW50S5pIulD7a QrOPFyc6gpZJRIkoP0pnC9ABlqT4woyVNYlCwjQyAz27h7TOfqPyfKOwIiS0BDJaDnci 5FgQiTk9I2RiVpQCUt/uLdgimt5TZCHgjS0gRnp7V300pMN5hzwaSEi01XTvaYFryPPZ 4DWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GlQfBdnsRT1xNgRdlP3S3X2CXhc2D4/nxSU90oKbad0=; b=KqLP3w7a3wM6S9D1lWc6dTW/UhnfLuckrfDVWwsbs6IQOd8WGjoldzudPrIj4bY59V ia5Uduuj0bc+nk1fWFXw15JHW3JxZbKVs7TItZ8ak6YWpQzQnluxkJSDCyMsCuEaTz5d 3IizEClXcbDgO0sPpc1Hut5h0ja0MDymXhkHu94nhlRmvmELMJgUyqRq7u61u4+Xk5cl 419FMzIXz0TUILJuJ7kr2Rhg3HlIKfOiYdySJWwzrKsm5KBFo5A6DvCr7L4lY7qo77WU RWj5PQjheDRJmfc5/2svyxPlGETJQ0SfE4I83XiWB3t+lWJ59NIhhBVsJneUp/CXSLrd 0/Yw== X-Gm-Message-State: ALoCoQmUc/xb0+vSrpBjxMH7KR+SPg4Q7fMCfYCQNRmwcV7wJ00ZC96TuePz/9HdSC0MuRR2iOi3 MIME-Version: 1.0 X-Received: by 10.42.152.70 with SMTP id h6mr3125785icw.3.1401317217857; Wed, 28 May 2014 15:46:57 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Wed, 28 May 2014 15:46:57 -0700 (PDT) In-Reply-To: <817C1A47-A547-462B-9094-CEBF76B4DDE7@gmail.com> References: <05A66F17-6CCB-454B-AED2-B4F56187CB77@gmail.com> <817C1A47-A547-462B-9094-CEBF76B4DDE7@gmail.com> Date: Wed, 28 May 2014 15:46:57 -0700 Message-ID: From: Brandon Long To: Douglas Otis Content-Type: multipart/alternative; boundary=90e6ba6e8f28fd1e5804fa7d965c Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mB9MbJ1hoy6cndFT2dvkeWZ5lj8 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:47:04 -0000 --90e6ba6e8f28fd1e5804fa7d965c Content-Type: text/plain; charset=UTF-8 On Wed, May 28, 2014 at 11:20 AM, Douglas Otis wrote: > > On May 28, 2014, at 12:07 AM, Brandon Long wrote: > > So... > > I think this buries the lede a bit more than the OAR suggestion does. I > could imagine something like this for broadcasting who a service trusts the > OAR header from. > > This basically would require someone like Yahoo/Gmail to host some 30k DNS > records granting any one of those third party services the ability to send > mail for yahoo.com/gmail.com. > > For a service at this scale, you'd need to only do this for places where > you "trust" their Authentication-Results header. There is a potential > issue of conflicting AR headers, which is one benefit of the OAR. > > Its not clear to me that gmail.com needs to tell another service to trust > the OAR from a given third party, the choice to trust that service could > easily be up to the receiving service. > > Finally, doesn't this imply a potentially large number of DNS queries? > Given the various mechanisms for finding the domain, and given that you > have to look up the tpa record to know whether that mechanism is supported, > it would seem you would need to look up tpa records for up to 7 possible > domains, and potentially more with sub-domain checking. > > > Dear Brandon, > > http://tools.ietf.org/html/draft-kucherawy-original-authres-00 > > You'll see statements in the TPA-Label draft about including > authentication-results and indeed this new header should be referenced as > well. Sorry about the omission. When there is a problem, the DMARC domain > is still unable to respond to what might cause expensive damage when > misplaced trust leads to customer attrition whenever uncontrolled sources > are allowed to flood inboxes spoofing their identity. The TPA-Label draft > permits an effective response in minutes. > I don't think it does. Take another way, without AuthRes, you're exposing your entire domain to phishing attacks if there is any open relay on the "whitelisted" domain. Even with AuthRes, you're exposing your users to any intrusion on a third party, and with 30k such third parties, some of them are going to get hacked some times. We've already seen "open posting" mailing lists on trusted third parties used for spear phishing attacks, and that's not something that "response in minutes" would solve. > TPA-Label does not imply a large number of DNS transactions, unlike SPF or > even DKIM. TPA-Label is a single transaction directed toward a DMARC > domain. There should only be one DMARC domain recognized per message. Of > course, as with any DNS transaction, this can be redirected to other > domains. It is still a single transaction, unlike SPF which can result in > more than 100 transactions with any number of additional redirections > involving other domains completely unrelated to domains seen in the > exchange. The TPA-Label can assert which validation methods should be used > to help further reduce the number of DNS transactions needed. > Unless I'm mis-understanding, there is a single DMARC domain, but there are N third party domains allowed, and how each one is allowed is specified in their specific record. So, I look in list-id, and then do a lookup for ._smtp._tpa. and see if list-id domain is valid for tpa. If not, I then have to do and then go through the list of 7 possible locations, each of which could be different. And if sub-domains are allowed, then if the list-id is " foo.groups.google.com", I have to check "groups.google.com" and "google.com ". Also, if some of those domains are googlegroups.com or yahoogroups.com, whitelisting the entire thing is impractical, its not a controlled environment where you can garuntee zero abuse. Now, with caching, especially negative caching, and "legitimate" email most likely having the same domain in most of the seven locations, real world may be only a single lookup per message, and spoofed/bad messages would likely need all 7. Given that a small number of users is subscribed to any given mailing list, I think some sort of mail relay token or a new dkim canonicalization would be more practical. Then, you have "this list is allowed to relay this message" or "this user is subscribed to this list" or something. Even then, you may have issues with spear phishing attacks. Brandon > > A shared DMARC-bypass whitelists would remove control away from the DMARC > domain that has an incentive to ensure protection. Community white-lists > would make responding to any abuse impractical, to say the least. In > today's environment, an ability to respond should not be overlooked. > > A TPA-Label authorization would not be granting anyone the ability to send > email for a domain. This authorization simply permits alignment exceptions > for specific third-party services that must still permit the validation of > their own domain. The authorization can also stipulate third-party domains > must include their domain in a Sender or a List-ID. If a problem is seen > by any of their messages, the DMARC domain can retract authorization in > minutes. Those who apply DMARC alignment checks would be able to make > exceptions for these third-party messages based on advice given directly > from the DMARC domain. > > TPA-Labels as a disruption remedy can be done fairly rapidly since this > would involve only those implementing DMARC. Changing 30K mailing lists > where one might be running in the basement of a local church should be > expected to take much longer. > > Google already provides free recursive DNS for anyone to use. It seems > possible, Google could even get the ball rolling by offering a "_smtp._ > tpa.gmail.com" zone that others might wish to reference. This would > allow an easy and immediate solution for any DMARC domain willing to allow > Google to manage their third-party services. TPA-Labels will require the > support of some large ISP before is likely to gain adoption. I'll update > the draft to include draft-kucherawy-original-authres-00 > . > > Regards, > Douglas Otis > > On Tue, May 27, 2014 at 7:49 PM, Douglas Otis > wrote: > >> Dear DMARC WG, >> >> A draft has been submitted for review. It covers past failures while >> also providing a path forward. >> >> I have experience with similar systems operating at much higher scale >> without difficulty or using much in the way of resources. Serving several >> very large ISPs worth of users making queries against every received >> message that then returned about 2 billion unique resource responses. >> Originally, the service was free. >> >> In the wake of a massive compromise of accounts, some fairly large ISPs >> are doing perhaps the only thing that is not (yet) ignored, DMARC. >> >> However, this new scheme only needs to sustain queries against already >> validated third-party domains, but that then fail DMARC alignment >> assertions. The number of resource records likely needed by large ISPs will >> be in the 10s of thousands. For smaller domains, this will likely only be >> a hand-full. Domains asserting DMARC alignment practices are receiving >> cooperative feedback from many receivers who are also acting on behalf of >> these domains to either reject or quarantine non-aligned messages. >> Comparing this feedback against their own outbound logs should permit >> fairly automatic alignment exception list creation that can then be kindly >> offered to their cooperative receivers. These record permit several >> mitigation strategies in the case of trouble. This scheme should reduce the >> amount of feedback collected or support required to deal with broken >> services. This can be done by creating an informal federation of >> third-party providers. Perhaps one of the requirements for being included >> in the federation would be to provide normal DMARC feedback. ;^) >> >> http://tools.ietf.org/pdf/draft-otis-tpa-label-00.pdf >> >> Regards, >> Douglas Otis >> > > > --90e6ba6e8f28fd1e5804fa7d965c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, May 28, 2014 at 11:20 AM, Douglas Otis &l= t;doug.mtview@gm= ail.com> wrote:

On May 28, 2014, at 12:07 AM, Brandon Long <blong@google.com> wr= ote:

So...=C2=A0

I think this buries the lede a bit more than the OAR suggestion does. = =C2=A0I could imagine something like this for broadcasting who a service tr= usts the OAR header from.

This basically would require someone like Yahoo/Gmail to host some 30k= DNS records granting any one of those third party services the ability to = send mail for yaho= o.com/gmail.com.

For a service at this scale, you'd need to only do = this for places where you "trust" their Authentication-Results he= ader. =C2=A0There is a potential issue of conflicting AR headers, which is = one benefit of the OAR.

Its not clear to me that gmail.com needs to tell another service to trus= t the OAR from a given third party, the choice to trust that service could = easily be up to the receiving service.

Finally, doesn't this imply a potentially large num= ber of DNS queries? =C2=A0Given the various mechanisms for finding the doma= in, and given that you have to look up the tpa record to know whether that = mechanism is supported, it would seem you would need to look up tpa records= for up to 7 possible domains, and potentially more with sub-domain checkin= g.

Dear Brandon,

<= div>http://tools.ietf.org/html/draft-kucherawy-original-a= uthres-00

You'll see statements in the TPA-Label draft about = including authentication-results and indeed this new header should be refer= enced as well. =C2=A0Sorry about the omission. When there is a problem, the= DMARC domain is still unable to respond to what might cause expensive dama= ge when misplaced trust leads to customer attrition whenever uncontrolled s= ources are allowed to flood inboxes spoofing their identity. =C2=A0The TPA-= Label draft permits an effective response in minutes.

I don't think it does.

Take another way, without AuthRes, you're exposing your= entire domain to phishing attacks if there is any open relay on the "= whitelisted" domain. =C2=A0Even with AuthRes, you're exposing your= users to any intrusion on a third party, and with 30k such third parties, = some of them are going to get hacked some times. =C2=A0We've already se= en "open posting" mailing lists on trusted third parties used for= spear phishing attacks, and that's not something that "response i= n minutes" would solve. =C2=A0
=C2=A0
TPA-Label does not imply a large number of DNS transacti= ons, unlike SPF or even DKIM. =C2=A0TPA-Label is a single transaction direc= ted toward a DMARC domain. There should only be one DMARC domain recognized= per message. =C2=A0Of course, as with any DNS transaction, this can be red= irected to other domains. =C2=A0It is still a single transaction, unlike SP= F which can result in more than 100 transactions with any number of additio= nal redirections involving other domains completely unrelated to domains se= en in the exchange. =C2=A0The TPA-Label can assert which validation methods= should be used to help further reduce the number of DNS transactions neede= d.=C2=A0

Unless I'm mis-understandi= ng, there is a single DMARC domain, but there are N third party domains all= owed, and how each one is allowed is specified in their specific record.

So, I look in list-id, and then do a lookup for <lis= t-id domain hash>._smtp._tpa.<dmarc domain> and see if list-id dom= ain is valid for tpa. =C2=A0If not, I then have to do <sender domain>= and then go through the list of 7 possible locations, each of which could = be different.

And if sub-domains are allowed, then if the list-id is = "foo.groups.google.com&qu= ot;, I have to check "groups.goog= le.com" and "google.com&quo= t;.

Also, if some of those domains are googlegroups.com or = yahoogroups.com, whitelisting the entire thing is impractical, its not = a controlled environment where you can garuntee zero abuse.

Now, with caching, especially negative caching, and &qu= ot;legitimate" email most likely having the same domain in most of the= seven locations, real world may be only a single lookup per message, and s= poofed/bad messages would likely need all 7.

Given that a small number of users is subscribed to any= given mailing list, I think some sort of mail relay token or a new dkim ca= nonicalization would be more practical. =C2=A0Then, you have "this lis= t is allowed to relay this message" or "this user is subscribed t= o this list" or something. =C2=A0Even then, you may have issues with s= pear phishing attacks.

Brandon
=C2=A0

A shared= DMARC-bypass whitelists would remove control away from the DMARC domain th= at has an incentive to ensure protection. =C2=A0Community white-lists would= make responding to any abuse impractical, to say the least. =C2=A0In today= 's environment, an ability to respond should not be overlooked.

A TPA-Label authorization would not be granting anyone = the ability to send email for a domain. =C2=A0This authorization simply per= mits alignment exceptions for specific third-party services that must still= permit the validation of their own domain. =C2=A0The authorization can als= o stipulate third-party domains must include their domain in a Sender or a = List-ID. =C2=A0If a problem is seen by any of their messages, the DMARC dom= ain can retract authorization in minutes. =C2=A0Those who apply DMARC align= ment checks would be able to make exceptions for these third-party messages= based on advice given directly from the DMARC domain.

TPA-Labels as a disruption remedy can be done fairly ra= pidly since this would involve only those implementing DMARC. =C2=A0Changin= g 30K mailing lists where one might be running in the basement of a local c= hurch should be expected to take much longer.

Google already provides free recursive DNS for anyone t= o use. =C2=A0It seems possible, Google could even get the ball rolling by o= ffering a "_smtp._t= pa.gmail.com" zone that others might wish to reference. =C2=A0This= would allow an easy and immediate solution for any DMARC domain willing to= allow Google to manage their third-party services. =C2=A0TPA-Labels will r= equire the support of some large ISP before is likely to gain adoption. =C2= =A0I'll update the draft to include=C2=A0draft-kucher= awy-original-authres-00.

Regards,
Douglas Otis=C2=A0

<= div class=3D"gmail_quote">On Tue, May 27, 2014 at 7:49 PM, Douglas Otis <doug.mtview@gmail.com> wrote:
Dear DMARC WG,
A draft has been submitted for review. =C2=A0It covers past fail= ures while also providing a path forward.

I have experience with similar systems operating at muc= h higher scale without difficulty or using much in the way of resources. = =C2=A0Serving several very large ISPs worth of users making queries against= every received message that then returned about 2 billion unique resource = responses. Originally, the service was free.

In the wake of a massive compromise of accounts, some f= airly large ISPs are doing perhaps the only thing that is not (yet) ignored= , DMARC.

However, this new scheme only needs to su= stain queries against already validated third-party domains, but that then = fail DMARC alignment assertions. The number of resource records likely need= ed by large ISPs will be in the 10s of thousands. =C2=A0For smaller domains= , this will likely only be a hand-full. =C2=A0Domains asserting DMARC align= ment practices are receiving cooperative feedback from many receivers who a= re also acting on behalf of these domains to either reject or quarantine no= n-aligned messages. =C2=A0Comparing this feedback against their own outboun= d logs should permit fairly automatic alignment exception list creation tha= t can then be kindly offered to their cooperative receivers. =C2=A0These re= cord permit several mitigation strategies in the case of trouble. This sche= me should reduce the amount of feedback collected or support required to de= al with broken services. =C2=A0This can be done by creating an informal fed= eration of third-party providers. =C2=A0Perhaps one of the requirements for= being included in the federation would be to provide normal DMARC feedback= . ;^)




--90e6ba6e8f28fd1e5804fa7d965c-- From nobody Wed May 28 15:49:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B391A0743 for ; Wed, 28 May 2014 15:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD8nN_uILrkJ for ; Wed, 28 May 2014 15:49:29 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DF41A0716 for ; Wed, 28 May 2014 15:49:24 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id 131so8901557ykp.40 for ; Wed, 28 May 2014 15:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cSRtymjDX1veQkUUDt4o4BfjC84fPX8W86rhMfoKq2k=; b=Nk2CN9EJPhHY0FWDYj2GVws+AWuw7yxdRFwsstIefoyzh2XQ/ijHM/z1hN2+w2Etj9 miG5nHVhoCUzX0qlp+UGdpRuCf1FcVNB/OKEJokPahQVv9h8Q3eaUG/IyPawqbTPqewT zA0DuvLYKePxwhw02nfg93+C8QICEKSikVzRfkO3b5uWCpCnwzQVVNjMtl49Yw6vnjoK f32KnQtELb7qLt+dN60AdGY7K2yjpV1zo8+k3hBNnppcJgCsJwGCGUSTlkHYh6z9xNOp N1NMhoeb4Tjw88OMGB1RW2Ka6Xm6FbzyRHzsNykpAHzWb2mamahXf7k2Wpi96CAEDA0p rpLg== X-Received: by 10.236.147.232 with SMTP id t68mr3561699yhj.127.1401317360259; Wed, 28 May 2014 15:49:20 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id f7sm28530421yhd.1.2014.05.28.15.49.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 15:49:19 -0700 (PDT) Message-ID: <538667C7.8050206@gmail.com> Date: Wed, 28 May 2014 15:48:39 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Franck Martin References: <20140528163723.63860.qmail@joyce.lan> <1444962.yn6TflRTra@scott-latitude-e6320> <53865B33.9030506@gmail.com> <5386609C.5020506@bluepopcorn.net> <695969678.67071.1401316082355.JavaMail.zimbra@peachymango.org> <5386634A.4040208@gmail.com> <927381906.67404.1401317144602.JavaMail.zimbra@peachymango.org> In-Reply-To: <927381906.67404.1401317144602.JavaMail.zimbra@peachymango.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MFP1yqUHFXxsg0DBVd8pCKg9LzI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:49:30 -0000 On 5/28/2014 3:45 PM, Franck Martin wrote: > Before one can move to p=reject, it needs to take control of all the email streams. OK. Thanks for the clarification. The examples you provide are for third parties that have a business relationship with the domain owner. The interesting challenge is when a random user sends legitimate mail from an un-associated third party. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 28 15:49:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD5D1A0272 for ; Wed, 28 May 2014 15:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGZG6DxZUIOU for ; Wed, 28 May 2014 15:49:38 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01461A072F for ; Wed, 28 May 2014 15:49:38 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id hn18so3078628igb.0 for ; Wed, 28 May 2014 15:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sbuIpPBvToGKyJ8iPC6SvBfs6yFvcj04EP/KRs9Zt8I=; b=Pe+LDf33elwdKIq7Mqdc8zES1fRmgChV9xqnDzkNmynwMPDmjQNyf51uqoQpRR8RZV 2839x2siIs7AKwctr02hGzmZ0OAJxd/u9BzrYLLgcZCD71+MmGIQEHeZyedO5mVA4+A+ kg62zQI0GsiuRSyR61Vx1MTr9dIXeHuRqncL0un/X2wkdNqrb58aqPuTffF7FwPDiMI5 wWx/U7fCnoBfc6KjJSOOVeKSZmIV5CbsIQldfXMuWWdss9mLfajFLYJ19iYWgkHiN+Jf iaf8ZoZXE8HYMdfyDuPL/mFVNxVUocmVgPPtP4LtdGiQAwHv7qbz9WdEWNi8q8g3Pvjf Om6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sbuIpPBvToGKyJ8iPC6SvBfs6yFvcj04EP/KRs9Zt8I=; b=XFwqNV0khIPO34s7bc2HGxCrC34FKgvbz5PhgZXd1yOzSjPMH3Z1ZvEJxjWYD15JTa 8dzJeDqxwdIQwyq9PFgwM1C9xwZ3DFxu/zQnPKny1L8ARv1nbbFskqQnbJKTiUGYsNly GCW0szTpxHnyNJ0aZyBoGffPcJ6bN7/YYu8M3Z5TmbPAA2UGx2lb4Q+9agGNsO2GO3fL D37iaBP+kDZH+y/INVjlSwxgT/lQcGEcVRRRmXbhpRvYna/SpJlY/EzRQ7ud6r9YN4NS LAb4YvZWfudsw1rs0Hbek8/cPYeqgJQjbxGl9U6Op+FRAPfKymujd1NcF4NntfutSMJA eZ+g== X-Gm-Message-State: ALoCoQk5tBgZDF3+egVXnFsBmsOhnOpGdcAmFz7xTYNA+Byi+rRNd35W/j+BLVuag0c3h9MYxe2b MIME-Version: 1.0 X-Received: by 10.50.46.100 with SMTP id u4mr5290698igm.23.1401317374846; Wed, 28 May 2014 15:49:34 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Wed, 28 May 2014 15:49:34 -0700 (PDT) In-Reply-To: <5386609C.5020506@bluepopcorn.net> References: <20140528163723.63860.qmail@joyce.lan> <53865108.80207@gmail.com> <1444962.yn6TflRTra@scott-latitude-e6320> <53865B33.9030506@gmail.com> <5386609C.5020506@bluepopcorn.net> Date: Wed, 28 May 2014 15:49:34 -0700 Message-ID: From: Brandon Long To: Jim Fenton Content-Type: multipart/alternative; boundary=001a11347bf2589ee704fa7da00f Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Z8AUdab2xkpOJtVwU7zAaEezsfU Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:49:40 -0000 --001a11347bf2589ee704fa7da00f Content-Type: text/plain; charset=UTF-8 On Wed, May 28, 2014 at 3:18 PM, Jim Fenton wrote: > On 5/28/14 2:54 PM, Dave Crocker wrote: > > On 5/28/2014 2:52 PM, Scott Kitterman wrote: > >> How do we define the scope of work for this list? > > > > Merely as an example, one line of effort could be towards methods of > > DKIM signature survival through mailing lists. > > > > It's not a new topic and it's not an easy one, and it doesn't even have > > the string D-M-A-R-C in it, but any real progress for this could be > > quite helpful in mitigating collateral damage with especially aggressive > > DMARC use. > > Since you don't mention it, what about the "mail this article to a > friend" use case that has also been mentioned? Is that a problem that > should be addressed here? > > I want to make sure that isn't forgotten just because it doesn't affect > IETF directly. > Franky, that case has always been kind of ick, and is "easily" solved by sending From the domain in question (article-noreply@wsj.com). Granted, I don't know how many of those there are and fixing them all is certainly annoying work that its bad to force on the world... also, arguably most of those shares have been replaced by sharing to the social website of the week. Brandon --001a11347bf2589ee704fa7da00f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, May 28, 2014 at 3:18 PM, Jim Fenton <<= a href=3D"mailto:fenton@bluepopcorn.net" target=3D"_blank">fenton@bluepopco= rn.net> wrote:
On 5/28/14 2:54 PM, Dave Cro= cker wrote:
> On 5/28/2014 2:52 PM, Scott Kitterman wrote:
>> How do we define the scope of work for this list?
>
> Merely as an example, one line of effort could be towards methods of > DKIM signature survival through mailing lists.
>
> It's not a new topic and it's not an easy one, and it doesn= 9;t even have
> the string D-M-A-R-C in it, but any real progress for this could be > quite helpful in mitigating collateral damage with especially aggressi= ve
> DMARC use.

Since you don't mention it, what about the "mail this articl= e to a
friend" use case that has also been mentioned? Is that a problem that<= br> should be addressed here?

I want to make sure that isn't forgotten just because it doesn't af= fect
IETF directly.

Franky, that case has al= ways been kind of ick, and is "easily" solved by sending From the= domain in question (article-nor= eply@wsj.com). =C2=A0Granted, I don't know how many of those there = are and fixing them all is certainly annoying work that its bad to force on= the world... also, arguably most of those shares have been replaced by sha= ring to the social website of the week.

Brandon
--001a11347bf2589ee704fa7da00f-- From nobody Wed May 28 15:56:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62DD1A071B for ; Wed, 28 May 2014 15:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.018 X-Spam-Level: X-Spam-Status: No, score=-4.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tvMJyg3kZSF for ; Wed, 28 May 2014 15:55:57 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACF41A070C for ; Wed, 28 May 2014 15:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1401317755; x=1432853755; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oXewhtDZBWXJg0fbEmRMbFzn7J4P/XSK+5voKyM04U4=; b=FYy4YEHNR6bj14i5T868yPDfL/S9p5I3oZ6TPPn2y22CGPkuqCFZJU0L 9nbWBU8cVXPR4E6Lf7cy40kFmPCcyJASG30Q/lg/7WfFwY/SbsnGFN/53 Ok4wsdoYhR6ojd4U4k50RwMTBnQaCasiD3pw+SQfJvNuC1KFws2N+ivi5 U=; X-IronPort-AV: E=Sophos;i="4.98,931,1392192000"; d="scan'208";a="124159630" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by ESV4-HT02.linkedin.biz (172.18.46.236) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 28 May 2014 15:55:53 -0700 Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.03.0174.001; Wed, 28 May 2014 15:55:53 -0700 From: Kurt Andersen To: Dave Crocker , Franck Martin Thread-Topic: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection Thread-Index: AQHPesah0sNM0NKG3EK46KHnNC7SV5tXDbqA//+MnIA= Date: Wed, 28 May 2014 22:55:53 +0000 Message-ID: References: <20140528163723.63860.qmail@joyce.lan> <1444962.yn6TflRTra@scott-latitude-e6320> <53865B33.9030506@gmail.com> <5386609C.5020506@bluepopcorn.net> <695969678.67071.1401316082355.JavaMail.zimbra@peachymango.org> <5386634A.4040208@gmail.com> <927381906.67404.1401317144602.JavaMail.zimbra@peachymango.org> <538667C7.8050206@gmail.com> In-Reply-To: <538667C7.8050206@gmail.com> 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: <53AD00FE84A05A439A932F2DBB7EF931@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vqly2TI1yLMIl_cR4jsgxYhkoEU Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:55:58 -0000 On 2014-05-28, 15:48 , "Dave Crocker" wrote: >On 5/28/2014 3:45 PM, Franck Martin wrote: >> Before one can move to p=3Dreject, it needs to take control of all the >>email streams. > >The examples you provide are for third parties that have a business >relationship with the domain owner. > >The interesting challenge is when a random user sends legitimate mail >from an un-associated third party. "Taking control" means that there is no such legitimate usage. Not that there isn't usage, just that it is, by definition, no legitimate. --Kurt From nobody Wed May 28 15:59:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829B51A0754 for ; Wed, 28 May 2014 15:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e2J9M_7v2Xq for ; Wed, 28 May 2014 15:59:54 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id D5D5E1A0745 for ; Wed, 28 May 2014 15:59:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 44AFA60664; Wed, 28 May 2014 17:59:51 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnK3lepx-89B; Wed, 28 May 2014 17:59:51 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1B06B60684; Wed, 28 May 2014 17:59:51 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id F13FF60664; Wed, 28 May 2014 17:59:50 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4pVRFmgWZ50L; Wed, 28 May 2014 17:59:50 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id AF8A76049D; Wed, 28 May 2014 17:59:50 -0500 (CDT) Date: Wed, 28 May 2014 17:59:50 -0500 (CDT) From: Franck Martin To: Dave Crocker Message-ID: <1275674215.67542.1401317990555.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> <695969678.67071.1401316082355.JavaMail.zimbra@peachymango.org> <5386634A.4040208@gmail.com> <927381906.67404.1401317144602.JavaMail.zimbra@peachymango.org> <538667C7.8050206@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Solution for DMARC disruption of normal email use while still offering its normal protection Thread-Index: E+AyMhIGCVOELNxlIaSat4o3+0PriA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BqwGnG_G01Gfftojfo0sf-Z6UXw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 22:59:55 -0000 ----- Original Message ----- > From: "Dave Crocker" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Wednesday, May 28, 2014 3:48:39 PM > Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal > protection > > On 5/28/2014 3:45 PM, Franck Martin wrote: > > Before one can move to p=reject, it needs to take control of all the email > > streams. > > > OK. Thanks for the clarification. You are welcome > > The examples you provide are for third parties that have a business > relationship with the domain owner. > > The interesting challenge is when a random user sends legitimate mail > from an un-associated third party. > In many cases the domain owner IT department does not know an employee decided to use/contract someone to send emails... This case is not too far from the one Jim pointed to, and amount to detect and then inform the third party to pick from a set of possible solutions. From nobody Wed May 28 16:05:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ACE1A0765 for ; Wed, 28 May 2014 16:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xyoqXn6alYI for ; Wed, 28 May 2014 16:05:08 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D7D1A0766 for ; Wed, 28 May 2014 16:05:08 -0700 (PDT) Received: by mail-ig0-f178.google.com with SMTP id hl10so3146495igb.11 for ; Wed, 28 May 2014 16:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P37l+x3y7wOZ3lLfYe4IJ4KxuZGRCS9IPqS1AmJuG/I=; b=UcKQf58hiRvaIJMDEexutGqBBOPh7ALi1ocH2/TDissoLTCqipRfx28Y31CzgvhPwi j+/zm6gKQVz+Um8rG1VsJn5N2Zazsqn42bBLabWNAv2ANXYXU9oUEIbvJMSEdwdqHZjP +Nw3Piu52Crqmtfc53pCBCtwd4hsw7h7uEeHdj7i1MRHnrRkvJJSJUUZOnc9GZiXHrY+ kkq8NVnjEpZPR/Ybwq5sQmANilCG7XVW+Plz/wSAeiWQnF3Ep5zYgTnAU04+s1nwrqDI AKwH3Qqfnu35HCHgUdqPBpMAXGFunsLo6DZ73pAvktVRTn/81tXPyaENoWJVjkpUS3Tq pDug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=P37l+x3y7wOZ3lLfYe4IJ4KxuZGRCS9IPqS1AmJuG/I=; b=jKRBAPijuVGiJE9kkQMpyV01lT2hmxTgIx9t7AEH+jB1eZK6FE4mq5nqcBbTP08NY1 mRIOVDPidYP9r2dz5PdI+77ZEPyB1Tt7l38cO/k1BgL4sf1TQleMQ+Bx+jWk+XpqfjZU fddHtJUrznDZqGhaGS+ZY+SZoMWRSw13lMrT31vh/082FwcnJNeY6gZh/3nWT8BdvxL5 48XV9+wLakvNldShwZ3XkUkUUJBebX5fKg548u17eCaolVT6/IysG8+NHrT10ingP3Up qT0u7REjXSyv3QgveREuGe/gxBaSXJxJ7lIhHqyJzSr8G5VOUvTOaqhkaAM0y9FG8T9t Fpcw== X-Gm-Message-State: ALoCoQnhMLr7Wc5GHZE7W5p4RViTXTIdfKZchkfgUwj4ZXcwQpRKGMAFOjGowNuvuXWUOsQn7IIK MIME-Version: 1.0 X-Received: by 10.50.79.194 with SMTP id l2mr33415031igx.23.1401318304597; Wed, 28 May 2014 16:05:04 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Wed, 28 May 2014 16:05:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 May 2014 16:05:04 -0700 Message-ID: From: Brandon Long To: Barry Leiba Content-Type: multipart/alternative; boundary=089e01182e48c3a3b704fa7dd7ba Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/OMJkz_GeNLTnXZ_qnDmEEgZD6uY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 28 May 2014 23:05:10 -0000 --089e01182e48c3a3b704fa7dd7ba Content-Type: text/plain; charset=UTF-8 On Wed, May 28, 2014 at 3:46 PM, Barry Leiba wrote: > > We could attempt to define a dkim canonicalization that would pass > through a > > mailing list. > > This was beaten pretty severely during the DKIM work, and we couldn't > come up with anything that was workable. > > > It should include the subject, but have rules for stripping "standard" > > subject prefixes. It should obviously include other headers, but not > List-* > > headers (since the RFC for those says the mailing list should strip the > > existing ones). > > > > The body is challenging. We could have it specify a length... that does > > allow for some weirdness with html positioning. We could require no-html > > part. > > > > We could optionally require footers to be added as separate parts, and > have > > the canonicalization be for "first text part". > > Anything that requires mailing list software to change won't work. If > mailing list software is changed, the right answer is for the mailing > list to re-sign the message. That doesn't help the DMARC situation > now, but DMARC could be given other options once that happens. > If the mailing list signs and verifies, that's OAR... and then the challenge becomes knowing when to trust the OAR. Also, it seems to me that mailing lists without changes and DMARC are basically incompatible, so I'm unclear of any solution that will allow them to work unchanged. > We discussed using l= at (um...) length, and no one liked that > approach. There were too many holes, yes: allowing arbitrary amounts > of data to be added to the message text, having it fail anyway if text > isn't added at the end (such as for multipart messages), and so on. > > Heuristics involved in tweaking the subject are problematic. > > Some of this could perhaps work if we had a canonicalization that was > *specific* to mailing list posts... but then how would the signing > domain know that the message it was signing was going to a mailing > list? > Theoretically, a client could easily know its a mailing list in most cases, but yes, where the signing often occurs, its unlikely to know. The easiest thing to do would be to sign it both ways, and then the receiver might only trust the mailing list canonicalization if it went through a mailing list... and of course that can be forged as well. I really think this isn't a useful approach, but perhaps someone might > come up with the necessary "aha" to make it work. > I think it depends on what the goal is. If the goal is "unforgeable messages through a mailing list to pass DMARC", then yes, this is probably not going to work. The only solution there is for the mailing lists to actually not munge messages. I might argue that "if the mailing list is going to munge the message, then it needs to munge From as well"... but there seems to be a fairly high resistance to that. I suspect that many parties that implement DMARC are "cheating" by allowing things that look like mailing list or forwarded mail through even if they fail auth and the domain is p=REJECT. Providing a higher bar for when to "cheat" may be useful, then. Now, my anti-spam colleagues will say that any hole will eventually be exploited... but given that I don't see how we can make this work with no holes, and if we can't change mailing lists... and any sort of whitelisting is adding a hole... I feel like I'm in a circular argument. Brandon --089e01182e48c3a3b704fa7dd7ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, May 28, 2014 at 3:46 PM, Barry Leiba <= barryleiba@com= puter.org> wrote:
> We could attempt to def= ine a dkim canonicalization that would pass through a
> mailing list.

This was beaten pretty severely during the DKIM work, and we couldn&#= 39;t
come up with anything that was workable.

> It should include the subject, but have rules for stripping "stan= dard"
> subject prefixes. =C2=A0It should obviously include other headers, but= not List-*
> headers (since the RFC for those says the mailing list should strip th= e
> existing ones).
>
> The body is challenging. =C2=A0We could have it specify a length... th= at does
> allow for some weirdness with html positioning. =C2=A0We could require= no-html
> part.
>
> We could optionally require footers to be added as separate parts, and= have
> the canonicalization be for "first text part".

Anything that requires mailing list software to change won't work= . =C2=A0If
mailing list software is changed, the right answer is for the mailing
list to re-sign the message. =C2=A0That doesn't help the DMARC situatio= n
now, but DMARC could be given other options once that happens.

If the mailing list signs and verifies, that's = OAR... and then the challenge becomes knowing when to trust the OAR.

Also, it seems to me that mailing lists without changes= and DMARC are basically incompatible, so I'm unclear of any solution t= hat will allow them to work unchanged.
=C2=A0
We discussed using l=3D at (um...) length, and no one liked that
approach. =C2=A0There were too many holes, yes: allowing arbitrary amounts<= br> of data to be added to the message text, having it fail anyway if text
isn't added at the end (such as for multipart messages), and so on.

Heuristics involved in tweaking the subject are problematic.

Some of this could perhaps work if we had a canonicalization that was
*specific* to mailing list posts... but then how would the signing
domain know that the message it was signing was going to a mailing
list?

Theoretically, a client could eas= ily know its a mailing list in most cases, but yes, where the signing often= occurs, its unlikely to know. =C2=A0The easiest thing to do would be to si= gn it both ways, and then the receiver might only trust the mailing list ca= nonicalization if it went through a mailing list... and of course that can = be forged as well.

I really think this isn't a useful approach, but perhaps someone might<= br> come up with the necessary "aha" to make it work.

I think it depends on what the goal is. =C2=A0If the g= oal is "unforgeable messages through a mailing list to pass DMARC"= ;, then yes, this is probably not going to work. =C2=A0The only solution th= ere is for the mailing lists to actually not munge messages.

I might argue that "if the mailing list is going t= o munge the message, then it needs to munge From as well"... but there= seems to be a fairly high resistance to that.

I suspect that many parties that implement DMARC are "cheating" b= y allowing things that look like mailing list or forwarded mail through eve= n if they fail auth and the domain is p=3DREJECT. =C2=A0Providing a higher = bar for when to "cheat" may be useful, then.

Now, my anti-spam colleagues will say that any hole wil= l eventually be exploited... but given that I don't see how we can make= this work with no holes, and if we can't change mailing lists... and a= ny sort of whitelisting is adding a hole... I feel like I'm in a circul= ar argument.

Brandon
--089e01182e48c3a3b704fa7dd7ba-- From nobody Wed May 28 17:21:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA8C1A079C for ; Wed, 28 May 2014 17:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR71pmTHgTff for ; Wed, 28 May 2014 17:21:45 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D56C1A0704 for ; Wed, 28 May 2014 17:21:45 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id a108so19953320qge.22 for ; Wed, 28 May 2014 17:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=eDAiRw9FUO7XjYwgj3ddolLZiG3dYk1V7VL6KI10PHk=; b=Xquvhnbzlxy/SgrEtIVUsDeVKZMC7I5zosHdhJA63aBKjdgUexwBe26ZVArzNn+rrY 3v57kr0lViS2DnFP5RKx8eBR2KKc5+yHe77iBOH8zB4I3kzbXpGzTEkzGdx2L7/we/gP C7UYtJxk4eFKPxc/oTF+kR3o6faAax6cKK0snTcDAVLu6l7t9kMjO68hFn5ZkBO8QT5S tSH4AZPdO3wrmVgA5CRwJoJnX6wKzEwrqNpisJ5g9U5QOxODRQVqzuYtp3aA+ZOtG/Gc 9WAXp+26sxbRXHB9f0/DKjv5FrFJXAidTYWibw2q5tGiji7Fc2yBb5N0000bI2LcKDeJ bFgw== X-Received: by 10.224.223.195 with SMTP id il3mr4670236qab.104.1401322901083; Wed, 28 May 2014 17:21:41 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id l10sm20285523qae.41.2014.05.28.17.21.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 17:21:40 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D59C14F2-569A-4255-966D-FD8B55EB7FDF" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Wed, 28 May 2014 17:21:38 -0700 Message-Id: References: To: Brandon Long X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mOfNNstskIPC_VtyH0luI96CLFU Cc: "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 00:21:48 -0000 --Apple-Mail=_D59C14F2-569A-4255-966D-FD8B55EB7FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 28, 2014, at 4:05 PM, Brandon Long wrote: >=20 >=20 >=20 > On Wed, May 28, 2014 at 3:46 PM, Barry Leiba = wrote: > > We could attempt to define a dkim canonicalization that would pass = through a > > mailing list. >=20 > This was beaten pretty severely during the DKIM work, and we couldn't > come up with anything that was workable. >=20 > > It should include the subject, but have rules for stripping = "standard" > > subject prefixes. It should obviously include other headers, but = not List-* > > headers (since the RFC for those says the mailing list should strip = the > > existing ones). > > > > The body is challenging. We could have it specify a length... that = does > > allow for some weirdness with html positioning. We could require = no-html > > part. > > > > We could optionally require footers to be added as separate parts, = and have > > the canonicalization be for "first text part". >=20 > Anything that requires mailing list software to change won't work. If > mailing list software is changed, the right answer is for the mailing > list to re-sign the message. That doesn't help the DMARC situation > now, but DMARC could be given other options once that happens. >=20 > If the mailing list signs and verifies, that's OAR... and then the = challenge becomes knowing when to trust the OAR. Exactly. TPA-Label provides this answer. > Also, it seems to me that mailing lists without changes and DMARC are = basically incompatible, so I'm unclear of any solution that will allow = them to work unchanged. Again, TPA-Label provides this answer. By the way, the TPA-Label draft has been updated to include = Original-Authentication-Results draft reference which also states this = concern as well.=20 > We discussed using l=3D at (um...) length, and no one liked that > approach. There were too many holes, yes: allowing arbitrary amounts > of data to be added to the message text, having it fail anyway if text > isn't added at the end (such as for multipart messages), and so on. >=20 > Heuristics involved in tweaking the subject are problematic. >=20 > Some of this could perhaps work if we had a canonicalization that was > *specific* to mailing list posts... but then how would the signing > domain know that the message it was signing was going to a mailing > list? >=20 > Theoretically, a client could easily know its a mailing list in most = cases, but yes, where the signing often occurs, its unlikely to know. = The easiest thing to do would be to sign it both ways, and then the = receiver might only trust the mailing list canonicalization if it went = through a mailing list... and of course that can be forged as well. That is what spam-traps and DMARC feedback provides. When a problem is = detected and reported to the DMARC domain, the response can be to = withdraw authorization and report problems to third-party service = providers. Fast and easy. Depending on the urgency, it would be nicer = to report problems to the service provider and give then an opportunity = to fix issues before causing an unnecessary disruption. The point is to = ensure everyone has an incentive to cooperate. There are many cases that are never originally signed by the DMARC = domain. Such as an accounting package that sends out invoices on behalf = of some company that wants their email address in the =46rom header = since this is what their customers will recognize.=20 > I really think this isn't a useful approach, but perhaps someone might > come up with the necessary "aha" to make it work. >=20 > I think it depends on what the goal is. If the goal is "unforgeable = messages through a mailing list to pass DMARC", then yes, this is = probably not going to work. The only solution there is for the mailing = lists to actually not munge messages. >=20 > I might argue that "if the mailing list is going to munge the message, = then it needs to munge =46rom as well"... but there seems to be a fairly = high resistance to that. This would be an understatement which also ignores other valid uses. = People might remember someone said something profound without recalling = related details. Not being able to search through their message stream = would be fairly frustrating. Not all mailing lists offer usable = reference header fields for such use (perhaps to ensure user privacy). = References: = = might not be something that can be used by most MUAs to review what = someone said in the past, for example > I suspect that many parties that implement DMARC are "cheating" by = allowing things that look like mailing list or forwarded mail through = even if they fail auth and the domain is p=3DREJECT. Providing a higher = bar for when to "cheat" may be useful, then. >=20 > Now, my anti-spam colleagues will say that any hole will eventually be = exploited... but given that I don't see how we can make this work with = no holes, and if we can't change mailing lists... and any sort of = whitelisting is adding a hole... I feel like I'm in a circular argument. The hurdle that seems to be in everyone's mind is how to go about = facilitating feedback that is not a lot of work. Some have used specialize DNS servers to cut corners. = http://www.corpit.ru/mjt/rbldnsd.html is an example related to dealing = with email abuse. There are off-the-shelf DNS servers able to return = 30K resource records without an issue. Add a few scripts and voila.=20 A specialized server however may assist in the administration of = providing DMARC related authorizations for third-party domains. This = could be mailing-lists, office and facility services using a separate = Sender header, "acquaintance" initiated message services, etc. It seems = the same specialized server could be tasked with processing DMARC = feedback looking for confirmation in outbound logs. The server itself = might even look for which log domains match hashed labels. This could = provide a heads-up something is outside the federation. Once the = initial corpus has been accommodated, keeping the system maintained = should become progressively easier. Or of course we could say it is too hard which places this problem back = into making guesses. When that happens, vast amounts of abuse will = suddenly appear. Malefactors quickly learn where the gray areas exist. = The goal is to ensure there is as little guesswork as possible while = keeping the DMARC domain in control. It seems unlikely there will be many outside service providers willing = to make decisions about which DMARC related messages are legitimate or = not. Only the DMARC domain can realistically be expected to make those = decisions. This then means the real task is to then communicate these = decisions to all of the DMARC domain's potential receivers. Regards, Douglas Otis --Apple-Mail=_D59C14F2-569A-4255-966D-FD8B55EB7FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 28, 2014, at 4:05 PM, Brandon = Long <blong@google.com> = wrote:




On Wed, May 28, 2014 at 3:46 PM, Barry Leiba = <barryleiba@computer.org> wrote:
> = We could attempt to define a dkim canonicalization that would pass = through a
> mailing list.

This was beaten pretty severely during the DKIM work, and we = couldn't
come up with anything that was workable.

> It should include the subject, but have rules for stripping = "standard"
> subject prefixes.  It should obviously include other headers, = but not List-*
> headers (since the RFC for those says the mailing list should strip = the
> existing ones).
>
> The body is challenging.  We could have it specify a length... = that does
> allow for some weirdness with html positioning.  We could = require no-html
> part.
>
> We could optionally require footers to be added as separate parts, = and have
> the canonicalization be for "first text part".

Anything that requires mailing list software to change won't work. =  If
mailing list software is changed, the right answer is for the = mailing
list to re-sign the message.  That doesn't help the DMARC = situation
now, but DMARC could be given other options once that = happens.

If the mailing list signs = and verifies, that's OAR... and then the challenge becomes knowing when = to trust the = OAR.

Exactly. = TPA-Label provides this answer.

Also, it seems to me that mailing lists = without changes and DMARC are basically incompatible, so I'm unclear of = any solution that will allow them to work = unchanged.

Again, = TPA-Label provides this answer.
By the way, the TPA-Label = draft has been updated to include Original-Authentication-Results draft = reference which also states this concern as = well. 

We discussed using l=3D at (um...) length, and no one liked that
approach.  There were too many holes, yes: allowing arbitrary = amounts
of data to be added to the message text, having it fail anyway if = text
isn't added at the end (such as for multipart messages), and so on.

Heuristics involved in tweaking the subject are problematic.

Some of this could perhaps work if we had a canonicalization that = was
*specific* to mailing list posts... but then how would the signing
domain know that the message it was signing was going to a mailing
list?

Theoretically, a client could = easily know its a mailing list in most cases, but yes, where the signing = often occurs, its unlikely to know.  The easiest thing to do would = be to sign it both ways, and then the receiver might only trust the = mailing list canonicalization if it went through a mailing list... and = of course that can be forged as = well.

That is = what spam-traps and DMARC feedback provides.  When a problem is = detected and reported to the DMARC domain, the response can be to = withdraw authorization and report problems to third-party service = providers.  Fast and easy.  Depending on the urgency, it would = be nicer to report problems to the service provider and give then an = opportunity to fix issues before causing an unnecessary disruption. The = point is to ensure everyone has an incentive to = cooperate.

There are many cases that are never = originally signed by the DMARC domain.  Such as an accounting = package that sends out invoices on behalf of some company that wants = their email address in the =46rom header since this is what their = customers will recognize. 

I really think this isn't a useful approach, but perhaps someone = might
come up with the necessary "aha" to make it = work.

I think it depends on what the = goal is.  If the goal is "unforgeable messages through a mailing = list to pass DMARC", then yes, this is probably not going to work. =  The only solution there is for the mailing lists to actually not = munge messages.

I might argue that "if the mailing list is going to = munge the message, then it needs to munge =46rom as well"... but there = seems to be a fairly high resistance to = that.

This would = be an understatement which also ignores other valid uses.  People = might remember someone said something profound without recalling related = details. Not being able to search through their message stream would be = fairly frustrating. Not all mailing lists offer usable reference header = fields for such use (perhaps to ensure user privacy).  References: = <CABa8R6v6tk7ZdgtTkBQGT6F7A17VP=3DzccpMcBoJFZE7sy99wFw@mail.gmai= l.com> might not be something that can be used by most MUAs to = review what someone said in the past, for = example

I suspect that many parties that implement DMARC are "cheating" by = allowing things that look like mailing list or forwarded mail through = even if they fail auth and the domain is p=3DREJECT.  Providing a = higher bar for when to "cheat" may be useful, then.

Now, my anti-spam colleagues will say that any hole = will eventually be exploited... but given that I don't see how we can = make this work with no holes, and if we can't change mailing lists... = and any sort of whitelisting is adding a hole... I feel like I'm in a = circular argument.

The hurdle that seems to = be in everyone's mind is how to go about facilitating feedback that is = not a lot of work.

Some have used specialize = DNS servers to cut corners.  http://www.corpit.ru/mjt/rb= ldnsd.html is an example related to dealing with email abuse. =  There are off-the-shelf DNS servers able to return 30K resource = records without an issue.  Add a few scripts and = voila. 

A specialized server however may = assist in the administration of providing DMARC related authorizations = for third-party domains.  This could be mailing-lists, office and = facility services using a separate Sender header, "acquaintance" = initiated message services, etc.  It seems the same specialized = server could be tasked with processing DMARC feedback looking for = confirmation in outbound logs.  The server itself might even look = for which log domains match hashed labels.  This could provide a = heads-up something is outside the federation.  Once the initial = corpus has been accommodated, keeping the system maintained should = become progressively easier.

Or of course we = could say it is too hard which places this problem back into making = guesses.  When that happens, vast amounts of abuse will suddenly = appear.  Malefactors quickly learn where the gray areas exist. =  The goal is to ensure there is as little guesswork as possible = while keeping the DMARC domain in control.

It = seems unlikely there will be many outside service providers willing to = make decisions about which DMARC related messages are legitimate or not. =  Only the DMARC domain can realistically be expected to make those = decisions.  This then means the real task is to then communicate = these decisions to all of the DMARC domain's potential = receivers.

Regards,
Douglas = Otis




= --Apple-Mail=_D59C14F2-569A-4255-966D-FD8B55EB7FDF-- From nobody Wed May 28 17:49:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CE91A0837 for ; Wed, 28 May 2014 17:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8fdoSpvY2ZR for ; Wed, 28 May 2014 17:49:01 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715AA1A081F for ; Wed, 28 May 2014 17:49:01 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id a108so20168786qge.39 for ; Wed, 28 May 2014 17:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BvkaxGCl8GizzjatjPcOxijSSX7dhuAUMaAQ4IFQXQM=; b=JO5HtibJLVBo1ovzKWb57I8/KkRhXgPR200lwkCkNUsdx05Yh5UaHPWB3jX6SFnSbX Kn2ftVym9c+k1XYrCjqchnAa31DgbudbQiET6fr43A7zMafn5KJI7vC3EW80+Z8NNAZl Caa6E9xgD7IzYXlKt1DoOeP+sxsDmxSRL1qTb45UvzoTnBTBSBmVpmFjU20w4r686gQI 9HWESt2KQdkLAsP9uBri6QE0Umn5RrItl9E7ZiS38+Ezi0Rt8JapnwlDX63gVVHVSoRw o/upXSeaZVun6+ipvAwqjI8t/HaPyOQoZaeCOY21PB3pGd+ObLk4CskUx8JoWfurOIGf ebzg== X-Received: by 10.140.81.146 with SMTP id f18mr4668302qgd.47.1401324537264; Wed, 28 May 2014 17:48:57 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id a13sm13193746qgf.38.2014.05.28.17.48.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 17:48:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> Date: Wed, 28 May 2014 17:48:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <483EA287-1C1C-4E9A-A1D8-6EB301F418D5@gmail.com> References: <20140528163723.63860.qmail@joyce.lan> <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> To: Tim Draegen X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7nVjBIK8K1i6sztQiDR6Q5ZZlXo Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 00:49:05 -0000 On May 28, 2014, at 1:13 PM, Tim Draegen wrote: > On May 28, 2014, at 12:37 PM, John Levine wrote: >>> Its not clear to me that gmail.com needs to tell another service to = trust >>> the OAR from a given third party, the choice to trust that service = could >>> easily be up to the receiving service. >>=20 >> Good point. That's why I keep saying that one or a few shared >> DMARC-bypass whitelists would work a lot better than anything >> per-sender. The set of senders where it makes sense to skip DMARC >> checks for Yahoo or AOL or Gmail addresses are likely to be the same. >=20 > Doug, >=20 > I read through the spec, and it is clear a lot of work went into it. = I think I echo Brandon and John's above opinions. >=20 > =46rom my PoV, there exists an immense pile of work to get through = before the draft under discussion becomes a solution. Aside from = support, tooling, getting senders to deploy accurately and getting = receivers to perform additional checks.. what is missing is the = justification for the additional work. >=20 > DMARC is a tradeoff between keeping things as simple as possible (as = unnecessary complexity acts as a giant barrier to adoption), building on = existing technologies (as new code/libraries in the world of email means = tacking on additional calendar years), and solving a problem that hurts = enough to warrant doing anything at all. >=20 > I don't believe TPA-Label hits the mark between "solving a big hurt" = and "simple". IOW, it's too complicated for the amount of pain it would = resolve. Just my opinion, take care, Dear Tim, All that is needed is a few bandaids? The motivation behind TPA-Label was to ensure both quick and efficient = methods to offer necessary feedback to receivers. DMARC already expects = receivers to offer failure feedback to DMARC domains. Unfortunately, = once the DMARC domain has decided which third-parties need to be granted = exceptions, there is no way to do so. It seems dangerous to suggest = this can be hard-coded in the form of informal lists indicating which = DMARC domains should be ignored. In the case of Yahoo, there is a real issue they are attempting to = mitigate. It would be nice to have a solution able to deal with = massively compromised user accounts, as ugly as that is. This is an = issue that is not going away any time soon. The issue is much worse in = China, for example. Please don't decide being helpful in such = situations is simply too hard. Is it really better to create lists = about which domains get ignored? It seems this quickly degrades DMARC's = initial intent, which was to offer results receivers felt safe to act = on. Is this still a worthy goal? Regards, Douglas Otis From nobody Wed May 28 18:47:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DA41A6F34 for ; Wed, 28 May 2014 18:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0lKDbYlMyPz for ; Wed, 28 May 2014 18:47:21 -0700 (PDT) Received: from mail1.altn.com (mail1.altn.com [65.99.242.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9521A02CB for ; Wed, 28 May 2014 18:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=altn.com; s=mail1; t=1401328036; x=1401932836; q=dns/txt; h=DomainKey-Signature: Received:VBR-Info:Message-ID:Date:From:User-Agent:MIME-Version: To:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=ZlGxj7dyiHqsFBL3ZfJDqOzIsy6aCiJJcc RNe6d3bHg=; b=IXc1w3z3pitthDLS8HHina/8pg1HthEh4T9epnkBTza990utqN vfu1D4/cvJDkBxze6FVooFxUz6LBpMAu6lO2d/17xYFdkt105DF56Z1Um5GlN4LY BE0E3mfsHLh3E84TK0by7bETCZ2kJQhg8aE7ZeXv1ZOgnqh4bKGqndJ8k= DomainKey-Signature: a=rsa-sha1; s=mail1; d=altn.com; c=nofws; q=dns; h=message-id:from; b=C9GSoWCvTeZQ1mUcyLzFovn0KwitXeLR2yC76hwqqIDi1KqgmNoJmBVxhWr2 rK+NIHwF7qFkXpOIaZlz4UJzJSmEQT/C7oqbOwWyoIbPM3RLuViaW7Bq2 S2Z0SjAFVp1nGlyk5/f0JHmLBy342X7ymWu+4hrpS2wmLghV47sx4Q=; X-MDAV-Processed: mail1.altn.com, Wed, 28 May 2014 20:47:16 -0500 Received: from [10.10.50.200] by altn.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v14.0.2) with ESMTP id 35-md50000106895.msg for ; Wed, 28 May 2014 20:47:14 -0500 VBR-Info: md=altn.com; mc=all; mv=dwl.spamhaus.org:vbr.emailcertification.org; X-Spam-Processed: mail1.altn.com, Wed, 28 May 2014 20:47:14 -0500 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Arvel.Hathcock@altn.com X-HashCash: 1:21:140529:md50000106895::4czioseLeP2prLmj:0000QuRN X-Return-Path: prvs=1226080157=arvel.hathcock@altn.com X-Envelope-From: arvel.hathcock@altn.com X-MDaemon-Deliver-To: dmarc@ietf.org X-CAV-Result: clean Message-ID: <538691A0.8010202@altn.com> Date: Wed, 28 May 2014 20:47:12 -0500 From: Arvel Hathcock User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3Nf6eKTylZGNTx19GQE5kK1W49c Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 01:47:22 -0000 > Anything that requires mailing list software to change won't work. If > mailing list software is changed, the right answer is for the mailing > list to re-sign the message. That doesn't help the DMARC situation > now, but DMARC could be given other options once that happens. That's right. But maybe there could be a multipart/dkim type that lets several signatures exist in a message - all of which could potentially verify with different d=. Then the list only needs to sign what it adds to the end somehow and it leaves the rest of the message alone. Seems like we went over this way back years ago but I'm old now :) Arvel Disclaimer: This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From nobody Wed May 28 18:54:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831BC1A6F3A for ; Wed, 28 May 2014 18:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYZGI6ShDLXM for ; Wed, 28 May 2014 18:54:48 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29111A6F39 for ; Wed, 28 May 2014 18:54:48 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id 29so9578425yhl.19 for ; Wed, 28 May 2014 18:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=rYoXoMTdSOt/f1SRhFXqGKg4p8n1UIobo8ZFpcMiUKE=; b=Xli2XcfpZTtO7a/aL4pb9hA4gGXzC70KiNs40xSEGP9sX3T13rYudQ2CCwSbiXI90y 3r6VZgRNykVICkC2HzGym3FbVwnQdXYKDs49pnYFHb9dq7nfIoiuhlWgp+9+uE5Q9DLx FhDeKtlUvGBiTDUCZdKAVeKkDxvqIlbQPNKHPvwatbk3KGXtnGoaR3IYYBJbFTd/PgAQ HUW8qQSMdZs+tDrLLrExc8JBgZx5BJPCVjNO6L3wQJL9M09u7D1Pw9WE1vftQVy0quf/ M/wsTynYJLJfrL5MPXKCYtBxSZ1zqqGP7QZGndPsffi4JLAn/+Tn8q6JzBR1cvh+ecjy 7WRg== X-Received: by 10.236.84.202 with SMTP id s50mr4938325yhe.77.1401328484740; Wed, 28 May 2014 18:54:44 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id k29sm30470039yha.33.2014.05.28.18.54.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 18:54:43 -0700 (PDT) Message-ID: <5386933B.7070009@gmail.com> Date: Wed, 28 May 2014 18:54:03 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Arvel Hathcock , dmarc@ietf.org References: <538691A0.8010202@altn.com> In-Reply-To: <538691A0.8010202@altn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8wdlNR80B9EbGjbUKrk_FBgsrps Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 01:54:50 -0000 On 5/28/2014 6:47 PM, Arvel Hathcock wrote: > That's right. But maybe there could be a multipart/dkim type that lets > several signatures exist in a message - all of which could potentially > verify with different d=. Hi Arvel. Great to see you re-entering the fray... Picking a nit: It's not a MIME level issue. It's in the main header. More substantive: Multiple signatures are ok now. And are sometimes done now. So the real challenge is who should sign what and how should it/they get used? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed May 28 19:19:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0181C1A06F9 for ; Wed, 28 May 2014 19:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-ps6APEYBi5 for ; Wed, 28 May 2014 19:19:03 -0700 (PDT) Received: from mail.catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 418521A065C for ; Wed, 28 May 2014 19:19:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1489; t=1401329936; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=m3u/gI96rm4HbnOKES22aAmKC+Q=; b=VWEpobMNPq2+HoeA2+Vk B6yJSb1v7i2Ny1aqjt63OKtzyhtROZDjc0t5AO0ZFw4KNYqDIx8uBcD6Wkb2NaLc TnkhTpFsEc6d3xlHnGFtHjNpYTOFcGcilw+O3k0wnr9Zo8mBPtW/HdRUdgoopDFl /ckVnkYakkrGzq/7jpSKibE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 28 May 2014 22:18:56 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 810070868.5233.2712; Wed, 28 May 2014 22:18:54 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1489; t=1401329789; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hBld0Sk Nfsw+sFmVd9Cs42XEG097U5XTChVgBH8lxzw=; b=qce0MUyOY0p9hi6I6Ig3ANc 7n0U4gy14YzIHUJHvTJEpVOg6CINIVYn65z00BluNLlu8CETTuZDCk/8HF0ZCAAU zZP2umwk2bsSx0OwjfkXB1b2SkPhbp6Q1NVMkBjSpvqLEQNSAHVvm10GmL547fW+ HYHCYmagaSg+HtXMbc9E= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 28 May 2014 22:16:29 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 826437125.9.4280; Wed, 28 May 2014 22:16:29 -0400 Message-ID: <5386990D.7060401@isdg.net> Date: Wed, 28 May 2014 22:18:53 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Arvel Hathcock , dmarc@ietf.org References: <538691A0.8010202@altn.com> In-Reply-To: <538691A0.8010202@altn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/F8Q0bbSvQTLCJNQrKu8z75ZwX1c Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 02:19:06 -0000 On 5/28/2014 9:47 PM, Arvel Hathcock wrote: > >> Anything that requires mailing list software to change won't work. If >> mailing list software is changed, the right answer is for the mailing >> list to re-sign the message. That doesn't help the DMARC situation >> now, but DMARC could be given other options once that happens. > > That's right. But maybe there could be a multipart/dkim type that > lets several signatures exist in a message - all of which could > potentially verify with different d=. Then the list only needs to > sign what it adds to the end somehow and it leaves the rest of the > message alone. Seems like we went over this way back years ago but > I'm old now :) > Yup, and the solution was policy. The problem is this group wants to skip doing any kind of policy lookup. We are also list developers. We don't have a free reign on resigning mail without permission, if any. Its irresponsible. It has to follow a policy framework. All software has to follow it. List systems are not the exception. No resigner is an exception and trying to get around this has not worked. Keep it simple -- lookup policy. But DMARC lacks 3rd party semantics, so you need extensions and that was done with ATPS for ADSP. See the wizard that supports it for ADSP and now a new beta using DMARC: http://www.winserver.com/public/wcADSP http://www.winserver.com/public/wcDMARC You can easily add ATPS support to your DKIM C/C++ library. -- HLS From nobody Wed May 28 23:26:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8551A0359 for ; Wed, 28 May 2014 23:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3lKfYwvKImn for ; Wed, 28 May 2014 23:26:46 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394671A0329 for ; Wed, 28 May 2014 23:26:46 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so4842496wiw.9 for ; Wed, 28 May 2014 23:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZrVNDUvGuZEWof043CK0esArsc3+wjMJaMD9Z0v00Qk=; b=QTaH4z/89PhY1m6FgmeA+EyKQX/WlS82CBHXCBXcFOs5pWEKHZuvgsPnC5S7Kz5Uky K/awaQS5H26S5zgYWI48Lw0KY5jE1MnUw3cCQ+5dhXj73CQKBdVdKv27evfXygNwD/It K3TapO2uUKMYZUNxMhEMjor2TBdSZllr9cwuhbJnBUl9p3M4wq10RKMOjPZpyQewOYHg YXlPvwir5RsOH3s3CvlKMV+bwjhhab4XXX095CsqHmh0oJjJH0+T83MFywsM27iezZWo nx8qvopVwDD4igPVzUxu7PZCm3W0/eoPIBe3Suzq44y9E6MglD7VreZqLhcqHqP2cwcW 7B8Q== MIME-Version: 1.0 X-Received: by 10.181.8.67 with SMTP id di3mr8302640wid.8.1401344801290; Wed, 28 May 2014 23:26:41 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Wed, 28 May 2014 23:26:40 -0700 (PDT) Date: Wed, 28 May 2014 23:26:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a1134d24416c18004fa840312 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DaeLlNjf5o94lEU9mXGic_V0NGU Subject: [dmarc-ietf] Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 06:26:48 -0000 --001a1134d24416c18004fa840312 Content-Type: text/plain; charset=UTF-8 Colleagues, The IETF has some written guidelines about management of and conduct on mailing lists. In particular, the IETF's anti-harassment policy [1] and a number of RFCs [2] [3] [4] [5] and IESG statements [6] [7] form the body of the IETF's guidelines and procedures regarding mailing list management. Although this mailing list is not presently associated with a working group, its management and policies are covered by several of these. The recurring theme among them is that the lists are to be used for technical or procedural discussion to advance a particular goal, and professionalism is expected of participants. When the debate veers off topic or into anything from the plainly impolite to the patently personal, it serves only to interfere with any progress that's being made. Multiple posts from the last 24 hours certainly have the feel of being outside of what's acceptable. In at least one case, it has resulted in a formal complaint from another participant, which has led me here as one of the two list administrators of record. I understand that it might be fun or even cathartic to beat up on people who disagree with your position, or on those who are members of the DMARC.org "cabal", or any of the other the people you may wish to blame for the mess in which we find ourselves, but I believe we are all better served by cooperating to find a path forward from where we are now rather than engaging in those activities. Learning from the past is fine; pointing fingers about the past is not. Thus, I am reminding all of you of your obligation to keep this discussion professional, on topic, respectful, and friendly. You do neither yourself nor the community any favors by giving in to the temptation to be rude or one-up the other person when you get frustrated. It will not be tolerated here going forward. -MSK, list admin [1] http://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html [2] RFC 2418 [3] RFC 3683 [4] RFC 3934 [5] RFC 4633 [6] http://www.ietf.org/IESG/STATEMENTS/statement-disruptive-posting.txt [7] http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt --001a1134d24416c18004fa840312 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

The IETF has some w= ritten guidelines about management of and conduct on mailing lists.=C2=A0 I= n particular, the IETF's anti-harassment policy [1] and a number of RFC= s [2] [3] [4] [5] and IESG statements [6] [7] form the body of the IETF'= ;s guidelines and procedures regarding mailing list management.=C2=A0 Altho= ugh this mailing list is not presently associated with a working group, its= management and policies are covered by several of these.

The recurring theme among them is that the lists are to be u= sed for technical or procedural discussion to advance a particular goal, an= d professionalism is expected of participants.=C2=A0 When the debate veers = off topic or into anything from the plainly impolite to the patently person= al, it serves only to interfere with any progress that's being made.
Multiple posts from the last 24 hours certainly have the fee= l of being outside of what's acceptable.=C2=A0 In at least one case, it= has resulted in a formal complaint from another participant, which has led= me here as one of the two list administrators of record.

I understand that it might be fun or even cathartic to beat = up on people who disagree with your position, or on those who are members o= f the DMARC.org "cabal", or any of the other the people you may w= ish to blame for the mess in which we find ourselves, but I believe we are = all better served by cooperating to find a path forward from where we are n= ow rather than engaging in those activities.=C2=A0 Learning from the past i= s fine; pointing fingers about the past is not.

Thus, I am reminding all of you of your obligatio= n to keep this discussion professional, on topic, respectful, and friendly.= =C2=A0 You do neither yourself nor the community any favors by giving in to= the temptation to be rude or one-up the other person when you get frustrat= ed.=C2=A0 It will not be tolerated here going forward.

-MSK, list admin
[2] RFC 24= 18
[3] RFC 3683
[4] RFC 3934
[5] RFC 4633
--001a1134d24416c18004fa840312-- From nobody Thu May 29 00:05:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24801A0767 for ; Thu, 29 May 2014 00:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uT6DjGd2fkTy for ; Thu, 29 May 2014 00:05:21 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EF11A0705 for ; Thu, 29 May 2014 00:05:20 -0700 (PDT) Received: (qmail 86443 invoked from network); 29 May 2014 07:05: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:references:mime-version:content-type:user-agent:cleverness; s=151aa.5386dc26.k1405; bh=N+ike9MzoEA0epFo3ZWJq/RlplirdymvCNNkVoJFz1Y=; b=ciexwyps8ly8tpQT3X2ISe+WcefrwnlQLBeBas/PCe8QUyLaivHy6gfhezOiu5qCL/9TR/Z5GC5xDr5N5fiZq/f+UD6uWIWXKZu4m50ubDmwz856CImlwaKxptSwsnP5VeIoJ4EJtFtR4oeqMN/W61PgwhASXsnXBLOL9UtIszZZrISwDbUktNHXHf6Q4UHF0nNFqNtPWy3BwmmBvQmWg+yg7fjOJWEWxQg+k2P/+ZmUr/Fl7Hvv2IYaMeXtlh2H 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=151aa.5386dc26.k1405; bh=N+ike9MzoEA0epFo3ZWJq/RlplirdymvCNNkVoJFz1Y=; b=kvTddVfuYSPKSHROEZPUJiMz3qIXkWnmFWCZYEERo3bGMy4zCxlX3DSmbSBylj3vOMvesLIsfFXCvHU4rf1puA9T9CLdUZ6K1VQOWX+TukWdVtZChPnigScH3qEwimN33749eip7eY1ThDpmVTz+mbd0qNt4UXQRfsRcQyVX9L7JsIcwrHNU22YOoVm8usZuaRV92Rv5rGj1j0v0CXjnrfRD2lKsBKVz4R3hWK19JskbV1hCaET3Chkn34+B5s6b Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 29 May 2014 07:05:08 -0000 Date: 29 May 2014 00:05:08 -0700 Message-ID: From: "John R Levine" To: "Tim Draegen" In-Reply-To: References: <20140528163723.63860.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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PV2_eBDto1rSdVHAfAyqxjR__wY Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Non-solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 07:05:22 -0000 > Hello John, what you're missing -- and its easy to miss -- is that Yahoo > has an outstanding offer to help developers (this means $!) fix things. Really, that makes no difference. I don't want Yahoo or anyone else to pay us to screw up our mail software to work around them -- I want them to spend their money to fix things so we don't have to. Yahoo, in their own blog, estimates there are 30,000 mail systems that they have damaged by their DMARC actions. I would be surprised if there were more than a few hundred mail systems acting on DMARC policies, although some of those are very, very large. Is it that hard to understand why someone might think it was unreasonable to demand that the 30,000 make changes of no benefit to themselves, rather than the few hundred fix their buggy fussp? The 30K estimate is probably low, since there are likely many small mail systems they aren't aware of but that they are damaging. For example, yesterday a middle school teacher who found my old Dummmies web site wrote to me out of the blue to say that his web form that lets students and parents send mail to him stopped working for AOL and Yahoo addresses, which just disappear. It took about two seconds to figure out what was wrong when he told me that his script sends mail to his Gmail account. I told him what was wrong, and he did a hack that sticks in a fake From: address, so the mail gets through but now his script works worse since he can't write back without extra effort. If he hadn't written to me, he'd probably never have figured out what was wrong. These are real people who are really hurt by the two providers' actions. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. PS: Here endeth the rant. From nobody Thu May 29 00:06:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883F01A0705 for ; Thu, 29 May 2014 00:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owfYFIHerrev for ; Thu, 29 May 2014 00:06:38 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9ED11A04C1 for ; Thu, 29 May 2014 00:06:37 -0700 (PDT) Received: (qmail 87280 invoked from network); 29 May 2014 07:06:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=154ef.5386dc76.k1405; bh=YKv5a3yF3RAtJra5tEbtDWGCe1hJzBnA0Hvad3iMtYI=; b=U7Vdvu7nRy1/NEUhP/lL6keCj5kAKFn4/qD31vo/rd4V+bnRk7R/1vtpsq5OMB909cvDFithbp/bQceuAibqjfWMFmok00WzEcrmd3vrEFsHgdjpC3b8HzesIwyRjHl7rlIOUgbf23NArsQKLfRVpe1CRW30ZZ9tc7yuLnPZYB0zN2g4cj7zUoMW8T0GXwd1MZMPfgd0vG+hr+ALrJmuM1NnHEKL7U9hnEcu+8uwOBTPzPDyHiVDPHeY6OX/yFu3 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=154ef.5386dc76.k1405; bh=YKv5a3yF3RAtJra5tEbtDWGCe1hJzBnA0Hvad3iMtYI=; b=NnA/aEo/qbzfS8QhLFzAGaYIzp1/9y3CBD/qqlGVjB1ctcrm+5AJ1XAh/tMuEqygsAVFNpeO6umRmGiOSeLdEEPRJTVEu26QN486NV8jqmnrgiOziRfBWLCK9SUdA7Db+iBLwYPJqgCeLh4Qcqldbyj4rRvrI0PQMi9SZ9K6dfcSRzRSL8bsl26q/kjGrGCQB9hakKoNV1E9XBFB2iY4mfh9kapBcfnz8Jdi/lqbC61Moi2xwxwpqhB6reVTYEU2 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 29 May 2014 07:06:29 -0000 Date: 29 May 2014 00:06:29 -0700 Message-ID: From: "John R Levine" To: dmarc@ietf.org In-Reply-To: References: <20140528163723.63860.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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/u3fxoD5lz7Wmd9T5MIldCJt-oG0 Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 07:06:38 -0000 By the way, to return to the original point, it still seems vanishingly unlikely to me that if we invented per-sender whitelists that the two mail providers would implement them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu May 29 00:09:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE261A0174 for ; Thu, 29 May 2014 00:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dyrgbwgrk_MJ for ; Thu, 29 May 2014 00:09:50 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A918D1A00AA for ; Thu, 29 May 2014 00:09:49 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id q59so12290900wes.38 for ; Thu, 29 May 2014 00:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qU0iFy6KGZcSAt/qysi1e+kCX71BrNOi+zD7IHQF4J4=; b=fgkwF1eBH8N6p9XSaglPhXuvvw9hIYOm7VRwxm+BVvE7GgdwhMzX6RO44FG9FdJAVo ocK3IMwV9Zq47fdjS5W6wTqMN58Krd8CjB4iU76M6+/fNR4cwuW6Tm1Ug2YnaByyOhDQ 14ejBMpuDRWKD+yToiSS5LybdwrQpg7MHIuhSn6eWMby4NsSZbx//YmodYEapBRaQ3aB KlJk32k37d2n1Aw310aqSkrwr8C3Atbn+zb9b4DZ+aPQ4158XI9hpR1QPcC/1zITWKgr mOJy1YplwJub8GeP+Tp5XHVMtElhs0vhV7h7jnQM4irVp60DptzemP7d/5j+N1WSIEUd mSxw== MIME-Version: 1.0 X-Received: by 10.180.94.163 with SMTP id dd3mr8598311wib.26.1401347384759; Thu, 29 May 2014 00:09:44 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Thu, 29 May 2014 00:09:44 -0700 (PDT) In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> Date: Thu, 29 May 2014 00:09:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=f46d04462e5e1376e604fa849dad Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FcvomSImdrB8wSbQOpNYya4cZjw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 07:09:51 -0000 --f46d04462e5e1376e604fa849dad Content-Type: text/plain; charset=UTF-8 On Thu, May 29, 2014 at 12:06 AM, John R Levine wrote: > By the way, to return to the original point, it still seems vanishingly > unlikely to me that if we invented per-sender whitelists that the two mail > providers would implement them. > Has anyone tried asking them? I'm not sure what value I should put in all this (ahem) third-party speculation about their intentions or what they care about. -MSK --f46d04462e5e1376e604fa849dad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 29, 2014 at 12:06 AM, John R Levine <johnl@tau= gh.com> wrote:
By the way, to return to the original point,= it still seems vanishingly unlikely to me that if we invented per-sender w= hitelists that the two mail providers would implement them.

Has anyone tried asking them?

I'= ;m not sure what value I should put in all this (ahem) third-party speculat= ion about their intentions or what they care about.

-MSK
--f46d04462e5e1376e604fa849dad-- From nobody Thu May 29 03:21:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6928A1A0043 for ; Thu, 29 May 2014 03:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaVJ2GACMQmI for ; Thu, 29 May 2014 03:21:37 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2C41A03ED for ; Thu, 29 May 2014 03:21:36 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 62054970B1E; Thu, 29 May 2014 19:21:32 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4CADF11F235; Thu, 29 May 2014 19:21:32 +0900 (JST) From: "Stephen J. Turnbull" To: Tim Draegen In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 29 May 2014 19:21:32 +0900 Message-ID: <87vbso7umr.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UN-yiF9iBtVlfNYLsblMKQpG-TE Cc: dmarc@ietf.org, John R Levine Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 10:21:39 -0000 Hi, I've been invited by Murray Kucherawy and Franck Martin to participate in these discussions, so let me introduce my affiliation briefly. I've been operating GNU Mailman lists since 1999, an occasional contributor for about 10 years, and a GSoC Mentor for Mailman since 2012. I have somewhat ambiguous authorization to speak for the developers (ie, a rolling consensus of the Mailman Steering Committee[1]). Tim Draegen writes: > John, you are very difficult to communicate with, maybe because > you're easily insulted, even when there is no insult. I too have > been in correspondence with mailing list developers, Which ones? GNU Mailman is now here. Besides me, John is a reliable source of summaries of past Mailman list discussions in what I've read of his posting here. I'm sure in the following I'll be going over a lot of ground that's been covered before, but since you think it's controversial enough to address, I hope I'll be forgiven for a certain degree of redundancy. > and also developers behind businesses that rely on email, That's insufficiently precise. To my mind, there are two kinds (at least) of businesses that rely on provision of mailboxes (other use cases follow). (1) Corporate use case: mailboxes are provided for the convenience of organizational representatives communicating directly with agents outside the organization. (2) Mail service provider (ESP) use case: mailboxes are provided to customers for personal use of customers. I have no problem with "p=reject" in the corporate use case because I don't believe it causes significant burdens on users or unreliablity of delivery. I believe that John has the same assessment, and it is a weak consensus in the Mailman community AFAICT. Our issue is with "p=reject" as used by large ESPs like Yahoo! and AOL, especially since it seems to be associated with severe security problems, either at those services or on the users' own machines. (Evidently this is a consensus here as well, I'm just making Mailman's understanding clear.) Does DMARC actually impose significant burdens on the "corporate use case", contrary to my belief? Of course there are other use cases of "businesses that rely on email". I understand the "mailing list as user forum" case, and I believe Mailman has already implemented a sufficiently broad set of measures for business use in this use case. The tradeoffs aren't pleasant, but that's a cost of doing business with Yahoo! and AOL users. A business has the usual set of options (pay the costs, find less costly customers, use alternative forum technology, etc). I don't see a real problem here. There's also the "on behalf of" content provision use case. Others describe a good remedy in this thread, but I would like to point out that such providers may publish "p=reject" to good effect, as an instance of the "corporate use case". But my knowledge of "business use" is quite limited. Are there other "business activities relying on email" such that DMARC imposes burdens? Are those burdens specific to "p=reject", or more general? (If this is all well-known, please point me to a reference where I can book up without disturbing the Councils of the Wise.) > and also a slew of decision makers... and they're all trying to > understand how they can fix things without going backwards. IMO, they're wasting their time. Email service *must* deteriorate in the presence of users who send messages from "p=reject" domains, unless those domains are draconian in enforcing direct transmission to final destinations that observe "p=reject" (see Franck Martin's post later in the thread, and the following subthread on "legitmate use of 'p=reject'" that follows). Unfortunately, these domains are proposing that third parties adjust to their (unilaterally imposed) policy, rather than modifying those policies or restricting their users to safe email usage. But the "let third parties adjust" solution is a pretty dismal option. There are just too many MXes and MTAs and services that are DMARC-incompatible. It's going to take years, maybe a decade, to modify both the software and the installations. We really can't expect help from Yahoo! and AOL. You talk about money, well, Mailman doesn't care about money, it's a volunteer project. The effort in development required is actually tiny, less than 100 new/changed SLOC in Python for any given mitigation available in Mailman (probably about 200 N/CSLOC for all of them together). Maybe we'll take their money, but the effort to actually accept and use the money in a basically pure volunteer organization may make it a net zero. The help we need is in explaining to our users that they cannot maintain past configurations and allow posting from "p=reject" domains at the same time. For many of our users, they get a MLM as a part of a hosting package and the only solution they can implement themselves is to refuse posts from those domains. Where's the money to compensate those list operators for lost subscribers or the costs of switching hosting services? Where's the money to encourage hosting providers to upgrade their MLM installations? Where's the money to compensate operators for the emotional and social damage done by Yahoo! users who throw fits privately and publicly over lost posts? Yahoo!'s offer of support for developers is a pure FUD PR stunt, as far as GNU Mailman concerned. The question is, to paraphrase John, how best to defend our users (subscribers as well as list operators) from the unilateral behavior of corporations desperate to mitigate their own problems. The rest of us *will* go backwards. The question is how do we minimize the retreat, and in which backward direction to go. Mailman, at least, offers list operators (precisely, those who can install the most recent versions) several options, so they can choose the one they dislike least. > Figuring out how to make email slightly less capable of harming > people is a big deal. Yahoo!'s use of "p=reject" reminds us that there is little we can do to make email as such less harmful. The DMARC consortium can revise their protocol, which I remind you was a purely private agreement at the time of Yahoo!'s action, at any time. For example, they could decide that the presence of strings resembling their mailboxes anywhere in a From: field is subject to DMARC identity alignment. That would cause the same set of problems for several of the less unpalatable mitigations developed so far. The only way to completely prevent future disruptions is to ostracize "p=reject" domains. That's a technical assessment, not a recommendation! Obviously, businesses and most discussion list operators will find that "solution" completely unacceptable. > > They know as much about e-mail as anyone, they've been tearing > > their hair out trying to figure out how to deal with the problems > > that the two mail providers have created, they've implemented and > > tested all sorts of workarounds including several not on that web > > page, and they agree that they all stink. Slight correction: all are more or less aromatic in most Mailman use cases, and for some use cases all stink like rotting fish. One of the big problems for Mailman is that on many discussion lists there is strong resistance to changing things like the Subject tag (many people use it auto-folder filtering and the like) and the footer (I believe for some businesses it's the best solution to requirements to make it easy to unsubscribe which is more or less legally required AFAIK). Users often resist From: corrupting modifications that do not put the Author Domain in the display name, but this of course goes a long way to defeating identifier alignment requirements and reenabling phishing and spam (not necessarily via mailing lists, but also via crooks imitating the header format in direct mail shots). I accept that this may not be a "big" problem from the point of view of this group, that's just Mailman's point of view. > Tell the people you're communicating with to post their finding to > either this list or the dmarc-discuss list. There is no reason why > their findings should be frustrating -- others are meeting the > challenge, Nice pep talk, but please, save it for the board room. If you want to present specific solutions, I'd love to hear about them (even if they don't apply directly to mailing list management). > and others still would likely benefit from their learnings. Watch this space! Footnotes: [1] The ultimate authorities for GNU Mailman are Barry Warsaw (project lead) and Mark Sapiro (release engineer and lead for the stable version). I've been pretty good at channeling them in the past, but I have no formal authority. From nobody Thu May 29 04:19:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4DD1A08BA for ; Thu, 29 May 2014 04:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DSIBmf5fRD6 for ; Thu, 29 May 2014 04:19:35 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 54BA71A08A2 for ; Thu, 29 May 2014 04:19:35 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 01CC3970B1E; Thu, 29 May 2014 20:19:31 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E253E11F235; Thu, 29 May 2014 20:19:30 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> References: <20140528163723.63860.qmail@joyce.lan> <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 29 May 2014 20:19:30 +0900 Message-ID: <87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HUg64C99ukLrCPe9HtumLrOPte4 Cc: Tim Draegen , dmarc@ietf.org, John R Levine Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 11:19:37 -0000 Franck Martin writes: > The changes in mailman to handle DMARC came from people involved > with DMARC.org. Not all of them. The "message-wrapping" suggestion was mine (at least I invented it independently and was an early public proponent), and it was implemented by Mark Sapiro AFAIK. A From-corrupting patch was provided by DMARC.org, but final integration and of course release management was provided by Mark Sapiro. Other From-corrupting patches have been proposed, including one provided by John Levine (not yet implemented in a released Mailman, but obviously Mark will be involved in that). None of these patches have been ported to Mailman 3 yet. That sounds like a possible use for Yahoo! and DMARC.org funds, although we don't have organizational infrastructure to manage external funding now. > So we cared. Nobody has denied that DMARC consortium members have put some effort into developing mitigation strategies. Nevertheless, I describe reasons why that effort (and Yahoo!'s offer of financial support) may be properly characterized as *negligible* in my response to Tim Draegen. (N.B. I don't claim the argument has broader applicability than the GNU Mailman project. For us, the contribution of DMARC consortium members has been net negative. Sorry, Franck. Feel free to poll the other Mailman developers if you disagree; I admit my strong feelings on the matter may cause bias.) > I recall clearly, you did not want to see any change happening so > you could reinforce your conspiracy theory. That happens not to be the case. Conspiracy theories abound on the Mailman lists (especially Mailman-Users), it's true, but John was not the source. John's account of decision-making at the freemail ESPs is substantially the same as the rationale you have repeatedly presented yourself (a "push the panic button" response to a concentrated spam attack). > While the mailman developers are not happy on the current solutions > and are looking for better solutions, they are at the same time > happy to had one, when yahoo did the DMARC policy change, and > quickly extended on the possibilities based on the experience they > had before Yahoo did the policy change. Indeed we are *not* happy, and yes we did respond as quickly as possible to the *denial of service* experienced by many list subscribers, not restricted to the denial of service imposed by Yahoo! and AOL on their own subscribers. However, my wrapping suggestion had already been implemented, so the DMARC.org From-corrupting setting was not the only mitigation available (both became available in version 2.1.16). And we remain unhappy, not least because list operators are unhappy. The configurations are somewhat tricky and not understood at all by most list operators -- they follow recipes that are appropriate for common cases, but may conflict with unusual settings. The requirement by some mitigations that Mailman access the DNS in order to apply them only to "p=reject" posters (which is frequently mentioned by list operators requesting help) introduces substantial additional complexity. This is going to be an ongoing burden for the project, I fear. > Now, while mailman has some solutions, it is in the recent versions > and many people are still running old versions of mailman and > upgrading or patching for them is difficult. So saying people do > not know how to fix things is perfectly valid too. That's misdirection. We know one simple and guaranteed fix for the problem, and it is trivial to implement: domains providing mailboxes for personal use (including sending as a mailbox user of that domain from a different one, transfers that modify Content-Transfer-Encoding, mailing lists, use of on-behalf-of content distribution services, and so on) should stop publishing DMARC policies with "p=reject". There appear to be two of them, they can do this in 5 minutes, and the problem will be completely eliminated within a day or so. That is not the only solution, but it really should be on the table, despite the additional costs of spam and spam-fighting those ESPs may suffer. I don't expect them to follow it any time soon, but that's no reason why we should sanction their current policy. We can condemn the policy and implement rational countermeasures at the same time. I support adding your "conditions for legitimate use of 'p=reject'" to the DMARC-base document, for example. I have no hope that DMARC.org will acquiesce, of course. > Time to stop these non-technical threads These threads are input to the BCP process, at the very least. In any case, "p=reject" cannot be treated as a "technical" problem since the damage it does affects third parties who are not party to the DMARC protocol. > and focus on making email more secure by providing solutions for > people to choose from. I've made the lists used by my students more secure (against denial of service) by filtering "p=reject" domains. As it happens, *all* of my users agree that is the appropriate solution for us (the Yahoo! users didn't even think about fighting before switching, they already had GMail addresses). Of course I hesitate to recommend that policy to anybody else, but it *is* technically simple, and was the optimum response in my case. Regards, Steve From nobody Thu May 29 04:47:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920341A01B3 for ; Thu, 29 May 2014 04:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUsGr9wQLG3y for ; Thu, 29 May 2014 04:47:38 -0700 (PDT) Received: from ntbbs.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D589B1A00C6 for ; Thu, 29 May 2014 04:47:37 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1552; t=1401364051; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=SX3CnpHzic/iftQ247jwvNjeNL0=; b=PSF6JDIURoimHomlUi46 Pd6y53C0O6F3Zcl8ssdYvUhqEAAr3qMuYE9hJjBpFDFS041Yk9pz5P5hRcbo0hlj McemTD9AcZS4eGqAQ5Im+apegnO3+VbMuUI5xb5tRCAX9RKGUvRu1BTa4VjHRoak RVieFid1amNnYqSHwHkJObg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 29 May 2014 07:47:31 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 844186290.6499.1628; Thu, 29 May 2014 07:47:30 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1552; t=1401363907; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=x9I198x eU5qDs2Pnca5D78BI2P3mxs4u35T+kFiBlq0=; b=idWyL/jSQKY/4ZLqNnbj5v/ j3xiTVPfNf9Kq/R9+9LIUqUcmpxk8G0PSQe4TL1TYmKDszm9neJFDmtKTPjrPJFY ZQQ6M8gUm+4W+nJnr2Gp3Uaxh8afhE17MG6ROqncZwRj/2RmZqJ7PH/5a1Ren/TN opngYmgofOnf7P29s8A0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 29 May 2014 07:45:07 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 860554921.9.1984; Thu, 29 May 2014 07:45:07 -0400 Message-ID: <53871E55.5080609@isdg.net> Date: Thu, 29 May 2014 07:47:33 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <20140528163723.63860.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3c0L8T0xYFe7JZErqt_hamv5GHE Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 11:47:40 -0000 On 5/29/2014 3:09 AM, Murray S. Kucherawy wrote: > On Thu, May 29, 2014 at 12:06 AM, John R Levine > wrote: > > By the way, to return to the original point, it still seems > vanishingly unlikely to me that if we invented per-sender > whitelists that the two mail providers would implement them. > > Has anyone tried asking them? > > I'm not sure what value I should put in all this (ahem) third-party > speculation about their intentions or what they care about. Good point. Why don't you ask them? We need positive endorsement for 3rd party semantics which we don't have. I've implemented ATPS for ADSP and it works. Update the extension for DMARC and I'm sure Yahoo can manage 30K records if they decide to use it. That shouldn't be a problem and it will be a growth thing, not adding 30K records in one shot. It will be more manageable. A major consideration is that not all domains are YAHOOs so it they won't need the same scale, not even close. But you see, thats been the problem with all this all along -- picking who this or that protocol, DKIM itself, will be using them and leveraging its value via a policy layer. We can't do that. The protocol modeling must fit all. That doesn't mean it works for all but from a mail integration and engineering standpoint, it has to apply to all -- small and large. It has to make sense at all scales. The danger was to miss this with the large who will have a higher impact when assumed they won't be using it. -- HLS From nobody Thu May 29 07:02:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACC51A0099 for ; Fri, 23 May 2014 23:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MprBIYg4yLpr for ; Fri, 23 May 2014 23:48:16 -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 A1ACD1A0011 for ; Fri, 23 May 2014 23:48:16 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.235.120]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s4O6lpI1027016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 May 2014 23:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1400914083; bh=22aZI/+cv4LylT0deglTzz8uPTqzq7ulW6jpNWGhYgM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oVUryO2SzMY13NNSgY+C671GfTq7eYy5MggKfCvhNadais7unmVdXroW7kRvfiD8D eJyl6Q9Vwui3OTFHqT1WhWULnpitckNpOhZ2Utmz7z3RQ/DC4VRpmoqJtfP8BgG+iv JUE0y6bWgpxJ1IDeFp8kK5qNnzSBBGG2vH7EcJ8I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1400914083; i=@elandsys.com; bh=22aZI/+cv4LylT0deglTzz8uPTqzq7ulW6jpNWGhYgM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xISQzYX5/BdE5cqt2JL3jknTuu7LHhNe+22DoYCvpYYGnzbL5eVSIDeYrUrHscQUv bTNLZGVtGHZXzIESQ0GFD19uN+/c3xV3J8hPc6aZft4ZORPlUNs09HPCK3HQS88V+u zSSw3K7pBPLEOwjvNmRQc3bV1ITemjpAkywuEcTA= Message-Id: <6.2.5.6.2.20140523223844.0bc29590@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 23 May 2014 23:18:48 -0700 To: Douglas Otis From: S Moonesamy In-Reply-To: References: <536FD3EB.7090104@people.ops-trust.net> <7B715D1A-FC45-4ACA-8B28-2E80DBDD2EB2@gmail.com> <6.2.5.6.2.20140512131712.0b86a730@resistor.net> <3B10F111-B781-4473-88A4-F6EAD4E8EAFE@gmail.com> <6.2.5.6.2.20140522223431.0bc90500@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Crem9k7GGcMGS_b1BIiz6tGrcFM X-Mailman-Approved-At: Thu, 29 May 2014 07:02:11 -0700 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Support for DMARC "p=reject" X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 May 2014 06:48:18 -0000 Hi Doug, At 17:07 23-05-2014, Douglas Otis wrote: >I have been asked nearly the same question by others. A section >will be added to explain the how and why and its impact on >privacy. Senders and receivers desire a scheme that improves >protection of the From header field. The business aspects of this >became extremely clear to PayPal by effects on their customers then >obligated to sift through massive amounts of email abuse. The >benefit of timely out-of-band notification instead caused an exodus >of customers. To staunch customer loss, direct appeals to major >ESPs to reject non-aligned PayPal messages helped, and helped >everyone. Unfortunately, direct appeal does not scale. Hence we >have a limited stop-gap scheme. I was not thinking about privacy in that comment. Some time back I looked into why abuse occurred in different systems. I was not trying to understand the matter instead of trying to resolve it. Note that I have read the relevant papers. Anyway, you did not answer the question I asked. :-) PayPal is the not really a good case in my opinion. I do not get money by solving PayPal's problem. I might put it some effort as encouraging abuse is not a good idea. A problem, which you identified, is that a scheme would have to scale or else be workable at some scale. >As has become extremely clear, although there was early evidence, >DMARC did not fully consider important "corner cases". It seemed >okay to leave these issues for receivers to sort out. Now AOL and >Yahoo! have made it evident receiver cooperation is in jeopardy. If >you are like most others, you have had malicious and socially >engineered messages from someone you know prompting you to click a >link or call a number, etc. Resorting to the only functional policy >scheme able to reject messages is understandable, but this came at a >dear cost. As John Levine describes, "a death by a thousand cuts". If you push things too strongly I (as a receiver) would be no longer be inclined to be cooperative. >Asserting whether all messages must have From/Source domain >alignment is somewhat analogous to the type of federation supporting >single-sign-on schemes. A federation has the purpose of protecting >identifiers. In other words using laissez faire protocols where the >strategy of "block on event" is inverted to become "accept on >event". In the case of DMARC + TPA, "accept on event" is derived >from DMARC feedback/log review accurately determining which domains >require exception. Further review can even characterize how domains >authenticate and which header elements confirm or narrow authorization. I'll say ok to the above. >Cute comic. It is not really the information protected by a >federation scheme. It is not even the exclusion of bad stuff. It >is protection of federated identities by receivers implementing >DMARC + TPA. By using this scheme, associated identities can be >protected while also avoiding disruption of legitimate >messages. Even Eliot Lear's mother becomes safer. (I hope this is >the right example as it was discussed many years ago.) The problem might be one of trust. I won't even try to analyze that as it is going to end up being a lot of work. >Unfortunately, that approach now only works for authenticated >domains. :^( Dane anyone? You'll have other problems then. :-( Regards, S. Moonesamy From nobody Thu May 29 07:07:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93561A0950 for ; Thu, 29 May 2014 07:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nkkcnifx2TR for ; Thu, 29 May 2014 07:07:43 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 322A81A094F for ; Thu, 29 May 2014 07:07:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id C101A970B1E; Thu, 29 May 2014 23:07:38 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B26B711F235; Thu, 29 May 2014 23:07:38 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 29 May 2014 23:07:38 +0900 Message-ID: <87ppiw7k5x.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oIlvKpC48nfIxs12qoXiILJJ2Lo Cc: Brandon Long , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 14:07:45 -0000 Douglas Otis writes: > There are many cases that are never originally signed by the DMARC > domain. Such as an accounting package that sends out invoices on > behalf of some company that wants their email address in the From > header since this is what their customers will recognize. I don't understand this example. This use case seems quite compatible with DMARC as it is. That is, company and accountant should have a substantial and expensive to maintain trust relationship already. I would think that the company could (a) provide an alias (subdomain) in its own domain for the accountant's host, and advertise the accountant's policy via _dmarc.invoices.example.com, or (b) maintain an authenticated channel (ie, special purpose VPN) direct to a special host under its own control in its own domain for the accountant to relay through, and the company signs there. Sure, there'd be some additional cost, but not prohibitive. Note that in either case the client can fire the accountant in an instant by changing the DNS or shutting down the authenticated channel. > > I suspect that many parties that implement DMARC are "cheating" > > by allowing things that look like mailing list or forwarded mail > > through even if they fail auth and the domain is p=REJECT. > > Providing a higher bar for when to "cheat" may be useful, then. > The hurdle that seems to be in everyone's mind is how to go about > facilitating feedback that is not a lot of work. Again, I seem to require an additional clue. DMARC feedback is working fine AFAICS. It may be costly, and we want to reduce those costs, of course. But "p=reject" OTOH is a more or less legitimate denial of service, a completely different issue. Are you talking about a different kind of feedback? Steve From nobody Thu May 29 07:17:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAD81A6F05 for ; Thu, 29 May 2014 07:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa__5PK8xW8f for ; Thu, 29 May 2014 07:17:50 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1E11A0789 for ; Thu, 29 May 2014 07:17:50 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id i57so310818yha.41 for ; Thu, 29 May 2014 07:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=etuhxallJM65lma6bZWnrTmjk2QRwidqh5XhXSxwsB4=; b=yej5dq1AZPueGm9wWb8/f5XDrN2UYIFo7GRx0lBhBtUSWmKKN0ch7EJFxnIJwF1wT7 whIn10j7w8LytwxmbFqkunWKZeLUGsk8SWzFpjeGd6yA3e0DMfLnksUucPk+RDDyeuV7 dBBOQ7UIDh0H/stMscohjEVZCnbOONArNgf8KW5EVtOP/QglTOSNgRdAqBzqg5iS6pog ad5+qdHczxruaMjWUY3NQQTWH/QwK0S7NmmZCTXOPwtixA7U2nqjzj8I0ewUmNnGS4Ht cHv8JD2CquvHUw3H/0PekmDujF2TsfqvOVCp1wPlPgy6+xkWm+h4HS8GxbYC9f4lyA3D j06A== X-Received: by 10.236.206.97 with SMTP id k61mr10463779yho.107.1401373066265; Thu, 29 May 2014 07:17:46 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id k66sm1114869yhg.39.2014.05.29.07.17.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 07:17:45 -0700 (PDT) Message-ID: <5387415F.7010108@gmail.com> Date: Thu, 29 May 2014 07:17:03 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , John R Levine References: <20140528163723.63860.qmail@joyce.lan> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UMppv5XJ06Vgj6rG3GL2UUdh5Ew Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 14:17:51 -0000 On 5/29/2014 12:09 AM, Murray S. Kucherawy wrote: > Has anyone tried asking them? I'll suggest that it's premature to do such asking, just as it is premature to say that they are uninterested or would reject the idea. Absent a very concrete proposal -- along the lines of a specification -- the request would be generic. Companies don't (and shouldn't) make meaningful commitments to vague concepts. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu May 29 10:47:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FB61A018A for ; Thu, 29 May 2014 10:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oC9VTupXn99 for ; Thu, 29 May 2014 10:47:50 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 579871A01A0 for ; Thu, 29 May 2014 10:47:50 -0700 (PDT) Received: (qmail 21583 invoked from network); 29 May 2014 17:47:40 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 29 May 2014 17:47: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; s=24ec.538772bd.k1405; i=johnl@user.iecc.com; bh=KWNWV1GXkPVkGIXzRL9hn5jjt/eb6NVFW3yzRvMPfhA=; b=d2rGqcgOfvMEBKybcFFBICUETWtlJCzkIia0O/bTXjQYLGRVtRSj7QOy7KGDrxFPf4+r/2wp9J0ImKfSlhZfv475nBjPFW/hMD8Fn/FwSMutgIThHjS2cH5aWTOzHIIVrzhatPfom2K74juRsBSxTnPUyzKmJOwzhG/O77CNJSrJDCzYQ4fIjAorDHIS6TUqG5YbYAvx8SIJ1r716Nd2igN4TfGUCcxPl8ocNHuIykM18cyu8W3KYMwlgeNjRHpj 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=24ec.538772bd.k1405; olt=johnl@user.iecc.com; bh=KWNWV1GXkPVkGIXzRL9hn5jjt/eb6NVFW3yzRvMPfhA=; b=WOiwFvfelpkicwrEIEgij4mhFMqlzw+yJhKl2gYvxU5WsVvKtLy2xxnhZFiZO0GKkkCHN+Jh8R05HaUtB+3lzG19P7og2PTkQyMEt8jMIBmHF9DXUZYmzfLihaIvKwgZpD10Kk4MptxtogHpBcWYdHk25AE0ytg6o2h68Rnfx8MMOLJzw3toUPMucm7iB1NbCtowrOMTSY/wGo51Yz9AYo64IWQJn7PMRqhK3CPIpkHJh6WjvK9f2uwJCrqvEIYb Date: 29 May 2014 17:47:19 -0000 Message-ID: <20140529174719.9451.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: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dYdkVLhzzHKNhdgptp4f8NeNuoo Cc: blong@google.com Subject: Re: [dmarc-ietf] send-to-a-friend, was Solution for X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 17:47:51 -0000 >> Since you don't mention it, what about the "mail this article to a >> friend" use case that has also been mentioned? Is that a problem that >> should be addressed here? ... >Franky, that case has always been kind of ick, and is "easily" solved by >sending From the domain in question (article-noreply@wsj.com). Granted, I >don't know how many of those there are and fixing them all is certainly >annoying work that its bad to force on the world... also, arguably most of >those shares have been replaced by sharing to the social website of the >week. There seem to be rather a lot, since it's a feature on most magazine and newspaper web sites. Since you mentioned the WSJ, they use the user's own address as the From: address (I just checked.) Some do the hack you mentioned, but a lot don't. My college class has a mailing list, and I sometimes send articles to it from my WSJ account, which would stop working if they didn't let me put my own address on the From: line. Do you have any numbers on how much if any of a spam or phish problem these things are? They've never been on my radar, I think because they do a lot of rate limiting and inbound filtering. Some also limit it to subscribers. Also please keep in mind uses like the school teacher I mentioned earlier today. Again, useful, not abusive, and I think there are likely to be a lot of little setups like his that are now mysteriously failing. R's, John From nobody Thu May 29 10:58:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597D31A019C for ; Thu, 29 May 2014 10:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WV5nK81rz8E for ; Thu, 29 May 2014 10:58:40 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0C61A018A for ; Thu, 29 May 2014 10:58:39 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id lx4so651395iec.33 for ; Thu, 29 May 2014 10:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=npu/R3pqJCTY48x71vSIB5vQx1ItZi+vod+kQjVpw+g=; b=CwyJwpRkd5G8yDyy0tj680YsNhPicJnyO+nfZAKUfWGVV18vhX/QPZRGP+SF3So3kb 1f/KrHicC9wmT9x5PM5Z8N5gobbUNxN3rYFiZTF7jTL4Blnq/fhhYyntDf1ZsXGljXIA jNc12VC0x/ybWKE2yeb7hLaDocx514TIkfm3NTYruyLVDmY6CwE9MLGUBYR5RW+7t0GA VLDNoai1hnQUvuJTvsWueEvmdjGmekpYp8Lu9JkLHL53b8HNuzh+rU3mgXGRM6KF477O /IQlzgb+jYjVQYH4Ny0rLIMX1mhnEzYZIKzww1SEt9lPLiT+SQ0hV+vEBql/7JYWSsmY hFeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=npu/R3pqJCTY48x71vSIB5vQx1ItZi+vod+kQjVpw+g=; b=VbNbtP1CDCUNdKzqqPcqSxWhQ2tdgdAGbwSOwMnp23VP/WHyQ8MkDkbP92IA6aU4Tv 7F1GQiaQI82Lvvvt4WGnqXD/hFTtnfVmo2ripbKpBkNpxjSPLq4vI4DgKZc6PhtYmHbI DnD9gJ9lKI5FHfzRMvRdGPlOhZdPNlB9gAG2OMl0xEyWYINlQemv2QZKAOR/ggdSTXYf kDmFxqWmQo2HoeZCKJ7PuZwV8tAA2aRRytV8K6Tr5IJAA5cuU0rVaY0NcVEUbQqLv9N3 b+wn4mn8pWJWjmrGQNpIQ4TLS8IMAn7ps6Rc7eh0AKeBkYON+9s6VuSEaLCXc8q+9YYk 5CCQ== X-Gm-Message-State: ALoCoQnyErvha1eus2a4sxMrCKMF+MfyicFiPH9Is40dqM/zR5f1pksbA1pJbvxvM3EketPVQMKa MIME-Version: 1.0 X-Received: by 10.42.68.18 with SMTP id v18mr9120094ici.1.1401386315632; Thu, 29 May 2014 10:58:35 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Thu, 29 May 2014 10:58:35 -0700 (PDT) In-Reply-To: <20140529174719.9451.qmail@joyce.lan> References: <20140529174719.9451.qmail@joyce.lan> Date: Thu, 29 May 2014 10:58:35 -0700 Message-ID: From: Brandon Long To: John Levine Content-Type: multipart/alternative; boundary=20cf303636d989838004fa8dada3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rlhkL4A2QCiZXU2SxK6eCwyZdVA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] send-to-a-friend, was Solution for X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 17:58:41 -0000 --20cf303636d989838004fa8dada3 Content-Type: text/plain; charset=UTF-8 On Thu, May 29, 2014 at 10:47 AM, John Levine wrote: > >> Since you don't mention it, what about the "mail this article to a > >> friend" use case that has also been mentioned? Is that a problem that > >> should be addressed here? ... > > >Franky, that case has always been kind of ick, and is "easily" solved by > >sending From the domain in question (article-noreply@wsj.com). Granted, > I > >don't know how many of those there are and fixing them all is certainly > >annoying work that its bad to force on the world... also, arguably most of > >those shares have been replaced by sharing to the social website of the > >week. > > There seem to be rather a lot, since it's a feature on most magazine > and newspaper web sites. Since you mentioned the WSJ, they use the > user's own address as the From: address (I just checked.) Some do the > hack you mentioned, but a lot don't. My college class has a mailing > list, and I sometimes send articles to it from my WSJ account, which > would stop working if they didn't let me put my own address on the > From: line. > > Do you have any numbers on how much if any of a spam or phish problem > these things are? They've never been on my radar, I think because they > do a lot of rate limiting and inbound filtering. Some also limit it > to subscribers. > > Also please keep in mind uses like the school teacher I mentioned > earlier today. Again, useful, not abusive, and I think there are > likely to be a lot of little setups like his that are now mysteriously > failing. > I'm sure most of the big ones are well protected with abuse limits, but I'm sure there are plenty of other ones which are not. I'm sure each one that is abused is a drop in the bucket of the overall abuse. That being said, with DMARC, I see no way forward for them. Even if the WSJ and other large publishers are whitelisted by one of the schemes we're talking about, the forms like your teacher's are never going to get whitelisted. At best, a provider may provide a mechanism to whitelist things for a specific user, but I haven't imagined anything like that which would be particularly user friendly either. Brandon --20cf303636d989838004fa8dada3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, May 29, 2014 at 10:47 AM, John Levine <= ;johnl@taugh.com&g= t; wrote:
>> Since you don't mention it, wha= t about the "mail this article to a
>> friend" use case that has also been mentioned? Is that a prob= lem that
>> should be addressed here? ...

>Franky, that case has always been kind of ick, and is "easily"= ; solved by
>sending From the domain in question (article-noreply@wsj.com). =C2=A0Granted, I
>don't know how many of those there are and fixing them all is certa= inly
>annoying work that its bad to force on the world... also, arguably most= of
>those shares have been replaced by sharing to the social website of the=
>week.

There seem to be rather a lot, since it's a feature on most magazine and newspaper web sites. =C2=A0Since you mentioned the WSJ, they use the user's own address as the From: address (I just checked.) =C2=A0Some do= the
hack you mentioned, but a lot don't. =C2=A0My college class has a maili= ng
list, and I sometimes send articles to it from my WSJ account, which
would stop working if they didn't let me put my own address on the
From: line.

Do you have any numbers on how much if any of a spam or phish problem
these things are? =C2=A0They've never been on my radar, I think because= they
do a lot of rate limiting and inbound filtering. =C2=A0Some also limit it to subscribers.

Also please keep in mind uses like the school teacher I mentioned
earlier today. =C2=A0Again, useful, not abusive, and I think there are
likely to be a lot of little setups like his that are now mysteriously
failing.

I'm sure most of the big o= nes are well protected with abuse limits, but I'm sure there are plenty= of other ones which are not. =C2=A0I'm sure each one that is abused is= a drop in the bucket of the overall abuse.

That being said, with DMARC, I see no way forward for t= hem. =C2=A0Even if the WSJ and other large publishers are whitelisted by on= e of the schemes we're talking about, the forms like your teacher's= are never going to get whitelisted. =C2=A0At best, a provider may provide = a mechanism to whitelist things for a specific user, but I haven't imag= ined anything like that which would be particularly user friendly either.

Brandon=C2=A0

--20cf303636d989838004fa8dada3-- From nobody Thu May 29 11:05:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187A41A016D for ; Thu, 29 May 2014 11:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z7TOkAKii6Q for ; Thu, 29 May 2014 11:05:51 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79CB31A0168 for ; Thu, 29 May 2014 11:05:51 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so1152167wiw.10 for ; Thu, 29 May 2014 11:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kpGEh96LRxdPJAhuSwaFtm4qkxqufvxwvY8ohH13A88=; b=fghwUYY3nlZtEqXjA+EDnPBV+Kz+o/bO2X35ymK++kSIqflAYpHR+nLLnyRcb/bFa9 VKrK27Nv0y8bicjqVnUQXcDkL00fJBhnDPabDOAzCVFn2oWSsuBS8TBjMPLD6yFatTrx FO3Iso7gSe6YezJ2PLPX6EhfU8dxja4ux/R/FhiWe4+TDcuou0bNY7zffh3VCdRivKaj +T0PIcFPDM8vQe/oyy0ykFkn8grgaVMV1hEPXTJV6gIp76uRrk3na+DxYk3GAQYnCc2d jTxR/RE7oBXxbpVglC3v07tEUFmKceEQuzBMRz/cyMDvwKoumuVp+RPwjcuqMTC11/nn /ptw== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr13018169wjb.73.1401386745628; Thu, 29 May 2014 11:05:45 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Thu, 29 May 2014 11:05:45 -0700 (PDT) In-Reply-To: References: <20140529174719.9451.qmail@joyce.lan> Date: Thu, 29 May 2014 11:05:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: Brandon Long Content-Type: multipart/alternative; boundary=047d7bf10a1c2a912604fa8dc701 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/aqLOUB8rwKFxBYS771jHetYieks Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] send-to-a-friend, was Solution for X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 18:05:53 -0000 --047d7bf10a1c2a912604fa8dc701 Content-Type: text/plain; charset=UTF-8 On Thu, May 29, 2014 at 10:58 AM, Brandon Long wrote: > > > There seem to be rather a lot, since it's a feature on most magazine >> and newspaper web sites. Since you mentioned the WSJ, they use the >> user's own address as the From: address (I just checked.) Some do the >> hack you mentioned, but a lot don't. My college class has a mailing >> list, and I sometimes send articles to it from my WSJ account, which >> would stop working if they didn't let me put my own address on the >> From: line. >> >> Do you have any numbers on how much if any of a spam or phish problem >> these things are? They've never been on my radar, I think because they >> do a lot of rate limiting and inbound filtering. Some also limit it >> to subscribers. >> >> Also please keep in mind uses like the school teacher I mentioned >> earlier today. Again, useful, not abusive, and I think there are >> likely to be a lot of little setups like his that are now mysteriously >> failing. >> > > I'm sure most of the big ones are well protected with abuse limits, but > I'm sure there are plenty of other ones which are not. I'm sure each one > that is abused is a drop in the bucket of the overall abuse. > > That being said, with DMARC, I see no way forward for them. Even if the > WSJ and other large publishers are whitelisted by one of the schemes we're > talking about, the forms like your teacher's are never going to get > whitelisted. At best, a provider may provide a mechanism to whitelist > things for a specific user, but I haven't imagined anything like that which > would be particularly user friendly either. > I'd love to see some usage statistics from one or more of them. Lately it seems to me a lot more of such link sharing happens over social media (where this is all moot) rather than over email. -MSK --047d7bf10a1c2a912604fa8dc701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 29, 2014 at 10:58 AM, Brandon Long <blong@go= ogle.com> wrote:


There seem to be rather a lot, since it's a feature on most magazine and newspaper web sites. =C2=A0Since you mentioned the WSJ, they use the user's own address as the From: address (I just checked.) =C2=A0Some do= the
hack you mentioned, but a lot don't. =C2=A0My college class has a maili= ng
list, and I sometimes send articles to it from my WSJ account, which
would stop working if they didn't let me put my own address on the
From: line.

Do you have any numbers on how much if any of a spam or phish problem
these things are? =C2=A0They've never been on my radar, I think because= they
do a lot of rate limiting and inbound filtering. =C2=A0Some also limit it to subscribers.

Also please keep in mind uses like the school teacher I mentioned
earlier today. =C2=A0Again, useful, not abusive, and I think there are
likely to be a lot of little setups like his that are now mysteriously
failing.

I'm sure most = of the big ones are well protected with abuse limits, but I'm sure ther= e are plenty of other ones which are not. =C2=A0I'm sure each one that = is abused is a drop in the bucket of the overall abuse.

That being said, with DMARC, I see no way forward for t= hem. =C2=A0Even if the WSJ and other large publishers are whitelisted by on= e of the schemes we're talking about, the forms like your teacher's= are never going to get whitelisted. =C2=A0At best, a provider may provide = a mechanism to whitelist things for a specific user, but I haven't imag= ined anything like that which would be particularly user friendly either.

I'd love to see some usage statist= ics from one or more of them.=C2=A0 Lately it seems to me a lot more of suc= h link sharing happens over social media (where this is all moot) rather th= an over email.

-MSK
--047d7bf10a1c2a912604fa8dc701-- From nobody Thu May 29 12:01:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268251A0B78 for ; Thu, 29 May 2014 12:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uELEItm_Csen for ; Thu, 29 May 2014 12:01:38 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A171A047D for ; Thu, 29 May 2014 12:01:38 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id i50so2334829qgf.3 for ; Thu, 29 May 2014 12:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=+52uBFYm/7po2GSk4ZuwYLxMYlQWv2gCQnQAau4sUI0=; b=qtK+tAd+vlhrmi75QakhJbQ7C+ToksSL/qqmI8lqxNFi+pIdAMb58/mIBR+0fK+xWS /sBWPVqb3F/N65tI9xPbBuY/0Kq1AveKNIDXQV1HOxZ7gVsDpef737cFnkudOm7ZOEmJ CH2cVxaHi1TaqQqrvzyMj2IsXi0PmcYm/9g/BW3qvB0N6VA3GH2ok0Mt3WWjgR7N/eMG Oq4LiiHenR0DiJ/fXSqQfPFuQWddvNacAU7Lc2QbSNU4svleDLn2CSQqrVNlg/Ow8ZhD NJBB4JdkpiDxErB6jqgKCfCuWLuSjAuVZh11pPGZtwG8QgdAM2ZXYwpHofFaXpneEbWD gAJQ== X-Received: by 10.224.14.79 with SMTP id f15mr13487544qaa.96.1401390094219; Thu, 29 May 2014 12:01:34 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id s13sm2248430qay.39.2014.05.29.12.01.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 12:01:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_97FDC46D-213B-44E3-8CA2-F3771991C2CD" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <87ppiw7k5x.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 29 May 2014 12:01:32 -0700 Message-Id: <4B556652-E552-4EF7-8513-B008D8CD1ED2@gmail.com> References: <87ppiw7k5x.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2h9oMCNjwn3h7J4cXdkbP98S9WY Cc: Brandon Long , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 19:01:41 -0000 --Apple-Mail=_97FDC46D-213B-44E3-8CA2-F3771991C2CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On May 29, 2014, at 7:07 AM, Stephen J. Turnbull = wrote: > Douglas Otis writes: >=20 >> There are many cases that are never originally signed by the DMARC >> domain. Such as an accounting package that sends out invoices on >> behalf of some company that wants their email address in the From >> header since this is what their customers will recognize. >=20 > I don't understand this example. This use case seems quite compatible > with DMARC as it is. >=20 > That is, company and accountant should have a substantial and > expensive to maintain trust relationship already. I would think that > the company could (a) provide an alias (subdomain) in its own domain > for the accountant's host, and advertise the accountant's policy via > _dmarc.invoices.example.com, or (b) maintain an authenticated channel > (ie, special purpose VPN) direct to a special host under its own > control in its own domain for the accountant to relay through, and the > company signs there. Sure, there'd be some additional cost, but not > prohibitive. Note that in either case the client can fire the > accountant in an instant by changing the DNS or shutting down the > authenticated channel. Dear Stephen, = https://community.intuit.com/questions/899989-please-make-quickbooks-pass-= the-dmarc-evaluation-please-do-this-quickly I know of many small operations with similar services and previously = working strategies. With a low profit margin, no one wants to then be = dealing with DNS or VPN configurations or deciding who is allowed to = have access to their networks or their DKIM private keys. Think of the heating and air conditioning outfit given VPN access for = the purpose of submitting invoices. That error in judgement cost = hundreds of millions for a well known retailing outfit. There are also = similar types of risks when anyone opens any MS Office document given to = them by a spoofed party. http://krebsonsecurity.com/2014/05/the-target-breach-by-the-numbers/ The intent behind TPA-Label is to permit a secure scheme without ever = asking anyone to share credentials. Not ever! Instead, everyone uses = what they already have, perhaps even stronger schemes than what is = offered by DKIM or SPF. Large ESPs that have had a major security = breach should set aside a budget related to restoring order. A = TPA-Label setup could be part of that effort. Two DNS servers (for redundancy) and some DMARC and MTA log processing = scripts should offer a comprehensive and fairly complete starting point. = Yes, even for a large ESP. Of course there will be ongoing support = issues, but this should also pale in comparison to unsolvable email = complaints of affected legitimate email use. For this, there should be = web-based forms to supplement DMARC feedback. By setting up a TPA-Label extension, it would also allow their users to = know when they have themselves been compromised, while also preventing = unauthorized use by rogue servers. This added feature seems like a nice = way of saying "Sorry, but we are now doing more to improve security." >>> I suspect that many parties that implement DMARC are "cheating" >>> by allowing things that look like mailing list or forwarded mail >>> through even if they fail auth and the domain is p=3DREJECT. >>> Providing a higher bar for when to "cheat" may be useful, then. >=20 >> The hurdle that seems to be in everyone's mind is how to go about >> facilitating feedback that is not a lot of work. Again, TPA-Label also permits a way to squelch DMARC feedback already = evaluated. Perhaps a flag could even be added that basically says. "Yes = we know about this domain, and we think it cannot be trusted." This = would be a change to the current draft. > Again, I seem to require an additional clue. DMARC feedback is > working fine AFAICS. It may be costly, and we want to reduce those > costs, of course. But "p=3Dreject" OTOH is a more or less legitimate > denial of service, a completely different issue. Are you talking > about a different kind of feedback? Rather than having a channel only between receiver-to-sender, there = should also be a channel between sender-to-receiver. The channel can = represent a single DNS resource record. Such a single resource record = would offer low latency, low cost, and cacheable near the receiver for = even lower latency. I know that John and Tim would have little trouble setting up such a = service. The real challenge is to have an ESP do this that really needs = such a solution. Once in place, this opens up a range of services = others could easily offer on behalf of those who simply desire greater = email security. Regards, Douglas Otis --Apple-Mail=_97FDC46D-213B-44E3-8CA2-F3771991C2CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 29, 2014, at 7:07 AM, Stephen = J. Turnbull <stephen@xemacs.org> = wrote:

Douglas Otis writes:

There = are many cases that are never originally signed by the DMARC
domain. =  Such as an accounting package that sends out invoices on
behalf = of some company that wants their email address in the From
header = since this is what their customers will recognize.

I = don't understand this example.  This use case seems quite = compatible
with DMARC as it is.

That is, company and = accountant should have a substantial and
expensive to maintain trust = relationship already.  I would think that
the company could (a) = provide an alias (subdomain) in its own domain
for the accountant's = host, and advertise the accountant's policy via
_dmarc.invoices.example.com,= or (b) maintain an authenticated channel
(ie, special purpose VPN) = direct to a special host under its own
control in its own domain for = the accountant to relay through, and the
company signs there. =  Sure, there'd be some additional cost, but not
prohibitive. =  Note that in either case the client can fire the
accountant in = an instant by changing the DNS or shutting down the
authenticated = channel.

Dear Stephen,

https://community.int= uit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-= please-do-this-quickly

I know of many small = operations with similar services and previously working strategies. =  With a low profit margin, no one wants to then be dealing with DNS = or VPN configurations or deciding who is allowed to have access to their = networks or their DKIM private keys.

Think of = the heating and air conditioning outfit given VPN access for the purpose = of submitting invoices. That error in judgement cost hundreds of = millions for a well known retailing outfit.  There are also similar = types of risks when anyone opens any MS Office document given to them by = a spoofed party.





I = suspect that many parties that implement DMARC are "cheating"
by = allowing things that look like mailing list or forwarded mail
through = even if they fail auth and the domain is p=3DREJECT.
Providing a = higher bar for when to "cheat" may be useful, = then.

The = hurdle that seems to be in everyone's mind is how to go = about
facilitating feedback that is not a lot of = work.

Again, TPA-Label also = permits a way to squelch DMARC feedback already evaluated. Perhaps a = flag could even be added that basically says.  "Yes we know about = this domain, and we think it cannot be trusted."  This would be a = change to the current draft.

Again, I seem to require an additional clue.  DMARC = feedback is
working fine AFAICS.  It may be costly, and we want = to reduce those
costs, of course.  But "p=3Dreject" OTOH is a = more or less legitimate
denial of service, a completely different = issue.  Are you talking
about a different kind of = feedback?

Rather than having a channel = only between receiver-to-sender, there should also be a channel between = sender-to-receiver.  The channel can represent a single DNS = resource record. Such a single resource record would offer low latency, = low cost, and cacheable near the receiver for even lower = latency.

I know that John and Tim would have = little trouble setting up such a service.  The real challenge is to = have an ESP do this that really needs such a solution.  Once in = place, this opens up a range of services others could easily offer on = behalf of those who simply desire greater email = security.

Regards,
Douglas = Otis








= --Apple-Mail=_97FDC46D-213B-44E3-8CA2-F3771991C2CD-- From nobody Thu May 29 13:29:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32331A0666 for ; Thu, 29 May 2014 13:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH5ypkFyozSY for ; Thu, 29 May 2014 13:29:01 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DADCB1A0545 for ; Thu, 29 May 2014 13:29: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.298.1; Thu, 29 May 2014 22:28:54 +0200 Message-ID: <8F0A5BCBFFB046AF9F79C6E9772A253D@fgsr.local> From: "J. Gomez" To: References: <20140528163723.63860.qmail@joyce.lan> <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> Date: Thu, 29 May 2014 22:28:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/R9QRtd2im4v-Aixm7PbhrOKU6J4 Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 20:29:03 -0000 On Wednesday, May 28, 2014 10:13 PM [GMT+1=3DCET], Tim Draegen wrote: > I don't believe TPA-Label hits the mark between "solving a big hurt" > and "simple". IOW, it's too complicated for the amount of pain it > would resolve. Just my opinion, take care, =20 I'm of the same opinion as above. In my own words, I would say the TPA-label draft Otis posted reads like = perfectly polished Klingon to me. Id est, overly too complex for very little gain. Regards, J.Gomez From nobody Thu May 29 14:23:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B9D1A08AE for ; Thu, 29 May 2014 14:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKWWar3pxcEa for ; Thu, 29 May 2014 14:23:19 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B36DA1A08DC for ; Thu, 29 May 2014 14:23:18 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so1033109wes.41 for ; Thu, 29 May 2014 14:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=806Yztg4Ap9b1Tus6+CXZRLy9NaVb5613BNOs9SNMyM=; b=gMoCCmV/94EnYefTiTBLnC1zeFaHzCmj0QFCCLaNaF8s5G/2q1DhNR53ZmE3NvhuyM 0XLMkFZxehhmf/k9cZiCVlrJYVbR6JQhrSBbBrBSfwOs0rSduWwPPqRFX9ZTn151kHWs BRI0Co/G36xTPSs7vF66Bk9l2+sQMak9deqfJ8SBcc6S5gzmmf6irgQRdY7UmrQWhZVv FGEyxWfpHrUDsXzD1803qkWtcKBHFtXQ2iBdXE6yzZBV1RqO1lCMgeDG3BAJCj5smBaC XdOw/tQTj9N0nd2c4YgpAe6Z9Q9tZ90DCRzctH/CHN+/+TVld65lJxcwoJBKoqGc4kzW NtBA== MIME-Version: 1.0 X-Received: by 10.180.94.163 with SMTP id dd3mr54299wib.26.1401398593661; Thu, 29 May 2014 14:23:13 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Thu, 29 May 2014 14:23:13 -0700 (PDT) In-Reply-To: <8F0A5BCBFFB046AF9F79C6E9772A253D@fgsr.local> References: <20140528163723.63860.qmail@joyce.lan> <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> <8F0A5BCBFFB046AF9F79C6E9772A253D@fgsr.local> Date: Thu, 29 May 2014 14:23:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=f46d04462e5e5d33a104fa9089ec Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/72PvxXZwov9DoZlJd97hDcZHjvA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 21:23:20 -0000 --f46d04462e5e5d33a104fa9089ec Content-Type: text/plain; charset=UTF-8 On Thu, May 29, 2014 at 1:28 PM, J. Gomez wrote: > > I don't believe TPA-Label hits the mark between "solving a big hurt" > > and "simple". IOW, it's too complicated for the amount of pain it > > would resolve. Just my opinion, take care, > > I'm of the same opinion as above. > > In my own words, I would say the TPA-label draft Otis posted reads like > perfectly polished Klingon to me. > > Id est, overly too complex for very little gain. > +1. -MSK --f46d04462e5e5d33a104fa9089ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 29, 2014 at 1:28 PM, J. Gomez <jgomez@seryr= ich.com> wrote:
> I don't believe TPA= -Label hits the mark between "solving a big hurt"
> and "simple". =C2=A0IOW, it's too complicated for the am= ount of pain it
> would resolve. =C2=A0Just my opinion, take care,

I'm of the same opinion as above.

In my own words, I would say the TPA-label draft Otis posted reads like per= fectly polished Klingon to me.

Id est, overly too complex for very little gain.

+= 1.

-MSK
--f46d04462e5e5d33a104fa9089ec-- From nobody Thu May 29 14:55:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E3A1A0429 for ; Thu, 29 May 2014 14:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYl6O66NRHCG for ; Thu, 29 May 2014 14:55:49 -0700 (PDT) Received: from msginmsm03vapp.fmr.com (ltm-fwus209m-210m.fidelity.com [155.199.204.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF421A0437 for ; Thu, 29 May 2014 14:55:48 -0700 (PDT) Received: from msgrtphc05win.DMN1.FMR.COM (MSGRTPHC05WIN.dmn1.fmr.com [10.95.11.185]) by msginmsm03vapp.fmr.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.1) with ESMTP id s4TLtfSf024530 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Thu, 29 May 2014 21:55:41 GMT X-DKIM: OpenDKIM Filter v2.1.3 msginmsm03vapp.fmr.com s4TLtfSf024530 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; s=2012-05-26; t=1401400542; bh=MRyH5Ot8uEVQ802ymQqaL1Rmbb9IZoC4MBM7t2QuP5A=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=oT1qR7UBaDS7TFM62TRhT9dXxvVKW8yxGeg+qfwFMRQlXrIF8knVZYFhuvr5+nbyY floiQ7Xwiho7nDQkwnRIFzEoHwR8yLkeZBwtuqXxxZR8fq+pNpwr1yh+9FOsbDSgn4 8Lp23TV9sSro5HG/3bjQyIOh0h6poL6Di8pBOZ6o= Received: from MSGRTPCCRF2WIN.DMN1.FMR.COM ([10.95.12.31]) by msgrtphc05win.DMN1.FMR.COM ([10.95.11.185]) with mapi; Thu, 29 May 2014 17:55:41 -0400 From: "Popowycz, Alex" To: "Murray S. Kucherawy" , "J. Gomez" Date: Thu, 29 May 2014 17:55:38 -0400 Thread-Topic: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection Thread-Index: Ac97hDzXb9ZCyJL3RrmdFV6IZKo7oQAA9rOw Message-ID: <9495B91F5CA0E24C9161D71CD46E43DB011C8C6D7611@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <20140528163723.63860.qmail@joyce.lan> <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> <8F0A5BCBFFB046AF9F79C6E9772A253D@fgsr.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/related; boundary="_004_9495B91F5CA0E24C9161D71CD46E43DB011C8C6D7611MSGRTPCCRF2_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6jrbCb6hdwuOdeTtwb350a66Qi0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 21:55:50 -0000 --_004_9495B91F5CA0E24C9161D71CD46E43DB011C8C6D7611MSGRTPCCRF2_ Content-Type: multipart/alternative; boundary="_000_9495B91F5CA0E24C9161D71CD46E43DB011C8C6D7611MSGRTPCCRF2_" --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8C6D7611MSGRTPCCRF2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgS2xpbmdvbiBtYXkgYmUgcnVzdHksIGJ1dCBJIHRoaW5rIHRoYXQgbWFrZXMgaXQgYSArW2Np ZDppbWFnZTAwMy5wbmdAMDFDRjdCNjcuMzJFNDE0RDBdIChhcG9sb2dpZXMgZm9yIHRob3NlIHNl ZWluZyB0aGlzIGluIHRleHQgYXMgSSBkb27igJl0IGhhdmUgS2xpbmdvbi50dGYgb24gbXkgd29y ayBsYXB0b3ApLg0KDQpGcm9tOiBkbWFyYyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBNdXJyYXkgUy4gS3VjaGVyYXd5DQpTZW50OiBUaHVyc2RheSwgTWF5IDI5 LCAyMDE0IDU6MjMgUE0NClRvOiBKLiBHb21leg0KQ2M6IGRtYXJjQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2RtYXJjLWlldGZdIFNvbHV0aW9uIGZvciBETUFSQyBkaXNydXB0aW9uIG9mIG5vcm1h bCBlbWFpbCB1c2Ugd2hpbGUgc3RpbGwgb2ZmZXJpbmcgaXRzIG5vcm1hbCBwcm90ZWN0aW9uDQoN Ck9uIFRodSwgTWF5IDI5LCAyMDE0IGF0IDE6MjggUE0sIEouIEdvbWV6IDxqZ29tZXpAc2VyeXJp Y2guY29tPG1haWx0bzpqZ29tZXpAc2VyeXJpY2guY29tPj4gd3JvdGU6DQo+IEkgZG9uJ3QgYmVs aWV2ZSBUUEEtTGFiZWwgaGl0cyB0aGUgbWFyayBiZXR3ZWVuICJzb2x2aW5nIGEgYmlnIGh1cnQi DQo+IGFuZCAic2ltcGxlIi4gIElPVywgaXQncyB0b28gY29tcGxpY2F0ZWQgZm9yIHRoZSBhbW91 bnQgb2YgcGFpbiBpdA0KPiB3b3VsZCByZXNvbHZlLiAgSnVzdCBteSBvcGluaW9uLCB0YWtlIGNh cmUsDQpJJ20gb2YgdGhlIHNhbWUgb3BpbmlvbiBhcyBhYm92ZS4NCg0KSW4gbXkgb3duIHdvcmRz LCBJIHdvdWxkIHNheSB0aGUgVFBBLWxhYmVsIGRyYWZ0IE90aXMgcG9zdGVkIHJlYWRzIGxpa2Ug cGVyZmVjdGx5IHBvbGlzaGVkIEtsaW5nb24gdG8gbWUuDQoNCklkIGVzdCwgb3Zlcmx5IHRvbyBj b21wbGV4IGZvciB2ZXJ5IGxpdHRsZSBnYWluLg0KDQorMS4NCi1NU0sNCg== --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8C6D7611MSGRTPCCRF2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24g VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJh bGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5r PWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5NeSBLbGluZ29uIG1heSBiZSBydXN0eSwgYnV0IEkg dGhpbmsgdGhhdCBtYWtlcyBpdCBhICs8aW1nIHdpZHRoPTEyIGhlaWdodD0yMCBpZD0iUGljdHVy ZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwMy5wbmdAMDFDRjdCNjcuMzJFNDE0RDAiIGFsdD0y PiAoYXBvbG9naWVzIGZvciB0aG9zZSBzZWVpbmcgdGhpcyBpbiB0ZXh0IGFzIEkgZG9u4oCZdCBo YXZlIEtsaW5nb24udHRmIG9uIG15IHdvcmsgbGFwdG9wKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6LjVpbic+ PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gZG1hcmMgW21haWx0bzpkbWFyYy1i b3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk11cnJheSBTLiBLdWNoZXJhd3k8 YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXkgMjksIDIwMTQgNToyMyBQTTxicj48Yj5Ubzo8 L2I+IEouIEdvbWV6PGJyPjxiPkNjOjwvYj4gZG1hcmNAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8 L2I+IFJlOiBbZG1hcmMtaWV0Zl0gU29sdXRpb24gZm9yIERNQVJDIGRpc3J1cHRpb24gb2Ygbm9y bWFsIGVtYWlsIHVzZSB3aGlsZSBzdGlsbCBvZmZlcmluZyBpdHMgbm9ybWFsIHByb3RlY3Rpb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tbGVm dDouNWluJz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHls ZT0nbWFyZ2luLWxlZnQ6LjVpbic+T24gVGh1LCBNYXkgMjksIDIwMTQgYXQgMToyOCBQTSwgSi4g R29tZXogJmx0OzxhIGhyZWY9Im1haWx0bzpqZ29tZXpAc2VyeXJpY2guY29tIiB0YXJnZXQ9Il9i bGFuayI+amdvbWV6QHNlcnlyaWNoLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxk aXY+PGRpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4nPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFy Z2luLWxlZnQ6LjVpbic+Jmd0OyBJIGRvbid0IGJlbGlldmUgVFBBLUxhYmVsIGhpdHMgdGhlIG1h cmsgYmV0d2VlbiAmcXVvdDtzb2x2aW5nIGEgYmlnIGh1cnQmcXVvdDs8YnI+Jmd0OyBhbmQgJnF1 b3Q7c2ltcGxlJnF1b3Q7LiAmbmJzcDtJT1csIGl0J3MgdG9vIGNvbXBsaWNhdGVkIGZvciB0aGUg YW1vdW50IG9mIHBhaW4gaXQ8YnI+Jmd0OyB3b3VsZCByZXNvbHZlLiAmbmJzcDtKdXN0IG15IG9w aW5pb24sIHRha2UgY2FyZSw8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPkknbSBvZiB0aGUgc2FtZSBvcGluaW9uIGFzIGFib3Zl Ljxicj48YnI+SW4gbXkgb3duIHdvcmRzLCBJIHdvdWxkIHNheSB0aGUgVFBBLWxhYmVsIGRyYWZ0 IE90aXMgcG9zdGVkIHJlYWRzIGxpa2UgcGVyZmVjdGx5IHBvbGlzaGVkIEtsaW5nb24gdG8gbWUu PGJyPjxicj5JZCBlc3QsIG92ZXJseSB0b28gY29tcGxleCBmb3IgdmVyeSBsaXR0bGUgZ2Fpbi48 bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEy LjBwdDttYXJnaW4tbGVmdDouNWluJz48YnI+KzEuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1sZWZ0Oi41aW4nPi1NU0sgPG86cD48L286 cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8C6D7611MSGRTPCCRF2_-- --_004_9495B91F5CA0E24C9161D71CD46E43DB011C8C6D7611MSGRTPCCRF2_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=576; creation-date="Thu, 29 May 2014 21:55:40 GMT"; modification-date="Thu, 29 May 2014 21:55:40 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAAwAAAAUCAYAAAC58NwRAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAHASURBVDjL Y2hsbGTAh3fv3q3j7e3d6OjouJSDg0MQq6L///+z19fX2ycmJm6WlJR8z8nJ+d/V1fXyokWLVLAp luzo6NijrKz8n5GR8b+IiMh/QUHBKJg8imIWFhZrY2PjG0JCQv8ZGBj+S0lJ/W9tbV0KNIQZQ4Oo qGg0MzPzV5BCEObh4fkvLi5eje4CMDF//vwATU1NsBOAmsAa/Pz8jiCbDNewefNmcTMzs1sgRTDF QP7/JUuWRGMLEBAQBimEYVZW1v+WlpYngabLY9UAJNqA7v0Lcg7IdGAw/u/u7t6CK14YJk6c2MTO zg7WAMLCwsI/Vq1alYVTA9BEYVVV1f9MTExgDcDQ+gMMhF6cGoBuFQ8NDb0JC06QkyZMmLAVpwYQ kZGR4ScvLw/WwMXF9V9LS2slXg0gDIykGAEBAbAmWVnZuz09PVp4NYCwj4/PJpAGYCD8z8rKWgt0 LjdeDTdv3tRLS0t7xs3N/d/d3f0/MGmL4NUAwnfv3lXj4+M7C7JJQUFhJdAWUbwaoNEvqK6ufgqU xFNTUzuAmhjxagDhU6dOOQCd9goUzC0tLbYENUBt0gbmtFMrVqyogIkBAJXmaT/ygk+dAAAAAElF TkSuQmCC --_004_9495B91F5CA0E24C9161D71CD46E43DB011C8C6D7611MSGRTPCCRF2_-- From nobody Thu May 29 15:49:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD5B1A6EEC; Thu, 29 May 2014 15:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mh1ijY_LqWD6; Thu, 29 May 2014 15:49:47 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC2A1A08BF; Thu, 29 May 2014 15:49:46 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id 29so924287yhl.5 for ; Thu, 29 May 2014 15:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1xkBuGC2guRr4OQfXGNB66u8a18IGZd+qzhrkzApDIs=; b=YM6pdFj3pw2yjd3LVFktaOiedbdzpfWUPDsVbd44D8Kej4pkS2Uw+cSjjXDxZ3+VHD YTIFB5KpzkUwjOJnZvYsBA6kHIst5UkNaX2MS269RpsdywoTpoPf2A2wNqQl4Cc7AjOL WMl6B5HjUbDr96zrCMcPV9u6CFROUYXe0czpbAYHVBWFNCnt5tMTmgq6jNSowg+4gUuX 9ocItoograeLHazQ3bU0Scakc/BiSbQLO1xG91NEu1Et7kNKiIaMUpS/l+2D52SZqi91 WCg4hp8xranJ2lgj6otAMIwjwhAcn2qUk0JwtlKLsd47nw7S2fMxEH/MrRwg3J22RLlj t3Fg== X-Received: by 10.236.23.163 with SMTP id v23mr14906789yhv.58.1401403782446; Thu, 29 May 2014 15:49:42 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id c66sm3105991yhk.23.2014.05.29.15.49.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 15:49:41 -0700 (PDT) Message-ID: <5387B95B.6040605@gmail.com> Date: Thu, 29 May 2014 15:48:59 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: ietf@ietf.org References: <20140529222156.25936.96244.idtracker@ietfa.amsl.com> In-Reply-To: <20140529222156.25936.96244.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_Le-QwUX4UT5uWJnj9aS25_7apw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New Non-WG Mailing List: Domain-based Message Authentication, Reporting, and Compliance (DMARC) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 22:49:48 -0000 Just so nobody gets excited, this announcement is because the entry for the mailing list was missing from the non-wg page and now it's been added: http://www.ietf.org/list/nonwg.html d/ On 5/29/2014 3:21 PM, IETF Secretariat wrote: > A new IETF non-working group email list has been created. > > List address: dmarc@ietf.org > Archive: http://www.ietf.org/mail-archive/web/dmarc/current/maillist.html > To subscribe: https://www.ietf.org/mailman/listinfo/dmarc > > Purpose: > > Summary Description: Discussion related to the development, clarification, and > implementation of the DMARC protocol, and operational uses of it. > > Detailed Description: Discussion related to the development, clarification, and > implementation of the DMARC protocol, and operational uses of it. > DMARC (Domain-based Message Authentication, Reporting, and Compliance) > is an overlay on top of email and some current authentication > protocols, which allows for limited policy enforcement and anomaly > reporting. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu May 29 15:57:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185791A04BA for ; Thu, 29 May 2014 15:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3-yH9cdSVm8 for ; Thu, 29 May 2014 15:57:08 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4061A0469 for ; Thu, 29 May 2014 15:57:07 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 30 May 2014 00:57:02 +0200 Message-ID: From: "J. Gomez" To: "Stephen J. Turnbull" References: <20140528163723.63860.qmail@joyce.lan> <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> <87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Fri, 30 May 2014 00:56: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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fFHPV5aQe609Q3uGCsikk_WHUWc Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 22:57:10 -0000 On Thursday, May 29, 2014 1:19 PM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > And we remain unhappy, not least because list operators are unhappy. > The configurations are somewhat tricky and not understood at all by > most list operators -- they follow recipes that are appropriate for > common cases, but may conflict with unusual settings. The requirement > by some mitigations that Mailman access the DNS in order to apply them > only to "p=3Dreject" posters (which is frequently mentioned by list > operators requesting help) introduces substantial additional > complexity. This is going to be an ongoing burden for the project, I > fear. Missuse of DMARC's p=3Dreject by Senders is here to stay. It won't go = away. It will only grow.[*] On the other hand, when hard pressed, [I think] email users are going to = choose to keep their mailbox/address over a mailing list subscription, = therefore mailing list software will have to adapt to the new theater of = operations -- provided DMARC gets deployed in the real world by some = significant measure, of course. In my opinion, the least disruptive adaptation which mailing list = software can do is to take ownership --in a DMARC-compatible way-- of = the Header-From, just like they already take ownership of the envelope's = ReturnPath-From. And, also in my opinion, that mailing list adaptation to DMARC should be = the new default out-of-the-box behaviour of mailing list packages from = now on, and the old behaviour should be regarded as legacy and = deprecated. Why? Because we cannot count on the average mailing list = operator to stop to ponder the fine points of "the DMARC issue" while he = is setting up his VPS server in a haste.[**] Therefore [in my opinion], = a sane, out-of-the-box DMARC-compatible behaviour should be the default = for mailing list software, from now on. [*][**] Because that's the way the world goes by. > We know one simple and guaranteed fix for the > problem, and it is trivial to implement: domains providing mailboxes > for personal use (including sending as a mailbox user of that domain > from a different one, transfers that modify Content-Transfer-Encoding, > mailing lists, use of on-behalf-of content distribution services, and > so on) should stop publishing DMARC policies with "p=3Dreject". There > appear to be two of them, they can do this in 5 minutes, and the > problem will be completely eliminated within a day or so. Yes, but it just won't happen. Once someone publishes p=3Dreject, if he = is "too-big-to-reject", then he is not going to go back to the previous = situation. He expects the world to accomodate him, and this is EXACTLY = what will happen if he just happens to be, by definition, = "too-big-to-reject". I think we should accept this as a fact, and move forward, and take the = neccesary "countermeasures" as the new by-default situation. > I've made the lists used by my students more secure (against denial of > service) by filtering "p=3Dreject" domains. As it happens, *all* of = my > users agree that is the appropriate solution for us (the Yahoo! users > didn't even think about fighting before switching, they already had > GMail addresses). Of course I hesitate to recommend that policy to > anybody else, but it *is* technically simple, and was the optimum > response in my case. That solution is good, but can only be expected from savvy mailing list = operators who fully understand the fine details of "the DMARC issue" -- = I think we cannot expect that to be the case for the vast majority of = mailing list operators world-wide. Also, the support costs of such a = solution are high (disgruntled users calling the help desk), and may = even be unbearable if the mailing list operator happens not to have a = more or less "captive" user base. Regards, J.Gomez From nobody Thu May 29 16:09:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5A01A06DF for ; Thu, 29 May 2014 16:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5dtcg5NzWG9 for ; Thu, 29 May 2014 16:09:07 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0D11A06B7 for ; Thu, 29 May 2014 16:09:07 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 20so896943yks.9 for ; Thu, 29 May 2014 16:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bfn5R41XMGNyQlVCgZjBzy2aNwOOQMPLA2b0/2h1p/0=; b=uuSnbTigsj2ZyGTit1371NocvMJUrGISRm0kBqQE5brPvqdtM5xH9XsqAQgYGNh2e6 Jh3+qsYNRTrUiA+HPbqbgt1+p6wS4wOK2lSXsztdkpZO4J2qHcTA96XCEHqiTEH0WYWX U2gCEfXk2lovfIe0/ee0z7zGOEPfAU3hQwGv8JMRzIvqGnThwI2OZs+7JYab+K87bLG2 6+MsXIhDZTjXg3dQJ5doeJQVn/SpFTyw5WyL+aZXgH7l4Q1HtW/S8u0Tuxu7/cIhPShP ohWidSOhUe/A3RsHz4ENrLLfOXZzQhjXHp0EpvRZXlQ48QHyixO3TpPkdNOy9zA2kYz4 LT8g== X-Received: by 10.236.2.165 with SMTP id 25mr14905295yhf.136.1401404943440; Thu, 29 May 2014 16:09:03 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id z67sm3160190yhk.50.2014.05.29.16.09.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 16:09:02 -0700 (PDT) Message-ID: <5387BDE4.2040208@gmail.com> Date: Thu, 29 May 2014 16:08:20 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140528163723.63860.qmail@joyce.lan> <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> <87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KB-_gLi8nt8GyKJgapo2qn0elII Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 23:09:11 -0000 On 5/29/2014 4:19 AM, Stephen J. Turnbull wrote: >Franck Martin writes: >> Time to stop these non-technical threads > > These threads are input to the BCP process, at the very least. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu May 29 16:27:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579DE1A0731 for ; Thu, 29 May 2014 16:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOXa9ZH0vwNH for ; Thu, 29 May 2014 16:27:11 -0700 (PDT) Received: from mail.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 32C251A6F11 for ; Thu, 29 May 2014 16:26:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5142; t=1401406007; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=wwwon0AZJpxC0vtLM2KXvl+gUrc=; b=hNbIIL/p8peJnF7TOEXZ 3FxURLgT/SOSKsS2zEJDBTeR/UZdu6CM3Dr+sOoaX3hPfYOi2sGTgx30+aVtwckI DzNj27KvI64bSRHBUMBhgfXd0iQWLMx+l8gEvGTp3DJDFixvlzzzNf9Nr9d8amNe vj3v1YBafUvVLNFQSjRRgOs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 29 May 2014 19:26:47 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 886142073.1.3316; Thu, 29 May 2014 19:26:46 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5142; t=1401405863; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5jDsygI 9hk3jMMrYBaXPvUwXEL5TmvXtHrgKAxDscGE=; b=Q98TWafo1fLjerTxgje+fw2 iAPFDFmENbyLW+KdQo4yl3eVQ/nhDARbRrQStqllAy/Y64fq5Yt+GAyT/PnrqGrV 2wXgUpUS1FiXyTbv2e0Jj0czGZmkLV0GxDzlUgaJlCEbhRFm0uHeCYonU3hiriu0 bSC4smqpCaFa9eGARrco= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 29 May 2014 19:24:23 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 902510375.9.3548; Thu, 29 May 2014 19:24:22 -0400 Message-ID: <5387C239.7030804@isdg.net> Date: Thu, 29 May 2014 19:26:49 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "J. Gomez" , dmarc@ietf.org References: <20140528163723.63860.qmail@joyce.lan> <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> <8F0A5BCBFFB046AF9F79C6E9772A253D@fgsr.local> In-Reply-To: <8F0A5BCBFFB046AF9F79C6E9772A253D@fgsr.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PKOMvbX393oseHcf2z54s4CQI4s Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 29 May 2014 23:27:16 -0000 On 5/29/2014 4:28 PM, J. Gomez wrote: > On Wednesday, May 28, 2014 10:13 PM [GMT+1=CET], Tim Draegen wrote: > >> I don't believe TPA-Label hits the mark between "solving a big hurt" >> and "simple". IOW, it's too complicated for the amount of pain it >> would resolve. Just my opinion, take care, > > I'm of the same opinion as above. > > In my own words, I would say the TPA-label draft Otis posted reads like perfectly polished Klingon to me. > > Id est, overly too complex for very little gain. > Mr. Gomez, TPA has a wider scope and an overly described functional specification. But the main idea should not be thrown away due to lack of fundamentally understanding the long time problem and proposed solutions. In its simplest terms, the idea is to lookup a 3rd party domain for authorization to sign or resign originating author domain mail. The earliest suggestions like in the 2006 DSAP proposal used an Allowed Signer List (ASL) "asl=" tag in the policy records. So applying this simpler idea to DMARC, an example policy for your domain, seryrich.com, might be _dmarc.seryrich.com TXT ("v=dmarc1; p=reject; asl=ietf.org; ...") This would expose to the world the policy that says: Only domains seryrich.com and ietf.org are authorized to sign mail for seryrich.com. If you see anything else, reject it. Simple idea. No extra lookup beyond the DMARC lookup. The problem with ASL is that it works for the shorter list domains. It would not scale for the larger domains, i.e. can't fit Yahoo's 30K potential authorization list. I think its an optimization idea for the majority of domains who are smaller than YAHOO. This is where Doug's TPA (Third Party Authorization) and Murray's simpler version of TPA called ATPS (Authorized Third Party Signer, RFC6541) comes into play. TPA and ATPS is basically the same when it comes to the lookup formula, which is to combine the signer domain as a subdomain zone of the author domain. I have implemented ATPS but its basically the same as TPA with a query formula of: BASE64(SHA1(signer-domain))+"."+author-domain So for you, your DMARC and ATPS subdomain records for seryrich.com zone would be: _dmarc TXT ("v=dmarc1; p=reject; atps=y;") PQ6XADOZSI47RLUIQ5YOHG2HY3MVJYOO._atps TXT ("v=atps01; d=ietf.org;") So the ideas has been worked out. The problem has been to get the IETF List Operators and Administrators to support this. So why not? Note, we also develop list software, so I have no problem doing what is necessary to get it all to work right. The main problem is that list operators prefer to use a TRUST model by looking up the signer domain. Not the author domain. They currently do neither, but they prefer to use the signer domain and this was the DKIM standard suggestion. Use the SIGNER domain. Forget about the author domain. Again, I am just looking for a total mail integrated solution between all parts. So lets go ahead and lookup the signer domain. What's the problem then? Well, what happens when any of these simple use cases occur: a) The signature does not exist in the message. Its missing. b) Signature exist, but it doesn't hash verify. Its broken. c) Signature exist and its valid, but its not your signature. Its some unknown signer that wants to tell the world its signing on your behalf. So the basic argument against depending on a signer domain only is that may not exist nor be valid. It can be completely fake. Now, Levine's VBR was a step in the right direction with the "combo" author and signer lookup but again, what happens when the signature is missing or invalid so that there is no signer domain to lookup? The trust advocates don't have an answer for these simple first level security issues that are easily detectable as failure. In summary, this has been examine all ways and the best and original idea was looking up the author domain because its the single identity that MUST exist in the message. It is the most important header of them all, the 5322.From header. This is the reason it is also the only header that MUST be hash bound to the signature. No other header is required to be hashed to the signature. But the resigners don't want to look it up. They want the freedom to resign mail. The policy advocates wants a more flexible 1st and 3rd party resigner framework, but one with options to lock down the 3rd party signers. I believe the latter is the more protocol strong solution. Its require more wider support and it will clamp down on the laissez-faire resigners who want to resign and don't wish to even check to see if its valid. Yes, there is the problem of the legacy users that has long used public, but also highly spam polluted big email brand domain. The Yahoos are not the only one who domains are polluted and they wish to finally take control and increase its security quality value. The IETF need to stop trying to make policy itself on what parts of the mail market it wishes to support. Its not just about resigners. Hope the above makes sense. -- HLS From nobody Thu May 29 17:06:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAD71A074C for ; Thu, 29 May 2014 17:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.618 X-Spam-Level: X-Spam-Status: No, score=-4.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpASK2dbbMRw for ; Thu, 29 May 2014 17:05:59 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75821A0744 for ; Thu, 29 May 2014 17:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1401408356; x=1432944356; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0AMlX6DN1zieueD/B1IUxu4228MfxcquQvW7cmcw2kc=; b=Qux460ulDwG7zyIZO4GQvI+pYI6n1dlvzkUWwsKlatoZ3y9pFf2mTWOw bpZ5k0x9pUJNrm8iU8R26zF21e+xgSZXIQNnb2uEeI2vnv1JuQfGkiLfk RpO0wVyOpUfHMuoewShhM9eYRcbVEHncOHPkHYRp8pOvwdDHkLn3xmVXX 0=; X-IronPort-AV: E=Sophos;i="4.98,937,1392192000"; d="scan'208";a="124456514" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.03.0174.001; Thu, 29 May 2014 17:05:42 -0700 From: Kurt Andersen To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection Thread-Index: AQHPeh92fMZ8nTUaFEyBU6cNhuDnE5tWCCqAgACfI4CAADyAgIABITqDgACnAID//5VugA== Date: Fri, 30 May 2014 00:05:42 +0000 Message-ID: References: <20140528163723.63860.qmail@joyce.lan> <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> <8F0A5BCBFFB046AF9F79C6E9772A253D@fgsr.local> <5387C239.7030804@isdg.net> In-Reply-To: <5387C239.7030804@isdg.net> 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: <91D36282908DB543AAAF6DD1AB98CCC6@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FlX9BJRB2-88OPRs1iiNIMgISqI Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 00:06:01 -0000 On 2014-05-29, 16:26 , "Hector Santos" wrote: >. . .the idea is to lookup a 3rd party domain for >authorization to sign or resign originating author domain mail. > >. . .The problem . . . is that . . . [i]t would not >scale for the larger domains I have to confess that I have not (yet) waded through the details of TPA or ASL or ATPS, but from a corporate perspective, it would be extremely unworkable for any but the smallest company to manage DNS records to whitelist every list server on the internet that my employees would happen to use. Even if I did, why would I want to give blanket permission for all of those list services to sign on my behalf? I doubt that I would trust them not to be exploited - even such a highly esteemed organization as IETF :-) --Kurt Andersen From nobody Thu May 29 17:20:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711FF1A0753 for ; Thu, 29 May 2014 17:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLxQ7YJaEOpf for ; Thu, 29 May 2014 17:20:42 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 598191A0765 for ; Thu, 29 May 2014 17:20:41 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9CB9E95605E; Thu, 29 May 2014 20:20:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401409236; bh=riS00VlqA6k7ZefrepAF0vXLkCRu+1/n+dYo0bLbkxc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=lzrVDApGNJz0NZiKbd6IafEOrYD1Hw31hOQIuwoq5TW4B4Gcbka/FdVbaixkUYwR9 Hzgbnf0qOHDw3Fs2rainNHB242y75kErMb1fU3xLSNBz8rkgnCNN5oUjIRqjdi+U5m 8+L+KscljtuKVEqcfBBlAtiPUFt+cHtUn3d5/htc= Received: from [IPV6:2600:1003:b116:680a:1072:c2bf:26eb:6cc7] (unknown [IPv6:2600:1003:b116:680a:1072:c2bf:26eb:6cc7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 41E9DD043F7; Thu, 29 May 2014 20:20:36 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 29 May 2014 20:20:29 -0400 To: "dmarc@ietf.org" Message-ID: <13580374-3220-451d-9623-44b108e32db0@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WUBfw53AtpPCcJi46wcDvwDTB4c Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 00:20:43 -0000 On May 29, 2014 3:09:44 AM EDT, "Murray S. Kucherawy" wrote: >On Thu, May 29, 2014 at 12:06 AM, John R Levine >wrote: > >> By the way, to return to the original point, it still seems >vanishingly >> unlikely to me that if we invented per-sender whitelists that the two >mail >> providers would implement them. >> > >Has anyone tried asking them? > >I'm not sure what value I should put in all this (ahem) third-party >speculation about their intentions or what they care about. I think Yahoo's communications have been very clear about what they care about. No speculation is needed. Scott K From nobody Thu May 29 20:11:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBF01A07DB for ; Thu, 29 May 2014 20:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlAwZRlbRrxW for ; Thu, 29 May 2014 20:11:36 -0700 (PDT) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 13D0F1A07BB for ; Thu, 29 May 2014 20:11:36 -0700 (PDT) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5/8.14.5) with ESMTP id s4U3BU6N005128 for ; Thu, 29 May 2014 20:11:31 -0700 Received: from vpn-135-70-100-132.vpn.swst.att.com ([135.70.100.132]) by maillennium.att.com (mailgw1) with ESMTP id <20140530031130gw100j0c2qe>; Fri, 30 May 2014 03:11:30 +0000 X-Originating-IP: [135.70.100.132] Message-ID: <5387F6E0.1070903@att.com> Date: Thu, 29 May 2014 23:11:28 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/o_AYlXetYByfOPerh6BSwe5kuCM Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 03:11:41 -0000 On 5/28/14, 6:46 PM, Barry Leiba wrote: > Anything that requires mailing list software to change won't work. I'm going to push back on this statement. I think we keep getting stuck on the mantra that "the mailing list software won't change". However, the majority of the mailing list software packages that are out there now DO generate proper List-* headers. It took some time, and it may not be 100% coverage, but by gosh and by golly, most of them do so and do it correctly. Why? There were a few things: 1) a well defined spec about what change was desired, AND 2a) there was perceived benefit to adding those headers, or 2b) there was perceived harm in not adding those headers. > If mailing list software is changed, the right answer is for the mailing > list to re-sign the message. I think this is exactly the correct solution for mailing lists to pursue. This is an excellent start of a spec for what mailing lists should be doing in a world where systems are using DKIM and SPF, and more systems are expecting such mail to pass validation. (A post-DMARC world, if you will.) There may be alternative solutions that are less optimal that will also get mailing list messages delivered more reliably. (For example, delete all DKIM signatures and force the From: header to use the originator's name in the comment but with the mailing list address instead of the originator's address. It works, but isn't pretty.) It might be worth doing some investigation of those alternatives, and showing their advantages and disadvantages. Mailing lists have an expectation of being able to get their mail delivered. That is no longer the case. The benefit of them making changes is that their messages will get delivered more reliably. The harm in not making changes is that their service will continue to be unreliable. But clear specs detailing what they CAN do and SHOULD do is the starting point. > That doesn't help the DMARC situation > now, but DMARC could be given other options once that happens. I agree completely that a change to DMARC is needed in conjunction with having clear ML specs. When HeartBleed came out recently, it was discovered that openssl had rather poor support, even though everyone and their neighbor seems to use it in some fashion or another. A consortium was then formed to provide some needed support and to improve the quality control for openssl. I've heard it said that the majority of the mailing lists out there are managed by only a handful of ML management systems. I maintain that these ML packages are in the same boat as openssl. It sure would be nice if we could get some of that consortium money thrown at that handful of ML management systems. That's a political solution for this current technical problem. However, before it can happen: we NEED clear specs as to what should be done by ML systems, at least in the face of DKIM and SPF (and DMARC) Tony Hansen From nobody Thu May 29 20:44:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94D21A02F9 for ; Thu, 29 May 2014 20:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLU8i-0vPYuv for ; Thu, 29 May 2014 20:44:20 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C7A1A02E8 for ; Thu, 29 May 2014 20:44:20 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 8F10DD04435; Thu, 29 May 2014 23:44:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401421455; bh=29s+h6itMMqcDNh9a3xrYQvTfwrQk1nGZ2420Fb6hk4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=tCi5pp+oS1JpD+SHHKLtc7wwGZlidxFKBWFAkKMbrPiOX6ZwC2vyjASO40NvogqGG 5pHVlEv4l5jGvKIzU3hTq0bflhvpQeVchPJYDs3oE40ye3SyNJqqjs2cYtoxbu7t4G qOwCp10p+baI+vOpl2OH0n2QrR/dC1WGPlvWxcPQ= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5C16CD04420; Thu, 29 May 2014 23:44:15 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 29 May 2014 23:44:14 -0400 Message-ID: <15749590.z7A0vHW603@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: <5387F6E0.1070903@att.com> References: <5387F6E0.1070903@att.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7OXo4RAaK3u8yB83TCeWbCb2GkM Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 03:44:21 -0000 On Thursday, May 29, 2014 23:11:28 Tony Hansen wrote: > On 5/28/14, 6:46 PM, Barry Leiba wrote: > > Anything that requires mailing list software to change won't work. > > I'm going to push back on this statement. I think we keep getting stuck > on the mantra that "the mailing list software won't change". However, > the majority of the mailing list software packages that are out there > now DO generate proper List-* headers. It took some time, and it may not > be 100% coverage, but by gosh and by golly, most of them do so and do it > correctly. > > Why? There were a few things: 1) a well defined spec about what change > was desired, AND 2a) there was perceived benefit to adding those > headers, or 2b) there was perceived harm in not adding those headers. > > > If mailing list software is changed, the right answer is for the mailing > > list to re-sign the message. > > I think this is exactly the correct solution for mailing lists to > pursue. This is an excellent start of a spec for what mailing lists > should be doing in a world where systems are using DKIM and SPF, and > more systems are expecting such mail to pass validation. (A post-DMARC > world, if you will.) > > There may be alternative solutions that are less optimal that will also > get mailing list messages delivered more reliably. (For example, delete > all DKIM signatures and force the From: header to use the originator's > name in the comment but with the mailing list address instead of the > originator's address. It works, but isn't pretty.) It might be worth > doing some investigation of those alternatives, and showing their > advantages and disadvantages. > > Mailing lists have an expectation of being able to get their mail > delivered. That is no longer the case. The benefit of them making > changes is that their messages will get delivered more reliably. The > harm in not making changes is that their service will continue to be > unreliable. > > But clear specs detailing what they CAN do and SHOULD do is the starting > point. > > > That doesn't help the DMARC situation > > now, but DMARC could be given other options once that happens. > > I agree completely that a change to DMARC is needed in conjunction with > having clear ML specs. > > > When HeartBleed came out recently, it was discovered that openssl had > rather poor support, even though everyone and their neighbor seems to > use it in some fashion or another. A consortium was then formed to > provide some needed support and to improve the quality control for openssl. > > I've heard it said that the majority of the mailing lists out there are > managed by only a handful of ML management systems. I maintain that > these ML packages are in the same boat as openssl. It sure would be nice > if we could get some of that consortium money thrown at that handful of > ML management systems. That's a political solution for this current > technical problem. > > However, before it can happen: we NEED clear specs as to what should be > done by ML systems, at least in the face of DKIM and SPF (and DMARC) The reason there is no IETF working group is that the people behind DMARC were unwilling to entertain participation in a working group that had a charter that allowed for any chance of a change to the DMARC protocol. DMARC change is even more off the table than MLM software change (which does, as you suggest, evolve over time). Yahoo's view, based on their public statements clearly seems to me to be that using DMARC p=reject is beneficial to them and they are big enough that 3rd parties will adapt rather than suffer the consequences of not adapting. I believe they are right on both counts. Mailing lists and other related systems that are affected by this are adapting. It's painful and the solutions inevitably involve regressions in functionality, but they are one of the few 800 pound gorillas and they can get away with it. I am entirely sympathetic to people that are unhappy about this state of affairs (I'm unhappy about it too), but it is what it is. I wrote the other day asking what IETF work is there around DMARC and didn't get much of an answer. I think that's instructive. I'm increasingly convinced that there isn't any. At this point, while there's value in a central point for operators and developers to exchange information about how to mitigate the damage caused by what is in my opinion irresponsible use of DMARC, I don't think there is anything to standardize. Eventually, there's probably a BCP in this, but it's premature. If the IETF tries to go off and write a BCP on DMARC work arounds now, we'll end up looking silly by the time the metaphorical ink is dry. We've all got lots of ideas on practices that would be a good idea, but many of them are new enough they can only barely be described as current and knowing what among them is best is premature. Scott K From nobody Thu May 29 23:19:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4E71A070F for ; Thu, 29 May 2014 23:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEeYcxBnn78R for ; Thu, 29 May 2014 23:19:23 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567021A06EE for ; Thu, 29 May 2014 23:19:23 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rd3so1361140pab.1 for ; Thu, 29 May 2014 23:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tUqL6hlNXPWZRZ2ao5JENMOPMZIFvcnIRv5CB1puDis=; b=FcIEdOkUUlprlI7/akZfrciScwR2djGRvyzWxO9LUxRl7GB3zZgNf3U18nExs/wrWe SCdKUG+xiqS5zkdswD4dja4B7O/Cw5aYXESQLBCyaYoEOD9ACn8b5CF1plSS/OVzaTlW DoCgJShDuiBSdiZAEuoTPVw54Mf0bcRVBNY5itlVQ1hZSDkQbeNOd4XWMm8esz62HN0E cbjisDVXomsTCysI38xxQNtPaT+lltA4uBx+Vz/QODrWIo7d+l7jFiRTfCgaM3Cs+Huu oe27x6ZdyXQXmR7wbOJcLL0Ze2jlV9WAB4hj0Hg2XIZ1JSXLP1Rbx+fuTCCq/YEY+2z5 hHyw== X-Received: by 10.68.164.4 with SMTP id ym4mr15384856pbb.53.1401430759176; Thu, 29 May 2014 23:19:19 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id wp3sm4414496pbc.67.2014.05.29.23.19.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 23:19:18 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DF18019E-D3C1-4FD3-88A4-B9D49F7054D4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <5387F6E0.1070903@att.com> Date: Thu, 29 May 2014 23:19:17 -0700 Message-Id: <65FB0025-C14C-4DDD-BC89-CE8EB21E63D9@gmail.com> References: <5387F6E0.1070903@att.com> To: Tony Hansen X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oxl7oMzQNY5v9ExoEOraMf8uS9I Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 06:19:26 -0000 --Apple-Mail=_DF18019E-D3C1-4FD3-88A4-B9D49F7054D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Tony, See comments inline: On May 29, 2014, at 8:11 PM, Tony Hansen wrote: > On 5/28/14, 6:46 PM, Barry Leiba wrote: >> Anything that requires mailing list software to change won't work.=20 >=20 > I'm going to push back on this statement. I think we keep getting = stuck on the mantra that "the mailing list software won't change". = However, the majority of the mailing list software packages that are out = there now DO generate proper List-* headers. It took some time, and it = may not be 100% coverage, but by gosh and by golly, most of them do so = and do it correctly. I agree with Barry. It is not just getting tens of thousands of = mailing-lists updated into something that offers what is surely going to = be a substandard user interface. This also means ensuring the added list = headers allow selecting a particular participant in a straight forward = manner. And that this selection also operates in conjunction with MUAs. = There is a sizable variation in this regard, many of which will not = facilitate this ability. =20 The next question that needs to be considered is the timeframe for such = migration. How many years is reasonable? Secondly, what can be done to help facilitate various informal services = to permit them to be effective at acting on behalf of their clients = while still ensuring the =46rom header field contains an identity the = eventual recipient will recognize? It seems that in order to be able to = do this, a way to make exceptions for Sender header fields is needed as = well. If making exceptions for Sender header fields can be accommodated, = then simply make this exception for List-ID headers too. Any effort at arranging domain alignments will be shuffling around where = people must look to understand who substantially originated the content. = Keeping these changes to a minimum would be ideal. After all, these = changes will create a fair amount of confusion for recipients, where = they then become vulnerable to a whole new range of deceptions. As it = is now, most have already begun to ignore DMARC assertions placed = against user accounts which then degrades even modest protections this = may have initially offered. Perhaps you might also consider:=20 = https://community.intuit.com/questions/899989-please-make-quickbooks-pass-= the-dmarc-evaluation-please-do-this-quickly I know of several other professional services sending email on behalf of = their clients. It seems these situations also run afoul of this rather = simplistic DMARC approach.=20 > Why? There were a few things: 1) a well defined spec about what change = was desired, AND 2a) there was perceived benefit to adding those = headers, or 2b) there was perceived harm in not adding those headers. Hmmm. Perhaps we could call this new header "Sender". ;^) >> If mailing list software is changed, the right answer is for the = mailing >> list to re-sign the message. >=20 > I think this is exactly the correct solution for mailing lists to = pursue. This is an excellent start of a spec for what mailing lists = should be doing in a world where systems are using DKIM and SPF, and = more systems are expecting such mail to pass validation. (A post-DMARC = world, if you will.) How many people have problems with mailing-lists? After all, = problematic lists fade away rather quickly.=20 The real issue was caused by millions of users accounts being = compromised. The providers that even played a small role in that = problem should contribute to what should also be an expedient solution.=20= The described changes to lists and many many other services will never = offer an expedient solution for several very difficult and important = reasons. Mailing-lists have not caused this problem, and yet the same = ESPs are expecting mailing-lists and the like to handle a major portion = of the change. This change is to permit =46rom header field alignment = with the source or a replay-able signed message fragment. This rather = dramatic change moves email a large distance into becoming a far less = versatile peer-to-peer protocol. Perhaps it would be simpler to move = SMTP to historic and adopt use of XMPP instead? After all, that service = already offers the concept of federated services and does not offer any = mailing list feature at this time. After all, it is hard to get ad = impressions shipping around signed messages. ;^P > There may be alternative solutions that are less optimal that will = also get mailing list messages delivered more reliably. (For example, = delete all DKIM signatures and force the From: header to use the = originator's name in the comment but with the mailing list address = instead of the originator's address. It works, but isn't pretty.) It = might be worth doing some investigation of those alternatives, and = showing their advantages and disadvantages. I have setup and run systems that tracked email from several very large = ISPs of all used IPv4 addresses. Taking in the entire inbound traffic = and comparing it to what was hitting various spam-traps was done on a = moderate server producing updates for the entire dataset in less than 15 = minutes (often in less than 5). While this was all done using mostly C = code, it was rather small and extremely efficient. Even so, this could = have been done much more efficiently for domains using Judy techniques, = instead of IP addresses, especially IPv6 addresses. In addition, = today's servers have become much faster. A good guess would be = corrective information can be produced using two DNS servers in = conjunction with two log aggregation servers. The use of two is for = redundancy. DNS offers low latency and very good edge caching. Doing this by domain makes the problem much easier. Even then, the = actual domain alignment problems only comprise a very small sub-portion = of the email stream. The systems needed to manage this would also be = fairly small, nor would this require operators to learn a new language. = :^) The sender information necessary to overcome difficulties would be = deployed by the same entities demanding that email be handled = differently. This only seems fair. There are some very real benefits by handling the problem in this = manner. This requires senders to actually monitor their DMARC and user = web portal feedback. Gasp. At least their support staff would have fewer = angry complaints. After doing this, they'll discover two important = pieces of information that receivers are unable to divine. Which = sources represent rogue servers, and which appear to be legitimately = handling their users messages. What is left and is still hitting their = spam traps are likely compromised customers. This would offer their = customers better protection from spoofing permitted by loss of account = credentials and exposed messages and contact lists. Don't think for one = minute authorizing responsible domains means this will permit a torrent = of abuse. The effected domain is still able to just their authorization = and shut done a source in minutes.=20 > Mailing lists have an expectation of being able to get their mail = delivered. That is no longer the case. The benefit of them making = changes is that their messages will get delivered more reliably. The = harm in not making changes is that their service will continue to be = unreliable. >=20 > But clear specs detailing what they CAN do and SHOULD do is the = starting point. >=20 >> That doesn't help the DMARC situation >> now, but DMARC could be given other options once that happens. >=20 > I agree completely that a change to DMARC is needed in conjunction = with having clear ML specs. May I recommend: http://tools.ietf.org/html/draft-otis-tpa-label Saying that it would be too hard is simply being lazy. It can also be = implemented fairly quickly, as this impacts those actually wanting this = change. Regards, Douglas Otis= --Apple-Mail=_DF18019E-D3C1-4FD3-88A4-B9D49F7054D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Dear = Tony,

See comments inline:
On = May 29, 2014, at 8:11 PM, Tony Hansen <tony@att.com> wrote:

On = 5/28/14, 6:46 PM, Barry Leiba wrote:
Anything= that requires mailing list software to change won't work. =

I'm going to push back on this statement. I think = we keep getting stuck on the mantra that "the mailing list software = won't change". However, the majority of the mailing list software = packages that are out there now DO generate proper List-* headers. It = took some time, and it may not be 100% coverage, but by gosh and by = golly, most of them do so and do it = correctly.

I agree with Barry. =  It is not just getting tens of thousands of mailing-lists updated = into something that offers what is surely going to be a substandard user = interface. This also means ensuring the added list headers allow = selecting a particular participant in a straight forward manner. And = that this selection also operates in conjunction with MUAs.  There = is a sizable variation in this regard, many of which will not facilitate = this ability.  

The next question that = needs to be considered is the timeframe for such migration.  How = many years is reasonable?

Secondly, what can be = done to help facilitate various informal services to permit them to be = effective at acting on behalf of their clients while still ensuring the = =46rom header field contains an identity the eventual recipient will = recognize?  It seems that in order to be able to do this, a way to = make exceptions for Sender header fields is needed as well. If making = exceptions for Sender header fields can be accommodated, then simply = make this exception for List-ID headers = too.

Any effort at arranging domain alignments = will be shuffling around where people must look to understand who = substantially originated the content.  Keeping these changes to a = minimum would be ideal.  After all, these changes will create a = fair amount of confusion for recipients, where they then become = vulnerable to a whole new range of deceptions.  As it is now, most = have already begun to ignore DMARC assertions placed against user = accounts which then degrades even modest protections this may have = initially offered.

Perhaps you might also = consider: 

I know of several = other professional services sending email on behalf of their clients. =  It seems these situations also run afoul of this rather simplistic = DMARC approach. 

Why? = There were a few things: 1) a well defined spec about what change was = desired, AND 2a) there was perceived benefit to adding those headers, or = 2b) there was perceived harm in not adding those = headers.

Hmmm. Perhaps we could call = this new header "Sender". ;^)

If mailing list software is = changed, the right answer is for the mailing
list to re-sign the = message.

I think this is exactly the correct = solution for mailing lists to pursue. This is an excellent start of a = spec for what mailing lists should be doing in a world where systems are = using DKIM and SPF, and more systems are expecting such mail to pass = validation. (A post-DMARC world, if you = will.)

How many people have problems = with mailing-lists?  After all, problematic lists fade away rather = quickly. 

The real issue was caused by = millions of users accounts being compromised.  The providers that = even played a small role in that problem should contribute to what = should also be an expedient solution. 

The = described changes to lists and many many other services will never offer = an expedient solution for several very difficult and important reasons. =  Mailing-lists have not caused this problem, and yet the same ESPs = are expecting mailing-lists and the like to handle a major portion of = the change. This change is to permit =46rom header field alignment with = the source or a replay-able signed message fragment. This rather = dramatic change moves email a large distance into becoming a far less = versatile peer-to-peer protocol.  Perhaps it would be simpler to = move SMTP to historic and adopt use of XMPP instead?  After all, = that service already offers the concept of federated services and does = not offer any mailing list feature at this time.  After all, it is = hard to get ad impressions shipping around signed messages. =  ;^P

There may be = alternative solutions that are less optimal that will also get mailing = list messages delivered more reliably. (For example, delete all DKIM = signatures and force the From: header to use the originator's name in = the comment but with the mailing list address instead of the = originator's address. It works, but isn't pretty.) It might be worth = doing some investigation of those alternatives, and showing their = advantages and disadvantages.

I have = setup and run systems that tracked email from several very large ISPs of = all used IPv4 addresses.  Taking in the entire inbound traffic and = comparing it to what was hitting various spam-traps was done on a = moderate server producing updates for the entire dataset in less than 15 = minutes (often in less than 5). While this was all done using mostly C = code, it was rather small and extremely efficient.  Even so, this = could have been done much more efficiently for domains using Judy = techniques, instead of IP addresses, especially IPv6 addresses.  In = addition, today's servers have become much faster.  A good guess = would be corrective information can be produced using two DNS servers in = conjunction with two log aggregation servers.  The use of two is = for redundancy.  DNS offers low latency and very good edge = caching.

Doing this by domain makes the problem = much easier.  Even then, the actual domain alignment problems only = comprise a very small sub-portion of the email stream. The systems = needed to manage this would also be fairly small, nor would this require = operators to learn a new language. :^)

The = sender information necessary to overcome difficulties would be deployed = by the same entities demanding that email be handled differently. =  This only seems fair.

There are some very = real benefits by handling the problem in this manner.  This = requires senders to actually monitor their DMARC and user web portal = feedback. Gasp. At least their support staff would have fewer angry = complaints.  After doing this, they'll discover two important = pieces of information that receivers are unable to divine.  Which = sources represent rogue servers, and which appear to be legitimately = handling their users messages.  What is left and is still hitting = their spam traps are likely compromised customers.  This would = offer their customers better protection from spoofing permitted by loss = of account credentials and exposed messages and contact lists. =  Don't think for one minute authorizing responsible domains means = this will permit a torrent of abuse.  The effected domain is still = able to just their authorization and shut done a source in = minutes. 

Mailing = lists have an expectation of being able to get their mail delivered. = That is no longer the case. The benefit of them making changes is that = their messages will get delivered more reliably. The harm in not making = changes is that their service will continue to be unreliable.

But = clear specs detailing what they CAN do and SHOULD do is the starting = point.

That doesn't help the DMARC = situation
now, but DMARC could be given other options once that = happens.

I agree completely that a change to DMARC = is needed in conjunction with having clear ML = specs.

May I recommend:

Saying that = it would be too hard is simply being lazy.  It can also be = implemented fairly quickly, as this impacts those actually wanting this = change.

Regards,
Douglas = Otis
= --Apple-Mail=_DF18019E-D3C1-4FD3-88A4-B9D49F7054D4-- From nobody Thu May 29 23:39:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0571F1A02B0 for ; Thu, 29 May 2014 23:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X_ruiXdFUm3m for ; Thu, 29 May 2014 23:39:10 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC50D1A083B for ; Thu, 29 May 2014 23:39:09 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id p10so620394pdj.35 for ; Thu, 29 May 2014 23:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Dt4e/23LUIRSTU5Xf5rVNrM8yTYlKnV4JyderDFmHd0=; b=D5Yt6XvVIm96u142p57cLz77MOOT9/eg0nWQKp4Ljime3tJa2JD/CAteXKZju9ujtW TMVbRRrav41Kgbr46Gfczbd6IbM0ap3aPLhdgZqa1Y9eeXcBOw0ASJDMrCAM895ouvJn OIWk603X7/AA0DRUyPfJRnDfDrxVtRchYkexfZX++MTjdFDuNEljVS4dMEggFsybL7ft MxTagUVDK0h9QHIy5zz9ZBUEQimghU7V2OFBml1Z4/P7oy0D6j+Piy9hSlNPvf0pmnfR 1Fv4LPnB473/h2+C29JZb7zJSlxW2QciBaVR9T2nqeBRABVmZzZnXuRcttWZXLNXJFkf lPCA== X-Received: by 10.66.120.201 with SMTP id le9mr15594588pab.98.1401431945817; Thu, 29 May 2014 23:39:05 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id aj10sm13946818pac.43.2014.05.29.23.39.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 23:39:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Thu, 29 May 2014 23:39:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140528163723.63860.qmail@joyce.lan> <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> <8F0A5BCBFFB046AF9F79C6E9772A253D@fgsr.local> <5387C239.7030804@isdg.net> To: Kurt Andersen X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WXJZw1_M-ViogmfQC_n3mx1BBJw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 06:39:14 -0000 On May 29, 2014, at 5:05 PM, Kurt Andersen = wrote: > On 2014-05-29, 16:26 , "Hector Santos" wrote: >=20 >> . . .the idea is to lookup a 3rd party domain for >> authorization to sign or resign originating author domain mail. >>=20 >> . . .The problem . . . is that . . . [i]t would not >> scale for the larger domains >=20 > I have to confess that I have not (yet) waded through the details of = TPA > or ASL or ATPS, but from a corporate perspective, it would be = extremely > unworkable for any but the smallest company to manage DNS records to > whitelist every list server on the internet that my employees would = happen > to use. >=20 > Even if I did, why would I want to give blanket permission for all of > those list services to sign on my behalf? I doubt that I would trust = them > not to be exploited - even such a highly esteemed organization as IETF = :-) Dear Kurt, There seems to be some confusion about how TPA-Labels would operate. It = is an Authorization scheme. At no time would any other domain be able = to sign on your behalf. It simply permits specific alignment exceptions = regarding both domains and headers for those domains your company allows = employees to use. This could also be setup to automatically authorize = mailing-lists used by your industry, and all outsourced services without = exchanging any credentials or granting network access. I doubt any = company executive will today blithely exchange credentials to permit an = HVAC firm to submit invoices. By requiring a Sender header field, Outlook will modify what is seen on = the =46rom header to say Intuit.com on behalf of Linkin.com when sending = out invoices on your behalf. Recipients should not have a hard time = understanding who both signed and sent the message. Most MUAs will even = allow you to normally display the Sender header when it is there. Would = this be a major issue for Linkedin? At least there would be a far = greater certainty rogue messages will continue to be rejected as = desired. Regards, Douglas Otis From nobody Fri May 30 00:37:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB2B1A08A3 for ; Fri, 30 May 2014 00:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzRWOLqxig15 for ; Fri, 30 May 2014 00:37:34 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EB91A037E for ; Fri, 30 May 2014 00:37:33 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id k14so1505212wgh.31 for ; Fri, 30 May 2014 00:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tV5MSufN6OZtINj0kDZua28z+TGhAew3MyZ++Idc+N0=; b=WE2qlJilLqwFNMtQqYK/t+u5mBC6QPFn/Hb9uGHh0nKHCipV9WfCP4IGi0+uX9qbzj HEA+GEjckR6/f6lio9esZyc3AcAhl3c1br0vWKSX0WfuXk8/pXl3ayR08FODXRRd3K+T X0edOwq8UUYRDF79zhOo4SuFHbGjYEev/1sTsdKfgY4YbRJjJC8wC/XRYeXovF17rTSk b9z9xkLfcHuGusL2h3wBPyRmWLcqXotVVyeWk0zfIevYGT4xABnmrzvhxe0XbuvR7tnm dduoKJvbBMfmSgltZzjOdTfl9erCayncUeEBI+Gyhrx0yQw3lMo5put5hHsKLRgoQGqO xZaQ== MIME-Version: 1.0 X-Received: by 10.180.75.102 with SMTP id b6mr4047812wiw.26.1401435448759; Fri, 30 May 2014 00:37:28 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Fri, 30 May 2014 00:37:28 -0700 (PDT) In-Reply-To: <15749590.z7A0vHW603@scott-latitude-e6320> References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> Date: Fri, 30 May 2014 00:37:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04389155195b1704fa991ec0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vfHH3KEcFABi2Bcvv6Its-T9XhY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 07:37:36 -0000 --f46d04389155195b1704fa991ec0 Content-Type: text/plain; charset=UTF-8 On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman wrote: > The reason there is no IETF working group is that the people behind DMARC > were > unwilling to entertain participation in a working group that had a charter > that allowed for any chance of a change to the DMARC protocol. > I think that's a bit hyperbolic. There was perhaps too much emphasis on protecting the deployed base, but had they been confronted with actual data about something that wouldn't work (rather than the typical theory-only assertions on which working groups like to rathole), there would have been ample justification for a change. > DMARC change is even more off the table than MLM software change (which > does, > as you suggest, evolve over time). > Are there changes people want to make? So far all I've seen is "something needs to change", but nothing concrete, or at least nothing that has garnered consensus of some sort. > I wrote the other day asking what IETF work is there around DMARC and > didn't > get much of an answer. I think that's instructive. I think that conclusion is premature. -MSK --f46d04389155195b1704fa991ec0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
The = reason there is no IETF working group is that the people behind DMARC were<= br>
unwilling to entertain participation in a working group that had a charter<= br> that allowed for any chance of a change to the DMARC protocol.

I think that's a bit hyperbolic.=C2=A0 There wa= s perhaps too much emphasis on protecting the deployed base, but had they b= een confronted with actual data about something that wouldn't work (rat= her than the typical theory-only assertions on which working groups like to= rathole), there would have been ample justification for a change.
=C2=A0
DMARC change is even more off the table than MLM software change (which doe= s,
as you suggest, evolve over time).

Are = there changes people want to make?=C2=A0 So far all I've seen is "= something needs to change", but nothing concrete, or at least nothing = that has garnered consensus of some sort.
=C2=A0
I wrote the other day asking what IETF work is there around DMARC and didn&= #39;t
get much of an answer. =C2=A0I think that's instructive.

I think that conclusion is premature.

-MSK
--f46d04389155195b1704fa991ec0-- From nobody Fri May 30 01:05:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468951A6F07 for ; Fri, 30 May 2014 01:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS6g2V9g15ao for ; Fri, 30 May 2014 01:05:13 -0700 (PDT) Received: from nm34.bullet.mail.ne1.yahoo.com (nm34.bullet.mail.ne1.yahoo.com [98.138.229.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595D01A6EFB for ; Fri, 30 May 2014 01:05:13 -0700 (PDT) Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 30 May 2014 08:05:08 -0000 Received: from [98.138.226.177] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 30 May 2014 08:02:08 -0000 Received: from [216.39.60.184] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 30 May 2014 08:02:05 -0000 Received: from [98.137.12.194] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 08:02:05 -0000 Received: from [127.0.0.1] by omp1002.mail.gq1.yahoo.com with NNFMP; 30 May 2014 08:02:05 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 697720.58124.bm@omp1002.mail.gq1.yahoo.com Received: (qmail 16532 invoked by uid 60001); 30 May 2014 08:02:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401436925; bh=MyVIzrs8vENganGpP/ssXweOYvpqgXLgzwpj85aq5gQ=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=myY3wcjqmOpG2b3n+3Iv2HbCPhnxP5GQKnRfbzmEMftye2JFi73o978KQjX2s6ICP9o1D5hfIDX7TX7ev6oYFQyctn+b7PF+KHgJfGQxc3dyboXAoWP0AsaSeYIHsX4sLQdkG8YZEwLa5ZYwPGLuPrjurY4dXKNUlFhlgsJzevI= X-YMail-OSG: Mv2RsbcVM1lH.eXNjtGKQ1bKBZxoKO9ktSz19o1f.PFhpA3 ymd1QZVMkO7_.VO8pOXFJQafUwqcwB9EDxFeLStX8uVg2nlaXgsL6GcBq5s1 A6jvxHR5ako9a4KAPjHsIFZDpkRXSi3lRRKaehaywAsv5nAQKq2d1xHfmMBv JSRee.MrWjFlUBC0XXUSkDUhNw7IWPZopydjWSGdRSeVhjoMCJbhqkj9TtWd EXOkiAiUIxlzFSKvBcJEueUxGK1hCtoZn3MklHu4guYNhseXnTxb0E_OP4mP iZQAbKfi0VxNhes6J6y8WIJ.zJJnSjQ02qyh5DM8r.7ZzmSNLsMAg5Nz5eHh xKART_au9GjbZFaNlTR9EO2M6ex9zbwARfmUijJfFxmlnEpklouPS.OurPN5 lsWYwPEXoRlBgb7eC4aEtFesTd9KEYpFyaQehfl.4GApVzXbaOSNWy9kzPLH vQQoFJQJV37C_4OorMIhq7Vt6CVliVVXHdk1Jg.XhrwGaxOQUxhiP_Sipyez hXI_rPRrFvyPsnru7OPuz7_7OUvAu_29_wyMMBL_jfx8iffoYjh7F6IbUSrb te_P4g7EJthwSA.Bwjsuzef1QiYSr8PWlglNrpoyVzytOb7IB2Eb112psTdA - Received: from [77.105.26.220] by web164603.mail.gq1.yahoo.com via HTTP; Fri, 30 May 2014 01:02:05 PDT X-Rocket-MIMEInfo: 002.001, PiBUaHVzLCBJIGFtIHJlbWluZGluZyBhbGwgb2YgeW91IG9mIHlvdXIgb2JsaWdhdGlvbiB0byBrZWVwCj4gdGhpcyBkaXNjdXNzaW9uIHByb2Zlc3Npb25hbCwgb24gdG9waWMsIHJlc3BlY3RmdWwsIGFuZCBmcmllbmRseS4KCgppIGRvIG5vdCBzZWUgaG93IHRoaXMgaXMgYXQgYWxsIHBvc3NpYmxlLCB3aGVuIGEgcHJldHR5IGRldmVsb3BlZApzb2x1dGlvbiBpcyByaWRpY3VsZWQgYXMgYSBLbGluZ29uLXNwZWVjaCwgbm90IGJ5IG9ubHkgZmV3IG9mCnBhcnRpY2lwYW50cywgYnV0IHRoZSB2ZXJ5IHNhbWUBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.188.663 Message-ID: <1401436925.52759.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Fri, 30 May 2014 01:02:05 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/K_KqB3QgYcFuNn8dcf9PU5Yf0Eo Subject: Re: [dmarc-ietf] Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 08:05:15 -0000 > Thus, I am reminding all of you of your obligation to keep > this discussion professional, on topic, respectful, and friendly. i do not see how this is at all possible, when a pretty developed solution is ridiculed as a Klingon-speech, not by only few of participants, but the very same administrator of this mailing list. let's call it irony. for what it's worth, both Hector's and Douglas' solutions to, more than obvious DMARC problem, work fine for solving issues with case-scenarios i have in my environment. thanks for working on those, guys. yes, you do need much wider support, if this is gonna take off, and i hope some of the more influential speakers here will provide it [looking to ML developers]. in the end, imo, DMARC policy model, if not bug-fixed, which seems all too much probable as whole DMARC establishment doesn't care, will justdie off and become irrelevant, fading with smoke of false-positivesit generates, as no sane service will respect "reject" policy whose legitimacy is fluid, saving themselves from wrath of both end-senders and end-receivers. and world will choose to keep email functional as it is, instead of breaking it with some ill-developed rigid standard forinternet of parallel universe. at least we will have DMARC reporting... and possibly some ground for building a better protocol in the future. cause, this one is simply not working properly. since as much is obvious to a small guy like myself, it should be obvious to any speaker of a Federation of Planets specie that doesn't speak Klingon very well. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri May 30 01:13:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5D61A079E for ; Fri, 30 May 2014 01:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M9DO1yp6D9b for ; Fri, 30 May 2014 01:13:11 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADE11A00AA for ; Fri, 30 May 2014 01:13:11 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id tp5so1441193ieb.11 for ; Fri, 30 May 2014 01:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4jTWMps64bANutrwrPtkvCLebzHGJ3zHVHRZRV/mylI=; b=Imk3QohqjQ1EQRkOUN1WKB0pXjX0KM8rrxbtRCGLSwXsJYqakbArLJqqDQ51Dp3p+U Vkgb7NOSOz5Zr0gY9zItsTdUlO/inQ7Y9E6q7S5aEaYH4RO9Ijm/rps+84fp8Ya2oU+S 3Rp95wogfkAAZSDWoHVkotoEAag9H/d1zbqZa6GeomjVyi7epy5mkLeotHcuHdJ5S4hC dNnoFNopfYOUkD1xJl5OnNez1h7yJ2Pk5HJKogjl2xkn6JH2clLs3GXsN7isk8xdUUpx RqGBHwRM/3y1aSuotetEnIO2C9AK8wluT0mFbjQB8lql6QCvzoq6TsOQwvNjEDIeyuAn Z/qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=4jTWMps64bANutrwrPtkvCLebzHGJ3zHVHRZRV/mylI=; b=I2GAgDFa3vxIxw2V5uAU8nkqxxZuhZrMTA430+Ydn19q15KwF9B/EfCiWvc4MVPgr2 9MVDU2nbfchLq0GQlzofdyT74xHimovgpWgrpa/U7bHrh5644R3E7B3v+pdceW9WHFzr nDIqV6juwU7D9yKARMsbdZFGFq+tCkL7t/UGVRvV7YJHffaSh/7jHJAX2wM3tqlVgG/G YNnbj/vTw4feT8xrgALg+1Zls/YBj2Q5cMk1Cu62XCTW+dUnqC6SsRAVJbYVz7eF79w1 /Nudep10QpdA5CGEeYgN+42dVstK4YYtZa+P9ocsB/eC6c2LWmN5C5Zew98KX/VwAI43 ODaQ== X-Gm-Message-State: ALoCoQlJ72WGjqOpm12uFYm91AVZtgwBC6kLGNzTmXU/Cs3jVhbDuFAD9RtEXCC2QiIGcA7mK/q1 MIME-Version: 1.0 X-Received: by 10.50.43.201 with SMTP id y9mr3482955igl.12.1401437587261; Fri, 30 May 2014 01:13:07 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Fri, 30 May 2014 01:13:07 -0700 (PDT) Date: Fri, 30 May 2014 01:13:07 -0700 Message-ID: From: Brandon Long To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=089e011825c0906b5704fa999dd9 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZrQfl0bcexMUxNkilFcuMn2tQ9o Subject: [dmarc-ietf] Yet another mailing list solution thread X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 08:13:13 -0000 --089e011825c0906b5704fa999dd9 Content-Type: text/plain; charset=UTF-8 What can mailing lists do today 1) Reject posting from p=REJECT users 2) Re-write From header for p=REJECT/QUARANTINE users 3) Don't break the DKIM signature (no subject prefix, no footer) 4) Recognize DMARC reject bounce messages and don't consider them as reason to unsubscribe users 5) Add a sender header and sign their messages with DKIM 6) Add an Authentication-Results header with the auth-results for the post. Consider adding an OAR header as well (though, this may be premature). It seems like #4 should be relatively uncontroversial, arguably there are whole classes of bounce messages which don't indicate that all future messages would be rejected... Perhaps we should agree on an extended smtp status code that such rejections should use in order to make this easier to implement. I also realize that for some servers, the increased rate of bounces, even if they're to be ignored, is itself a problem, which means one of 1-3 would need to also be implemented. #2 could potentially use some finessing or standardization. For example, several MLMs are moving the original From header to X-Original-From, I could also imagine a List-Original-From or List-Poster header. Standardizing on that would allow clients to do intelligent things about the display of the two pieces of information, or handling reply-to better. #5 won't fix DMARC alignment, but its a step in the authenticated mail direction, and likely to be necessary for any next steps such as OAR What can DMARC enforcing domains do right now: 1) Whitelist mailing lists from enforcement. This is obviously a hole in DMARC which lowers the overall utility. Its basically saying "we don't trust your p=REJECT, we'll sometimes downgrade it to p=QUARANTINE". 2) Put a really simple DKIM signature on messages which doesn't cover the subject/body. Ick, but it could theoretically be done. The Future 1) Support Original-Authentication-Results. This requires the MLM to add them in the first place, and for the DMARC enforcing domains to check them. Has an open question of how best to "trust" the OAR header on a message. Options there are explicit whitelists from the sending domains (tpa-labels or whatever) or to leave it up to the individual receiving domain. 2) A new mailing list specific DKIM canonicalization. Its unlikely to be possible to be 100% authentication, its open for debate whether we could come up with one that'll provide some level of auth that may be useful in a more complicated "spam/phishing evaluation". 3) Some sort of "permission to relay" token. This is pretty similar to the DKIM above. 4) Plain old whitelisting (tpa-labels or whatever). Personally, I think without AuthRes/OAR, this is too big a hole to be useful. 5) More radical changes to MLMs/clients such as defining new headers with associated client requirements (ie, the footer / subject prefix is theoretically redundant with the adoptions of List-* headers). Other alternatives include embedding the original message in a wrapper (a message/digest of one). Are there any other clients besides mutt which handle this well? Other ideas? Brandon --089e011825c0906b5704fa999dd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What can mailing lists do today

1)= Reject posting from p=3DREJECT users
2) Re-write From header for= p=3DREJECT/QUARANTINE users
3) Don't break the DKIM signatur= e (no subject prefix, no footer)
4) Recognize DMARC reject bounce messages and don't consider them = as reason to unsubscribe users
5) Add a sender header and sign th= eir messages with DKIM
6) Add an Authentication-Results header wi= th the auth-results for the post. =C2=A0Consider adding an OAR header as we= ll (though, this may be premature).

It seems like #4 should be relatively uncontroversial, = arguably there are whole classes of bounce messages which don't indicat= e that all future messages would be rejected... Perhaps we should agree on = an extended smtp status code that such rejections should use in order to ma= ke this easier to implement. =C2=A0I also realize that for some servers, th= e increased rate of bounces, even if they're to be ignored, is itself a= problem, which means one of 1-3 would need to also be implemented.

#2 could potentially use some finessing or standardizat= ion. =C2=A0For example, several MLMs are moving the original From header to= X-Original-From, I could also imagine a List-Original-From or List-Poster = header. =C2=A0Standardizing on that would allow clients to do intelligent t= hings about the display of the two pieces of information, or handling reply= -to better.

#5 won't fix DMARC alignment, but its a step in the= authenticated mail direction, and likely to be necessary for any next step= s such as OAR

What can DMARC enforcing domains do = right now:
1) Whitelist mailing lists from enforcement. =C2=A0This is obviously a= hole in DMARC which lowers the overall utility. =C2=A0Its basically saying= "we don't trust your p=3DREJECT, we'll sometimes downgrade it= to p=3DQUARANTINE".

2) Put a really simple DKIM signature on messages= which doesn't cover the subject/body. =C2=A0Ick, but it could theoreti= cally be done.

The Future
1) Support Ori= ginal-Authentication-Results. =C2=A0This requires the MLM to add them in th= e first place, and for the DMARC enforcing domains to check them. =C2=A0Has= an open question of how best to "trust" the OAR header on a mess= age. =C2=A0Options there are explicit whitelists from the sending domains (= tpa-labels or whatever) or to leave it up to the individual receiving domai= n.

2) A new mailing list specific DKIM canonicalization. = =C2=A0Its unlikely to be possible to be 100% authentication, its open for d= ebate whether we could come up with one that'll provide some level of a= uth that may be useful in a more complicated "spam/phishing evaluation= ".

3) Some sort of "permission to relay" token. = =C2=A0This is pretty similar to the DKIM above.

4)= Plain old whitelisting (tpa-labels or whatever). =C2=A0Personally, I think= without AuthRes/OAR, this is too big a hole to be useful.

5) More radical changes to MLMs/clients such as definin= g new headers with associated client requirements (ie, the footer / subject= prefix is theoretically redundant with the adoptions of List-* headers). = =C2=A0Other alternatives include embedding the original message in a wrappe= r (a message/digest of one). =C2=A0Are there any other clients besides mutt= which handle this well?

Other ideas?

Brandon
--089e011825c0906b5704fa999dd9-- From nobody Fri May 30 01:25:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB67F1A6EF8 for ; Fri, 30 May 2014 01:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uinHeYPmeano for ; Fri, 30 May 2014 01:25:16 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 213501A026D for ; Fri, 30 May 2014 01:25:15 -0700 (PDT) Received: from [10.0.1.114] (97-82-223-101.dhcp.hckr.nc.charter.com [97.82.223.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id DE87ACB46; Fri, 30 May 2014 04:25:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Draegen In-Reply-To: <483EA287-1C1C-4E9A-A1D8-6EB301F418D5@gmail.com> Date: Fri, 30 May 2014 04:25:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7A575E6F-B65D-4E3D-8E76-02BA17D192BE@eudaemon.net> References: <20140528163723.63860.qmail@joyce.lan> <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> <483EA287-1C1C-4E9A-A1D8-6EB301F418D5@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/W0oOT5lPu7tlRtIdl2tikDMj3YQ Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 08:25:21 -0000 On May 28, 2014, at 8:48 PM, Douglas Otis wrote: > Dear Tim, >=20 > All that is needed is a few bandaids? Hi Doug, I don't see the problem space as allowing bandaid approaches. = The widespread ability to build controls on top of stable domain level = identifiers is relatively new. In my view, people that want to use = these controls are stuck in one of two ways: 1. They're trying to modify how their email is structured so that = controls can safely be put into place, and there is some sort of = relationship that allows change to happen. Franck Martin wrote = previously about this here: http://www.ietf.org/mail-archive/web/dmarc/current/msg00878.html 2. They're trying to address "legitimate-but-unauthorizable" email. In = this bucket I'd put everything that is mostly beyond the ability for = individual domain owners to change: mailing lists, forward-to-friend, = services that send on behalf of users. Scott Kitterman wrote about this = and asked about the scope of IETF work in this bucket: http://www.ietf.org/mail-archive/web/dmarc/current/msg00872.html Pain due to inaccurate deployment of controls is the domain owner's = problem (#1 above). There (should be!) plenty of feedback available for = domain owners to recognize their own problems. Pain due to everything else (#2 above) is something domain owners can't = expect to solve on their own. It's in this area that "bandaids" might = work in the short term (like publishing lists of exceptions), but long = term I'd personally prefer not to see a codified model of exceptions. I think it would be better to specify how impacted email in bucket #2 = can be dealt with, but not with a goal of preserving all existing email = use cases. IMO a better goal would be to specify how specific = categories of email should be presented. For example, codify how = mailing lists go about their business (maybe: adhere to relevant RFCs + = DKIM sign with ML's domain + perform OAR-like checks). A different = example: analyze the use of "Reply-to:", determine what is preferable = behavior, and codify what should be expected. The resulting = specifications would at least tell developers (across the spectrum from = MTA through MUA) what they need to do to interoperate. >=20 > The motivation behind TPA-Label was to ensure both quick and efficient = methods to offer necessary feedback to receivers. DMARC already expects = receivers to offer failure feedback to DMARC domains. Unfortunately, = once the DMARC domain has decided which third-parties need to be granted = exceptions, there is no way to do so. It seems dangerous to suggest = this can be hard-coded in the form of informal lists indicating which = DMARC domains should be ignored. I think I understand the motivation. I guess I'm in the horrible = position of viewing TPA-Label as a bandaid, given my own view of the = scope and amount of work involved in making email suck less. I don't = mean to disparage TPA-Label -- I just mean that given a finite amount of = focus and fuel, I'd prefer to work out what I wrote about above: = "specifying how impacted email in bucket #2 can be dealt with". >=20 > In the case of Yahoo, there is a real issue they are attempting to = mitigate. It would be nice to have a solution able to deal with = massively compromised user accounts, as ugly as that is. This is an = issue that is not going away any time soon. The issue is much worse in = China, for example. Please don't decide being helpful in such = situations is simply too hard. Is it really better to create lists = about which domains get ignored? It seems this quickly degrades DMARC's = initial intent, which was to offer results receivers felt safe to act = on. Is this still a worthy goal? One facet of the problem that Yahoo & AOL are addressing via DMARC-based = controls goes beyond "compromised user accounts". A malware-infected = PC's local address book gets scraped, and the infected PC emits = spam/malware that spoofs the owner of the PC's email address (because = fraud appearing to be from a known friend/colleague is pretty effective = fraud). This fraud does not flow through Yahoo or AOL. I hope the above shows that the size and scope of difficult problems is = not something I'm looking to work around. IMO bandaids are = exception-lists and mechanisms like TPA-Label, and the difficult (but = necessary) work remains in proposing, researching, specifying, = implementing, and advocating for how well established mailing practices = can interoperate in an email environment where stable domain-level = identifiers are the norm. -=3D Tim From nobody Fri May 30 01:31:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A7A1A0859 for ; Fri, 30 May 2014 01:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU5HaEF_NHQ2 for ; Fri, 30 May 2014 01:31:18 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A38C1A0385 for ; Fri, 30 May 2014 01:31:18 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id hn18so537666igb.12 for ; Fri, 30 May 2014 01:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fSRjjvoP7ddYZ8iMd2iULF++bNq7pCyfQcdY5PYd7uI=; b=k9A0RhBDudOWIBQ2N8glhe5riP/dAc9Fz1tHbN+t21NDVRyxYNCLqSHEVMlNYxFO71 Vjl5mQKZaRvrgHka7dgNt0YvsGe36gNeay4SUw3PCybN7aF1teCq3DDDmboL++CYUZsb FwhZg3GNdN1++HDsdVwAgssHsooJ9njrdvWOkaCvwc7z5EOsDjoONspr19TSxClO0ITQ EOsImLhti256L5Nel12hLwta+4J87dx49j7QX0gZczGxOD9Ij60Z60grHkqnS7yrIHsE 3WxVwBwEhbgqRe72hbI4QNjlnhxzur6YLGf9t6OvwEX5ADf96qgJLJa2LhBl2ZJHF+sU EkUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fSRjjvoP7ddYZ8iMd2iULF++bNq7pCyfQcdY5PYd7uI=; b=hvwMsgBHE4M48wmb4yRSKuazsnn8rkPJYBwr9qZEjDLcirz8PwYLF+z3dqFX/SSM90 Huuvobel+6GZRazD9YJ9Rvt4R9Cd84MO0QD0ucHV17WNKLBQ6Tr0zhvBknMc5o07L3me rQFN7OwdEdJmnwXggA5qnmguaP3DNWpe851xVTg44gpXzepCEvMNI8RP4YkqzaGf28v2 DKQg7+79uK386kYgZGg2Tq8M0ofYdEebj7FroZAUkustkebafxy0661yChymjhI3F6u2 ASXy2AHTgM/7RnRJLMvdwBckPksQNSW/70h6aMdqM5cypzS84maMi1MuT5BzxZvVlqxr WkSg== X-Gm-Message-State: ALoCoQnh4Q+8H79HOJu5Yhcb+AxvYJqMnBGwqC/yCJB0nz2+T5PrPgkPiHT02Wz1dRljB6PnNrJo MIME-Version: 1.0 X-Received: by 10.50.111.161 with SMTP id ij1mr3599331igb.12.1401438673632; Fri, 30 May 2014 01:31:13 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Fri, 30 May 2014 01:31:13 -0700 (PDT) In-Reply-To: <1401436925.52759.YahooMailNeo@web164603.mail.gq1.yahoo.com> References: <1401436925.52759.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Fri, 30 May 2014 01:31:13 -0700 Message-ID: From: Brandon Long To: Vlatko Salaj Content-Type: multipart/alternative; boundary=047d7b3a8a6251337d04fa99de39 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Mz-Dgyn0xjMrUyd3uf0eTBgYH6k Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 08:31:19 -0000 --047d7b3a8a6251337d04fa99de39 Content-Type: text/plain; charset=UTF-8 On Fri, May 30, 2014 at 1:02 AM, Vlatko Salaj wrote: > > Thus, I am reminding all of you of your obligation to keep > > this discussion professional, on topic, respectful, and friendly. > > > i do not see how this is at all possible, when a pretty developed > solution is ridiculed as a Klingon-speech, not by only few of > participants, but the very same administrator of this mailing list. > > let's call it irony. > > > for what it's worth, both Hector's and Douglas' solutions to, more > than obvious DMARC problem, work fine for solving issues with > case-scenarios i have in my environment. > > thanks for working on those, guys. yes, you do need much wider > support, if this is gonna take off, and i hope some of the more > influential speakers here will provide it [looking to ML > developers]. > > > in the end, imo, DMARC policy model, if not bug-fixed, which seems > all too much probable as whole DMARC establishment doesn't care, > will justdie off and become irrelevant, fading with smoke of > false-positivesit generates, as no sane service will respect > "reject" policy whose legitimacy is fluid, saving themselves from > wrath of both end-senders and end-receivers. > > and world will choose to keep email functional as it is, instead of > breaking it with some ill-developed rigid standard forinternet of > parallel universe. > I think many of the folks on this list don't use email the way that the vast majority of people do. Most people with a personal mail account aren't on any mailing lists. Even if they are, its likely from a major provider which is also a DMARC user, and so the MLMs will change to support DMARC. What would be more likely to happen, would be that there would be two semi-compatible but actually separate email systems, one which moves more and more to strong authentication and other policies, and one which attempts to remain the wild west. These systems would sometimes interact, but that interaction would likely result in messages going to spam folders or being rejected outright some percentage of the time. If hotmail/gmail were to go to p=REJECT, is a boycott still possible? vzw/ mail.ru/sina/me.com/163.com/docomo/etc? Brandon --047d7b3a8a6251337d04fa99de39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, May 30, 2014 at 1:02 AM, Vlatko Salaj <= ;vlatko.salaj@goodone.tk> wrote:
> Thus, I am reminding al= l of you of your obligation to keep
> this discussion professional, on topic, respectful, and friendly.


i do not see how this is at all possible, when a pretty developed
solution is ridiculed as a Klingon-speech, not by only few of
participants, but the very same administrator of this mailing list.

let's call it irony.


for what it's worth, both Hector's and Douglas' solutions to, m= ore
than obvious DMARC problem, work fine for solving issues with
case-scenarios i have in my environment.

thanks for working on those, guys. yes, you do need much wider
support, if this is gonna take off, and i hope some of the more
influential speakers here will provide it [looking to ML
developers].


in the end, imo, DMARC policy model, if not bug-fixed, which seems
all too much probable as whole DMARC establishment doesn't care,
will justdie off and become irrelevant, fading with smoke of
false-positivesit generates, as no sane service will respect
"reject" policy whose legitimacy is fluid, saving themselves from=
wrath of both end-senders and end-receivers.

and world will choose to keep email functional as it is, instead of
breaking it with some ill-developed rigid standard forinternet of
parallel universe.

I think many of the = folks on this list don't use email the way that the vast majority of pe= ople do.

Most people with a personal mail account = aren't on any mailing lists. =C2=A0Even if they are, its likely from a = major provider which is also a DMARC user, and so the MLMs will change to s= upport DMARC.

What would be more likely to happen, would be that ther= e would be two semi-compatible but actually separate email systems, one whi= ch moves more and more to strong authentication and other policies, and one= which attempts to remain the wild west. =C2=A0These systems would sometime= s interact, but that interaction would likely result in messages going to s= pam folders or being rejected outright some percentage of the time.

If hotmail/gmail were to go to p=3DREJECT, is a boycott= still possible? =C2=A0 vzw/mail.ru/sina/me.com/163.com/docomo/etc?

=
Brandon
--047d7b3a8a6251337d04fa99de39-- From nobody Fri May 30 02:12:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269F91A6EFC for ; Fri, 30 May 2014 02:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOEhHlsFdXkC for ; Fri, 30 May 2014 02:12:29 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 349FE1A075C for ; Fri, 30 May 2014 02:12:29 -0700 (PDT) Received: from [10.0.1.114] (97-82-223-101.dhcp.hckr.nc.charter.com [97.82.223.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 7AB9ECB46; Fri, 30 May 2014 05:12:44 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Draegen In-Reply-To: Date: Fri, 30 May 2014 05:12:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <69138421-9EA4-4189-9252-F36AE7082258@eudaemon.net> References: <20140528163723.63860.qmail@joyce.lan> To: John R Levine X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/d5sAJ6IGJBZSSMN4YBo4wamU5TQ Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Non-solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 09:12:35 -0000 On May 29, 2014, at 3:05 AM, John R Levine wrote: > Really, that makes no difference. I don't want Yahoo or anyone else = to pay us to screw up our mail software to work around them -- I want = them to spend their money to fix things so we don't have to. Yes, I get it, I guess in my own jaded way I don't think there is any = amount of money that Yahoo and AOL can spend that will fix things = (because email isn't owned by Yahoo or AOL). BUT, if Yahoo or AOL is = willing to experiment, let that experiment be me! I replied to Doug earlier (not yet in archive), and hashed out my own = thinking around how much domain owners can do vs. how to address = "legitimate-but-unauthorizable" email. TLDR summary: addressing "legitimate-but-unauthorizable" mail is my = answer to Scott Kitterman's question: "How do we define the scope of = work for this list?". >=20 > Yahoo, in their own blog, estimates there are 30,000 mail systems that = they have damaged by their DMARC actions. I would be surprised if there = were more than a few hundred mail systems acting on DMARC policies, = although some of those are very, very large. Is it that hard to = understand why someone might think it was unreasonable to demand that = the 30,000 make changes of no benefit to themselves, rather than the few = hundred fix their buggy fussp? I don't think there is/was a way for Yahoo to fix the estimated few = hundred mail systems acting on DMARC policies, especially since most are = not controlled by Yahoo. Maybe they could have published a list of = 30,000 mail systems that are white-listed, but wouldn't that just be a = publication of 30,000 holes to exploit? The absolute most work I could imagine Yahoo and AOL having done would = have been to analyze and publish a series of articles/guidance on how = impacted email can be fixed, complete with accessible patches to all = known mailing systems. THEN, give the entire internet enough time to = apply said patches. This is my unicorn. For the next 10 years, I'm going to attempt to recreate this unicorn. >=20 > The 30K estimate is probably low, since there are likely many small = mail systems they aren't aware of but that they are damaging. For = example, yesterday a middle school teacher who found my old Dummmies web = site wrote to me out of the blue to say that his web form that lets = students and parents send mail to him stopped working for AOL and Yahoo = addresses, which just disappear. It took about two seconds to figure = out what was wrong when he told me that his script sends mail to his = Gmail account. I told him what was wrong, and he did a hack that sticks = in a fake From: address, so the mail gets through but now his script = works worse since he can't write back without extra effort. If he = hadn't written to me, he'd probably never have figured out what was = wrong. These are real people who are really hurt by the two providers' = actions. In a similar vein, there are a fair number of businesses that do stuff = like encapsulate their customer mail with bling (fancy headers, = pictures, footers w/ disclaimers... "stationary"), and they're having to = figure out how to maintain their service when sending on behalf of = clients with Yahoo and AOL addresses. =20 What is missing is "how am I supposed to do this right"? I'm not being = glib, there's a real vacuum due to email being what it is, and it's a = vacuum that I personally don't think corporations can/should fill. -=3D Tim >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. >=20 > PS: Here endeth the rant. From nobody Fri May 30 02:18:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F051A075C for ; Fri, 30 May 2014 02:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoTK2Nyr0sdI for ; Fri, 30 May 2014 02:18:27 -0700 (PDT) Received: from nm35.bullet.mail.gq1.yahoo.com (nm35.bullet.mail.gq1.yahoo.com [98.136.217.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09F041A078F for ; Fri, 30 May 2014 02:18:27 -0700 (PDT) Received: from [127.0.0.1] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 09:18:22 -0000 Received: from [98.137.12.59] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 09:15:29 -0000 Received: from [98.137.12.215] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 09:15:29 -0000 Received: from [127.0.0.1] by omp1023.mail.gq1.yahoo.com with NNFMP; 30 May 2014 09:15:29 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 711068.42989.bm@omp1023.mail.gq1.yahoo.com Received: (qmail 27620 invoked by uid 60001); 30 May 2014 09:15:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401441329; bh=gRZ37QE29IPK4q1lH380NqXEOpyk8YUMzwlU8DTmvOc=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=e2leEo1G12Dnuaga+/F9pK3QCQdKiZqhblbHQQgfmVaY90KkOUYJzA+ik0mHcWcglAX2YT3oSO1b6exgdDcoGXlG/TmxBGAOgcH8k3IRZqUFa1rhu73KBUEY+QnFpAVBwkX7X7MxocOAnnU/9rW06WLfXijdH8Wdbojvqi4kOQ4= X-YMail-OSG: Dz2GNGQVM1nnNFeEgnkiVEjDK9cf8aoBKx6.lkn8HGPk8nr gWMvz9CCJzK_5V9k2xUZhhSmGuYIrSbE64UxPXNA5t5JCtEINJ0Aa3wJH47j igMIPhLv_Dk38lyo_u19Ml8BHnFb2Bz1Vg8B_6ib3CsHVHzXHKdTop4gM4IG LJ6TLTgf8nLuRTUVLy517Qs..Pg3Tx6Ud9JUw1bhwXHBkBAgkHiLbk6WRMZy QlhbpBNRAeWDE3dmsXOmfWYUpSZAH0sp4iOyyE1vLQWeTuNCmBYX7vrqV6Us n.Jsep3IDFrWhhqw8JxxI98yyjgItnzTDb.Mdr2spa.mgIAX.iVaYeS5hxZX JLbJKcSd8jGTFVzxLuY6qm23JvIdzCJgP_YrrdsGWkI4kOank8KnujDdZPJ7 J1A0YtZZSKEPNxtdiOfmNOHtv8E2Kjhlm7YPIf_6289rPmErAHwJv5T1viio fQdnjNF15nFhE8qcudIOVIJfccn6pVC_LT2bmfq2AESc7gBCRDzjV3jIr6U8 GRs0Hk2ORrF9by7Smc866pHTPbloTSNHLN1b_miTVwZYvuJX3tezfluaG4tF tiSPBHEp_b0oYzZiFWOlfbr58nmwJHgl2J9ge_Lu.KVq8RsLC Received: from [77.105.26.220] by web164602.mail.gq1.yahoo.com via HTTP; Fri, 30 May 2014 02:15:29 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBNYXkgMzAsIDIwMTQgMTA6NDcgQU0sIEJyYW5kb24gTG9uZyA8YmxvbmdAZ29vZ2xlLmNvbT4gd3JvdGU6Cgo.IElmIGhvdG1haWwvZ21haWwgd2VyZSB0byBnbyB0byBwPVJFSkVDVCwgaXMgYSBib3ljb3R0IHN0aWxsIHBvc3NpYmxlPwoKCmFjdHVhbGx5LCBpIHdvdWxkIGxvdmUgdGhpcyB0byBoYXBwZW4uIHRoYXQgd2F5LApwPXJlamVjdCB3b3VsZCBsb3NlIGFsbCBsZWdpdGltYWN5IGFuZCBETUFSQyBwb2xpY3kKbW9kZWwgd291bGQgYmUgY29tcGxldGVseSBkZWFkLiBhbmQgaSB3b3UBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.188.663 References: <1401436925.52759.YahooMailNeo@web164603.mail.gq1.yahoo.com> Message-ID: <1401441329.98351.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 30 May 2014 02:15:29 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Y99bdWuhGAVzu2HBo69RyVeoeGU Subject: Re: [dmarc-ietf] Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 09:18:28 -0000 On Friday, May 30, 2014 10:47 AM, Brandon Long wrote: > If hotmail/gmail were to go to p=REJECT, is a boycott still possible? actually, i would love this to happen. that way, p=reject would lose all legitimacy and DMARC policy model would be completely dead. and i would unsubscribe. by tightening the rope, more things fall out. since DMARC gate-keepers don't rly wanna fix it, i look forward for their over-zealousness to completely break the protocol. nobody would bother developing for and checking DMARC policy requirements, and DMARC would essentially become a simple reporting protocol, without authentication or compliance checks, for most services. the same happened with SPF, the same happened with DKIM+policy. and we would just fall back to blacklisting, whitelisting and all deep and complex processing good old anti-spam services do instead. cause the wisdom of blacklisting and whitelisting is too complex for DMARC to handle, it seems. even though, actually, alignment check is a way of whitelisting, essentially. when somebody like me has to draw pictures of basics... it speaks volume about how things in question are broken. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri May 30 02:50:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AD61A087C for ; Fri, 30 May 2014 02:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BumcZMtuGAbt for ; Fri, 30 May 2014 02:50:24 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id C90C11A0875 for ; Fri, 30 May 2014 02:50:23 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id F2F97970B1F; Fri, 30 May 2014 18:50:18 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E7BF011F235; Fri, 30 May 2014 18:50:18 +0900 (JST) From: "Stephen J. Turnbull" To: Kurt Andersen In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> <63B7CF39-2EA2-468B-93BB-FB17050E9B1F@eudaemon.net> <8F0A5BCBFFB046AF9F79C6E9772A253D@fgsr.local> <5387C239.7030804@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 30 May 2014 18:50:18 +0900 Message-ID: <877g537fz9.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/eDywzNfJslinCvnODrg8d93g85w Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 09:50:25 -0000 Kurt Andersen writes: > I have to confess that I have not (yet) waded through the details > of TPA or ASL or ATPS, but from a corporate perspective, it would > be extremely unworkable for any but the smallest company to manage > DNS records to whitelist every list server on the internet that my > employees would happen to use. I don't see that a small company, or any company, would want to. Your employees are representatives of the organization when using (most of) your subdomains and your main domain, and "p=reject", with no mitigation on your part, seems perfectly reasonable to me.[1] Use a subdomain like just-for-fun.example.com or list-post.example.com with "p=none" if you want to permit personal posts to 3rd-party mailing lists. If companies can agree on a single such subdomain (or even 5 or 10 of them), the MUAs-for-people-prone-to-entering-passwords- in-email-forms can recognize it and treat that subdomain as suspicious. Eg, disabling all links in the email, or redirecting to a page which explains why clicking on these links is dangerous. If your employees find it tedious to switch return addresses, let them use XEmacs![2] The idea is that Yahoo! and AOL can use these protocols to mitigate the damage they are doing, not just in actual DoS, but in causing people to run around saying "The sky is falling! The sky is falling! Let's change the semantics of RFC5322.From!". I find the thought of "p=reject" domains putting their own resources on the line appealing. Footnotes: [1] The exception would be the small set of vendors like QuickBooks who provide you with value-added services, so that you have a business reason for whitelisting them. [2] Yes, I know what happened to Marie Antoinette. Just kidding. However, Emacsen-based MUAs are proof of concept. It is not that hard to write an MUA smart enough to automatically switch personalities when posting to a list or writing home to Mom. From nobody Fri May 30 03:09:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3061A086C for ; Fri, 30 May 2014 03:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5seac6wSTqc for ; Fri, 30 May 2014 03:09:06 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 748191A079D for ; Fri, 30 May 2014 03:09:06 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id D6AF9970AEF; Fri, 30 May 2014 19:09:01 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CB51311F235; Fri, 30 May 2014 19:09:01 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> <87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 30 May 2014 19:09:01 +0900 Message-ID: <8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XLjDxsBR9bXWkJUNKoYlb7iqYN0 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 10:09:08 -0000 J. Gomez writes: > Missuse of DMARC's p=reject by Senders is here to stay. It won't go > away. It will only grow.[*] I'm not so sure. Anyway, that doesn't mean we need to sanction it. > In my opinion, the least disruptive adaptation which mailing list > software can do is to take ownership --in a DMARC-compatible way-- > of the Header-From, I disagree. The least disruptive adaption is whatever the users of the mailing list think is the least disruptive adaptation. That's why Mailman provides multiple mitigation options, and will probably add more as we think of them or they're contributed to us. > just like they already take ownership of the envelope's > ReturnPath-From. Ah, but "just like" is a complete misstatement of the situation. There's a big difference. Users on a mailing list think of the poster, not the mailing list, as responsible for the content. So according to RFC 5322, the poster's mailbox belongs in From:. Remailed or not, the author belongs there. According to the RFCs, Return-Path does not correspond to From, it's more similar to the semantics of Sender (but not identical). Whoever is going to handle delivery issues belongs in Return-Path. The remailing agent belongs there, because the poster, in general, doesn't know where the message is being sent, and can't help debug problems between the remailer and the subscriber. > And, also in my opinion, that mailing list adaptation to DMARC > should be the new default out-of-the-box behaviour of mailing list > packages from now on, and the old behaviour should be regarded as > legacy and deprecated. Actually, in GNU Mailman I suspect that going forward the default behavior will be either no mitigation (as now, just by momentum), or wrap-in-a-new-message-if-p=reject-detected, which is fully RFC conformant, although not iDevice-Apple-Mail-friendly. Some developers are just prickly curmudgeons.[***] cPanel and Plesk and RHEL are welcome to patch their versions, of course. [***] And that, too, is the way the world goes by. Steve From nobody Fri May 30 04:04:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AC41A03DC for ; Fri, 30 May 2014 04:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAinIthSgN1a for ; Fri, 30 May 2014 04:04:08 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2F31A0193 for ; Fri, 30 May 2014 04:04:08 -0700 (PDT) Received: from [10.0.1.114] (97-82-223-101.dhcp.hckr.nc.charter.com [97.82.223.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 03DA0CB46; Fri, 30 May 2014 07:04:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Draegen In-Reply-To: <87vbso7umr.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Fri, 30 May 2014 07:04:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140528163723.63860.qmail@joyce.lan> <87vbso7umr.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cSgdt4f-IRNbQqiVjPCBIOPPGpY Cc: dmarc@ietf.org, John R Levine Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 11:04:11 -0000 Stephen! Welcome! No one said making sausage was pretty. :-( On May 29, 2014, at 6:21 AM, Stephen J. Turnbull = wrote: > Tim Draegen writes: >=20 >> John, you are very difficult to communicate with, maybe because >> you're easily insulted, even when there is no insult. I too have >> been in correspondence with mailing list developers, >=20 > Which ones? I don't think it would be appropriate to name people, but to a larger = point, I have to apologize if I come across like a jerk. There are a = lot of people trying to deal with DMARC across many forums, and my = attempt to imbue a sense of breadth and depth was ham fisted. I live = and learn.=20 >=20 >> and also developers behind businesses that rely on email, >=20 > That's insufficiently precise. To my mind, there are two kinds (at > least) of businesses that rely on provision of mailboxes (other use > cases follow). I was thinking of businesses that rely on the perfectly acceptable (but = now at loggerheads with DMARC-based controls) practice of sending on = behalf of customers. For example, "stationary" businesses (described = towards the end of this mail: = http://www.ietf.org/mail-archive/web/dmarc/current/msg00923.html). There are also businesses that perform "SMTP Cleaning" ala anti-spam = filtering, plus "SMTP backup" services that people find enough value in = to pay for. My ham-fisted point was that mailing lists are interesting for sure, but = the scope of email (potentially) impacted by DMARC is bigger, and maybe = we should think about the space a bit more generically. > Does DMARC actually impose significant burdens on the "corporate use > case", contrary to my belief? I don't personally carve up the email space along corporate vs = non-corporate lines. People at corporations communicate via mailing = lists. Before Yahoo and AOL went to p=3Dreject policies, the advice was to keep = DMARC-reject policies to "transactional" domains. "Transactional" in = this context mapped to "email that isn't likely to be impacted by things = that break DMARC like mailing lists".... stuff like account = notifications, receipts, not people-to-people. But it turns out that quite a few people create mini mailing lists to = map a single recipient of a transactional piece of email to multiple = recipients... like receipts going to bills@family.org, where the parents = and an archive are the final recipients. So, dang. > Of course there are other use cases of "businesses that rely on > email". I understand the "mailing list as user forum" case, and I > believe Mailman has already implemented a sufficiently broad set of > measures for business use in this use case. The tradeoffs aren't > pleasant, but that's a cost of doing business with Yahoo! and AOL > users. A business has the usual set of options (pay the costs, find > less costly customers, use alternative forum technology, etc). I > don't see a real problem here. =46rom your mouth to the Internet.God's ear! > There's also the "on behalf of" content provision use case. Others > describe a good remedy in this thread, but I would like to point out > that such providers may publish "p=3Dreject" to good effect, as an > instance of the "corporate use case". >=20 > But my knowledge of "business use" is quite limited. Are there other > "business activities relying on email" such that DMARC imposes > burdens? Are those burdens specific to "p=3Dreject", or more general? >=20 > (If this is all well-known, please point me to a reference where I can > book up without disturbing the Councils of the Wise.) One giant problem that ISPs face is that they have large numbers of = customers that send email through their infrastructure but for domains = that are not related to the ISP. Imagine a residential network = providers with lots of customers that configured their email clients 20 = years ago. It's largely worked up until now. Is the ISP supposed to = contact each customer and get them to use the correct outbound SMTP = servers? What is the right thing to communicate? Council of the Wise?! I always thought the IETF was a bunch of people = hanging off the edge of the world, getting together every once in a = while to maybe allow an accidental shared piece of understanding to be = written down. >=20 >> and also a slew of decision makers... and they're all trying to >> understand how they can fix things without going backwards. >=20 > IMO, they're wasting their time. >=20 > Email service *must* deteriorate in the presence of users who send > messages from "p=3Dreject" domains, unless those domains are draconian > in enforcing direct transmission to final destinations that observe > "p=3Dreject" (see Franck Martin's post later in the thread, and the > following subthread on "legitmate use of 'p=3Dreject'" that follows). > Unfortunately, these domains are proposing that third parties adjust > to their (unilaterally imposed) policy, rather than modifying those > policies or restricting their users to safe email usage. But the "let > third parties adjust" solution is a pretty dismal option. There are > just too many MXes and MTAs and services that are DMARC-incompatible. > It's going to take years, maybe a decade, to modify both the software > and the installations. I think you're largely correct, but I don't agree with the "wasting = their time" part. Bringing domain-level identifiers to email took over a decade of largely = haphazard work. It probably *will* take another decade of work to = modify both software and the installations. Given that much time, it should be possible to structure email service = so that service/features do not necessarily have to deteriorate. Well, = today the damage is being done, but is the response from the Council of = the Wise to be "email is deteriorating, this is the new normal", or can = we put together documents that describe how to interoperate -- not just = for dealing with p=3Dreject domains within the context of mailing lists, = but interoperability between MLs and MUAs? >=20 > The help we need is in explaining to our users that they cannot > maintain past configurations and allow posting from "p=3Dreject" = domains > at the same time. For many of our users, they get a MLM as a part of > a hosting package and the only solution they can implement themselves > is to refuse posts from those domains. This is the stuff, right here. Asking Yahoo and AOL for help in = educating users is spot on. > Where's the money to > compensate those list operators for lost subscribers or the costs of > switching hosting services? Where's the money to encourage hosting > providers to upgrade their MLM installations? Where's the money to > compensate operators for the emotional and social damage done by > Yahoo! users who throw fits privately and publicly over lost posts? > Yahoo!'s offer of support for developers is a pure FUD PR stunt, as > far as GNU Mailman concerned. A few hours ago I replied to John and expressed my view that Yahoo and = AOL aren't in a position to fix the internet... as much I can, I tried = not to be ham-fisted: http://www.ietf.org/mail-archive/web/dmarc/current/msg00923.html There's wreckage, yes. My aim, because I'm eternally an optimist, is = that the wreckage doesn't end with yahoo and aol being given the middle = finger. Sure, do that, but there's more work to be done that doesn't = belong to yahoo or aol. >=20 > The question is, to paraphrase John, how best to defend our users > (subscribers as well as list operators) from the unilateral behavior > of corporations desperate to mitigate their own problems. The rest of > us *will* go backwards. The question is how do we minimize the > retreat, and in which backward direction to go. Mailman, at least, > offers list operators (precisely, those who can install the most > recent versions) several options, so they can choose the one they > dislike least. I get it, but painting the scenario as this being only Yahoo and AOL's = problem is a distraction. There are plenty of small organizations and = individuals that are using DMARC to curtail abuse. I'd argue that the = problem of email's trivial ability to be used for abuse is everyone's = problem. It's only Yahoo and AOL's size that brought this work to the = forefront. >=20 >=20 >> Figuring out how to make email slightly less capable of harming >> people is a big deal. >=20 > Yahoo!'s use of "p=3Dreject" reminds us that there is little we can do > to make email as such less harmful. Email is the #1 online attack vector. The "attack surface" that email = presents is incredibly huge. Attempting to change email so that = defrauding millions of people using email becomes only incrementally = more difficult is what is going on here. The flip side is that the introduction of stable domain-level = identifiers should make filtering a lot simpler. How does the Internet = take advantage of these identifiers in the context of mailing lists, = forward-to-friend, send-on-behalf, and other contexts? [my quarters are running out, so snip snip] >=20 > I accept that this may not be a "big" problem from the point of view > of this group, that's just Mailman's point of view. I don't think "big" is required to be important. I for one am trying to = understand as much as I can about DMARC's impact from all angles. >=20 >> Tell the people you're communicating with to post their finding to >> either this list or the dmarc-discuss list. There is no reason why >> their findings should be frustrating -- others are meeting the >> challenge, >=20 > Nice pep talk, but please, save it for the board room. If you want to > present specific solutions, I'd love to hear about them (even if they > don't apply directly to mailing list management). I am not a mailing list developer, but I do try to get people involved = in the same areas of work to at least get a chance to collaborate. What = you've communicated is far better than any filtered version. These folks take a nice and deliberate approach: = http://onlinegroups.net/blog/2014/05/01/dmarc-taking-responsibility-sendin= g-group-email/#more-934 ..different problem space, because of Mailman's huge installed & = distributed base, but at least ideas are there. -=3D Tim From nobody Fri May 30 04:31:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992A61A03DC for ; Fri, 30 May 2014 04:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8vW7y9tB217 for ; Fri, 30 May 2014 04:30:57 -0700 (PDT) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EAF21A03DB for ; Fri, 30 May 2014 04:30:57 -0700 (PDT) Received: from [98.139.215.142] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2014 11:30:52 -0000 Received: from [98.139.212.233] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 30 May 2014 11:30:52 -0000 Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 30 May 2014 11:30:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 208963.48070.bm@omp1042.mail.bf1.yahoo.com Received: (qmail 97594 invoked by uid 60001); 30 May 2014 11:30:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401449452; bh=CoEK3dLBcFng3hIKszaQfe/QG18rdt7lI4MFlBzii0A=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=w+DM9QE+xcJcrJ4+aa6zj6/EnDfwqOxA88f3RfvRS1rGJYeB4eJUl4YjVuf836MNTSRkMv+Exo+pxjVtbxb8USmhDxrumcBaFmPfFs9cbSDhlpNu3e7cG9VFHKHzHzVoyyj72Fn89M/pRVzroEboi7N4tm1uMk76CFzANnFHjiI= X-YMail-OSG: Z.xIGr8VM1keDyH9nYhSg0Rff_iHBh9TAf8hSOABoTOpUTm LOjVIT1P.d8fnhuPs17DNijJA94civw3snsdAFXEWZBNCkv34tAttfgxcFhY F0HA8w54aGBOGkSN1.8LwA0.5F9u1KnXlnJhy5OPr0S6iFUsjfL8VawQyctJ xhe8VjbEN2xixMJmvLbLUp1xrlMbS0DmP_2InB5OeBmhOGXkPdl1lX_6meMh T7LZfXJOvPgksK.c6PyaZPvgYVhohYGO2FCGjoVi1q0rJe1cNqfp1rZtj_s0 CHlyGXNXOTw8PgsYjlzEJbbyuAUfGrTyL1CRpXb_nxspk97wV9NL7CkeqP8n TkJNXQw57UikZJzEMJLXIo1FyLE0TJRaNgu9iHJdp5fpcgo.k7y9IjisYl8I 4nGtKh.6_eBc6ptT.yqaEGBTonh13vG5BOiW0Y7qM2N.TWXhHeYLb9Nj.REZ XYcrOEeC5z0bYl28xk7G6ywCv.7Z0pQURrlRDn5zsJXLBPUZ2Td5Ys50m9IP NK6zWsGiRy1jelzjRswSSUNJvnD_Y0PfA0P7Gwxfp_DGnhtNH0FOyDhLPUwW vZ8nO_3dOr90Ao7ccKOu_TyD2Tki93P6POFv0WJXQ6iPvAnxlpZhtE7o82iH 9ZvPRh3RT18qzkiLpxfBG Received: from [108.95.156.18] by web160506.mail.bf1.yahoo.com via HTTP; Fri, 30 May 2014 04:30:52 PDT X-Rocket-MIMEInfo: 002.001, DQoNCiAiTW9zdCBwZW9wbGUgd2l0aCBhIHBlcnNvbmFsIG1haWwgYWNjb3VudCBhcmVuJ3Qgb24gYW55IG1haWxpbmcNCiBsaXN0cy4iDQoNCiANCiBJIEFNIG9uIHNldmVyYWwsIGFuZCB0aGUgT05MWSByZWFzb24gSSBhbSBoZXJlIGlzIHRvIHRyeSBhbmQgZmlndXJlDQogb3V0IHdoeSBzbyBtYW55IHBlb3BsZSBsaWtlIG15c2VsZiBoYXZlIGJlZW4gQ09NUExFVEVMWQ0KICdkaXNyZXNwZWN0ZWQnIHdpdGggdGhlc2UgJ3BvbGljaWVzLicgV2hpbGUNCiBJIG1pZ2h0IGJlIGluIHN1cHBvcnQgb2Ygd29ya2kBMAEBAQE- X-Mailer: YahooMailClassic/592 YahooMailWebService/0.8.188.663 Message-ID: <1401449452.50909.YahooMailBasic@web160506.mail.bf1.yahoo.com> Date: Fri, 30 May 2014 04:30:52 -0700 (PDT) From: eugene hayhoe To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rXUi9hRBnmKhbFSc0wFA_5TF78w Subject: [dmarc-ietf] Fw: Re: Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 11:30:58 -0000 "Most people with a personal mail account aren't on any mailing lists." =20 I AM on several, and the ONLY reason I am here is to try and figure out why so many people like myself have been COMPLETELY 'disrespected' with these 'policies.' While I might be in support of working on the spam/fraud issue, my ''Yahoo spam'' has actually INCREASED at least 5 fold since this 'improvement' began, not to mention the pain of being forced to jump from email provider to email provider every few days 're-subscribing' to lists which I had previously been on for years. Not attacking you Brandon, just using your comment as a jumping off point.= I am a very frustrated user, not a programmer. Gene=20 > -------------------------------------------- > On Fri, 5/30/14, Brandon Long > wrote: >=20 > Subject: Re: > [dmarc-ietf] Comportment on this list > To: > "Vlatko Salaj" > Cc: "dmarc@ietf.org" > > Date: Friday, May 30, 2014, 4:31 AM > =20 > =20 > =20 > =20 > On Fri, May 30, 2014 at > 1:02 AM, Vlatko Salaj > wrote: > =20 > > > Thus, I am reminding all of you > of your > obligation to keep > =20 > > > this discussion professional, on topic, respectful, and > friendly. > =20 >=20 >=20 > =20 > =20 > =20 > i do not see how this is at all possible, when > a > pretty developed > =20 > solution is ridiculed as a Klingon-speech, not > by only few > of > =20 > participants, but the very same administrator > of this > mailing list. > =20 > =20 > =20 > let's > call it irony. > =20 > =20 > =20 > =20 > =20 > for what it's worth, both Hector's and > Douglas' > solutions to, more > =20 > than obvious DMARC problem, > work fine for solving issues > with > =20 > case-scenarios i have in my > environment. > =20 > =20 > =20 > thanks for working on those, > guys. yes, you do need much > wider > =20 > support, if this is gonna > take off, and i hope some of the > more > =20 > influential speakers here > will provide it [looking to ML > =20 > developers]. > =20 > =20 > =20 > =20 > =20 > in the end, imo, DMARC > policy model, if not bug-fixed, which >=20 > seems > =20 > all too much > probable as whole DMARC establishment >=20 > doesn't care, > =20 > will > justdie off and become irrelevant, fading with smoke > of > =20 >=20 > false-positivesit generates, as no sane service will > respect > =20 >=20 > "reject" policy whose legitimacy is fluid, > saving > themselves from > =20 > wrath of both end-senders and > end-receivers. > =20 > =20 > =20 > and world will choose to > keep email functional as it is, > instead > of > =20 > breaking it with some > ill-developed rigid standard > forinternet > of > =20 > parallel universe. > =20 > I think many of the folks on > this > list don't use email the way that > the vast majority of > people do. > Most people > with a personal > mail account aren't on any mailing >=20 > lists. =A0Even if they are, its likely from a major > provider > which is also a DMARC user, and so > the MLMs will change to > support DMARC. > =20 > What would be more likely > to happen, would be that there would be two > semi-compatible > but actually separate email > systems, one which moves more > and more to > strong authentication and other policies, and > one which attempts to remain the wild west. > =A0These systems > would sometimes interact, > but that interaction would likely > result in > messages going to spam folders or being rejected > outright some percentage of the time. > =20 > If hotmail/gmail were to > go > to p=3DREJECT, is a boycott still > possible? =A0 vzw/mail.ru/sina/me.com/163.com/docomo/etc? > =20 > Brandon >=20 > -----Inline Attachment Follows----- > =20 >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Fri May 30 06:36:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345B61A08A2 for ; Fri, 30 May 2014 06:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-oX223w2GX6 for ; Fri, 30 May 2014 06:36:04 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3551A00DD for ; Fri, 30 May 2014 06:36:04 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D1736D04367; Fri, 30 May 2014 09:35:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401456959; bh=GxbsZlPLbZ7H/9GFTHTLGXgSwCJlScbxhPdzkXRK+vM=; h=In-Reply-To:References:Subject:From:Date:To:From; b=rMGHSmQ4kTd/1/qXmBuv6+jlLTiKm87vRRl5cgO7PPiNQx2EfREuEq2UMLdo2NmfY 0sXoB0W8RaZbwAuDZqRQ/+NJAsk9Lu4Tcc4Zl13lV1EfVTlgVVizGKDnqkyYBI4iEk ZcC44zpWOTsC9jhfk1jLUFiLp6DXkFcYXeuSioBQ= Received: from [192.168.111.116] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8C276D04106; Fri, 30 May 2014 09:35:59 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Fri, 30 May 2014 09:35:35 -0400 To: "dmarc@ietf.org" Message-ID: <8fa52f8b-8447-42a7-8c87-5d875674ee1b@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ErTA8T046sO5oE_0gVScQZuvUVY Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 13:36:06 -0000 On May 30, 2014 3:37:28 AM EDT, "Murray S. Kucherawy" wrote: >On Thu, May 29, 2014 at 8:44 PM, Scott Kitterman >wrote: > >> The reason there is no IETF working group is that the people behind >DMARC >> were >> unwilling to entertain participation in a working group that had a >charter >> that allowed for any chance of a change to the DMARC protocol. >> > >I think that's a bit hyperbolic. There was perhaps too much emphasis >on >protecting the deployed base, but had they been confronted with actual >data >about something that wouldn't work (rather than the typical theory-only >assertions on which working groups like to rathole), there would have >been >ample justification for a change. > > >> DMARC change is even more off the table than MLM software change >(which >> does, >> as you suggest, evolve over time). >> > >Are there changes people want to make? So far all I've seen is >"something >needs to change", but nothing concrete, or at least nothing that has >garnered consensus of some sort. > > >> I wrote the other day asking what IETF work is there around DMARC and >> didn't >> get much of an answer. I think that's instructive. > > >I think that conclusion is premature. At this point, I could probably craft a reasonable problem statement. I don't know what the solution is, but the solution space is certainly different if DMARC changes to deal with the current mess are on the table. Currently such changes aren't up for consideration, so no one is expending much mental energy in that direction. It's not even an IETF specification. Change the potential solution space and you'll change the discussion. Scott K From nobody Fri May 30 06:42:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF1D1A08F3 for ; Fri, 30 May 2014 06:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v477jlLTYX7q for ; Fri, 30 May 2014 06:42:11 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8B91A08A2 for ; Fri, 30 May 2014 06:42:11 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so1119939wib.17 for ; Fri, 30 May 2014 06:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rny9TiFfhp9TQVXHwGjCV+epFOi6gQW2iTlHb6x5TFQ=; b=IFyblaeQA/lkXV3Nzc/9jp8JhuQmJRHPPBYCCrXhyospafKPLRHUBG6EIZP8nBIhxY uDP/sWfpYpRitz3mIyJPvLuejkm3ck2keIxV8yCxPIVQgGXOEJ7YWGgT894iYKWGRgeW SJ9+CPV5xAmfWWfnc1btrXE/xgRVqYV/tC0fW6fg9l6v/drFrMj69xIGws6ytxEJebTW EPKouTWwYQ4NhY/1cX6wyolthYuRSaOrpnlEYxNQbaivjd0CK40dow+Qe2Z3iPXBaWMV jS2nMbc0C9RYDyhq5BOC0xiuDqpGSrV6NMwhz4rsx/y1+WlgdVKsNTwfazGtmQF86Zkl gMKA== MIME-Version: 1.0 X-Received: by 10.195.17.169 with SMTP id gf9mr22686016wjd.10.1401457323395; Fri, 30 May 2014 06:42:03 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Fri, 30 May 2014 06:42:03 -0700 (PDT) In-Reply-To: <1401441329.98351.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <1401436925.52759.YahooMailNeo@web164603.mail.gq1.yahoo.com> <1401441329.98351.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 30 May 2014 06:42:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=089e01681bfcedd34e04fa9e35d8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nijDkfSmFPlk6jCFmPnGWkzD9lE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 13:42:13 -0000 --089e01681bfcedd34e04fa9e35d8 Content-Type: text/plain; charset=UTF-8 On Fri, May 30, 2014 at 2:15 AM, Vlatko Salaj wrote: > when somebody like me has to draw pictures of basics... > it speaks volume about how things in question are broken. > I think there's another possible answer, which is that your perspective on how this all works or should work isn't shared by anyone else. In either case, there are a lot of smart and very experienced email people here. I suggest that talking down to everyone that doesn't see it your way isn't an especially constructive approach. -MSK --089e01681bfcedd34e04fa9e35d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 30, 2014 at 2:15 AM, Vlatko Salaj <vlat= ko.salaj@goodone.tk> wrote:
when somebody like me has to draw pictures o= f basics...
it speaks volume about how things in question are broken.
<= div>
I think there's another possible answer, which is th= at your perspective on how this all works or should work isn't shared b= y anyone else.

In either case, there are a lot of smart and very experienced email peo= ple here.=C2=A0 I suggest that talking down to everyone that doesn't se= e it your way isn't an especially constructive approach.

<= div> -MSK
--089e01681bfcedd34e04fa9e35d8-- From nobody Fri May 30 08:02:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67881A0991 for ; Fri, 30 May 2014 08:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5Hrmf13W1ht for ; Fri, 30 May 2014 08:02:05 -0700 (PDT) Received: from nm32.bullet.mail.gq1.yahoo.com (nm32.bullet.mail.gq1.yahoo.com [98.136.217.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CDA1A0962 for ; Fri, 30 May 2014 08:02:04 -0700 (PDT) Received: from [127.0.0.1] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 15:02:00 -0000 Received: from [98.137.12.62] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 14:59:15 -0000 Received: from [98.137.12.224] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 30 May 2014 14:59:15 -0000 Received: from [127.0.0.1] by omp1032.mail.gq1.yahoo.com with NNFMP; 30 May 2014 14:59:15 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 630028.79488.bm@omp1032.mail.gq1.yahoo.com Received: (qmail 88533 invoked by uid 60001); 30 May 2014 14:59:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401461955; bh=9qYo5MMAMfxnEEwXshxYl1gLIspbzdpZg1uRGI1JcIk=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=B3Om9pN9AUv05/68bljr/6GlzCfEwrvKTS0dpos4qp/zTQHEnT8BwxKMijfelnoyRsQSiCydT0+tHOb961w3kRBvE91dn9ZL0ttXHniCh8A5kC/h4lJ06jQDu3X2TbO0ZKQoREHcDffnsussanDsnMCusxtgKqaxozv00j3zc80= X-YMail-OSG: 5f90mfMVM1mjrW8GSIPu9NSBrfjKenLk3rHo6.Y2SV__fc0 lvmFfbYp.D_9cK83XVznzYhAmLOupBMFuOVw6uXANt7NGVI9Ql8kmGhrFS7F lBdoLJMmyCuoIPVIc34SlUW43ZoR.MGtnciU3U2CTd4y5CyF3e1q3Q8Tzm.J A4YhKJ0cMvocWjuDkILBl.no.rZ9GGlBqaYmIXdAUdFx1xg3S_Sk8Mgf3yEq EO3fhf_wgf9asN1PGIfqdGlegAEofHqQ4iC6oWxFJ6ZJwzewgFXGBnag0CBd 9b95SnszYqx5TsFt33ur_MzjWaDXaIinoKbMoTcgE0Szqtv_MnjAAnADpz0z rEDTmdv566NbAqWsURa3.kDczthTbLHP.PcJwiM5jaTKODN84RF_obJzDRIy T975hLWpBFv8liA4ajr61uc7iXlqWo8ppkD5Eri6HQBw8VZwKp08lE_.FMNr MRyhmuJHtAuVnMzJonDtbrtlk7.M9krpAWoYMj7thxBJCL2stkeFMU7PK0dD 0OJcnmWlmMagyZ8PRp.RU2r79ezEihbQ3U.zNGeDEQpDV9b8h4vt6AcgFww7 WLnr8XLf_HxUyhpni8QEhVRgEh2um4g9UecdVOw8xN2hRhTuq Received: from [77.105.26.220] by web164606.mail.gq1.yahoo.com via HTTP; Fri, 30 May 2014 07:59:15 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBNYXkgMzAsIDIwMTQgMzo0MiBQTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4gd3JvdGU6CgoKPj4gd2hlbiBzb21lYm9keSBsaWtlIG1lIGhhcyB0byBkcmF3IHBpY3R1cmVzIG9mIGJhc2ljcy4uLgo.PiBpdCBzcGVha3Mgdm9sdW1lIGFib3V0IGhvdyB0aGluZ3MgaW4gcXVlc3Rpb24gYXJlIGJyb2tlbi4KPiBJIHRoaW5rIHRoZXJlJ3MgYW5vdGhlciBwb3NzaWJsZSBhbnN3ZXIsIHdoaWNoIGlzIHRoYXQgeW91cgo.IHBlcnNwZWN0aXZlIG9uIGhvdyB0aGkBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.188.663 References: <1401436925.52759.YahooMailNeo@web164603.mail.gq1.yahoo.com> <1401441329.98351.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1401461799.22579.YahooMailNeo@web164601.mail.gq1.yahoo.com> Message-ID: <1401461955.25433.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Fri, 30 May 2014 07:59:15 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <1401461799.22579.YahooMailNeo@web164601.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ItibM5ZXwBaQiY3jzVbbYTg5Als Subject: Re: [dmarc-ietf] Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:02:09 -0000 On Friday, May 30, 2014 3:42 PM, Murray S. Kucherawy wrote: >> when somebody like me has to draw pictures of basics... >> it speaks volume about how things in question are broken. > I think there's another possible answer, which is that your > perspective on how this all works or should work isn't > shared by anyone else. > In either case, there are a lot of smart and very experienced > email people here. I suggest that talking down to everyone > that doesn't see it your way isn't an especially constructive > approach. In either case, there are a lot of smart and very experienced email people here. I suggest that talking down to everyone that doesn't see it your way isn't an especially constructive approach, administrator. Believe me, I'm not the only one amazed. Let's hope that's the last of offtopic, personal, insulting messages we'll see running around here. I am, at least, posting stuff about DMARC, not how-to-behave-for-dummies. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri May 30 10:09:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13B31A0451 for ; Fri, 30 May 2014 10:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.921 X-Spam-Level: X-Spam-Status: No, score=-16.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8pj0XEBllyE for ; Fri, 30 May 2014 10:08:59 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710AC1A038E for ; Fri, 30 May 2014 10:08:59 -0700 (PDT) Received: from GQ1-EX10-CAHT11.y.corp.yahoo.com (gq1-ex10-caht11.corp.gq1.yahoo.com [10.87.93.110]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s4UH7Vq9097449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 10:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1401469653; bh=a5ScdYPnqtvQABrXC/KX+MZWFms5wG8EzbzAsVUDR9g=; h=From:To:Subject:Date:References:In-Reply-To; b=lYav6KAwGX9tB7b7B2b90tAC++IuXxJwxn3a4oTfoOHrb6rvjga/V2/KIKsRs5CPR E4pWsXP/4HSrcf/H9tt3HU66HrRegNfH6Bwb+uy4QYhOWEwUAnAu7Y+u9/aXOO9EgQ NFSwnStL4SISl1QCWKdD+AOnDCCnJwwG+M+EEDTU= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT11.y.corp.yahoo.com ([fe80::fced:19dc:eaca:7886%12]) with mapi id 14.03.0181.006; Fri, 30 May 2014 10:07:31 -0700 From: Elizabeth Zwicky To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) Thread-Index: AQHPe7Tw0rXUTivWFE2qV1g12n37IZtY8MgAgABrEAA= Date: Fri, 30 May 2014 17:07:30 +0000 Message-ID: References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> In-Reply-To: <15749590.z7A0vHW603@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [216.145.54.15] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 469652008 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jPiI8wSlX6QKNATyij17LVAqLD0 Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 17:09:02 -0000 On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: >DMARC change is even more off the table than MLM software change (which >does, >as you suggest, evolve over time). DMARC changes are not off the table for Yahoo. Right now, the option that best serves the majority of our customers is one that also has unpleasant consequences for a significant number of people (our customers and others). We would vastly, vastly prefer a world where that was not true, or even where it was less true. So changes that maintain effective protection for users who are being targeted by attackers with addressbook information, with less disruption to email that people want, are of great interest to us. Elizabeth Zwicky zwicky@yahoo-inc.com From nobody Fri May 30 10:20:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922D91A6F99 for ; Fri, 30 May 2014 10:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGV_c8BaL2iZ for ; Fri, 30 May 2014 10:20:38 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E208A1A02C9 for ; Fri, 30 May 2014 10:20:37 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2592D9560C1; Fri, 30 May 2014 13:20:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401470433; bh=BOt+jcxoxFUtYeV51Wiob91TKS65Rv6PgFQxsynfXKE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=JOLYM3n5ncdIeNmdW9/IEgXFGfqf+VcY3wsZDAsLqxNqve4Ns9h4OCNl/UIpDPPlo s3yKDF0EmeoYlCLdMJIeQO4j/Xtyng5/dH5dKs5lwew4MB1qbnJuKqTyhVG2ii/xb9 /ZdU0wttEMBiwojzHhBjbgPOClx7EQa2tT0Ut22A= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 068D89560BB; Fri, 30 May 2014 13:20:33 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 30 May 2014 13:20:32 -0400 Message-ID: <5499220.jluVr8Oysk@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: <15749590.z7A0vHW603@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ihmsvyrooP1IK-wKE6P71lkGyng Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 17:20:39 -0000 On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote: > On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: > >DMARC change is even more off the table than MLM software change (which > >does, > >as you suggest, evolve over time). > > DMARC changes are not off the table for Yahoo. Right now, the option that > best serves the majority of our customers is one that also has unpleasant > consequences for a significant number of people (our customers and > others). We would vastly, vastly prefer a world where that was not true, > or even where it was less true. > So changes that maintain effective protection for users who are being > targeted by attackers with addressbook information, with less disruption > to email that people want, are of great interest to us. Great. Then instead of submitting DMARC as is via a non-IETF process, let's have a working group chartered to do that work. I'm glad to hear it. Scott K From nobody Fri May 30 11:17:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C648C1A045E for ; Fri, 30 May 2014 11:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsBBD0CnPcMu for ; Fri, 30 May 2014 11:17:46 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E15F1A036A for ; Fri, 30 May 2014 11:17:46 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id la4so2533796vcb.1 for ; Fri, 30 May 2014 11:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7GWZZ6KePreJi5/TENOU3rf13RS48xw3ji1GKnGySXE=; b=O52dOWiho1CraKX2F75e0BQ5SLXUERcrcEzhfmcx7f4znq+M0zrPs3tTm9/OgtNWFG 2OQTwQGwlt8seRg+UXHOeB5bMS+h9LTClPlslK6ablKsi6KB8LjwggZPkyn0ogoT/mvI qpSdy6tAB5+nEc8CGa1jVQVNM2Ab5Ql0yQkKI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=7GWZZ6KePreJi5/TENOU3rf13RS48xw3ji1GKnGySXE=; b=k4AMPTo/t8XoQXYIGXQj7vsdtEwJr/L1tkdEjX173qUYhPpbnMGk3EKnkbvSypBVMa JT+CIBoEdtl/4Nm8W/S0//PiYZ409kdp7ZDlEM/MEYNFBe4MchkaZF5gl2WByokViKOI nznxqjlbJX5Xf2Id5Yp5rZkoNwuHfOwc020pkgQ7ATdaO61U/dnhBWDa7C03cHPGrK7v pZLJ5kTjaviT6b/G9FF7LINSK8JDKRNv1eAuB8qcAgyB7+wy+LsL8EoZSYoUbjIISBCB /HV3p35wSz/Oo2LIGpqV6C0avPRlS+N+GllsxyeDcOJmHZgZeNYbc65o/mBThlRo112k EqYQ== X-Gm-Message-State: ALoCoQlC6WFGzAMjq/YmDmyBRZB4rwVcnfQazM2bVmDNrZFVyiLWh54QGRvz3bpYCXr92v9uSPCj X-Received: by 10.52.154.241 with SMTP id vr17mr13143609vdb.40.1401473861459; Fri, 30 May 2014 11:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.69.20 with HTTP; Fri, 30 May 2014 11:17:21 -0700 (PDT) X-Originating-IP: [50.0.158.243] In-Reply-To: <69138421-9EA4-4189-9252-F36AE7082258@eudaemon.net> References: <20140528163723.63860.qmail@joyce.lan> <69138421-9EA4-4189-9252-F36AE7082258@eudaemon.net> From: John Sweet Date: Fri, 30 May 2014 11:17:21 -0700 Message-ID: To: Tim Draegen Content-Type: multipart/alternative; boundary=bcaec51a8e2aacbce604faa20fa7 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/qTKRgyF6DgjePAOaNQvMt0w6YXQ Cc: "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] Non-solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 18:17:49 -0000 --bcaec51a8e2aacbce604faa20fa7 Content-Type: text/plain; charset=UTF-8 There's probably no point in coding a patch unless you feel the people responsible for the codebase are likely to apply it. That's a lot of effort down a rathole, especially since some number of the intended audience feel that it's inappropriate to ask them to change anything in their software. It's probably more constructive to offer dev time, since a lot of these packages are volunteer projects. "Once you decide what you want to do, if you need developers, we'll provide one half-time on your project for as long as it takes." It might be even better to offer some QA/test help. A lot of volunteer-only projects tend to lag on the unit/regression test front. J On Fri, May 30, 2014 at 2:12 AM, Tim Draegen wrote: > On May 29, 2014, at 3:05 AM, John R Levine wrote: > > Really, that makes no difference. I don't want Yahoo or anyone else to > pay us to screw up our mail software to work around them -- I want them to > spend their money to fix things so we don't have to. > > Yes, I get it, I guess in my own jaded way I don't think there is any > amount of money that Yahoo and AOL can spend that will fix things (because > email isn't owned by Yahoo or AOL). BUT, if Yahoo or AOL is willing to > experiment, let that experiment be me! > > I replied to Doug earlier (not yet in archive), and hashed out my own > thinking around how much domain owners can do vs. how to address > "legitimate-but-unauthorizable" email. > > TLDR summary: addressing "legitimate-but-unauthorizable" mail is my answer > to Scott Kitterman's question: "How do we define the scope of work for this > list?". > > > > > > Yahoo, in their own blog, estimates there are 30,000 mail systems that > they have damaged by their DMARC actions. I would be surprised if there > were more than a few hundred mail systems acting on DMARC policies, > although some of those are very, very large. Is it that hard to understand > why someone might think it was unreasonable to demand that the 30,000 make > changes of no benefit to themselves, rather than the few hundred fix their > buggy fussp? > > I don't think there is/was a way for Yahoo to fix the estimated few > hundred mail systems acting on DMARC policies, especially since most are > not controlled by Yahoo. Maybe they could have published a list of 30,000 > mail systems that are white-listed, but wouldn't that just be a publication > of 30,000 holes to exploit? > > The absolute most work I could imagine Yahoo and AOL having done would > have been to analyze and publish a series of articles/guidance on how > impacted email can be fixed, complete with accessible patches to all known > mailing systems. THEN, give the entire internet enough time to apply said > patches. This is my unicorn. > > For the next 10 years, I'm going to attempt to recreate this unicorn. > > > > > The 30K estimate is probably low, since there are likely many small mail > systems they aren't aware of but that they are damaging. For example, > yesterday a middle school teacher who found my old Dummmies web site wrote > to me out of the blue to say that his web form that lets students and > parents send mail to him stopped working for AOL and Yahoo addresses, which > just disappear. It took about two seconds to figure out what was wrong > when he told me that his script sends mail to his Gmail account. I told > him what was wrong, and he did a hack that sticks in a fake From: address, > so the mail gets through but now his script works worse since he can't > write back without extra effort. If he hadn't written to me, he'd probably > never have figured out what was wrong. These are real people who are > really hurt by the two providers' actions. > > In a similar vein, there are a fair number of businesses that do stuff > like encapsulate their customer mail with bling (fancy headers, pictures, > footers w/ disclaimers... "stationary"), and they're having to figure out > how to maintain their service when sending on behalf of clients with Yahoo > and AOL addresses. > > What is missing is "how am I supposed to do this right"? I'm not being > glib, there's a real vacuum due to email being what it is, and it's a > vacuum that I personally don't think corporations can/should fill. > > -= Tim > > > > > Regards, > > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > > Please consider the environment before reading this e-mail. > > > > PS: Here endeth the rant. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- "We've learned some important lessons about Democracy. After 100 years, you have to let your slaves go. And after 150, you have to let your women vote." (Kurt Vonnegut) --bcaec51a8e2aacbce604faa20fa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's probably no point in coding a patch unles= s you feel the people responsible for the codebase are likely to apply it. = That's a lot of effort down a rathole, especially since some number of = the intended audience feel that it's inappropriate to ask them to chang= e anything in their software.

It's probably more constructive to offer dev time, since a lo= t of these packages are volunteer projects. "Once you decide what you = want to do, if you need developers, we'll provide one half-time on your= project for as long as it takes." It might be even better to offer so= me QA/test help. A lot of volunteer-only projects tend to lag on the unit/r= egression test front.

J

On Fri, May 30, 2014 at 2:12 AM, Tim Draegen <tim@= eudaemon.net> wrote:
On May 29, 2014, at 3:05 AM,= John R Levine <johnl@taugh.com&g= t; wrote:
> Really, that makes no difference. =C2=A0I don't want Yahoo or anyo= ne else to pay us to screw up our mail software to work around them -- I wa= nt them to spend their money to fix things so we don't have to.

Yes, I get it, I guess in my own jaded way I don't think there is= any amount of money that Yahoo and AOL can spend that will fix things (bec= ause email isn't owned by Yahoo or AOL). =C2=A0BUT, if Yahoo or AOL is = willing to experiment, let that experiment be me!

I replied to Doug earlier (not yet in archive), and hashed out my own think= ing around how much domain owners can do vs. how to address "legitimat= e-but-unauthorizable" email.

TLDR summary: addressing "legitimate-but-unauthorizable" mail is = my answer to Scott Kitterman's question: "How do we define the sco= pe of work for this list?".


>
> Yahoo, in their own blog, estimates there are 30,000 mail systems that= they have damaged by their DMARC actions. =C2=A0I would be surprised if th= ere were more than a few hundred mail systems acting on DMARC policies, alt= hough some of those are very, very large. Is it that hard to understand why= someone might think it was unreasonable to demand that the 30,000 make cha= nges of no benefit to themselves, rather than the few hundred fix their bug= gy fussp?

I don't think there is/was a way for Yahoo to fix the estimated f= ew hundred mail systems acting on DMARC policies, especially since most are= not controlled by Yahoo. =C2=A0Maybe they could have published a list of 3= 0,000 mail systems that are white-listed, but wouldn't that just be a p= ublication of 30,000 holes to exploit?

The absolute most work I could imagine Yahoo and AOL having done would have= been to analyze and publish a series of articles/guidance on how impacted = email can be fixed, complete with accessible patches to all known mailing s= ystems. =C2=A0THEN, give the entire internet enough time to apply said patc= hes. =C2=A0This is my unicorn.

For the next 10 years, I'm going to attempt to recreate this unicorn.

>
> The 30K estimate is probably low, since there are likely many small ma= il systems they aren't aware of but that they are damaging. For example= , yesterday a middle school teacher who found my old Dummmies web site wrot= e to me out of the blue to say that his web form that lets students and par= ents send mail to him stopped working for AOL and Yahoo addresses, which ju= st disappear. =C2=A0It took about two seconds to figure out what was wrong = when he told me that his script sends mail to his Gmail account. =C2=A0I to= ld him what was wrong, and he did a hack that sticks in a fake From: addres= s, so the mail gets through but now his script works worse since he can'= ;t write back without extra effort. =C2=A0If he hadn't written to me, h= e'd probably never have figured out what was wrong. =C2=A0These are rea= l people who are really hurt by the two providers' actions.

In a similar vein, there are a fair number of businesses that do stuf= f like encapsulate their customer mail with bling (fancy headers, pictures,= footers w/ disclaimers... "stationary"), and they're having = to figure out how to maintain their service when sending on behalf of clien= ts with Yahoo and AOL addresses.

What is missing is "how am I supposed to do this right"? =C2=A0I&= #39;m not being glib, there's a real vacuum due to email being what it = is, and it's a vacuum that I personally don't think corporations ca= n/should fill.

-=3D Tim

>
> Regards,
> John Levine, johnl@taugh.com, T= aughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
>
> PS: Here endeth the rant.

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



--
"We've learned some important lessons about Democracy. After= 100 years, you have to let your slaves go. And after 150, you have to let = your women vote." (Kurt Vonnegut)
--bcaec51a8e2aacbce604faa20fa7-- From nobody Fri May 30 11:25:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B831A043F for ; Fri, 30 May 2014 11:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_ni0Tg_9E6q for ; Fri, 30 May 2014 11:25:48 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7D41A036A for ; Fri, 30 May 2014 11:25:48 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id il7so2528229vcb.18 for ; Fri, 30 May 2014 11:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5q2zLIj/M1PS6LofFSmfCIz1yiM05LnKdbNeb/3rJ1w=; b=SHSUPxgUg/ZGoWn6xYNaWg9Eazhn/UHcT0wP2Fa1HyOvq+uh9GPXaSvjtQxEWCm8lg +OZwl98raivsGfNJPWH1WQFncwWgvrfYMYw4+RWDB1t1OsGfJdd7ZJNwi4PpVCj7+kgC uGSS7D1y0ynF+tR2oV8hf+n9tOxi1P6MiTMnA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5q2zLIj/M1PS6LofFSmfCIz1yiM05LnKdbNeb/3rJ1w=; b=AgdeiGn2quIxKqlNhiBXd2n+ydwkXw4D5gmV2yy5BzZ2q23ya/uKa0WtHFJCqyM7VM wv+0hVatJoatUyHqSin9DTNh7FlfGJQ84jFk1rLzvu9FlrL3+oiea7b8EdiusOOI42zw jVPQR3CyHlb1ZzyNLaKwx6BOKQ/INqQiGVvjA8LG1qsFdw8BC2mRVWJGLACekTwFWS2N 0PD+UxpfakjRwP9I9b09WuVCmhCJENlmc5MXjDOaQblubWUPA27ReAK8ETRMePDitl05 axFlsAPs937qqMsjCPkQOOgI1KvKAiY07M/ev0XfGXUGdAoBfsMvD7hB4Iy+t8tWq9k3 Rciw== X-Gm-Message-State: ALoCoQmicLerx07VsNGi2lWBi8zBAJN7V0cNFsAPFTJnFfvoI+cOWNkZo73GX6AZNJEaIEtr4NGO X-Received: by 10.58.216.34 with SMTP id on2mr15923040vec.22.1401474343805; Fri, 30 May 2014 11:25:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.69.20 with HTTP; Fri, 30 May 2014 11:25:23 -0700 (PDT) X-Originating-IP: [50.0.158.243] In-Reply-To: References: <1401436925.52759.YahooMailNeo@web164603.mail.gq1.yahoo.com> From: John Sweet Date: Fri, 30 May 2014 11:25:23 -0700 Message-ID: To: Brandon Long Content-Type: multipart/alternative; boundary=047d7b6d85746cb93204faa22ccb Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/pcisN0I2P9gzz3w1ykigyeyMK-Q Cc: Vlatko Salaj , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 18:25:50 -0000 --047d7b6d85746cb93204faa22ccb Content-Type: text/plain; charset=UTF-8 On Fri, May 30, 2014 at 1:31 AM, Brandon Long wrote: > I think many of the folks on this list don't use email the way that the > vast majority of people do. > The longer I work in email, the less I feel as though there's any consensus in how it is used, beyond the bare minimum required for it to interoperate. Sort of interoperate. Most of the time. J --047d7b6d85746cb93204faa22ccb Content-Type: text/html; charset=UTF-8
On Fri, May 30, 2014 at 1:31 AM, Brandon Long <blong@google.com> wrote:
I think many of the folks on this list don't use email the way that the vast majority of people do.

The longer I work in email, the less I feel as though there's any consensus in how it is used, beyond the bare minimum required for it to interoperate. Sort of interoperate. Most of the time.

J
--047d7b6d85746cb93204faa22ccb-- From nobody Fri May 30 11:27:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEFF1A0902 for ; Fri, 30 May 2014 11:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0w_9wUtHK68R for ; Fri, 30 May 2014 11:27:55 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BC21A043F for ; Fri, 30 May 2014 11:27:55 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id x48so2424080wes.36 for ; Fri, 30 May 2014 11:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Am3yopra/fsneZDlMtcJD+w+XuMXCY0HT64XTg2og2A=; b=ELU2yqqGc4GpvbwhdlaFmNmz9TRHD3gG9MZSq6ecX9+zK0ONpIo599wQibrtPL1sON k6KSy077qXuPQpSMOF0BSgAc6lNGT0Vv2A8ao6EtVKFpsgs20MPhjMuX7sU1WWYaWzGq mhINbQzXHOPh3fBk8yDZBsbTJcf0o8oBmL/a387zIsrFyxzv2k09VnRwRgV4XlI/DfXf JFZWOFHQXbJfccv6AaSGUKS4LvUOdF+D3pzrtHWMXUAR/1ZvY7jm4EUuyjS2qWVFIL5q zuQlmXtNurVQozwEjed6nyGEnaNoYMppuPCfnHlQNCUPi85O8cO7vJCEKawo+ttDOmC1 tzdQ== MIME-Version: 1.0 X-Received: by 10.180.75.102 with SMTP id b6mr9332127wiw.26.1401474470049; Fri, 30 May 2014 11:27:50 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Fri, 30 May 2014 11:27:49 -0700 (PDT) In-Reply-To: References: <1401436925.52759.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Fri, 30 May 2014 11:27:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Sweet Content-Type: multipart/alternative; boundary=f46d04389155f3014c04faa23381 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WS4Tmq2slU2dfM2hkdwS8gFTvIg Cc: Brandon Long , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 18:27:56 -0000 --f46d04389155f3014c04faa23381 Content-Type: text/plain; charset=UTF-8 On Fri, May 30, 2014 at 11:25 AM, John Sweet wrote: > On Fri, May 30, 2014 at 1:31 AM, Brandon Long wrote: > > I think many of the folks on this list don't use email the way that the >> vast majority of people do. >> > > The longer I work in email, the less I feel as though there's any > consensus in how it is used, beyond the bare minimum required for it to > interoperate. Sort of interoperate. Most of the time. > "Everyone you meet is fighting a battle you don't understand." --f46d04389155f3014c04faa23381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 30, 2014 at 11:25 AM, John Sweet <sweet@se= condlook.com> wrote:
On Fri, May= 30, 2014 at 1:31 AM, Brandon Long <blong@google.com> wrote:<= br>

I think many of the folks o= n this list don't use email the way that the vast majority of people do= .

The longer I work in email, the less= I feel as though there's any consensus in how it is used, beyond the b= are minimum required for it to interoperate. Sort of interoperate. Most of = the time.

"Everyone you meet = is fighting a battle you don't understand."
=C2=A0
--f46d04389155f3014c04faa23381-- From nobody Fri May 30 11:28:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CCF1A0A50 for ; Fri, 30 May 2014 11:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.009 X-Spam-Level: ** X-Spam-Status: No, score=2.009 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGwK5NsCXbAn for ; Fri, 30 May 2014 11:28:10 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 897641A043F for ; Fri, 30 May 2014 11:28:10 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id BB50F970AF2; Sat, 31 May 2014 03:28:05 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AD7D711F235; Sat, 31 May 2014 03:28:05 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 31 May 2014 03:28:05 +0900 Message-ID: <871tvb6s0a.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xrL5xfdoppkOvqLR-gnxSgx-264 Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 18:28:12 -0000 Murray S. Kucherawy writes: > > DMARC change is even more off the table than MLM software change > > (which does, as you suggest, evolve over time). > > Are there changes people want to make? I am of the opinion that the technical DMARC protocols (including "p=reject") are fine. I have not heard of any complaint about use by banks (Bank of America joined the ranks of "p=reject" banks some time in the last 10 days AFAICT). Have there been any? I'm sure that the probability of technical bugs in the protocols remaining is not zero, but I imagine they'll be fixed as discovered. I believe that is also the opinion of the Mailman developers (specifically, they've seen a document where I expressed a similar opinion and generally expressed approval of the document as a whole). The issue is use of "p=reject" by ESPs whose users think they can send mail to anywhere they want. I would like the logical consequences of unilateral publication of "p=reject" without prior arrangement with *all* possible relays spelled out. Something like: Publishing a DMARC policy including "p=reject" has the following consequences. Users who attempt to 1. post to a mailing list 2. use QuickBooks 3. send content to a friend from the Wall Street Journal etc, etc may find their message bounces or is silently discarded. This is expected according to the DMARC specification when faithfully implemented, even when all services in all domains are functioning normally and in conformance to all relevant Internet standards. ESPs SHOULD notify their users of these consequences at the time of publishing a policy including "p=reject". N.B. I haven't discussed this with the Mailman community, but I suspect they would approve. As a technical specification of what the ESP refuses to fully support by publishing "p=reject", I think the list Franck Martin posted is a pretty good start. To ESPs who object, "But that's not what we meant!" I reply, "I know. But Code is Law, everything else is cheap talk. Those are the results *your* protocol and *your* policy say *your* users should expect. Why don't you want to tell them about it? After all, you're doing it for them. Your users will undoubtedly be overjoyed to discover how hard you are fighting spam on their behalf, right?" From nobody Fri May 30 11:48:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEA21A0168 for ; Fri, 30 May 2014 11:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIgZlnAsl7Vf for ; Fri, 30 May 2014 11:48:36 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 669901A0164 for ; Fri, 30 May 2014 11:48:36 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id b6so1924207yha.18 for ; Fri, 30 May 2014 11:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AVd75T+BS+Ja4WqCxBJDAskmAEvrlUcjgWuG9f1ZhGQ=; b=mRI6tbAqfbNdSLACxBbm5bCvwx3E9oWOkCDOXsK1iVr5pPuGpDFSe3/vhuWHfKCczQ A4e8RtM1YafGN53HaRPUAj9y6XldMjILI+HquqDfd/E0uh2DafJ+4CDjcVFVYH5ZFAPk hI8zRTSIvBOEYT1rO0b6a0c+t/vJ6z4NI7/nGgetc+yKGS+tXddjtHG7Jiq0cE6ion5/ tD9PFrLrdlJB7gCvPCyyUCYBX+d7F3XUIWkat1ePHf9za3b+TRaNvAXHGWCEatxoRzAl MGzlHFtdvjaFKBuPSivHu3Yal2E3kJrrsw9zKGDBsUBjBIFVzu2zTOve8J7KG/WEXzTu oBpQ== X-Received: by 10.236.136.69 with SMTP id v45mr12257066yhi.112.1401475711826; Fri, 30 May 2014 11:48:31 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id 63sm7283520yhi.13.2014.05.30.11.48.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 11:48:30 -0700 (PDT) Message-ID: <5388D253.9070907@gmail.com> Date: Fri, 30 May 2014 11:47:47 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , John Sweet References: <1401436925.52759.YahooMailNeo@web164603.mail.gq1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/pXztbjeHhTPnjc11ztQBW6bAkxM Cc: Brandon Long , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 18:48:37 -0000 On 5/30/2014 11:27 AM, Murray S. Kucherawy wrote: > On Fri, May 30, 2014 at 11:25 AM, John Sweet > wrote: > The longer I work in email, the less I feel as though there's any > consensus in how it is used, beyond the bare minimum required for it > to interoperate. Sort of interoperate. Most of the time. > > > "Everyone you meet is fighting a battle you don't understand." s/most/some/ but that's probably because i don't understand... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 30 11:59:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F291A03E9 for ; Fri, 30 May 2014 11:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQnQYbRQuvI9 for ; Fri, 30 May 2014 11:59:48 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AEF1A0254 for ; Fri, 30 May 2014 11:59:48 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s4UIxaSJ012164 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 30 May 2014 11:59:42 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s4UIxaSJ012164 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1401476382; bh=9IbBh7gKSwXTZYO01kROjru/I2x+inqmWajrtKlf+C4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GxMJLQ+E0hSJvgoD6fbEegFtWemaSCmF09idGDqsexEruA2X97daeA4XQUKHAFcyl 2SxQyXYh5LRUsK5TLi+kkOADbn10Lo5VFNzIv4RiLLFXji3UBOOEJAuKNz6UMMr4NL 4L4tZejxj0Entv4qFDNYDcQyRzwr4SNcUOCIlPyU= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <5388D51A.2050602@crash.com> Date: Fri, 30 May 2014 11:59:38 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <1401449452.50909.YahooMailBasic@web160506.mail.bf1.yahoo.com> In-Reply-To: <1401449452.50909.YahooMailBasic@web160506.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Fri, 30 May 2014 11:59:42 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HgCuCCkWqBBbBiSmNsL5RnDqRHc Cc: jazzme48912@yahoo.com Subject: Re: [dmarc-ietf] Fw: Re: Comportment on this list X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 18:59:51 -0000 On 05/30/2014 04:30 AM, eugene hayhoe wrote: > > "Most people with a personal mail account aren't on any mailing > lists." > > > I AM on several, and the ONLY reason I am here is to try and figure > out why so many people like myself have been COMPLETELY > 'disrespected' with these 'policies.' > > ... > > not to mention the pain of > being forced to jump from email provider to email provider > every few days 're-subscribing' to lists which I had > previously been on for years. I don't think this is a situation anybody is happy to see, no matter how they feel about DMARC in general or the policies certain mailbox providers have adopted in particular. I assume we're all here because we value email as a service and want to see it continue to be viable. Differences seem to come in perception of how much that viability is under threat from the truly amazing number of ways email is currently subject to fraud and abuse, and what progress has/hasn't been made (or can/can't be made) in areas like email authentication. > While I might be in support of working on the spam/fraud issue, my > ''Yahoo spam'' has actually INCREASED at least 5 fold since this > 'improvement' began, As a general rule, not everybody is impacted equally, or at the same time, by abusive activity (spam, phishing, etc). If your address is on their list(s) you get it, and if it isn't you may not notice anything happening while others are severely impacted. And next day/week/month that situation may flip. At least consider the possibility that - perhaps - you are now seeing, at whichever mailbox, the impact of the wave of abuse Yahoo was originally trying to stop. No, I don't have the numbers or patterns of behavior. And unfortunately I don't really expect a public company to be able to share anything too detailed, given the way lawsuits get tossed around. --Steve. From nobody Fri May 30 14:49:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAAD1A06B8 for ; Fri, 30 May 2014 14:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCH3EmhpqX4L for ; Fri, 30 May 2014 14:49:41 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2793A1A0383 for ; Fri, 30 May 2014 14:49: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.298.1; Fri, 30 May 2014 23:49:33 +0200 Message-ID: From: "J. Gomez" To: "Stephen J. Turnbull" References: <20140528163723.63860.qmail@joyce.lan><728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org><87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> <8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Fri, 30 May 2014 23:49:05 +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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CaziZcZWSj6D5RIn4V0l8D64jgk Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 21:49:43 -0000 On Friday, May 30, 2014 12:09 PM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > Missuse of DMARC's p=3Dreject by Senders is here to stay. It won't = go > > away. It will only grow.[*] >=20 > I'm not so sure. Anyway, that doesn't mean we need to sanction it. To maneuver towards being interoperable with something (the misuse of = DMARC's p=3Dreject as a sad fact of life), does not equal sanctioning = that something. Furthermore, what is more important - to deserve or not to deserve the = prize of being sanctioned as kosher, or keeping a world-wide system = interoperable? > > In my opinion, the least disruptive adaptation which mailing list > > software can do is to take ownership --in a DMARC-compatible way-- > > of the Header-From, >=20 > I disagree. The least disruptive adaption is whatever the users of > the mailing list think is the least disruptive adaptation. That's why > Mailman provides multiple mitigation options, and will probably add > more as we think of them or they're contributed to us. Yes, that is true. But a default out-of-the-box always has to exist, and = in my opinion that default should be the most interoperable which is = possible --interoperable with the real world, not with how we would like = the world to be--, while keeping as much valuable features as possible, = and while keeping operator's duties as straight forward and simple as = possible. > > just like they already take ownership of the envelope's > > ReturnPath-From. >=20 > Ah, but "just like" is a complete misstatement of the situation. > There's a big difference. Users on a mailing list think of the > poster, not the mailing list, as responsible for the content. So > according to RFC 5322, the poster's mailbox belongs in From:. > Remailed or not, the author belongs there. That is debatable. As long as the mailing list program tampers with the = message's content, rendering its DKIM signature invalid, it can be = argued that the mailing list program is rewriting the message's content, = and therefore that the mailing list program now becomes "the system = responsible for the writing of the message" (as per RFC 5322 parlance, = section 3.6.2), and thus the mailing list address would earn its = legitimate place in the Header-From field, making interoperability with = rogue DMARC Senders a solved problem. Regards, J.Gomez From nobody Fri May 30 15:08:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B36F1A8881 for ; Fri, 30 May 2014 15:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wnb2_TcT6ps0 for ; Fri, 30 May 2014 15:08:55 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6204D1A8878 for ; Fri, 30 May 2014 15:08:55 -0700 (PDT) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 31 May 2014 00:08:49 +0200 Message-ID: From: "J. Gomez" To: Brandon Long References: Date: Sat, 31 May 2014 00:08:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01CF7C64.6EABF250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3_UORRMndp0yn1l_sOFfJQF4S_c Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Yet another mailing list solution thread X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 22:08:56 -0000 ------=_NextPart_000_007B_01CF7C64.6EABF250 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Brandon Long wrote: > What can mailing lists do today >=20 >=20 > 1) Reject posting from p=3DREJECT users > 2) Re-write From header for p=3DREJECT/QUARANTINE users > 3) Don't break the DKIM signature (no subject prefix, no footer) > 4) Recognize DMARC reject bounce messages and don't consider them as > reason to unsubscribe users=20 > 5) Add a sender header and sign their messages with DKIM > 6) Add an Authentication-Results header with the auth-results for the > post. Consider adding an OAR header as well (though, this may be > premature). =20 >=20 > (snip) > #2 could potentially use some finessing or standardization. For > example, several MLMs are moving the original From header to > X-Original-From, I could also imagine a List-Original-From or > List-Poster header. Standardizing on that would allow clients to do > intelligent things about the display of the two pieces of > information, or handling reply-to better. I think #2 is the way to go, and in my opinion for consistency that = re-write of the From header should be done to all messages relayed = trough the list, irrespective of the Sender's published DMARC policy. = This also would make DMARC-checking a task = not-for-the-mailing-list-program, which is better because it's simpler. In my opinion, all the other options are either too complex, too = expensive, or depend on non-encouraged third parties whose collaboration = is doubtful. Regards, J.Gomez ------=_NextPart_000_007B_01CF7C64.6EABF250 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Brandon Long wrote:
> What can mailing lists do today
> =
>
> 1) Reject posting from p=3DREJECT users
> 2) = Re-write From=20 header for p=3DREJECT/QUARANTINE users
> 3) Don't break the DKIM = signature=20 (no subject prefix, no footer)
> 4) Recognize DMARC reject bounce = messages=20 and don't consider them as
> reason to unsubscribe users
> = 5) Add a=20 sender header and sign their messages with DKIM
> 6) Add an=20 Authentication-Results header with the auth-results for the
> = post. =20 Consider adding an OAR header as well (though, this may be
>=20 premature). 
>
> (snip)
> #2 could potentially use some finessing or=20 standardization.  For
> example, several MLMs are moving the = original=20 >From header to
> X-Original-From, I could also imagine a=20 List-Original-From or
> List-Poster header.  Standardizing on = that=20 would allow clients to do
> intelligent things about the display = of the=20 two pieces of
> information, or handling reply-to better.
 
I think #2 is the way to go, = and in my=20 opinion for consistency that re-write of the From header should be=20 done to all messages relayed trough the list, irrespective of the = Sender's=20 published DMARC policy. This also would make DMARC-checking a = task=20 not-for-the-mailing-list-program, which is better because it's=20 simpler.
 
In my opinion, all the other = options are=20 either too complex, too expensive, or depend on non-encouraged third = parties=20 whose collaboration is doubtful.
 
Regards,
J.Gomez
 
------=_NextPart_000_007B_01CF7C64.6EABF250-- From nobody Fri May 30 15:23:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996511A096B for ; Fri, 30 May 2014 15:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3iMx8e3Cbmd for ; Fri, 30 May 2014 15:23:11 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A0BD1A8888 for ; Fri, 30 May 2014 15:23:11 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s4UMMwOw014636 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 30 May 2014 15:23:03 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s4UMMwOw014636 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1401488583; bh=/vIo7QWFyVilgWSKTV5rcuk3/Kx2RAvbF7jTXuJrfpg=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SoAzGNwf3XD+iPgADt8g5kYQTKXCBJDnxjtuCQDRKF0U+gKtDGKb1gIxBDxk1Brtt Buq3E/rXkdRDjC9ie8Zzz9SHIuR8hCw6DHBmBIe5jqXJK6PCMvtp+eQwduTXyFuGCa 80QsmZI5Ie5JMtv5BYn5Az48ms5XazziRCJ8FMjs= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <538904C4.4000502@crash.com> Date: Fri, 30 May 2014 15:23:00 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> <871tvb6s0a.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <871tvb6s0a.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Fri, 30 May 2014 15:23:03 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/VGoD2aFGT5-bL3_-dk0Pmh_ANiU Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 22:23:14 -0000 On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote: > I am of the opinion that the technical DMARC protocols (including > "p=reject") are fine. I have not heard of any complaint about use by > banks (Bank of America joined the ranks of "p=reject" banks some time > in the last 10 days AFAICT). Have there been any? Disclosure: Technically I could be considered on BofA payroll through tomorrow. In essence I stopped being their employee earlier this year. While BofA does have some domains with "p=reject" they had not, so far as I know, published such a policy on a domain that sent email as part of a product or service. There were at least two product teams that were working to do so, and one of them had a "p=quarantine" published but hadn't solidified plans of when they would start sending email. The fact that this hadn't happened by nearly two years after the first release of the DMARC spec was not because I wasn't pushing for it... If you really want to know, I would look for anecdotes around JPMChase, who managed to publish "p=reject" for many if not all of their most visible production domains over a year ago, if I have the timeframe right. But I'm not aware of any complaints about DMARC when used in the manner you're referring to. --Steve. From nobody Fri May 30 16:44:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C841A0685 for ; Fri, 30 May 2014 16:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.602 X-Spam-Level: X-Spam-Status: No, score=-100.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4voJa7OX6mC for ; Fri, 30 May 2014 16:44:24 -0700 (PDT) Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A6DDB1A0636 for ; Fri, 30 May 2014 16:44:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2095; t=1401493455; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=U5d7l1cg9upgs+LGXykC08v0Tgo=; b=WMd5VXwWjpQE292nQ6Bq o11Pf/8C9CH2a9ZCIiu4iK4dNM5TiDf8dnAM7xN9/5XZKTC18YGU3nWEMOCE4Bhk Qcxz0RpCvoAmO1L2uNtXpSUqOeY9Ao513D3LSyJTtC2s5vaJ25k1R/TGpTuhYhc0 jetdVMb5tpihHXEJF6ZXGj0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 30 May 2014 19:44:15 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 973588277.356.2380; Fri, 30 May 2014 19:44:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2095; t=1401493307; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LbYeAvw Wtv2vqFg1sNA7cnyvCkqrxViG6eWE0HOhaAA=; b=2XDjj28cOmKkHxV92ON90x7 DtQTE7+iFJ8YjfPyLv177RDkpHmVHAKG7KhmqhnYUXawMcGtExF7J8KSZzcW/5kV m/ljcvM6tTDOyQgqrlrHnedJ2vUcfgCRKmwc9y17Vu87G8nSTXWarpw7mOc731YE lblgeR5wTs4SMQX/FVzM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 30 May 2014 19:41:47 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 989954171.9.5760; Fri, 30 May 2014 19:41:46 -0400 Message-ID: <538917D0.7040604@isdg.net> Date: Fri, 30 May 2014 19:44:16 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140528163723.63860.qmail@joyce.lan><728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org><87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> <8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/a1WhBtulYuhqzpW1hqdwMDeDMoI Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 30 May 2014 23:44:30 -0000 On 5/30/2014 5:49 PM, J. Gomez wrote: >> Ah, but "just like" is a complete misstatement of the situation. >> There's a big difference. Users on a mailing list think of the >> poster, not the mailing list, as responsible for the content. So >> according to RFC 5322, the poster's mailbox belongs in From:. >> Remailed or not, the author belongs there. > > That is debatable. As long as the mailing list program tampers with the message's content, rendering its DKIM signature invalid, it can be argued that the mailing list program is rewriting the message's content, and therefore that the mailing list program now becomes "the system responsible for the writing of the message" (as per RFC 5322 parlance, section 3.6.2), and thus the mailing list address would earn its legitimate place in the Header-From field, making interoperability with rogue DMARC Senders a solved problem. > In my book, this is mail tampering. It will be hard to justify adding support for this radical behavior in our mail list server product which puts customers at risk. You are putting yourself at product liability risk but intentionally defying a security protocol against the wishes of the publishing restrictive domain. Of course, its only becomes a problem when its used as a loophole to further spread harmful mail and someone actually gets harmed. Thats all you have to prove in a courtroom. If you had all the tools before you to tell you definitively, "This is unauthorized mail" and you intentionally, deliberately and neglectfully ignore it, do nothing about it but further distribute to end points, well, who knows what a young punk, tech savvy, high tech, new age lawyer will think about suing you. If you got deep pockets, well, don't think it can't happen. It is this sort of mentality that completely makes this old game no more fun to work with. Seriously. We can do it right. All we have to do is LOOKUP the policy and follow it. Give the YAHOOs the tools to authorize the resigners and you and I won't have these new ethical problems to content with. -- HLS From nobody Fri May 30 18:41:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9462A1A06C3 for ; Fri, 30 May 2014 18:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owBehFIoARV4 for ; Fri, 30 May 2014 18:41:35 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235C21A02BE for ; Fri, 30 May 2014 18:41:35 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s4V1fN84016400 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 30 May 2014 18:41:28 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s4V1fN84016400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1401500488; bh=32JENaXiKMS6x/4gG7cbUz0Ijcn5ZPYoav3ULfbpk7I=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=X3oLH1PJgHYAPj3H+Sr3qyrC+h6WFLoqmz1wAd0q8PGz66Aq3/6MQAd3CBUyoicTh XzEE3ZyMhu+p/ukwkKQ8zzYdDxwQe5QUqaZkgakjHmGSTLgMwcPgnH+/jnW+tMGj2S 3MZFJusp7q7REYItKGwAvwLVm8+1Q4WGAgo6qzX4= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <53893345.7020405@crash.com> Date: Fri, 30 May 2014 18:41:25 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> <871tvb6s0a.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <871tvb6s0a.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Fri, 30 May 2014 18:41:28 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wQ-5qqTZqS7qndoL5Zj7tb39ktw Subject: [dmarc-ietf] New DMARC WG, was Re: DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 01:41:36 -0000 On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote: > Murray S. Kucherawy writes: > > > > DMARC change is even more off the table than MLM software change > > > (which does, as you suggest, evolve over time). > > > > Are there changes people want to make? > > I am of the opinion that the technical DMARC protocols (including > "p=reject") are fine. ... I'm sure that the > probability of technical bugs in the protocols remaining is not zero, > but I imagine they'll be fixed as discovered. Yes, technical bug probability aside, it works well and at scale, and has for more than two years. Speaking strictly for myself, I expected DMARC and/or other specs and practices to evolve such that together they would support more use cases overall. The need to address those areas was well understood and was commented on publicly for quite a while, even if it wasn't adequately documented in the spec. Unfortunately previous activity to establish an IETF working group - where I had thought that evolution would happen - failed. The upshot was that the expected development didn't happen, and DMARC has been effectively static. In the meantime the large scale abuse of email continued to morph, to the point where DMARC was seen as the least harmful option to address a pernicious trend. I would like to see an IETF working group formed, so that we maintain the use cases where DMARC is currently effective and support additional use cases where it currently isn't. > I would like the logical consequences of > unilateral publication of "p=reject" without prior arrangement with > *all* possible relays spelled out. I agree that a solid list of known consequences would be good. And I'm sure it will grow beyond what any of us expect... --Steve. From nobody Fri May 30 18:46:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699651A0671 for ; Fri, 30 May 2014 18:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7bB4FAfDWNW for ; Fri, 30 May 2014 18:46:55 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259A71A02BE for ; Fri, 30 May 2014 18:46:55 -0700 (PDT) Received: from [10.10.10.41] (70-36-157-26.static.sonic.net [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id s4V1khv0016476 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 30 May 2014 18:46:48 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com s4V1khv0016476 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1401500808; bh=S4qzPwPb3mUlZ1ix6t0awv6MGMgvpF3PXPsAXeB6i+c=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=EvoGl3CZJaKIzs3N0rmgHpRb+3FPnqG0moxad1aFYS15ab8eBGKcNxWMaoGwYtCN+ hkjwwqZlpXNl7/eQ4peb179rxoi75Q/zclMomUDxabmTkpesOfiuyrQQp5Mqi3aVSW jzjq4H6LrRZpfFYi9bgpPhcVMEOqVKOoIawtzeQk= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.static.sonic.net [70.36.157.26] claimed to be [10.10.10.41] Message-ID: <53893485.70408@crash.com> Date: Fri, 30 May 2014 18:46:45 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: dmarc@ietf.org References: <15749590.z7A0vHW603@scott-latitude-e6320> <5499220.jluVr8Oysk@scott-latitude-e6320> In-Reply-To: <5499220.jluVr8Oysk@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Fri, 30 May 2014 18:46:48 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/OSSrtmPydz7XE4vsZL6krbpQ4mE Subject: [dmarc-ietf] New DMARC WG, was Re: DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 01:46:56 -0000 On 05/30/2014 10:20 AM, Scott Kitterman wrote: > On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote: >> On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: >>> DMARC change is even more off the table than MLM software change >> DMARC changes are not off the table for Yahoo. ... > Great. Then instead of submitting DMARC as is via a non-IETF process, let's > have a working group chartered to do that work. The Independent Submissions stream is an IETF process. However it does not involve a working group. Whether due to too much concern over potentially incompatible changes, or too much alarm at the language used to try to avoid it, past attempts to form a working group failed. More than one attempt was made. The Independent Submission stream was not the first choice. I have wanted to see DMARC - and any other necessary protocols - become the subject of a working group for two years. I hope we can find a way to make that happen. --S. From nobody Fri May 30 19:50:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95821A06F5 for ; Fri, 30 May 2014 19:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEj8hRGMgZKg for ; Fri, 30 May 2014 19:50:12 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674F31A06EF for ; Fri, 30 May 2014 19:50:12 -0700 (PDT) Received: (qmail 73764 invoked from network); 31 May 2014 02: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:references:mime-version:content-type:user-agent:cleverness; s=12023.5389435b.k1405; bh=Ol+V5u6Di1sotpEuTTnHxe3Gke1cguzu11RuMMMbakg=; b=PYWBsvNdkta/HRZlTFhw9nic5777fXDltZtWkYzCH+ybHpkAI5ADRuuKdrtymNMzVcCat/D+ZtNG+E2bEFUxoV/grNX8Xt8S2825XDPCT/PPSpHGBrObloICx0OIcuDGiZ4hNsLItVJkrBrZbb40RPiQCwBociQ5w2GLE/zqM3al1oXQH+0Qwwiwxs/KJD/TRr7NOJIXR1GoWdVKvtRjyykGaT1omCwk9jSfBjQ5gPcl5Zm9gDaaGm5y7Jmbb/Y6 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=12023.5389435b.k1405; bh=Ol+V5u6Di1sotpEuTTnHxe3Gke1cguzu11RuMMMbakg=; b=xvzHq5TNvyDARl3F6CAcXRBm1OOThEkEf9aZt8oaSzOgcZAb+mM72YHLTCuGceu93WVVO56wE41PgV4GnPlXGAbgdfx/+mgi9oPhGEMXCliIGk06ehprVjBVAqxWmh+E99aGsniy28kKhMVEsIaNNnilPcmz+/OApe5JwOoFV3e3VzbKPfWgWhzHGjELq5FcAGY1hWA9jv6bzi3/+4iNpJGy3qvNRSTEI8Skh6824PRnSGAtMtDwWtOhZ6SHLVoc Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 31 May 2014 02:50:03 -0000 Date: 30 May 2014 19:50:02 -0700 Message-ID: From: "John R Levine" To: "Tim Draegen" In-Reply-To: <69138421-9EA4-4189-9252-F36AE7082258@eudaemon.net> References: <20140528163723.63860.qmail@joyce.lan> <69138421-9EA4-4189-9252-F36AE7082258@eudaemon.net> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p08WjmMM20KrT09y1LSCGNO8xbA Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Non-solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 02:50:14 -0000 > TLDR summary: addressing "legitimate-but-unauthorizable" mail is my answer to Scott Kitterman's question: "How do we define the scope of work for this list?". Yup. > Yes, I get it, I guess in my own jaded way I don't think there is any > amount of money that Yahoo and AOL can spend that will fix things > (because email isn't owned by Yahoo or AOL). BUT, if Yahoo or AOL is > willing to experiment, let that experiment be me! ... Sounds good. > I don't think there is/was a way for Yahoo to fix the estimated few > hundred mail systems acting on DMARC policies, especially since most are > not controlled by Yahoo. Maybe they could have published a list of > 30,000 mail systems that are white-listed, but wouldn't that just be a > publication of 30,000 holes to exploit? Um, wait. Are we doing experiments or not? In answer to your second question, well, no. There's no reason to think that "can't be described by DMARC" is related to "insecure". A lot of them, like the WSJ and the schoolteacher who wrote to me, don't even have inbound MTAs to attack. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri May 30 20:10:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FD51A0710 for ; Fri, 30 May 2014 20:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CL_2MvilZg0Q for ; Fri, 30 May 2014 20:10:31 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9AB11A067F for ; Fri, 30 May 2014 20:10:31 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id fp1so1569483pdb.10 for ; Fri, 30 May 2014 20:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HWf2eoLxkvvx8wWQoG91P/u3Shg9gm/a2DB6Fk/ePuQ=; b=VN4ZxxTgHBV8eqcKRDz5Hx7soH2lZ4fTGuhp+5thPQRYzC6G+YC9GWpdl5I5P/izQ8 dhzY4UMPxUVEIJ8KPJbDEbilqlW7DKKzU4jxHGPLuaHqPKazC5nyOIP8IH+bVoJroGGG xiGbVIltxNvubsQWRetAkFsFPXM6arKASgBSzMdoJF0D7ITHs6ZEHaPjXtWPbQ+W1RNo BbrAZtbIvA/12hiQV+oAIqBYuLRg6AuVadivG0s6U28BR7g6sAXNkhzdGSwA14EAXXKi 5djz6FGaM3Od4bhvenW+zB3NdUhFhxj9ymhhQRMNSSO+83s2L1IvrJeVdQZJGimlY4PP Agqw== X-Received: by 10.68.250.3 with SMTP id yy3mr23862861pbc.56.1401505827274; Fri, 30 May 2014 20:10:27 -0700 (PDT) Received: from dhcp150.priv.bungi.com (c-24-4-159-60.hsd1.ca.comcast.net. [24.4.159.60]) by mx.google.com with ESMTPSA id ir10sm8734409pbc.59.2014.05.30.20.10.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 20:10:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <53893485.70408@crash.com> Date: Fri, 30 May 2014 20:10:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <73D6E6E9-6D2D-4B42-B51A-C0B90BDFDA4E@gmail.com> References: <15749590.z7A0vHW603@scott-latitude-e6320> <5499220.jluVr8Oysk@scott-latitude-e6320> <53893485.70408@crash.com> To: Steven M Jones X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9fI4GUe5Z9F1pDhRdH1wzIYHeNw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] New DMARC WG, was Re: DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 03:10:33 -0000 On May 30, 2014, at 6:46 PM, Steven M Jones wrote: > On 05/30/2014 10:20 AM, Scott Kitterman wrote: >> On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote: >>> On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: >>>> DMARC change is even more off the table than MLM software change=20 >>> DMARC changes are not off the table for Yahoo. ... >> Great. Then instead of submitting DMARC as is via a non-IETF = process, let's=20 >> have a working group chartered to do that work. >=20 > The Independent Submissions stream is an IETF process. However it does > not involve a working group. >=20 > Whether due to too much concern over potentially incompatible changes, > or too much alarm at the language used to try to avoid it, past = attempts > to form a working group failed. More than one attempt was made. The > Independent Submission stream was not the first choice. >=20 > I have wanted to see DMARC - and any other necessary protocols - = become > the subject of a working group for two years. I hope we can find a way > to make that happen. Dear Steven, I agree with this view. I am confident a fairly effective protocol can = allow a DMARC domain to communicate whether another domain forwards = their messages. This could be seen as a type of federation similar to = how single-sign-on works. Once such abilities have been instantiated = between the domain asserting DMARC and the domain enforcing DMARC, = nothing else really needs to change. There would be less concern about = the negative impact DMARC could have on other email uses. Since this communication would serve a very small faction of overall = email traffic from a DNS perspective, DNS should be fine. Results could = be cached for 300 seconds or more to improve scaling and at the same = time reduce latency. Even then, DMARC feedback would be a minor = fraction of email related DNS traffic. =20 Not offering feedback would be analogous to a parent denying the = existence of their own children then having them fend for themselves. = This attitude burdens receivers lacking knowledge about which exceptions = are valid. No other domain should offer these answers. With that said, DNAME would = also allow several DMARC domains to select a common feedback zone. It = seems this would be close to what John Levine described, except each = DMARC domain would be their own trust anchor for all their related email = traffic. Regards, Douglas Otis= From nobody Fri May 30 20:11:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FE61A0725 for ; Fri, 30 May 2014 20:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FzRbP4fP8Ub for ; Fri, 30 May 2014 20:11:24 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585121A067F for ; Fri, 30 May 2014 20:11:24 -0700 (PDT) Received: (qmail 76700 invoked from network); 31 May 2014 03:11:19 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 31 May 2014 03:11: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=95e.53894857.k1405; i=johnl@user.iecc.com; bh=oOoY2dhqw7nmcxa64A69svXQK4+eTHkDoEXShDXw0sg=; b=ZbSE149PpRuAjudm8DQERtgqxnCDqrl/eHNIbqcMJFIbeBBuBbWGO/YXlH8fLAFzfqSoEmCtCl1FvU0dcnBPnV3EboXJaDkviLOq+10zNPr7GDhCuUU/UOoBsqjnGuCaDVlAotFRXUpyS7oApCNyi5sapj7bf4rwk9Llqj8AYl58I9oRxS4SBajxB7HoaI7qGCL/m0Vb2gCr7E+8eb1CsjUJ3qI2trb0J2YUePe2Pa3eE014O7dA3exX5ukNL0vm 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=95e.53894857.k1405; olt=johnl@user.iecc.com; bh=oOoY2dhqw7nmcxa64A69svXQK4+eTHkDoEXShDXw0sg=; b=i5XXtxuQT8Z7uDN47/Lwjm9ytw2fu4aUs5DYBIBrWEmgz7xG3WehF3O85nNKwoxTSZkkoT/+Kep3dfn78SNs/Gf/doOVNRqG02dCPSYTEt5LkVKQqbHCgJ8uYD0EHgXBPM0zGbudONZ5SPrfxeJ/6OxT9Ua7tV1Ceae3IGxqDePuYYFpGJ6BSgQnYxKPZxl1urqLAHy5G1qVtISzzrJHX8ADm4NZeCs6lvs2Y9JktK5YCi6hUNtTsQCf+bypfNeZ Date: 31 May 2014 03:10:56 -0000 Message-ID: <20140531031056.2397.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: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0wfKVFCoWAjGcbDjJVNYENbWUkU Cc: blong@google.com Subject: Re: [dmarc-ietf] Yet another mailing list solution thread X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 03:11:33 -0000 >1) Support Original-Authentication-Results. This requires the MLM to add >them in the first place, and for the DMARC enforcing domains to check them. > Has an open question of how best to "trust" the OAR header on a message. > Options there are explicit whitelists from the sending domains (tpa-labels >or whatever) or to leave it up to the individual receiving domain. This keeps reducing to the previous case. If you know what senders you trust, why do you need the OAR header? R's, John From nobody Sat May 31 01:09:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CBF1A0438 for ; Sat, 31 May 2014 01:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIaTM1K77Zew for ; Sat, 31 May 2014 01:09:06 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDCBE1A035D for ; Sat, 31 May 2014 01:09: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.298.1; Sat, 31 May 2014 10:08:58 +0200 Message-ID: From: "J. Gomez" To: Hector Santos References: <20140528163723.63860.qmail@joyce.lan><728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org><87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> <8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> <538917D0.7040604@isdg.net> Date: Sat, 31 May 2014 10:08: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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xkquUW65cfqqn3qcVxmb9vwN4Yo Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 08:09:08 -0000 On Saturday, May 31, 2014 1:44 AM [GMT+1=3DCET], Hector Santos wrote: > On 5/30/2014 5:49 PM, J. Gomez wrote: >=20 > > > Ah, but "just like" is a complete misstatement of the situation. > > > There's a big difference. Users on a mailing list think of the > > > poster, not the mailing list, as responsible for the content. So > > > according to RFC 5322, the poster's mailbox belongs in From:. > > > Remailed or not, the author belongs there. > >=20 > > That is debatable. As long as the mailing list program tampers with > > the message's content, rendering its DKIM signature invalid, it can > > be argued that the mailing list program is rewriting the message's > > content, and therefore that the mailing list program now becomes > > "the system responsible for the writing of the message" (as per RFC > > 5322 parlance, section 3.6.2), and thus the mailing list address > > would earn its legitimate place in the Header-From field, making > > interoperability with rogue DMARC Senders a solved problem. =20 >=20 > In my book, this is mail tampering. It will be hard to justify adding > support for this radical behavior in our mail list server product > which puts customers at risk. You are putting yourself at product > liability risk but intentionally defying a security protocol against > the wishes of the publishing restrictive domain. I am not sure I am following you here. =20 When I say that mailing list programs should take ownership of the = Header-From if they tamper with the original message content rendering = its DKIM signature invalid, and that this behavior should happen = irrespective of the original Sender's published DMARC policy, I am not = saying that mailing list programs should relay to its subscribers fake = or phishing email from unverified sources. =20 It would go something like this: 1.Sender -> 2.MTA at mailing list host -> 3.ML processes message -> 4.ML = program relays message. DMARC/DKIM/SPF checking should happen at stage 2, not at stage 3. = Fake/phishing email should be detected and rejected at stage 2, and only = clean legitimate email should arrive at stage 3, and at that point the = mailing list program would "do its work" adding subject tags, body = footers, AND taking ownership of the Header-From (hopefully indicating = the original Sender in the description inside the Header-From), and then = go to step 4 and relay to the list members that message. And "that = message" would be a clean, wanted, legitimate email which ALSO would = solve the DMARC issues with mailing lists. =20 The only check the mailing list program should do (step 3) is to = ascertain whether the original Sender is or is not a subscribed address. = Checking the validity/authentication of that address belongs to step 2 = and to the MTA just before the mailing list program sees the message. =20 So I think that your worries of "putting customers at risk" are not = warranted, unless I do not understand what you are saying. > It is this sort of mentality that completely makes this old game no > more fun to work with. Seriously. Please, do not get frustrated. It is not helpful to the conversation. Regards, J.Gomez From nobody Sat May 31 05:19:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0601A088B for ; Sat, 31 May 2014 05:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmH50q-ABXuV for ; Sat, 31 May 2014 05:19:00 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id C42C01A0874 for ; Sat, 31 May 2014 05:18:59 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 1B691970B29; Sat, 31 May 2014 21:18:54 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0A13211F235; Sat, 31 May 2014 21:18:53 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: References: <20140528163723.63860.qmail@joyce.lan> <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> <87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> <8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 31 May 2014 21:18:53 +0900 Message-ID: <87sinq5efm.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mTvwRxClUPDsDVfjrmdI0M8SpCU Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 12:19:01 -0000 J. Gomez writes: > Furthermore, what is more important - to deserve or not to deserve > the prize of being sanctioned as kosher, or keeping a world-wide > system interoperable? In the face of bullying by large operators counting on the fact that ostracizing them would seriously annoy millions of *our* users and customers, I think calling it "bullying" is one of the more important steps we can take to keep that system interoperable. > Yes, that is true. But a default out-of-the-box always has to > exist, and in my opinion that default should be the most > interoperable which is possible --interoperable with the real > world, not with how we would like the world to be--, while keeping > as much valuable features as possible, and while keeping operator's > duties as straight forward and simple as possible. There's interoperability and there's interoperability. GNU Mailman has a feature such that (1) a DNS query checks for "p=reject" and (2) if found, the message is wrapped as a message/rfc822 part in a message from the mailing list and containing the header (if any) and footer (if any) as separate MIME parts. This is fully RFC conformant (it's basically a one-message digest) and almost all MUAs should be able to handle it. It is what I propose as default for Mailman. Do you see any defects in that proposal? > > according to RFC 5322, the poster's mailbox belongs in From:. > > Remailed or not, the author belongs there. > > That is debatable. As long as the mailing list program tampers with > the message's content, rendering its DKIM signature invalid, it can > be argued that the mailing list program is rewriting the message's > content, It can be and is argued, but the argument is clearly incorrect. The most recent RFCs state quite clearly that "same message" is in the eye of the users, and I cannot imagine that addition of a "[list]" tag to Subject or an unsubscribe footer to the message body would be interpreted by anyone involved in the list as making the list the author. Steve From nobody Sat May 31 06:07:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149C21A08B5 for ; Sat, 31 May 2014 06:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.509 X-Spam-Level: * X-Spam-Status: No, score=1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, MANGLED_FROM=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGLVUyHbcxMu for ; Sat, 31 May 2014 06:07:12 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 105671A08B1 for ; Sat, 31 May 2014 06:07:11 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id E052B970B30; Sat, 31 May 2014 22:07:06 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D25AB11F235; Sat, 31 May 2014 22:07:06 +0900 (JST) From: "Stephen J. Turnbull" To: Brandon Long In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 31 May 2014 22:07:06 +0900 Message-ID: <87r43a5c79.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KvSFv66Mz8UipXQ0477UgO5WKio Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Yet another mailing list solution thread X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 13:07:14 -0000 Brandon Long writes: > 1) Reject posting from p=REJECT users +1 <0.2 wink> > It seems like [ignoring DMARC bounces when checking if the > recipient is able to receive] should be relatively uncontroversial, Mailman is already working on this. Unfortunately, some domains just use a generic 5.7.x policy bounce, and other don't even give you that much information. (We are guessing, but backtracking to the sender -- you don't always even get that information -- and correlating with other DMARC bounces, we're pretty sure that these are DMARC bounces.) > messages would be rejected... Perhaps we should agree on an > extended smtp status code that such rejections should use in order > to make this easier to implement. This will take years to diffuse into the installed base, and some sites have this boneheaded idea that giving any information about why a message was rejected harms their security, so won't implement anyway. > [Rewriting From:] could potentially use some finessing or > standardization. For example, several MLMs are moving the original > From header to X-Original-From, I could also imagine a > List-Original-From or List-Poster header. Standardizing on that > would allow clients to do intelligent things about the display of > the two pieces of information, or handling reply-to better. The *last* thing we want is clients doing anything intelligent with any of those headers. The problem that DMARC addresses has nothing to do with the letters F-R-O-M. It has to do with identity alignment. It just happens that RFC5322 (and predecessors) standardized From: for conveying originatory identity. So as soon as MUAs start displaying Use-This-Field-To-Bypass-DMARC: to users, DMARC will *need* to be revised to sign that one, too -- with a signature authorized by the Author Domain, *not* the ML domain. This of course is impossible without Doug Otis's TPA-labels or something like that. > What can DMARC enforcing domains do right now: > 1) Whitelist mailing lists from enforcement. This is obviously a hole in > DMARC which lowers the overall utility. Its basically saying "we don't > trust your p=REJECT, we'll sometimes downgrade it to p=QUARANTINE". That horse already left the barn. I don't know what GMail's criterion is, but our testing demonstrates that some mailing list posts are passed through to the spam folder rather than rejected. I don't understand what you mean by "lowers overall utility". In fact, it's quite clear from the way Yahoo! is advocating various mitigation strategies that they really do not mean DMARC reject, they mean Do-What-I-Mean reject. That's what GMail gives them. For the others, I agree with John Levine's comments. From nobody Sat May 31 07:38:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3E91A08D0 for ; Sat, 31 May 2014 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 683oaaD_ULNH for ; Sat, 31 May 2014 07:38:04 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 189581A08C9 for ; Sat, 31 May 2014 07:38:03 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id DC8DD970B30; Sat, 31 May 2014 23:37:58 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CCA5811F235; Sat, 31 May 2014 23:37:58 +0900 (JST) From: "Stephen J. Turnbull" To: Elizabeth Zwicky In-Reply-To: References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 31 May 2014 23:37:58 +0900 Message-ID: <87ppiu57zt.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/X8KW5SOFKYMwRKGOo8IvNLNCZA8 Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 14:38:05 -0000 Elizabeth Zwicky writes: > So changes that maintain effective protection for users who are > being targeted by attackers with addressbook information, with less > disruption to email that people want, are of great interest to us. How about trying "p=quarantine" with a real short TTL just in case? After a while you crank it back up to the current level (which is only 1800 in any case). The argument is that, seriously, since the attackers have addressbook information, you're done for anyway. They're already hard at work on Plan B, using "I'm writing this from my friend's account" with self in Sender: (should work well on Outlook users despite having on-behalf-of point the wrong direction), and ... Heck, I've already thought of a dozen of these dodges and my name isn't even Laurence Canter. I think it's worth a check to see if the miscreants will bother to come back at you with the previous style of spam shot even though they should expect that the vast majority of their spam will get rejected anyway (messages apparently from a "p=quarantine" domain should be given a rough time as encouraged by the DMARC protocol), and the rest will end up in spam folders. I would think trying to avoid DMARC entirely would now be the best use of their resources, so maintaining quarantine should be enough. There may be some directly relevant recent evidence on this, since GMail is evidently promoting mailing list traffic from "p=reject" domains to "quarantine". If the spammers know this, they could continue targeting GMail customers in their stolen addressbook database. Dunno if GMail will tell Yahoo!, but you could ask. BTW I hope you guys are basing "p=reject" (vs. "p=quarantine") on real data on how often fraudulent mail that ends up in spam folders actually succeeds in harming the targeted victim. From nobody Sat May 31 09:35:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2C71A0019 for ; Sat, 31 May 2014 09:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-Yg9rUOga0J for ; Sat, 31 May 2014 09:35:00 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6241A0016 for ; Sat, 31 May 2014 09:35:00 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 69F55D04669; Sat, 31 May 2014 12:34:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401554094; bh=+mDF8lNRWrjhEIgmY462sdP47F94HPFwT3VKc1/3ayg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=tVAPEY2186MzIpyzgpgToexvECaH+SnxrmjCKlDc8wwCQveynnbt0BuMt8HE+HoS2 Y3BWdknOCWA5+k0ATzkBAlteB/qnFzVnxznF6RITNBYBE0nFB6UU5t8b+2yFXPWxJ5 bxrxXEjyIeRlj0vfSoikeRP6mATGnlvK6igWaqKs= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3E1C3D04667; Sat, 31 May 2014 12:34:53 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 31 May 2014 12:34:54 -0400 Message-ID: <1852273.lOLu4VvKdx@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: <53893485.70408@crash.com> References: <5499220.jluVr8Oysk@scott-latitude-e6320> <53893485.70408@crash.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dgUnUye2JYHgCrwEfxEC9MWMw9A Subject: Re: [dmarc-ietf] New DMARC WG, was Re: DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 16:35:01 -0000 On Friday, May 30, 2014 18:46:45 Steven M Jones wrote: > On 05/30/2014 10:20 AM, Scott Kitterman wrote: > > On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote: > >> On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: > >>> DMARC change is even more off the table than MLM software change > >> > >> DMARC changes are not off the table for Yahoo. ... > > > > Great. Then instead of submitting DMARC as is via a non-IETF process, > > let's have a working group chartered to do that work. > > The Independent Submissions stream is an IETF process. However it does > not involve a working group. No. It's not. That's why it's independent. There's no IETF consensus for Independent Submissions, only a very (by design) limited role for the IESG to do conflict reviews. This may seem like nit picking, but for doing work @ietf.org, it's a quite important one, IMO. Scott K From nobody Sat May 31 10:48:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B8A1A004C for ; Sat, 31 May 2014 10:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgL0QlFOLdrz for ; Sat, 31 May 2014 10:48:30 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3D91A0051 for ; Sat, 31 May 2014 10:48: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.298.1; Sat, 31 May 2014 19:48:22 +0200 Message-ID: <0C0E0190C23D47278475CC7D87F98808@fgsr.local> From: "J. Gomez" To: "Stephen J. Turnbull" References: <20140528163723.63860.qmail@joyce.lan><728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org><87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp><8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> <87sinq5efm.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sat, 31 May 2014 19:48:54 +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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/O1pZWu0Ur5b-Bc9uvSn3a0fXFQg Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 17:48:32 -0000 On Saturday, May 31, 2014 2:18 PM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > J. Gomez writes: >=20 > > Furthermore, what is more important - to deserve or not to deserve > > the prize of being sanctioned as kosher, or keeping a world-wide > > system interoperable? >=20 > In the face of bullying by large operators counting on the fact that > ostracizing them would seriously annoy millions of *our* users and > customers, I think calling it "bullying" is one of the more important > steps we can take to keep that system interoperable. I don't mind calling it bullying, but I would not focus on that, but on = the interoperability side of the issue. Users won't care about the politics of the email system, but about = relevant and wanted email landing on their inbox -- hopefully in an = easily readable manner. > > Yes, that is true. But a default out-of-the-box always has to > > exist, and in my opinion that default should be the most > > interoperable which is possible --interoperable with the real > > world, not with how we would like the world to be--, while keeping > > as much valuable features as possible, and while keeping operator's > > duties as straight forward and simple as possible. >=20 > There's interoperability and there's interoperability. GNU Mailman > has a feature such that (1) a DNS query checks for "p=3Dreject" and = (2) > if found, the message is wrapped as a message/rfc822 part in a message > from the mailing list and containing the header (if any) and footer > (if any) as separate MIME parts. This is fully RFC conformant (it's > basically a one-message digest) and almost all MUAs should be able to > handle it. It is what I propose as default for Mailman. >=20 > Do you see any defects in that proposal? That proposal is fine from a technical point of view - it solves the = problem and is interoperable. However, that proposal is not perfect from = a usability point of view - how well will an attached message/rf822 part = be legible when the final recipient is using webmail, or a mobile device = with a simple MUA? - how much a non-technical user will freak out when = he gets such a message from a mailing list? - will he call the help desk = about it, incurring support costs and being a burden for that help desk? = - will that proposal unnecessarily consume time in the Recipient side of = the communication, basically off-loading into the final innocent = Recipient the cost of solving "the DMARC issue"? - is that proposal = convoluted for the final Recipient's comfort? =20 I guess that once the interoperability issue is agreed to be important, = now the ergonomics of the proposed solution should get the focus. And = that proposal is not very ergonomical, in my humble opinion. > > > according to RFC 5322, the poster's mailbox belongs in From:. > > > Remailed or not, the author belongs there. > >=20 > > That is debatable. As long as the mailing list program tampers with > > the message's content, rendering its DKIM signature invalid, it can > > be argued that the mailing list program is rewriting the message's > > content, >=20 > It can be and is argued, but the argument is clearly incorrect. The > most recent RFCs state quite clearly that "same message" is in the eye > of the users, and I cannot imagine that addition of a "[list]" tag to > Subject or an unsubscribe footer to the message body would be > interpreted by anyone involved in the list as making the list the > author. If DKIM signatures were not involved, you would be right. Now that DKIM = signatures are indeed involved, and considered useful in the email = ecosystem, any tampering with a message's content means taking = responsibility of the result of such tampering, therefore taking = ownership of the Header-From. Regards, J.Gomez From nobody Sat May 31 10:51:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF281A004D for ; Sat, 31 May 2014 10:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTR3rNYMPcmO for ; Sat, 31 May 2014 10:51:31 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0961A004C for ; Sat, 31 May 2014 10:51:31 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7F743970AF2; Sun, 1 Jun 2014 02:51:26 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5C3BB11F235; Sun, 1 Jun 2014 02:51:26 +0900 (JST) From: "Stephen J. Turnbull" To: Tony Hansen In-Reply-To: <5387F6E0.1070903@att.com> References: <5387F6E0.1070903@att.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 01 Jun 2014 02:51:26 +0900 Message-ID: <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/aHpB_O9hE19wXgEo7ZpfRShS2E0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 17:51:33 -0000 Tony Hansen writes: >> That doesn't help the DMARC situation now, but DMARC could be >> given other options once that happens. > > I agree completely that a change to DMARC is needed in conjunction > with having clear ML specs. A change to the protocol? What? I don't see it. The protocol actually in use by many domains seems to actually do what it's designed for quite well. "p=reject" makes a lot of sense for banks, for example. I don't think it can be removed from the spec, and its proper use doesn't cause widespread problems for mailing lists. It's use outside the design space that causes problems. Those uses are by desperate organizations, and they'll ignore any change that attempts to prohibit them because they are desperate. > I've heard it said that the majority of the mailing lists out there > are managed by only a handful of ML management systems. I maintain > that these ML packages are in the same boat as openssl. It sure > would be nice if we could get some of that consortium money thrown > at that handful of ML management systems. I'm sorry, but that's nonsense for the volunteer-maintained MLMs like GNU Mailman. We already have implemented multiple mitigations, and it doesn't take much code. We just hate them all and leave it up to mailing list operators to choose the one they dislike least. If other MLMs haven't done so already, I doubt it involves all that much effort for them. > That's a political solution for this current technical problem. Mailing lists don't have a *technical* problem. If DMARC were used as designed, we'd never have noticed. The problem is political: we have a wounded 800-lb gorilla on the loose (not to forget a wounded 500-lb gorilla joining the fun). > However, before it can happen: we NEED clear specs as to what > should be done by ML systems, at least in the face of DKIM and SPF > (and DMARC) SPF and DKIM are now ancient history, at least as far as Mailman development goes. We've already done what's technically possible. We'll see what more our users want us to do about DMARC, if anything. There just isn't anything technical to be done AFAICS. I can't speak for other MLMs, but I think that if there's going to be real progress, the answer is with the MUAs. 1. If identity alignment fails, *all* links, scripts, and forms in the message should be deactivated, even if it's already in the spam folder. 2. If there's a type=password field in the message, *all* links and forms in the message should be deactivated, even if it's already in the spam folder. 3. Ditto misaligned MIME type and file name. 4. Ditto active or unknown attachments. 5. On activation of the message, all href and src URIs should be displayed clearly, along with an intrusive warning that ID theft is very common, so the user should check everything carefully (preferably call the author on the phone) before doing anything suggested by the message, even if it's already in the spam folder. I'm sure there are other things they could do, but those are off the top of my head. Finally, Tim Draegen is right, it's not just about mailing lists. Let's not forget all the other use cases that are stomped on by the inappropriate use of "p=reject". Steve From nobody Sat May 31 12:13:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47BB1A0005 for ; Sat, 31 May 2014 08:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX-CMO_LCR-4 for ; Sat, 31 May 2014 08:49:34 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id BF2C71A0004 for ; Sat, 31 May 2014 08:49:33 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 95645970B25; Sun, 1 Jun 2014 00:49:28 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8153611F235; Sun, 1 Jun 2014 00:49:28 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <4B556652-E552-4EF7-8513-B008D8CD1ED2@gmail.com> References: <87ppiw7k5x.fsf@uwakimon.sk.tsukuba.ac.jp> <4B556652-E552-4EF7-8513-B008D8CD1ED2@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 01 Jun 2014 00:49:28 +0900 Message-ID: <87ioom54on.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CmuFkoRfZK0BcHh-JR34OdyiyfY X-Mailman-Approved-At: Sat, 31 May 2014 12:13:43 -0700 Cc: Brandon Long , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 15:49:35 -0000 Douglas Otis writes: > https://community.intuit.com/questions/899989-please-make-quickbooks-pass-the-dmarc-evaluation-please-do-this-quickly Grr. Doesn't describe the problem! Is it that a QuickBooks client using a mailbox at a "p=reject" domain is having QuickBooks send invoices on their behalf? If that's it, I have a great deal for them. Register a domain and get their company name, instead of Yahoo!'s, in From:. Or (cheaper), Quickbooks just checks for "p=", and if so overrides any company-specific config, and puts QuickBooks in From: (with a working "p=reject" policy, even!), "Your invoice from " in subject, and the company address in Reply-To. Even supposing the company doesn't like either of those options, it's not clear to me that the "p=reject" domain is going to necessarily be happy trusting QuickBooks, even once TPA-Labels gets implemented. > I know of many small operations with similar services and > previously working strategies. Much less so the effort required to vette a million small operations (who could actually be the Yahoo! customer requesting a TPA-label for a vendor they use -- how does TPA-label deal with collusion between authors and relays?) So, yeah, I sympathize with the Mom & Pop shops whose kids go hungry this month because the bills didn't go out, and with the small operations tearing their hair out because they've got a thousand paying customers at Yahoo! whose content isn't arriving at destination, but I really don't see TPA-Labels as a solution to this problem yet. > > Again, I seem to require an additional clue. DMARC feedback is > > working fine AFAICS. It may be costly, and we want to reduce those > > costs, of course. But "p=reject" OTOH is a more or less legitimate > > denial of service, a completely different issue. Are you talking > > about a different kind of feedback? > > Rather than having a channel only between receiver-to-sender, there > should also be a channel between sender-to-receiver. We already have such a channel (the _dmarc subdomain). What is this new channel for? From nobody Sat May 31 12:45:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B382D1A008E for ; Sat, 31 May 2014 12:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN7kwBnuWH8u for ; Sat, 31 May 2014 12:45:01 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 109FB1A008D for ; Sat, 31 May 2014 12:45:00 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id D4C39970AF2; Sun, 1 Jun 2014 04:44:55 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C16C911F235; Sun, 1 Jun 2014 04:44:55 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <0C0E0190C23D47278475CC7D87F98808@fgsr.local> References: <20140528163723.63860.qmail@joyce.lan> <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> <87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> <8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> <87sinq5efm.fsf@uwakimon.sk.tsukuba.ac.jp> <0C0E0190C23D47278475CC7D87F98808@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 01 Jun 2014 04:44:55 +0900 Message-ID: <87d2et68co.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IutToIjEwPx1-CG4WQQKbv6rPtY Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 19:45:02 -0000 J. Gomez writes: > Users won't care about the politics of the email system, but about > relevant and wanted email landing on their inbox -- hopefully in an > easily readable manner. If you have users like that, configure your lists accordingly. The options are available (in GNU Mailman, at least). > That proposal is fine from a technical point of view - it solves > the problem and is interoperable. However, that proposal is not > perfect from a usability point of view - how well will an attached > message/rf822 part be legible when the final recipient is using > webmail, Works fine in GMail and SquirrelMail, IIRC (another developer did the testing). > is that proposal convoluted for the final Recipient's comfort? No. The proposal is intended to ensure delivery of messages posted from an ESP whose DMARC policy is in conflict with mailing list policy, with the message as posted by the author and modified by the mailing list, and comfortably readable in any MUA conforming to RFC 1341 (published in June 1992). A more pleasant reading experience is available in MUAs conforming to RFC 1806 (June 1995). If the list operator knows that she has users with MUAs that don't conform to 20-year-old standards, she can change the options easily at any time. > I guess that once the interoperability issue is agreed to be > important, now the ergonomics of the proposed solution should get > the focus. And that proposal is not very ergonomical, in my humble > opinion. So tell the MUA developers about it. It takes a moderate amount of code to DTRT with nested MIME parts and Content-Disposition: inline, but it's not rocket science, not compared with supporting text/html. From nobody Sat May 31 14:43:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105181A00F0 for ; Sat, 31 May 2014 14:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wto0Ix-quhJx for ; Sat, 31 May 2014 14:43:30 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB731A00EA for ; Sat, 31 May 2014 14:43:30 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id kx10so2914559pab.28 for ; Sat, 31 May 2014 14:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AzTm8fr3RLIL0XECHj2boQNzZNeL9UOI+4q9JIKXPmU=; b=gBI10h/k2iT9w6fI/hfBfly/Woudogxo9vBnwpe3hiPeKsF0svyA28yMi9Pl42hLLi 9qcAm4twq/2MCihGVMSnlNQBxsLVBmetQlxTl4YFlHS4Mg8rGBFvvZ08mhFDVLgTD/Av zdQNEMDqJN+qIJH8BHS7jpAr0c9nSAG+8ku6Afa8RseeujpJvIrAHEosP47hk26ID5Ru RDJ34a81Dtv4lCkdVAwe86R00HhzPBGf3LkEDhd9xnHbqYeZPpBBy9guVqhZUh4FTJ9Z E2IJDVhUem8tZJHCOEkSAg/5C1Y7u6x0Oq5+fWMKT0it7P2mhMMieyLYfuYvHLX+bMbx as7g== X-Received: by 10.68.224.101 with SMTP id rb5mr29160661pbc.135.1401572605547; Sat, 31 May 2014 14:43:25 -0700 (PDT) Received: from justsomecomcastuser.selfip.org (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id nx12sm39213677pab.6.2014.05.31.14.43.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 31 May 2014 14:43:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <87ioom54on.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sat, 31 May 2014 14:43:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <20087AF8-1A7B-410F-92A7-3AE4CB4488AE@gmail.com> References: <87ppiw7k5x.fsf@uwakimon.sk.tsukuba.ac.jp> <4B556652-E552-4EF7-8513-B008D8CD1ED2@gmail.com> <87ioom54on.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3eectX8rlzLsW18acWk_q_N482o Cc: Brandon Long , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] DKIM through mailing lists X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 31 May 2014 21:43:32 -0000 On May 31, 2014, at 8:49 AM, Stephen J. Turnbull = wrote: > Douglas Otis writes: >=20 >> = https://community.intuit.com/questions/899989-please-make-quickbooks-pass-= the-dmarc-evaluation-please-do-this-quickly >=20 > Grr. Doesn't describe the problem! Is it that a QuickBooks client > using a mailbox at a "p=3Dreject" domain is having QuickBooks send > invoices on their behalf? >=20 > If that's it, I have a great deal for them. Register a domain and get > their company name, instead of Yahoo!'s, in From:. >=20 > Or (cheaper), Quickbooks just checks for "p=3D", and if so > overrides any company-specific config, and puts QuickBooks in From: > (with a working "p=3Dreject" policy, even!), "Your invoice = from > " in subject, and the company address in Reply-To. >=20 > Even supposing the company doesn't like either of those options, it's > not clear to me that the "p=3Dreject" domain is going to necessarily = be > happy trusting QuickBooks, even once TPA-Labels gets implemented. Placing the original =46rom and Subject in the message body would be = cleaner, but people will wonder what to believe with few tools to help = them sort through the confusion.=20 After having large numbers change providers, spoofing their prior = recipients from anywhere can now accompany very believable reasons, such = as "DMARC caused me to change to this provider...". Once TPA-Label is implemented by both sender and receivers applying = requested DMARC policy, nothing in between would need to change. No one = would be confused, and malefactors can be reliably blocked. >> I know of many small operations with similar services and >> previously working strategies. >=20 > Much less so the effort required to vette a million small operations > (who could actually be the Yahoo! customer requesting a TPA-label for > a vendor they use -- how does TPA-label deal with collusion between > authors and relays?) The number of Sender use cases would likely be in the thousands. There = would be no free lunch which is why our company has a large and trained = abuse staff. :^) Cases reported by DMARC feedback should be reviewed = in the same manner as any possible abuse would. In this case, the = source domain will have been validated. If there is any evidence of = abuse, they don't get authorized. I should have added scopes to indicate = a decision has been made to squelch further processing. 'x' for See = Abuse Desk. After that, blocked domains would need to contact the abuse = desk. I'll add that feature.=20 > So, yeah, I sympathize with the Mom & Pop shops whose kids go hungry > this month because the bills didn't go out, and with the small > operations tearing their hair out because they've got a thousand > paying customers at Yahoo! whose content isn't arriving at > destination, but I really don't see TPA-Labels as a solution to this > problem yet. In the case of Intuit, likely one TPA-Label would have solved the = problem once DMARC evaluation confirms with the _smtp._tpa zone. With = TPA-Label, kids won't go to sleep hungry. :^) >>> Again, I seem to require an additional clue. DMARC feedback is >>> working fine AFAICS. It may be costly, and we want to reduce those >>> costs, of course. But "p=3Dreject" OTOH is a more or less = legitimate >>> denial of service, a completely different issue. Are you talking >>> about a different kind of feedback? >>=20 >> Rather than having a channel only between receiver-to-sender, there >> should also be a channel between sender-to-receiver. >=20 > We already have such a channel (the _dmarc subdomain). What is this > new channel for? A single TXT record is hardly a reverse channel since it is unable to = communicate the necessary range of exceptions DMARC really needs. In = the case of PayPal and others, most initially made the mistake of = posting to various mailing lists. They should have responded to these = early signs a better scheme was needed to encompass actual use even when = devised for only transactional email. That was not always the case = then, and it clearly is not the case now. The TPA-Label, unlike SPF = does not chain together a sequence of TXT resource records. All = information is contained in a single small resource record at a single = unique label which would represent a negligible overhead in comparison. = Use of http would be much slower by adding a connection setup delay = without any caching. We need to find an expedient and quick to implement solution where most = of the burden is handled by the sender requesting the DMARC policy. That = is only fair. Regards, Douglas Otis From nobody Sat May 31 17:42:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71EB1A0150 for ; Sat, 31 May 2014 17:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNrxRifRPncG for ; Sat, 31 May 2014 17:42:30 -0700 (PDT) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 51ECF1A014D for ; Sat, 31 May 2014 17:42:30 -0700 (PDT) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5/8.14.5) with ESMTP id s510gOVD023280 for ; Sat, 31 May 2014 17:42:25 -0700 Received: from vpn-135-70-101-249.vpn.swst.att.com ([135.70.101.249]) by maillennium.att.com (mailgw1) with ESMTP id <20140601004222gw100j0c3ae>; Sun, 1 Jun 2014 00:42:24 +0000 X-Originating-IP: [135.70.101.249] Message-ID: <538A76ED.4050609@att.com> Date: Sat, 31 May 2014 20:42:21 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3YmApp4hC1Tb7wLaxhiS8rWhi1c Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jun 2014 00:42:32 -0000 Thanks for your comments Stephen. On 5/31/14, 1:51 PM, Stephen J. Turnbull wrote: > Tony Hansen writes: > > >> That doesn't help the DMARC situation now, but DMARC could be > >> given other options once that happens. > > > > I agree completely that a change to DMARC is needed in conjunction > > with having clear ML specs. > > A change to the protocol? What? I don't see it. The protocol > actually in use by many domains seems to actually do what it's > designed for quite well. "p=reject" makes a lot of sense for banks, > for example. I don't think it can be removed from the spec, and its > proper use doesn't cause widespread problems for mailing lists. > > It's use outside the design space that causes problems. Those uses > are by desperate organizations, and they'll ignore any change that > attempts to prohibit them because they are desperate. See further below. > > I've heard it said that the majority of the mailing lists out there > > are managed by only a handful of ML management systems. I maintain > > that these ML packages are in the same boat as openssl. It sure > > would be nice if we could get some of that consortium money thrown > > at that handful of ML management systems. > > I'm sorry, but that's nonsense for the volunteer-maintained MLMs like > GNU Mailman. That's okay -- it was just a thought. However, note that not all MLMs are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it might be useful. > We already have implemented multiple mitigations, and it > doesn't take much code. We just hate them all and leave it up to > mailing list operators to choose the one they dislike least. If other > MLMs haven't done so already, I doubt it involves all that much effort > for them. I would love to see that list of multiple mitigations shared with the broader community. That would be useful information for people in the IETF, as well as other MLM teams not involved wherever those discussions occurred. Perhaps there is one or more of those solutions that we SHOULD be recommending. Perhaps a broader discussion might come up with some additional better solutions. And perhaps broader discussions will provide an AHA moment where we see a way to solve BOTH MLM's problems AND DMARC's problems with MLMs in the face of a p=reject policies. Are the current p=reject semantics totally correct? As has been pointed out by others, even with mail sent out from banks, there are legitimate uses of mailing lists or things like mailing lists where you want copies to be received by multiple people. There might be an alternative to p=reject that we can come up with that *) WOULD work with mailing lists *) if mailing lists also were to take certain steps, and *) these organizations might be willing to switch to. Or alternatively, perhaps p=reject needs to be redefined slightly to take advantage of specific recommended practices for mailing lists. > > That's a political solution for this current technical problem. > > Mailing lists don't have a *technical* problem. If DMARC were used as > designed, we'd never have noticed. The problem is political: we have > a wounded 800-lb gorilla on the loose (not to forget a wounded 500-lb > gorilla joining the fun). > > > However, before it can happen: we NEED clear specs as to what > > should be done by ML systems, at least in the face of DKIM and SPF > > (and DMARC) > > SPF and DKIM are now ancient history, at least as far as Mailman > development goes. We've already done what's technically possible. Since I'm not privy yet to what all GNU Mailman has chosen to do in the face of SPF and DKIM, so I don't know how to evaluate that statement. Sorry. If you're saying that you've thrown out all use of DKIM, I consider that a sorry state of affairs. > We'll see what more our users want us to do about DMARC, if anything. > There just isn't anything technical to be done AFAICS. > > I can't speak for other MLMs, but I think that if there's going to be > real progress, the answer is with the MUAs. > > 1. If identity alignment fails, *all* links, scripts, and forms in the > message should be deactivated, even if it's already in the spam > folder. > > 2. If there's a type=password field in the message, *all* links and > forms in the message should be deactivated, even if it's already in > the spam folder. > > 3. Ditto misaligned MIME type and file name. > > 4. Ditto active or unknown attachments. > > 5. On activation of the message, all href and src URIs should be > displayed clearly, along with an intrusive warning that ID theft is > very common, so the user should check everything carefully > (preferably call the author on the phone) before doing anything > suggested by the message, even if it's already in the spam folder. > > I'm sure there are other things they could do, but those are off the > top of my head. > > Finally, Tim Draegen is right, it's not just about mailing lists. > Let's not forget all the other use cases that are stomped on by the > inappropriate use of "p=reject". I agree with all of the MUA comments. Tony Hansen > > Steve From nobody Sat May 31 21:26:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264861A0166 for ; Sat, 31 May 2014 21:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRPLeHUF-AKR for ; Sat, 31 May 2014 21:26:31 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770CF1A0085 for ; Sat, 31 May 2014 21:26:31 -0700 (PDT) Received: (qmail 6879 invoked from network); 1 Jun 2014 04:26:24 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Jun 2014 04:26:24 -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=b4f8.538aab70.k1405; i=johnl@user.iecc.com; bh=RUMkvb9LHIeAk1Ilt2QJVXvqCjIs7P/B6SZgqkXGEMY=; b=J8BSMh1Gx2Jf6ei4nAN2yVo9Uy7P5rEtrYLu0dmgVgWn1shCSwmqkCi8F2fa1mhOXVHVI/R2z+puPidWdszeOUDYPl8YK5VLppcyYVu6poFbMgkJkdI4zoPEk0pQducqS1NYV5V6CFBttxfBItKbQfIlcAHD5+63LpD3n6kwQgpCBdfC8VnY4xbRrBfwL8sj0lytdD8Ve6PD8lstVQvx1g1Jd363Y/FVgdt96FuvuJxZrGJdv+JCIWGop83jpF1a 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=b4f8.538aab70.k1405; olt=johnl@user.iecc.com; bh=RUMkvb9LHIeAk1Ilt2QJVXvqCjIs7P/B6SZgqkXGEMY=; b=XFYQoAkoPhtX7kTENO+3RR1d+QCX4D7bGdlxZmlaEklHAGqt5E9ex+u8+r7WWf0PVmfNdo1oqlpcLiwmyTKxJQJ0gGyT7tmn81UV3de7Bi/U25xY1BLj5wV8hj+2CRiDq88e0K5X/qPFl3jCtgeliLvlfobYT9O8r9pKZCSh7/bUaTg0FX/j9nVRWfcMoN4JUSDOVG31Tv3ZKIul75XagvGRcgUt9j+z5QHOVEXAqIKL/SBNwI8to6i5Xl2nt+P9 Date: 1 Jun 2014 04:26:01 -0000 Message-ID: <20140601042601.46327.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <538A76ED.4050609@att.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4avrulFt1wyBPbWnHrLkFVZ6Fx4 Cc: tony@att.com Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jun 2014 04:26:33 -0000 >That's okay -- it was just a thought. However, note that not all MLMs >are in as good a shape as GNU Mailman is, volunteer-wise. For *them*, it >might be useful. I wouldn't count on it. I did .invalid patches for majordomo2, which is largely abandonware but still used a fair number of places. People were surprisingly uninterested, one site said they had few enough AOL and Yahoo users that they just kicked them all off. From nobody Sat May 31 21:34:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1CF1A016B for ; Sat, 31 May 2014 21:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.062 X-Spam-Level: *** X-Spam-Status: No, score=3.062 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MANGLED_SPAM=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGRE7jvHSvAe for ; Sat, 31 May 2014 21:34:28 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD90E1A0169 for ; Sat, 31 May 2014 21:34:27 -0700 (PDT) Received: (qmail 7592 invoked from network); 1 Jun 2014 04:34:22 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 1 Jun 2014 04:34:22 -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=b520.538aad4e.k1405; i=johnl@user.iecc.com; bh=BYCAf2aqm8z4H3cl/f/V8KbRSyJIkg8HD2vXl6O+lVk=; b=gs4QpsRkf4Xj6dMWGUDyhwejmUsxVL8kcexKvqifOMZGg/FJxhJzHMfmC2j5fsAiX60B6ZMvxSiQCCfpVPd+p9MbqKEGFlva6+fUV5/VQCicdzRi83POGYJSBSUwDi7oK6RVAWrt6LZOe/M8e5T05W2jyndlGpjSA2Hsej9ip0NM4vMuBw9smMlSuFuKk7aYf//ifjmSO95eW8rpQuG8PK28gGepPbjd9Uu+ppaXV3x96C6+/dbYF2VUVvGnPKrr 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=b520.538aad4e.k1405; olt=johnl@user.iecc.com; bh=BYCAf2aqm8z4H3cl/f/V8KbRSyJIkg8HD2vXl6O+lVk=; b=X2Lg/xBpIIRPMWitN4tCys6RsN/WrTEDr3NaiIa9f3rWBdozBz4MJB261x9qp7HA5TlMMV44IahiHBHkHHt5GCQ8gSsusnWYM6H71kxzJQ+F30FLoY8Qm03QbtM/SiI/UZpgy4QeJJDcQzzXMu3hMzG1zrwMhn9LwxsdZ+qKIjzQk+yylWWB6NpmWz7pXlJX7QgTFEMgadie5FuR1Ta8va8NiNwnpeR4I6NLg+hCoGyWk6bj7uMfVYqVDtLI4UoP Date: 1 Jun 2014 04:34:00 -0000 Message-ID: <20140601043400.46367.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <538A76ED.4050609@att.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/sp3dgPDT8SoeI0pmS6suMEJmyv4 Cc: tony@att.com Subject: Re: [dmarc-ietf] DMARC mitigation techniques X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list 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, 01 Jun 2014 04:34:28 -0000 >I would love to see that list of multiple mitigations shared with the >broader community. That would be useful information for people in the >IETF, as well as other MLM teams not involved wherever those discussions >occurred. Your wish is our command: http://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail (The ASRG is dead, but the wiki lives on.) I'm sure I've missed some. Tell me what to add, or ask me for a password and you can edit it yourself. If you already have a password for the ASRG wiki, it should still work. R's, John